Re: [linux-pm] ehci_hcd related S3 lockup on ASUS laptops, again

Re: [linux-pm] ehci_hcd related S3 lockup on ASUS laptops, again

[Alan Stern]

On Sat, 21 Apr 2012, wrar wrote:

> > Okay, that's good.  I assume the device you plugged in then 
> > functioned
> > properly?
> 
> Yes.

All right.  Maybe you posted this information earlier in the thread, 
but it's easier to ask again than try to find it.  What output do you 
get from "lspci -nv -s 1a.0"?

Alan Stern

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [linux-pm] ehci_hcd related S3 lockup on ASUS laptops, again

[Andrey Rahmatullin]

[-- Attachment #1: Type: text/plain, Size: 795 bytes --]

On Sat, Apr 21, 2012 at 05:15:14PM -0400, Alan Stern wrote:
> > > Okay, that's good.  I assume the device you plugged in then 
> > > functioned
> > > properly?
> > 
> > Yes.
> 
> All right.  Maybe you posted this information earlier in the thread, 
> but it's easier to ask again than try to find it.  What output do you 
> get from "lspci -nv -s 1a.0"?
00:1a.0 0c03: 8086:1c2d (rev 05) (prog-if 20 [EHCI])
        Subsystem: 1043:1147
        Flags: bus master, medium devsel, latency 0, IRQ 16
        Memory at dfe08000 (32-bit, non-prefetchable) [size=1K]
        Capabilities: [50] Power Management version 2
        Capabilities: [58] Debug port: BAR=1 offset=00a0
        Capabilities: [98] PCI Advanced Features
        Kernel driver in use: ehci_hcd

-- 
WBR, wRAR

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [linux-pm] ehci_hcd related S3 lockup on ASUS laptops, again

[Alan Stern]

On Sun, 22 Apr 2012, Andrey Rahmatullin wrote:

> > All right.  Maybe you posted this information earlier in the thread, 
> > but it's easier to ask again than try to find it.  What output do you 
> > get from "lspci -nv -s 1a.0"?
> 00:1a.0 0c03: 8086:1c2d (rev 05) (prog-if 20 [EHCI])
>         Subsystem: 1043:1147
>         Flags: bus master, medium devsel, latency 0, IRQ 16
>         Memory at dfe08000 (32-bit, non-prefetchable) [size=1K]
>         Capabilities: [50] Power Management version 2
>         Capabilities: [58] Debug port: BAR=1 offset=00a0
>         Capabilities: [98] PCI Advanced Features
>         Kernel driver in use: ehci_hcd

Steve, what about you?  Do you get the same thing?

Alan Stern

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: ehci_hcd related S3 lockup on ASUS laptops, again

[Steven Rostedt]

On Mon, 2012-04-23 at 12:29 -0400, Alan Stern wrote:
> On Sun, 22 Apr 2012, Andrey Rahmatullin wrote:
> 
> > > All right.  Maybe you posted this information earlier in the thread, 
> > > but it's easier to ask again than try to find it.  What output do you 
> > > get from "lspci -nv -s 1a.0"?
> > 00:1a.0 0c03: 8086:1c2d (rev 05) (prog-if 20 [EHCI])
> >         Subsystem: 1043:1147
> >         Flags: bus master, medium devsel, latency 0, IRQ 16
> >         Memory at dfe08000 (32-bit, non-prefetchable) [size=1K]
> >         Capabilities: [50] Power Management version 2
> >         Capabilities: [58] Debug port: BAR=1 offset=00a0
> >         Capabilities: [98] PCI Advanced Features
> >         Kernel driver in use: ehci_hcd
> 
> Steve, what about you?  Do you get the same thing?
> 

00:1a.0 0c03: 8086:1c2d (rev 05) (prog-if 20 [EHCI])
	Subsystem: 1043:1157
	Flags: bus master, medium devsel, latency 0, IRQ 16
	Memory at dfc08000 (32-bit, non-prefetchable) [size=1K]
	Capabilities: [50] Power Management version 2
	Capabilities: [58] Debug port: BAR=1 offset=00a0
	Capabilities: [98] PCI Advanced Features
	Kernel driver in use: ehci_hcd

Almost, the Subsystem is 1157 instead of 1147. But the rest looks alike.

-- Steve

Re: [linux-pm] ehci_hcd related S3 lockup on ASUS laptops, again

[Alan Stern]

On Mon, 23 Apr 2012, Steven Rostedt wrote:

> On Mon, 2012-04-23 at 12:29 -0400, Alan Stern wrote:
> > On Sun, 22 Apr 2012, Andrey Rahmatullin wrote:
> > 
> > > > All right.  Maybe you posted this information earlier in the thread, 
> > > > but it's easier to ask again than try to find it.  What output do you 
> > > > get from "lspci -nv -s 1a.0"?
> > > 00:1a.0 0c03: 8086:1c2d (rev 05) (prog-if 20 [EHCI])
> > >         Subsystem: 1043:1147
> > >         Flags: bus master, medium devsel, latency 0, IRQ 16
> > >         Memory at dfe08000 (32-bit, non-prefetchable) [size=1K]
> > >         Capabilities: [50] Power Management version 2
> > >         Capabilities: [58] Debug port: BAR=1 offset=00a0
> > >         Capabilities: [98] PCI Advanced Features
> > >         Kernel driver in use: ehci_hcd
> > 
> > Steve, what about you?  Do you get the same thing?
> > 
> 
> 00:1a.0 0c03: 8086:1c2d (rev 05) (prog-if 20 [EHCI])
> 	Subsystem: 1043:1157
> 	Flags: bus master, medium devsel, latency 0, IRQ 16
> 	Memory at dfc08000 (32-bit, non-prefetchable) [size=1K]
> 	Capabilities: [50] Power Management version 2
> 	Capabilities: [58] Debug port: BAR=1 offset=00a0
> 	Capabilities: [98] PCI Advanced Features
> 	Kernel driver in use: ehci_hcd
> 
> Almost, the Subsystem is 1157 instead of 1147. But the rest looks alike.

I don't have a very clear idea of how specific this needs to be.  There 
have been other bug reports of problems related to suspend that were 
fixed by the same script you were using, but the symptoms weren't the 
same.  For example, see Bugzilla #42728.

Anyway, this patch is reasonably close to being a final version, and it
should work on both machines.  You should be able to suspend and resume
with no problems, without using the script.

Alan Stern




Index: usb-3.4/include/linux/usb/hcd.h
===================================================================
--- usb-3.4.orig/include/linux/usb/hcd.h
+++ usb-3.4/include/linux/usb/hcd.h
@@ -126,6 +126,8 @@ struct usb_hcd {
 	unsigned		wireless:1;	/* Wireless USB HCD */
 	unsigned		authorized_default:1;
 	unsigned		has_tt:1;	/* Integrated TT in root hub */
+	unsigned		broken_pci_sleep:1;	/* Don't put the
+			controller in PCI-D3 for system sleep */
 
 	unsigned int		irq;		/* irq allocated */
 	void __iomem		*regs;		/* device memory/io */
Index: usb-3.4/drivers/usb/core/hcd-pci.c
===================================================================
--- usb-3.4.orig/drivers/usb/core/hcd-pci.c
+++ usb-3.4/drivers/usb/core/hcd-pci.c
@@ -493,6 +493,15 @@ static int hcd_pci_suspend_noirq(struct
 
 	pci_save_state(pci_dev);
 
+	/*
+	 * Some systems crash if an EHCI controller is in D3 during
+	 * a sleep transition.  We have to leave such controllers in D0.
+	 */
+	if (hcd->broken_pci_sleep) {
+		dev_dbg(dev, "Staying in PCI D0\n");
+		return retval;
+	}
+
 	/* If the root hub is dead rather than suspended, disallow remote
 	 * wakeup.  usb_hc_died() should ensure that both hosts are marked as
 	 * dying, so we only need to check the primary roothub.
Index: usb-3.4/drivers/usb/host/ehci-pci.c
===================================================================
--- usb-3.4.orig/drivers/usb/host/ehci-pci.c
+++ usb-3.4/drivers/usb/host/ehci-pci.c
@@ -144,6 +144,13 @@ static int ehci_pci_setup(struct usb_hcd
 			hcd->has_tt = 1;
 			tdi_reset(ehci);
 		}
+		if (pdev->subsystem_vendor == PCI_VENDOR_ID_ASUSTEK) {
+			/* EHCI #1 or #2 on 6 Series/C200 Series chipset */
+			if (pdev->device == 0x1c26 || pdev->device == 0x1c2d) {
+				ehci_info(ehci, "broken D3 during system sleep on ASUS\n");
+				hcd->broken_pci_sleep = 1;
+			}
+		}
 		break;
 	case PCI_VENDOR_ID_TDI:
 		if (pdev->device == PCI_DEVICE_ID_TDI_EHCI) {

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [linux-pm] ehci_hcd related S3 lockup on ASUS laptops, again

[Steven Rostedt]

On Mon, 2012-04-23 at 16:11 -0400, Alan Stern wrote:

> I don't have a very clear idea of how specific this needs to be.  There 
> have been other bug reports of problems related to suspend that were 
> fixed by the same script you were using, but the symptoms weren't the 
> same.  For example, see Bugzilla #42728.
> 
> Anyway, this patch is reasonably close to being a final version, and it
> should work on both machines.  You should be able to suspend and resume
> with no problems, without using the script.
> 

Tested-by: Steven Rostedt <rostedt-nx8X9YLhiw1AfugRpC6u6w@public.gmane.org>

Thanks!

-- Steve


--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [linux-pm] ehci_hcd related S3 lockup on ASUS laptops, again

[Andrey Rahmatullin]

[-- Attachment #1: Type: text/plain, Size: 625 bytes --]

On Mon, Apr 23, 2012 at 04:11:48PM -0400, Alan Stern wrote:
> I don't have a very clear idea of how specific this needs to be.  There 
> have been other bug reports of problems related to suspend that were 
> fixed by the same script you were using, but the symptoms weren't the 
> same.  For example, see Bugzilla #42728.
> 
> Anyway, this patch is reasonably close to being a final version, and it
> should work on both machines.  You should be able to suspend and resume
> with no problems, without using the script.
Tested-by: Andrey Rahmatullin <wrar-Bxt/JK/G85ezQB+pC5nmwQ@public.gmane.org>

-- 
WBR, wRAR

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [linux-pm] ehci_hcd related S3 lockup on ASUS laptops, again

[Steven Rostedt]

On Thu, 2012-04-19 at 12:22 -0400, Steven Rostedt wrote:

> I removed all previous patches and added this one. But without the
> script, it locks up again in suspend.
> 
> I'll rebuild again just to make sure I didn't screw something up.

Rebuilt with mrproper, and confirming the patch was added.

It still locked up. But, I looked at your patch and mine and realized
that mine applied with some "FUZZ".

Mine:

@@ -1723,6 +1723,8 @@ int pci_finish_runtime_suspend(struct pci_dev *dev)
        pci_power_t target_state = pci_target_state(dev);
        int error;
 
+       if (1)
+               target_state = PCI_D0;
        if (target_state == PCI_POWER_ERROR)
                return -EIO;

Yours:

@@ -1713,6 +1713,8 @@ int pci_prepare_to_sleep(struct pci_dev
        pci_power_t target_state = pci_target_state(dev);
        int error;
 
+       if (1)
+               target_state = PCI_D0;
        if (target_state == PCI_POWER_ERROR)
                return -EIO;

Mine applied to pci_finish_runtime_suspend not pci_prepare_to_sleep :-p
I'm using 3.2.5.

/me fixes, recompiles and retests

-- Steve


--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: ehci_hcd related S3 lockup on ASUS laptops, again

[Alan Stern]

On Thu, 19 Apr 2012, Steven Rostedt wrote:

> Rebuilt with mrproper, and confirming the patch was added.
> 
> It still locked up. But, I looked at your patch and mine and realized
> that mine applied with some "FUZZ".
> 
> Mine:
> 
> @@ -1723,6 +1723,8 @@ int pci_finish_runtime_suspend(struct pci_dev *dev)
>         pci_power_t target_state = pci_target_state(dev);
>         int error;
>  
> +       if (1)
> +               target_state = PCI_D0;
>         if (target_state == PCI_POWER_ERROR)
>                 return -EIO;
> 
> Yours:
> 
> @@ -1713,6 +1713,8 @@ int pci_prepare_to_sleep(struct pci_dev
>         pci_power_t target_state = pci_target_state(dev);
>         int error;
>  
> +       if (1)
> +               target_state = PCI_D0;
>         if (target_state == PCI_POWER_ERROR)
>                 return -EIO;
> 
> Mine applied to pci_finish_runtime_suspend not pci_prepare_to_sleep :-p
> I'm using 3.2.5.

Whoops!  That'll do it.  The names say it all: one routine is used for
runtime PM and the other is used for system sleep.  The two functions
are very similar, so naturally "patch" got confused.

Alan Stern

Re: [linux-pm] ehci_hcd related S3 lockup on ASUS laptops, again

[Andrey Rahmatullin]

[-- Attachment #1: Type: text/plain, Size: 1652 bytes --]

On Thu, Apr 19, 2012 at 09:43:45AM -0400, Alan Stern wrote:
> Below is a patch that will prevent any PCI device from being put into
> D3 during suspend.  (This is meant to be used without any of the
> earlier diagnostic patches.)  Obviously it's not the final solution; 
> the test in the "if" statement needs to be more discriminating.  :-)
> 
> But before going any farther, I'd like to test if USB wakeup works.  
> So after booting with this patch, make sure that the power/wakeup file
> says "enabled" in the sysfs path for each controller as well as the
> usb1, usb2, 1-2, and 2-2 paths under /sys/bus/usb/devices/.
> 
> Then suspend the computer without using the script, and while it is
> asleep try plugging in a new USB device.  That should cause the
> computer to wake up, if everything is working properly.
I've set "enabled" for following files:

/sys/bus/usb/devices/usb1/power/wakeup
/sys/bus/usb/devices/usb2/power/wakeup
/sys/bus/usb/devices/1-1/power/wakeup
/sys/bus/usb/devices/2-1/power/wakeup
/sys/bus/pci/devices/0000:00:1a.0/power/wakeup
/sys/bus/pci/devices/0000:00:1d.0/power/wakeup

yet it didn't wake up after plugging, though devices light up.


> Index: usb-3.4/drivers/pci/pci.c
> ===================================================================
> --- usb-3.4.orig/drivers/pci/pci.c
> +++ usb-3.4/drivers/pci/pci.c
> @@ -1713,6 +1713,8 @@ int pci_prepare_to_sleep(struct pci_dev
>  	pci_power_t target_state = pci_target_state(dev);
>  	int error;
>  
> +	if (1)
> +		target_state = PCI_D0;
>  	if (target_state == PCI_POWER_ERROR)
>  		return -EIO;
>  
> 
> 

-- 
WBR, wRAR

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [linux-pm] ehci_hcd related S3 lockup on ASUS laptops, again

[Alan Stern]

On Thu, 19 Apr 2012, Andrey Rahmatullin wrote:

> On Thu, Apr 19, 2012 at 09:43:45AM -0400, Alan Stern wrote:
> > Below is a patch that will prevent any PCI device from being put into
> > D3 during suspend.  (This is meant to be used without any of the
> > earlier diagnostic patches.)  Obviously it's not the final solution; 
> > the test in the "if" statement needs to be more discriminating.  :-)
> > 
> > But before going any farther, I'd like to test if USB wakeup works.  
> > So after booting with this patch, make sure that the power/wakeup file
> > says "enabled" in the sysfs path for each controller as well as the
> > usb1, usb2, 1-2, and 2-2 paths under /sys/bus/usb/devices/.
> > 
> > Then suspend the computer without using the script, and while it is
> > asleep try plugging in a new USB device.  That should cause the
> > computer to wake up, if everything is working properly.
> I've set "enabled" for following files:
> 
> /sys/bus/usb/devices/usb1/power/wakeup
> /sys/bus/usb/devices/usb2/power/wakeup
> /sys/bus/usb/devices/1-1/power/wakeup
> /sys/bus/usb/devices/2-1/power/wakeup
> /sys/bus/pci/devices/0000:00:1a.0/power/wakeup
> /sys/bus/pci/devices/0000:00:1d.0/power/wakeup

Good.

> yet it didn't wake up after plugging, though devices light up.

You mean, the devices that you plug in light up?

I'd like to see the dmesg log for the complete suspend/resume cycle 
(naturally you'll have to resume the system by hand after plugging in 
the USB device).  Make sure that CONFIG_USB_DEBUG is enabled.

Alan Stern

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: ehci_hcd related S3 lockup on ASUS laptops, again

[Andrey Rahmatullin]

[-- Attachment #1.1.1: Type: text/plain, Size: 1638 bytes --]

On Thu, Apr 19, 2012 at 02:07:47PM -0400, Alan Stern wrote:
> > > Below is a patch that will prevent any PCI device from being put into
> > > D3 during suspend.  (This is meant to be used without any of the
> > > earlier diagnostic patches.)  Obviously it's not the final solution; 
> > > the test in the "if" statement needs to be more discriminating.  :-)
> > > 
> > > But before going any farther, I'd like to test if USB wakeup works.  
> > > So after booting with this patch, make sure that the power/wakeup file
> > > says "enabled" in the sysfs path for each controller as well as the
> > > usb1, usb2, 1-2, and 2-2 paths under /sys/bus/usb/devices/.
> > > 
> > > Then suspend the computer without using the script, and while it is
> > > asleep try plugging in a new USB device.  That should cause the
> > > computer to wake up, if everything is working properly.
> > I've set "enabled" for following files:
> > 
> > /sys/bus/usb/devices/usb1/power/wakeup
> > /sys/bus/usb/devices/usb2/power/wakeup
> > /sys/bus/usb/devices/1-1/power/wakeup
> > /sys/bus/usb/devices/2-1/power/wakeup
> > /sys/bus/pci/devices/0000:00:1a.0/power/wakeup
> > /sys/bus/pci/devices/0000:00:1d.0/power/wakeup
> 
> Good.
> 
> > yet it didn't wake up after plugging, though devices light up.
> 
> You mean, the devices that you plug in light up?
Yes. An mp3 player and a flash drive.

> I'd like to see the dmesg log for the complete suspend/resume cycle 
> (naturally you'll have to resume the system by hand after plugging in 
> the USB device).  Make sure that CONFIG_USB_DEBUG is enabled.
Attached.


-- 
WBR, wRAR

[-- Attachment #1.1.2: dmesg --]
[-- Type: text/plain, Size: 15676 bytes --]

[  145.122398] PM: Syncing filesystems ... done.
[  146.095904] PM: Preparing system for mem sleep
[  146.110135] Freezing user space processes ... (elapsed 0.01 seconds) done.
[  146.121637] Freezing remaining freezable tasks ... (elapsed 0.01 seconds) done.
[  146.132804] PM: Entering mem sleep
[  146.140388] sd 0:0:0:0: [sda] Synchronizing SCSI cache
[  146.188114] sd 0:0:0:0: [sda] Stopping disk
[  146.569462] PM: suspend of devices complete after 436.593 msecs
[  146.569638] PM: late suspend of devices complete after 0.154 msecs
[  146.570125] ehci_hcd 0000:00:1d.0: wakeup: 1
[  146.570159] ehci_hcd 0000:00:1d.0: wake-up capability enabled by ACPI
[  146.570172] ehci_hcd 0000:00:1d.0: --> PCI D0
[  146.570234] ehci_hcd 0000:00:1a.0: wakeup: 1
[  146.570251] ehci_hcd 0000:00:1a.0: wake-up capability enabled by ACPI
[  146.570288] ehci_hcd 0000:00:1a.0: --> PCI D0
[  146.570399] PM: noirq suspend of devices complete after 0.747 msecs
[  146.571068] ACPI: Preparing to enter system sleep state S3
[  146.588943] ------------[ cut here ]------------
[  146.588995] WARNING: at drivers/gpu/drm/i915/i915_drv.c:398 gen6_gt_check_fifodbg.isra.5+0x31/0x44 [i915]()
[  146.589010] Hardware name: K53E
[  146.589017] MMIO read or write has been dropped ffffffff
[  146.589026] Modules linked in: aes_x86_64 aes_generic af_packet cpufreq_userspace cpufreq_stats cpufreq_powersave cpufreq_ondemand rfcomm bnep uinput fuse nfsd nfs nfs_acl auth_rpcgss fscache lockd sunrpc ipv6 snd_hda_codec_hdmi snd_hda_codec_realtek btusb bluetooth uvcvideo videobuf2_vmalloc snd_hda_intel videobuf2_memops snd_hda_codec videobuf2_core videodev snd_hwdep crc16 snd_pcm arc4 snd_page_alloc ath9k snd_seq_midi snd_seq_midi_event snd_rawmidi ath9k_common ath9k_hw ath mac80211 snd_seq acpi_cpufreq mperf freq_table joydev i915 asus_nb_wmi asus_wmi sparse_keymap pci_hotplug i2c_algo_bit drm_kms_helper i2c_i801 drm cfg80211 processor evdev battery wmi button i2c_core intel_agp intel_gtt psmouse video backlight snd_seq_device coretemp crc32c_intel ac agpgart snd_timer snd soundcore dm_mod ehci_hcd sr_mod cdrom usbcore usb_common atl1c thermal thermal_sys hwmon [last unloaded: scsi_wait_scan]
[  146.589261] Pid: 2880, comm: kworker/u:11 Not tainted 3.4.0-rc2-wrar-sabine-8+ #18
[  146.589273] Call Trace:
[  146.589294]  [<ffffffff8102a5e1>] warn_slowpath_common+0x7e/0x96
[  146.589310]  [<ffffffff8102a68d>] warn_slowpath_fmt+0x41/0x43
[  146.589337]  [<ffffffffa02143b7>] gen6_gt_check_fifodbg.isra.5+0x31/0x44 [i915]
[  146.589365]  [<ffffffffa021462e>] __gen6_gt_force_wake_put+0x19/0x1b [i915]
[  146.589392]  [<ffffffffa0214884>] i915_read32+0x61/0x82 [i915]
[  146.589433]  [<ffffffffa022e111>] ? intel_disable_plane+0x60/0x60 [i915]
[  146.589462]  [<ffffffffa02167ea>] i915_update_gfx_val+0x61/0xb9 [i915]
[  146.589500]  [<ffffffffa022e156>] intel_idle_update+0x45/0x18b [i915]
[  146.589518]  [<ffffffff810463d1>] ? need_resched+0x1e/0x28
[  146.589551]  [<ffffffffa022e111>] ? intel_disable_plane+0x60/0x60 [i915]
[  146.589569]  [<ffffffff8103c292>] process_one_work+0x13c/0x21e
[  146.589585]  [<ffffffff8103cb93>] worker_thread+0xce/0x152
[  146.589600]  [<ffffffff8103cac5>] ? manage_workers.isra.28+0x16c/0x16c
[  146.589614]  [<ffffffff8103ffab>] kthread+0x86/0x8e
[  146.589629]  [<ffffffff812f2094>] kernel_thread_helper+0x4/0x10
[  146.589644]  [<ffffffff8103ff25>] ? kthread_freezable_should_stop+0x3e/0x3e
[  146.589658]  [<ffffffff812f2090>] ? gs_change+0xb/0xb
[  146.589668] ---[ end trace d4f42eb8f9f0177b ]---
[  146.590280] ------------[ cut here ]------------
[  146.590302] WARNING: at drivers/gpu/drm/i915/i915_drv.c:398 gen6_gt_check_fifodbg.isra.5+0x31/0x44 [i915]()
[  146.590315] Hardware name: K53E
[  146.590322] MMIO read or write has been dropped ffffffff
[  146.590330] Modules linked in: aes_x86_64 aes_generic af_packet cpufreq_userspace cpufreq_stats cpufreq_powersave cpufreq_ondemand rfcomm bnep uinput fuse nfsd nfs nfs_acl auth_rpcgss fscache lockd sunrpc ipv6 snd_hda_codec_hdmi snd_hda_codec_realtek btusb bluetooth uvcvideo videobuf2_vmalloc snd_hda_intel videobuf2_memops snd_hda_codec videobuf2_core videodev snd_hwdep crc16 snd_pcm arc4 snd_page_alloc ath9k snd_seq_midi snd_seq_midi_event snd_rawmidi ath9k_common ath9k_hw ath mac80211 snd_seq acpi_cpufreq mperf freq_table joydev i915 asus_nb_wmi asus_wmi sparse_keymap pci_hotplug i2c_algo_bit drm_kms_helper i2c_i801 drm cfg80211 processor evdev battery wmi button i2c_core intel_agp intel_gtt psmouse video backlight snd_seq_device coretemp crc32c_intel ac agpgart snd_timer snd soundcore dm_mod ehci_hcd sr_mod cdrom usbcore usb_common atl1c thermal thermal_sys hwmon [last unloaded: scsi_wait_scan]
[  146.590551] Pid: 2880, comm: kworker/u:11 Tainted: G        W    3.4.0-rc2-wrar-sabine-8+ #18
[  146.590563] Call Trace:
[  146.590576]  [<ffffffff8102a5e1>] warn_slowpath_common+0x7e/0x96
[  146.590590]  [<ffffffff8102a68d>] warn_slowpath_fmt+0x41/0x43
[  146.590614]  [<ffffffffa02143b7>] gen6_gt_check_fifodbg.isra.5+0x31/0x44 [i915]
[  146.590639]  [<ffffffffa021462e>] __gen6_gt_force_wake_put+0x19/0x1b [i915]
[  146.590664]  [<ffffffffa0214884>] i915_read32+0x61/0x82 [i915]
[  146.590696]  [<ffffffffa022e1ae>] intel_idle_update+0x9d/0x18b [i915]
[  146.590728]  [<ffffffffa022e111>] ? intel_disable_plane+0x60/0x60 [i915]
[  146.590744]  [<ffffffff8103c292>] process_one_work+0x13c/0x21e
[  146.590758]  [<ffffffff8103cb93>] worker_thread+0xce/0x152
[  146.590772]  [<ffffffff8103cac5>] ? manage_workers.isra.28+0x16c/0x16c
[  146.590786]  [<ffffffff8103ffab>] kthread+0x86/0x8e
[  146.590797]  [<ffffffff812f2094>] kernel_thread_helper+0x4/0x10
[  146.590810]  [<ffffffff8103ff25>] ? kthread_freezable_should_stop+0x3e/0x3e
[  146.590823]  [<ffffffff812f2090>] ? gs_change+0xb/0xb
[  146.590832] ---[ end trace d4f42eb8f9f0177c ]---
[  146.644755] PM: Saving platform NVS memory
[  146.649445] Disabling non-boot CPUs ...
[  146.651233] CPU 1 is now offline
[  146.654012] CPU 2 is now offline
[  146.656592] CPU 3 is now offline
[  146.657317] Extended CMOS year: 2000
[  146.658682] ACPI: Low-level resume complete
[  146.658728] PM: Restoring platform NVS memory
[  146.659118] Extended CMOS year: 2000
[  146.659141] Enabling non-boot CPUs ...
[  146.660262] Booting Node 0 Processor 1 APIC 0x2
[  146.674899] CPU1 is up
[  146.675071] Booting Node 0 Processor 2 APIC 0x1
[  146.689611] CPU2 is up
[  146.689735] Booting Node 0 Processor 3 APIC 0x3
[  146.704075] CPU3 is up
[  146.707254] ACPI: Waking up from system sleep state S3
[  147.297244] ehci_hcd 0000:00:1a.0: wake-up capability disabled by ACPI
[  147.333090] power_supply BAT0: parent PNP0C0A:00 should not be sleeping
[  147.458847] ehci_hcd 0000:00:1d.0: wake-up capability disabled by ACPI
[  147.559435] PM: noirq resume of devices complete after 432.678 msecs
[  147.559694] PM: early resume of devices complete after 0.106 msecs
[  147.559822] i915 0000:00:02.0: setting latency timer to 64
[  147.559840] ehci_hcd 0000:00:1a.0: setting latency timer to 64
[  147.559880] usb usb1: root hub lost power or was reset
[  147.559906] ehci_hcd 0000:00:1a.0: reset command 0080002 (park)=0 ithresh=8 period=1024 Reset HALT
[  147.559930] snd_hda_intel 0000:00:1b.0: irq 45 for MSI/MSI-X
[  147.560048] ehci_hcd 0000:00:1d.0: setting latency timer to 64
[  147.560054] ahci 0000:00:1f.2: setting latency timer to 64
[  147.560071] usb usb2: root hub lost power or was reset
[  147.560085] ehci_hcd 0000:00:1d.0: reset command 0080002 (park)=0 ithresh=8 period=1024 Reset HALT
[  147.563800] ehci_hcd 0000:00:1a.0: cache line size of 64 is not supported
[  147.563820] usb usb1: usb resume
[  147.563828] ehci_hcd 0000:00:1a.0: resume root hub after power loss
[  147.564282] ehci_hcd 0000:00:1d.0: cache line size of 64 is not supported
[  147.564819] usb usb2: usb resume
[  147.564826] ehci_hcd 0000:00:1d.0: resume root hub after power loss
[  147.583553] hub 1-0:1.0: hub_reset_resume
[  147.583559] hub 1-0:1.0: trying to enable port power on non-switchable hub
[  147.584563] hub 2-0:1.0: hub_reset_resume
[  147.584572] hub 2-0:1.0: trying to enable port power on non-switchable hub
[  147.641086] [drm] Enabling RC6 states: RC6 on, RC6p off, RC6pp off
[  147.650114] atl1c 0000:03:00.0: irq 46 for MSI/MSI-X
[  147.684584] ehci_hcd 0000:00:1a.0: GetStatus port:1 status 001803 0  ACK POWER sig=j CSC CONNECT
[  147.684602] hub 1-0:1.0: port 1: status 0501 change 0001
[  147.685571] ehci_hcd 0000:00:1d.0: GetStatus port:1 status 001803 0  ACK POWER sig=j CSC CONNECT
[  147.685583] hub 2-0:1.0: port 1: status 0501 change 0001
[  147.785577] usb 1-1: finish reset-resume
[  147.786555] usb 2-1: finish reset-resume
[  147.836698] ehci_hcd 0000:00:1a.0: port 1 high speed
[  147.836714] ehci_hcd 0000:00:1a.0: GetStatus port:1 status 001005 0  ACK POWER sig=se0 PE CONNECT
[  147.875482] ata3: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
[  147.877791] ata3.00: ACPI cmd ef/10:06:00:00:00:a0 (SET FEATURES) succeeded
[  147.877811] ata3.00: ACPI cmd ef/10:03:00:00:00:a0 (SET FEATURES) filtered out
[  147.881892] ata3.00: ACPI cmd ef/10:06:00:00:00:a0 (SET FEATURES) succeeded
[  147.881912] ata3.00: ACPI cmd ef/10:03:00:00:00:a0 (SET FEATURES) filtered out
[  147.883449] ata3.00: configured for UDMA/100
[  147.887485] usb 1-1: reset high-speed USB device number 2 using ehci_hcd
[  147.938648] ehci_hcd 0000:00:1a.0: port 1 high speed
[  147.938664] ehci_hcd 0000:00:1a.0: GetStatus port:1 status 001005 0  ACK POWER sig=se0 PE CONNECT
[  148.001587] ehci_hcd 0000:00:1a.0: set dev address 2 for port 1
[  148.001598] ehci_hcd 0000:00:1a.0: LPM: no device attached
[  148.002062] hub 1-1:1.0: hub_reset_resume
[  148.002071] hub 1-1:1.0: enabling power on all ports
[  148.052711] ehci_hcd 0000:00:1d.0: port 1 high speed
[  148.052727] ehci_hcd 0000:00:1d.0: GetStatus port:1 status 001005 0  ACK POWER sig=se0 PE CONNECT
[  148.103404] usb 2-1: reset high-speed USB device number 2 using ehci_hcd
[  148.104514] hub 1-1:1.0: port 1: status 0101 change 0001
[  148.104888] hub 1-1:1.0: port 2: status 0101 change 0001
[  148.160530] ehci_hcd 0000:00:1d.0: port 1 high speed
[  148.160546] ehci_hcd 0000:00:1d.0: GetStatus port:1 status 001005 0  ACK POWER sig=se0 PE CONNECT
[  148.206372] usb 1-1: link qh256-0001/ffff88013a93ed00 start 3 [1/0 us]
[  148.206557] usb 1-1.2: finish reset-resume
[  148.206858] usb 1-1.1: finish reset-resume
[  148.223468] ehci_hcd 0000:00:1d.0: set dev address 2 for port 1
[  148.223480] ehci_hcd 0000:00:1d.0: LPM: no device attached
[  148.224226] hub 2-1:1.0: hub_reset_resume
[  148.224235] hub 2-1:1.0: enabling power on all ports
[  148.234465] hub 1-1:1.0: port 2 not reset yet, waiting 10ms
[  148.296583] usb 1-1.2: reset high-speed USB device number 4 using ehci_hcd
[  148.325925] hub 2-1:1.0: port 3: status 0101 change 0001
[  148.388528] hub 1-1:1.0: port 1 not reset yet, waiting 10ms
[  148.427243] usb 2-1: link qh256-0001/ffff88013a93e400 start 2 [1/0 us]
[  148.450517] usb 1-1.1: reset full-speed USB device number 3 using ehci_hcd
[  148.467506] hub 1-1:1.0: port 1 not reset yet, waiting 10ms
[  149.457684] ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
[  149.465889] ata1.00: ACPI cmd f5/00:00:00:00:00:a0 (SECURITY FREEZE LOCK) filtered out
[  149.472303] ata1.00: ACPI cmd ef/10:06:00:00:00:a0 (SET FEATURES) succeeded
[  149.472312] ata1.00: ACPI cmd ef/10:03:00:00:00:a0 (SET FEATURES) filtered out
[  149.482789] ata1.00: ACPI cmd f5/00:00:00:00:00:a0 (SECURITY FREEZE LOCK) filtered out
[  149.489164] ata1.00: ACPI cmd ef/10:06:00:00:00:a0 (SET FEATURES) succeeded
[  149.489176] ata1.00: ACPI cmd ef/10:03:00:00:00:a0 (SET FEATURES) filtered out
[  149.496961] ata1.00: configured for UDMA/133
[  149.502899] sd 0:0:0:0: [sda] Starting disk
[  149.559598] PM: resume of devices complete after 2000.913 msecs
[  149.619233] PM: Finishing wakeup.
[  149.619241] Restarting tasks ... 
[  149.619442] hub 1-0:1.0: state 7 ports 2 chg 0002 evt 0000
[  149.624455] done.
[  149.632672] hub 1-0:1.0: port 1, status 0503, change 0000, 480 Mb/s
[  149.632686] hub 2-0:1.0: state 7 ports 2 chg 0002 evt 0000
[  149.632699] hub 2-0:1.0: port 1, status 0503, change 0000, 480 Mb/s
[  149.632707] hub 1-1:1.0: state 7 ports 6 chg 0006 evt 0004
[  149.632817] hub 1-1:1.0: port 1, status 0103, change 0000, 12 Mb/s
[  149.632960] hub 1-1:1.0: port 2, status 0503, change 0000, 480 Mb/s
[  149.632974] hub 2-1:1.0: state 7 ports 6 chg 0008 evt 0000
[  149.633205] hub 2-1:1.0: port 3, status 0101, change 0000, 12 Mb/s
[  149.643682] hub 2-1:1.0: port 3 not reset yet, waiting 10ms
[  149.705688] usb 2-1.3: new high-speed USB device number 3 using ehci_hcd
[  149.720119] video LNXVIDEO:01: Restoring backlight state
[  149.790209] usb 2-1.3: default language 0x0409
[  149.790751] usb 2-1.3: udev 3, busnum 2, minor = 130
[  149.790761] usb 2-1.3: New USB device found, idVendor=04e8, idProduct=5133
[  149.790907] usb 2-1.3: New USB device strings: Mfr=1, Product=2, SerialNumber=5
[  149.791051] usb 2-1.3: Product: YP-U6
[  149.791127] usb 2-1.3: Manufacturer: Samsung Electronics
[  149.791234] usb 2-1.3: SerialNumber: 38F5000001B1241C0002DCE4D908E41C
[  149.791902] usb 2-1.3: usb_probe_device
[  149.791911] usb 2-1.3: configuration #1 chosen from 2 choices
[  149.792207] usb 2-1.3: adding 2-1.3:1.0 (config #1, interface 0)
[  149.925318] uas 2-1.3:1.0: usb_probe_interface
[  149.925328] uas 2-1.3:1.0: usb_probe_interface - got id
[  149.925422] usbcore: registered new interface driver uas
[  149.936863] libusual 2-1.3:1.0: usb_probe_interface
[  149.936877] libusual 2-1.3:1.0: usb_probe_interface - got id
[  149.936996] usbcore: registered new interface driver libusual
[  149.958603] Initializing USB Mass Storage driver...
[  149.958802] usb-storage 2-1.3:1.0: usb_probe_interface
[  149.958816] usb-storage 2-1.3:1.0: usb_probe_interface - got id
[  149.958931] scsi6 : usb-storage 2-1.3:1.0
[  149.959189] usbcore: registered new interface driver usb-storage
[  149.959309] USB Mass Storage support registered.
[  150.962927] scsi 6:0:0:0: Direct-Access     Samsung  YP-U6            0100 PQ: 0 ANSI: 4
[  150.965186] sd 6:0:0:0: [sdb] 1889152 2048-byte logical blocks: (3.86 GB/3.60 GiB)
[  150.966136] sd 6:0:0:0: [sdb] Write Protect is off
[  150.966271] sd 6:0:0:0: [sdb] Mode Sense: 3e 00 00 00
[  150.966875] sd 6:0:0:0: [sdb] No Caching mode page present
[  150.967020] sd 6:0:0:0: [sdb] Assuming drive cache: write through
[  150.968497] sd 6:0:0:0: [sdb] 1889152 2048-byte logical blocks: (3.86 GB/3.60 GiB)
[  150.969732] sd 6:0:0:0: [sdb] No Caching mode page present
[  150.969897] sd 6:0:0:0: [sdb] Assuming drive cache: write through
[  150.972374]  sdb: sdb1
[  150.974025] sd 6:0:0:0: [sdb] 1889152 2048-byte logical blocks: (3.86 GB/3.60 GiB)
[  150.975232] sd 6:0:0:0: [sdb] No Caching mode page present
[  150.979258] sd 6:0:0:0: [sdb] Assuming drive cache: write through
[  150.983262] sd 6:0:0:0: [sdb] Attached SCSI removable disk
[  150.994014] usb 1-1.1: usb auto-suspend, wakeup 0
[  150.994027] usb 1-1.2: usb auto-suspend, wakeup 0
[  153.003869] hub 1-1:1.0: hub_suspend
[  153.003893] usb 1-1: unlink qh256-0001/ffff88013a93ed00 start 3 [1/0 us]
[  153.004042] usb 1-1: usb auto-suspend, wakeup 1
[  155.013849] hub 1-0:1.0: hub_suspend
[  155.013870] usb usb1: bus auto-suspend, wakeup 1
[  155.013877] ehci_hcd 0000:00:1a.0: suspend root hub

[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: ehci_hcd related S3 lockup on ASUS laptops, again

[Alan Stern]

On Fri, 20 Apr 2012, Andrey Rahmatullin wrote:

> > I'd like to see the dmesg log for the complete suspend/resume cycle 
> > (naturally you'll have to resume the system by hand after plugging in 
> > the USB device).  Make sure that CONFIG_USB_DEBUG is enabled.
> Attached.

It looks quite normal.  Evidently USB wakeup does _not_ work on your 
system when the controller isn't in D3 -- and the system crashes during 
suspend if the controller _is_ in D3!

(Does anybody know if USB wakeup works on these machines under
Windows?)

What about runtime wakeup?  You can test it easily enough.  Write 
"auto" to the power/control attribute for the two controllers.  This 
should cause the controllers (or at least one of them) to go into 
runtime suspend.  Does it then wake up when you plug in a USB device?

Alan Stern

Re: ehci_hcd related S3 lockup on ASUS laptops, again

[Steven Rostedt]

On Fri, 2012-04-20 at 20:42 -0400, Alan Stern wrote:

> (Does anybody know if USB wakeup works on these machines under
> Windows?)

I still have my windows partition on this box. Do you happen to know how
to tell Windows to wake up on USB?

> 
> What about runtime wakeup?  You can test it easily enough.  Write 
> "auto" to the power/control attribute for the two controllers.  This 
> should cause the controllers (or at least one of them) to go into 
> runtime suspend.  Does it then wake up when you plug in a USB device?

Do you want me to do this with one of you patches, or with the script
applied?

-- Steve

Re: ehci_hcd related S3 lockup on ASUS laptops, again

[Andrey Rahmatullin]

[-- Attachment #1.1: Type: text/plain, Size: 1177 bytes --]

On Fri, Apr 20, 2012 at 08:42:03PM -0400, Alan Stern wrote:
> > > I'd like to see the dmesg log for the complete suspend/resume cycle 
> > > (naturally you'll have to resume the system by hand after plugging in 
> > > the USB device).  Make sure that CONFIG_USB_DEBUG is enabled.
> > Attached.
> 
> It looks quite normal.  Evidently USB wakeup does _not_ work on your 
> system when the controller isn't in D3 -- and the system crashes during 
> suspend if the controller _is_ in D3!
> 
> (Does anybody know if USB wakeup works on these machines under
> Windows?)
Out of the box it doesn't work and "Allow this device to wake up the
computer" checkboxes on both root hubs are unchecked and grayed out.

> What about runtime wakeup?  You can test it easily enough.  Write 
> "auto" to the power/control attribute for the two controllers.  This 
> should cause the controllers (or at least one of them) to go into 
> runtime suspend.  Does it then wake up when you plug in a USB device?
I wrote 'auto' to both power/control, both power/runtime_status became
'suspended', I plugged in a device, one of power/runtime_status became
'active'.

-- 
WBR, wRAR

[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: ehci_hcd related S3 lockup on ASUS laptops, again

[Alan Stern]

Steve and Andrey:

It turns out that the proposed solution for your problem causes a
regression on other ASUS computers (see Bugzilla 43278).  Rafael's got a
proposal for a replacement.

Can you try out the patch attached to comment #61 of Bugzilla 42728?  It
may even allow USB wakeup to work for you (but I wouldn't count on it!).
Thanks.

Alan Stern

Re: ehci_hcd related S3 lockup on ASUS laptops, again

[Steven Rostedt]

On Fri, 2012-05-25 at 22:01 -0400, Alan Stern wrote:
> Steve and Andrey:
> 
> It turns out that the proposed solution for your problem causes a
> regression on other ASUS computers (see Bugzilla 43278).  Rafael's got a
> proposal for a replacement.
> 
> Can you try out the patch attached to comment #61 of Bugzilla 42728?  It
> may even allow USB wakeup to work for you (but I wouldn't count on it!).
> Thanks.

I added the patch against 3.4 and my laptop still suspends.

And no, wakeup still doesn't work.

Tested-by: Steven Rostedt <rostedt@goodmis.org>

-- Steve

Re: ehci_hcd related S3 lockup on ASUS laptops, again

[Rafael J. Wysocki]

On Saturday, May 26, 2012, Steven Rostedt wrote:
> On Fri, 2012-05-25 at 22:01 -0400, Alan Stern wrote:
> > Steve and Andrey:
> > 
> > It turns out that the proposed solution for your problem causes a
> > regression on other ASUS computers (see Bugzilla 43278).  Rafael's got a
> > proposal for a replacement.
> > 
> > Can you try out the patch attached to comment #61 of Bugzilla 42728?  It
> > may even allow USB wakeup to work for you (but I wouldn't count on it!).
> > Thanks.
> 
> I added the patch against 3.4 and my laptop still suspends.
> 
> And no, wakeup still doesn't work.
> 
> Tested-by: Steven Rostedt <rostedt@goodmis.org>

Thanks!

Unfortunately, I have no idea what to do to make wakeup work on the
affected machines.

Rafael

Re: ehci_hcd related S3 lockup on ASUS laptops, again

[Andrey Rahmatullin]

[-- Attachment #1.1: Type: text/plain, Size: 551 bytes --]

On Fri, May 25, 2012 at 10:01:44PM -0400, Alan Stern wrote:
> Steve and Andrey:
> 
> It turns out that the proposed solution for your problem causes a
> regression on other ASUS computers (see Bugzilla 43278).  Rafael's got a
> proposal for a replacement.
> 
> Can you try out the patch attached to comment #61 of Bugzilla 42728?  It
> may even allow USB wakeup to work for you (but I wouldn't count on it!).
> Thanks.
With the patch from #61 and with 151b61284776 reverted suspending works,
though USB resuming doesn't.

-- 
WBR, wRAR

[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: ehci_hcd related S3 lockup on ASUS laptops, again

[Rafael J. Wysocki]

On Saturday, May 26, 2012, Andrey Rahmatullin wrote:
> On Fri, May 25, 2012 at 10:01:44PM -0400, Alan Stern wrote:
> > Steve and Andrey:
> > 
> > It turns out that the proposed solution for your problem causes a
> > regression on other ASUS computers (see Bugzilla 43278).  Rafael's got a
> > proposal for a replacement.
> > 
> > Can you try out the patch attached to comment #61 of Bugzilla 42728?  It
> > may even allow USB wakeup to work for you (but I wouldn't count on it!).
> > Thanks.
> With the patch from #61 and with 151b61284776 reverted suspending works,
> though USB resuming doesn't.

Thanks for testing!

Rafael

Re: [linux-pm] ehci_hcd related S3 lockup on ASUS laptops, again

[Andrey Rahmatullin]

[-- Attachment #1: Type: text/plain, Size: 1346 bytes --]

On Thu, Apr 19, 2012 at 09:43:45AM -0400, Alan Stern wrote:
> But before going any farther, I'd like to test if USB wakeup works.  
> So after booting with this patch, make sure that the power/wakeup file
> says "enabled" in the sysfs path for each controller as well as the
> usb1, usb2, 1-2, and 2-2 paths under /sys/bus/usb/devices/.
Also, I don't have [12]-2 there:

1-0:1.0 -> ../../../devices/pci0000:00/0000:00:1a.0/usb1/1-0:1.0
1-1 -> ../../../devices/pci0000:00/0000:00:1a.0/usb1/1-1
1-1.1 -> ../../../devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.1
1-1.1:1.0 -> ../../../devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.1/1-1.1:1.0
1-1.1:1.1 -> ../../../devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.1/1-1.1:1.1
1-1.2 -> ../../../devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.2
1-1.2:1.0 -> ../../../devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.2/1-1.2:1.0
1-1.2:1.1 -> ../../../devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.2/1-1.2:1.1
1-1:1.0 -> ../../../devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1:1.0
2-0:1.0 -> ../../../devices/pci0000:00/0000:00:1d.0/usb2/2-0:1.0
2-1 -> ../../../devices/pci0000:00/0000:00:1d.0/usb2/2-1
2-1:1.0 -> ../../../devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1:1.0
usb1 -> ../../../devices/pci0000:00/0000:00:1a.0/usb1
usb2 -> ../../../devices/pci0000:00/0000:00:1d.0/usb2

-- 
WBR, wRAR

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: ehci_hcd related S3 lockup on ASUS laptops, again

[Alan Stern]

On Thu, 19 Apr 2012, Andrey Rahmatullin wrote:

> On Thu, Apr 19, 2012 at 09:43:45AM -0400, Alan Stern wrote:
> > But before going any farther, I'd like to test if USB wakeup works.  
> > So after booting with this patch, make sure that the power/wakeup file
> > says "enabled" in the sysfs path for each controller as well as the
> > usb1, usb2, 1-2, and 2-2 paths under /sys/bus/usb/devices/.
> Also, I don't have [12]-2 there:
> 
> 1-0:1.0 -> ../../../devices/pci0000:00/0000:00:1a.0/usb1/1-0:1.0
> 1-1 -> ../../../devices/pci0000:00/0000:00:1a.0/usb1/1-1
> 1-1.1 -> ../../../devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.1
> 1-1.1:1.0 -> ../../../devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.1/1-1.1:1.0
> 1-1.1:1.1 -> ../../../devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.1/1-1.1:1.1
> 1-1.2 -> ../../../devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.2
> 1-1.2:1.0 -> ../../../devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.2/1-1.2:1.0
> 1-1.2:1.1 -> ../../../devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.2/1-1.2:1.1
> 1-1:1.0 -> ../../../devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1:1.0
> 2-0:1.0 -> ../../../devices/pci0000:00/0000:00:1d.0/usb2/2-0:1.0
> 2-1 -> ../../../devices/pci0000:00/0000:00:1d.0/usb2/2-1
> 2-1:1.0 -> ../../../devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1:1.0
> usb1 -> ../../../devices/pci0000:00/0000:00:1a.0/usb1
> usb2 -> ../../../devices/pci0000:00/0000:00:1d.0/usb2

My apologies, I meant 1-1 and 2-1.  (The number following the '-' is a 
port number, not a device address.)

Alan Stern

Re: [linux-pm] ehci_hcd related S3 lockup on ASUS laptops, again

[Alan Stern]

On Wed, 18 Apr 2012, Rafael J. Wysocki wrote:

> > Yes, there are ways to work around this.  At the moment I'm not sure 
> > what would be best; we can ask Rafael.  One big remaining puzzle: Why 
> > are the EHCI controllers the only devices that cause a crash when left 
> > in D3 during suspend?  We may never know...
> 
> Are they put into D3 by ACPI or using the native PCI PM?

PCI PM, definitely.  Maybe ACPI gets into the act as well, but I doubt 
it.  How would we tell?

Alan Stern

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [linux-pm] ehci_hcd related S3 lockup on ASUS laptops, again

[Rafael J. Wysocki]

On Wednesday, April 18, 2012, Alan Stern wrote:
> On Wed, 18 Apr 2012, Rafael J. Wysocki wrote:
> 
> > > Yes, there are ways to work around this.  At the moment I'm not sure 
> > > what would be best; we can ask Rafael.  One big remaining puzzle: Why 
> > > are the EHCI controllers the only devices that cause a crash when left 
> > > in D3 during suspend?  We may never know...
> > 
> > Are they put into D3 by ACPI or using the native PCI PM?
> 
> PCI PM, definitely.  Maybe ACPI gets into the act as well, but I doubt 
> it.  How would we tell?

If ACPI is involved, the dev_printk() in acpi_pci_set_power_state() should
trigger.

Thanks,
Rafael
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: ehci_hcd related S3 lockup on ASUS laptops, again

[Andrey Rahmatullin]

[-- Attachment #1.1: Type: text/plain, Size: 685 bytes --]

On Wed, Apr 18, 2012 at 11:44:16PM +0200, Rafael J. Wysocki wrote:
> > > > Yes, there are ways to work around this.  At the moment I'm not sure 
> > > > what would be best; we can ask Rafael.  One big remaining puzzle: Why 
> > > > are the EHCI controllers the only devices that cause a crash when left 
> > > > in D3 during suspend?  We may never know...
> > > 
> > > Are they put into D3 by ACPI or using the native PCI PM?
> > 
> > PCI PM, definitely.  Maybe ACPI gets into the act as well, but I doubt 
> > it.  How would we tell?
> 
> If ACPI is involved, the dev_printk() in acpi_pci_set_power_state() should
> trigger.
And it apparently doesn't?

-- 
WBR, wRAR

[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: [linux-pm] ehci_hcd related S3 lockup on ASUS laptops, again

[Andrey Rahmatullin]

[-- Attachment #1: Type: text/plain, Size: 1148 bytes --]

On Wed, Apr 18, 2012 at 10:51:38AM -0400, Alan Stern wrote:
> > > Now if you modify the patch by removing the change to hcd-pci.c, which 
> > > will leave the EHCI code exactly the same as in the vanilla kernel, and 
> > > set the pm_test value to "platform", what does the dmesg log show in 
> > > the two cases?
> > The same for the unbound state. For the bound state, it still locks up.
> 
> That's odd.  Didn't you say earlier that after "echo platform 
> >/sys/power/pm_test", the bound case worked?  Or was that just Steve?
I've forgot to do that %)

Unbound:

pci 0000:00:1d.0: wake-up capability enabled by ACPI
pci 0000:00:1d.0: Refused to change power state, currently in D0
pci 0000:00:1d.0: cur 5 target 3 error 0
pci 0000:00:1a.0: wake-up capability enabled by ACPI
pci 0000:00:1a.0: Refused to change power state, currently in D0
pci 0000:00:1a.0: cur 5 target 3 error 0

Bound:

ehci_hcd 0000:00:1d.0: wake-up capability enabled by ACPI
ehci_hcd 0000:00:1d.0: cur 0 target 3 error 0
ehci_hcd 0000:00:1a.0: wake-up capability enabled by ACPI
ehci_hcd 0000:00:1a.0: cur 0 target 3 error 0


-- 
WBR, wRAR

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: ehci_hcd related S3 lockup on ASUS laptops, again

[Alan Stern]

On Wed, 18 Apr 2012, Andrey Rahmatullin wrote:

> Unbound:
> 
> pci 0000:00:1d.0: wake-up capability enabled by ACPI
> pci 0000:00:1d.0: Refused to change power state, currently in D0
> pci 0000:00:1d.0: cur 5 target 3 error 0
> pci 0000:00:1a.0: wake-up capability enabled by ACPI
> pci 0000:00:1a.0: Refused to change power state, currently in D0
> pci 0000:00:1a.0: cur 5 target 3 error 0
> 
> Bound:
> 
> ehci_hcd 0000:00:1d.0: wake-up capability enabled by ACPI
> ehci_hcd 0000:00:1d.0: cur 0 target 3 error 0
> ehci_hcd 0000:00:1a.0: wake-up capability enabled by ACPI
> ehci_hcd 0000:00:1a.0: cur 0 target 3 error 0

Okay, it sounds like you both got the same result.

Here's the situation.  When the script unbinds ehci-hcd, 
pci_device_remove() sets the current state to PCI_UNKNOWN.  The patch 
to hcd-pci.c does the same thing before the suspend_noirq phase begins, 
i.e., before pci_prepare_to_sleep() is called.

In pci_raw_set_power_state(), there's a "switch" statement that depends
on dev->current_state.  If the current state is PCI_D0 then the new
state in pmcsr is set to PCI_D3; if the current state is PCI_UNKNOWN
then the state in pmcsr is left unchanged.  After that, the value in
pmcsr is written to the controller.

This means that when ehci-hcd is unbound or the patch is installed, the
controller stays in D0.  That's why we see those "Refused to change
power state" messages, since D0 is not what the target state was
supposed to be.  When ehci-hcd remains bound and the patch isn't
installed, the controller is put into D3.

And then finally, the computer crashes during the final stage of 
suspend if either controller is in D3.  Clearly this is a bug in the 
firmware, not in the kernel.

Have you guys checked to see if any BIOS updates are available?

Alan Stern

Re: ehci_hcd related S3 lockup on ASUS laptops, again

[Andrey Rahmatullin]

[-- Attachment #1.1: Type: text/plain, Size: 1299 bytes --]

On Wed, Apr 18, 2012 at 12:41:10PM -0400, Alan Stern wrote:
> Here's the situation.  When the script unbinds ehci-hcd, 
> pci_device_remove() sets the current state to PCI_UNKNOWN.  The patch 
> to hcd-pci.c does the same thing before the suspend_noirq phase begins, 
> i.e., before pci_prepare_to_sleep() is called.
> 
> In pci_raw_set_power_state(), there's a "switch" statement that depends
> on dev->current_state.  If the current state is PCI_D0 then the new
> state in pmcsr is set to PCI_D3; if the current state is PCI_UNKNOWN
> then the state in pmcsr is left unchanged.  After that, the value in
> pmcsr is written to the controller.
> 
> This means that when ehci-hcd is unbound or the patch is installed, the
> controller stays in D0.  That's why we see those "Refused to change
> power state" messages, since D0 is not what the target state was
> supposed to be.  When ehci-hcd remains bound and the patch isn't
> installed, the controller is put into D3.
> 
> And then finally, the computer crashes during the final stage of 
> suspend if either controller is in D3.  Clearly this is a bug in the 
> firmware, not in the kernel.
> 
> Have you guys checked to see if any BIOS updates are available?
I've just updated to 219 and it still hangs.

-- 
WBR, wRAR

[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: [linux-pm] ehci_hcd related S3 lockup on ASUS laptops, again

[Steven Rostedt]

On Wed, 2012-04-18 at 23:10 +0600, Andrey Rahmatullin wrote:
> On Wed, Apr 18, 2012 at 12:41:10PM -0400, Alan Stern wrote:
> > Here's the situation.  When the script unbinds ehci-hcd, 
> > pci_device_remove() sets the current state to PCI_UNKNOWN.  The patch 
> > to hcd-pci.c does the same thing before the suspend_noirq phase begins, 
> > i.e., before pci_prepare_to_sleep() is called.
> > 
> > In pci_raw_set_power_state(), there's a "switch" statement that depends
> > on dev->current_state.  If the current state is PCI_D0 then the new
> > state in pmcsr is set to PCI_D3; if the current state is PCI_UNKNOWN
> > then the state in pmcsr is left unchanged.  After that, the value in
> > pmcsr is written to the controller.
> > 
> > This means that when ehci-hcd is unbound or the patch is installed, the
> > controller stays in D0.  That's why we see those "Refused to change
> > power state" messages, since D0 is not what the target state was
> > supposed to be.  When ehci-hcd remains bound and the patch isn't
> > installed, the controller is put into D3.
> > 
> > And then finally, the computer crashes during the final stage of 
> > suspend if either controller is in D3.  Clearly this is a bug in the 
> > firmware, not in the kernel.
> > 
> > Have you guys checked to see if any BIOS updates are available?
> I've just updated to 219 and it still hangs.

I only see 213 on their website.

Alan,

Is there a way to detect this chipset or something, to add a workaround
for it?

As it works for Windows, I wonder what their workaround was.

-- Steve


--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [linux-pm] ehci_hcd related S3 lockup on ASUS laptops, again

[Alan Stern]

On Wed, 18 Apr 2012, Steven Rostedt wrote:

> On Wed, 2012-04-18 at 23:10 +0600, Andrey Rahmatullin wrote:
> > On Wed, Apr 18, 2012 at 12:41:10PM -0400, Alan Stern wrote:
> > > Here's the situation.  When the script unbinds ehci-hcd, 
> > > pci_device_remove() sets the current state to PCI_UNKNOWN.  The patch 
> > > to hcd-pci.c does the same thing before the suspend_noirq phase begins, 
> > > i.e., before pci_prepare_to_sleep() is called.
> > > 
> > > In pci_raw_set_power_state(), there's a "switch" statement that depends
> > > on dev->current_state.  If the current state is PCI_D0 then the new
> > > state in pmcsr is set to PCI_D3; if the current state is PCI_UNKNOWN
> > > then the state in pmcsr is left unchanged.  After that, the value in
> > > pmcsr is written to the controller.
> > > 
> > > This means that when ehci-hcd is unbound or the patch is installed, the
> > > controller stays in D0.  That's why we see those "Refused to change
> > > power state" messages, since D0 is not what the target state was
> > > supposed to be.  When ehci-hcd remains bound and the patch isn't
> > > installed, the controller is put into D3.
> > > 
> > > And then finally, the computer crashes during the final stage of 
> > > suspend if either controller is in D3.  Clearly this is a bug in the 
> > > firmware, not in the kernel.

> Is there a way to detect this chipset or something, to add a workaround
> for it?

Yes, there are ways to work around this.  At the moment I'm not sure 
what would be best; we can ask Rafael.  One big remaining puzzle: Why 
are the EHCI controllers the only devices that cause a crash when left 
in D3 during suspend?  We may never know...

In the meantime, just to be certain of the diagnosis, here's a
different patch for you guys to try.  This will test the ehci-hcd
unbound path (i.e., use it with the script).  The patch removes the
line that sets the dev->current_state to PCI_UNKNOWN when the driver is
unbound.  Thus current_state will remain equal to PCI_D0, so
pci_prepare_to_sleep should put the controllers into D3, which we
expect will cause a crash.

Please try this both with and without pm_test set to "platform", and 
post the debugging dmesg output from whichever cases the computer 
survives.

Alan Stern



Index: usb-3.4/drivers/pci/pci-driver.c
===================================================================
--- usb-3.4.orig/drivers/pci/pci-driver.c
+++ usb-3.4/drivers/pci/pci-driver.c
@@ -394,8 +394,8 @@ static int pci_device_remove(struct devi
 	 * If the device is still on, set the power state as "unknown",
 	 * since it might change by the next time we load the driver.
 	 */
-	if (pci_dev->current_state == PCI_D0)
-		pci_dev->current_state = PCI_UNKNOWN;
+//	if (pci_dev->current_state == PCI_D0)
+//		pci_dev->current_state = PCI_UNKNOWN;
 
 	/*
 	 * We would love to complain here if pci_dev->is_enabled is set, that
@@ -713,6 +713,8 @@ static int pci_pm_suspend_noirq(struct d
 
 	if (!pm) {
 		pci_save_state(pci_dev);
+		pci_prepare_to_sleep(pci_dev);
+		pci_pm_set_unknown_state(pci_dev);
 		return 0;
 	}
 
Index: usb-3.4/drivers/pci/pci.c
===================================================================
--- usb-3.4.orig/drivers/pci/pci.c
+++ usb-3.4/drivers/pci/pci.c
@@ -1710,6 +1710,7 @@ pci_power_t pci_target_state(struct pci_
  */
 int pci_prepare_to_sleep(struct pci_dev *dev)
 {
+	pci_power_t cur_state = dev->current_state;
 	pci_power_t target_state = pci_target_state(dev);
 	int error;
 
@@ -1723,6 +1724,8 @@ int pci_prepare_to_sleep(struct pci_dev
 	if (error)
 		pci_enable_wake(dev, target_state, false);
 
+	dev_info(&dev->dev, "cur %d target %d error %d\n", cur_state,
+			target_state, error);
 	return error;
 }
 

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: ehci_hcd related S3 lockup on ASUS laptops, again

[Andrey Rahmatullin]

[-- Attachment #1.1: Type: text/plain, Size: 943 bytes --]

On Wed, Apr 18, 2012 at 04:23:20PM -0400, Alan Stern wrote:
> In the meantime, just to be certain of the diagnosis, here's a
> different patch for you guys to try.  This will test the ehci-hcd
> unbound path (i.e., use it with the script).  The patch removes the
> line that sets the dev->current_state to PCI_UNKNOWN when the driver is
> unbound.  Thus current_state will remain equal to PCI_D0, so
> pci_prepare_to_sleep should put the controllers into D3, which we
> expect will cause a crash.
> 
> Please try this both with and without pm_test set to "platform", and 
> post the debugging dmesg output from whichever cases the computer 
> survives.
With "platform":

ehci_hcd 0000:00:1d.0: wake-up capability enabled by ACPI
ehci_hcd 0000:00:1d.0: cur 0 target 3 error 0
ehci_hcd 0000:00:1a.0: wake-up capability enabled by ACPI
ehci_hcd 0000:00:1a.0: cur 0 target 3 error 0

With "none" it locks up.

-- 
WBR, wRAR

[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: ehci_hcd related S3 lockup on ASUS laptops, again

[Andrey Rahmatullin]

[-- Attachment #1.1: Type: text/plain, Size: 236 bytes --]

On Wed, Apr 18, 2012 at 01:20:32PM -0400, Steven Rostedt wrote:
> > I've just updated to 219 and it still hangs.
> I only see 213 on their website.
Well, different models definitely have different version numbers.

-- 
WBR, wRAR

[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: [linux-pm] ehci_hcd related S3 lockup on ASUS laptops, again

[Andrey Rahmatullin]

[-- Attachment #1: Type: text/plain, Size: 407 bytes --]

On Fri, Apr 13, 2012 at 10:10:30AM -0400, Alan Stern wrote:
> Second, if you do
> 
> 	echo 0 >/sys/bus/usb/devices/usb1/bConfigurationValue
> 	echo 0 >/sys/bus/usb/devices/usb2/bConfigurationValue
> 
> before suspending (using a vanilla kernel and no script), does it 
> change the behavior?  I expect it won't, but we should check just to be 
> thorough.
No, it still locks up.

-- 
WBR, wRAR

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: ehci_hcd related S3 lockup on ASUS laptops, again

[Alan Stern]

On Sat, 14 Apr 2012, Andrey Rahmatullin wrote:

> On Fri, Apr 13, 2012 at 10:10:30AM -0400, Alan Stern wrote:
> > Second, if you do
> > 
> > 	echo 0 >/sys/bus/usb/devices/usb1/bConfigurationValue
> > 	echo 0 >/sys/bus/usb/devices/usb2/bConfigurationValue
> > 
> > before suspending (using a vanilla kernel and no script), does it 
> > change the behavior?  I expect it won't, but we should check just to be 
> > thorough.
> No, it still locks up.

Okay.

This is my next attempt to make the driver-bound and driver-unbound
suspend paths as similar as possible.  Apply this to a vanilla kernel;  
it is based on 3.4-rc2 plus a few unrelated changes.  See what happens
when you suspend without unbinding ehci-hcd -- and be sure to include
"no_console_suspend" on the boot command line beforehand.

These changes will prevent the driver from working after resume 
(assuming the computer survives that long).  That's all right; all I 
care about is whether the computer _does_ resume.

Alan Stern




Index: usb-3.4/drivers/pci/pci-driver.c
===================================================================
--- usb-3.4.orig/drivers/pci/pci-driver.c
+++ usb-3.4/drivers/pci/pci-driver.c
@@ -713,6 +713,8 @@ static int pci_pm_suspend_noirq(struct d
 
 	if (!pm) {
 		pci_save_state(pci_dev);
+		pci_prepare_to_sleep(pci_dev);
+		pci_pm_set_unknown_state(pci_dev);
 		return 0;
 	}
 
Index: usb-3.4/drivers/pci/pci.c
===================================================================
--- usb-3.4.orig/drivers/pci/pci.c
+++ usb-3.4/drivers/pci/pci.c
@@ -1348,6 +1348,7 @@ void pci_disable_enabled_device(struct p
 	if (pci_is_enabled(dev))
 		do_pci_disable_device(dev);
 }
+EXPORT_SYMBOL(pci_disable_enabled_device);
 
 /**
  * pci_disable_device - Disable PCI device after use
@@ -1710,6 +1711,7 @@ pci_power_t pci_target_state(struct pci_
  */
 int pci_prepare_to_sleep(struct pci_dev *dev)
 {
+	pci_power_t cur_state = dev->current_state;
 	pci_power_t target_state = pci_target_state(dev);
 	int error;
 
@@ -1723,6 +1725,8 @@ int pci_prepare_to_sleep(struct pci_dev
 	if (error)
 		pci_enable_wake(dev, target_state, false);
 
+	dev_info(&dev->dev, "cur %d target %d error %d\n", cur_state,
+			target_state, error);
 	return error;
 }
 
Index: usb-3.4/drivers/usb/core/hcd-pci.c
===================================================================
--- usb-3.4.orig/drivers/usb/core/hcd-pci.c
+++ usb-3.4/drivers/usb/core/hcd-pci.c
@@ -381,6 +381,8 @@ static int check_root_hub_suspended(stru
 }
 
 #if defined(CONFIG_PM_SLEEP) || defined(CONFIG_PM_RUNTIME)
+extern void pci_disable_enabled_device(struct pci_dev *);
+
 static int suspend_common(struct device *dev, bool do_wakeup)
 {
 	struct pci_dev		*pci_dev = to_pci_dev(dev);
@@ -427,12 +429,17 @@ static int suspend_common(struct device
 	if (!hcd->msix_enabled)
 		synchronize_irq(pci_dev->irq);
 
+	free_irq(hcd->irq, hcd);
+	iounmap(hcd->regs);
+	pci_disable_device(pci_dev);
+
 	/* Downstream ports from this root hub should already be quiesced, so
 	 * there will be no DMA activity.  Now we can shut down the upstream
 	 * link (except maybe for PME# resume signaling).  We'll enter a
 	 * low power state during suspend_noirq, if the hardware allows.
 	 */
-	pci_disable_device(pci_dev);
+	pci_disable_enabled_device(pci_dev);
+	pci_dev->current_state = PCI_UNKNOWN;
 	return retval;
 }
 
Index: usb-3.4/drivers/usb/host/ehci-pci.c
===================================================================
--- usb-3.4.orig/drivers/usb/host/ehci-pci.c
+++ usb-3.4/drivers/usb/host/ehci-pci.c
@@ -342,7 +342,6 @@ static int ehci_pci_suspend(struct usb_h
 	 * mark HW unaccessible.  The PM and USB cores make sure that
 	 * the root hub is either suspended or stopped.
 	 */
-	ehci_prepare_ports_for_controller_suspend(ehci, do_wakeup);
 	spin_lock_irqsave (&ehci->lock, flags);
 	ehci_writel(ehci, 0, &ehci->regs->intr_enable);
 	(void)ehci_readl(ehci, &ehci->regs->intr_enable);
@@ -350,6 +349,9 @@ static int ehci_pci_suspend(struct usb_h
 	clear_bit(HCD_FLAG_HW_ACCESSIBLE, &hcd->flags);
 	spin_unlock_irqrestore (&ehci->lock, flags);
 
+	ehci_silence_controller(ehci);
+	ehci_reset(ehci);
+
 	// could save FLADJ in case of Vaux power loss
 	// ... we'd only use it to handle clock skew
 

Re: ehci_hcd related S3 lockup on ASUS laptops, again

[Andrey Rahmatullin]

[-- Attachment #1.1: Type: text/plain, Size: 4325 bytes --]

On Mon, Apr 16, 2012 at 04:07:10PM -0400, Alan Stern wrote:
> This is my next attempt to make the driver-bound and driver-unbound
> suspend paths as similar as possible.  Apply this to a vanilla kernel;  
> it is based on 3.4-rc2 plus a few unrelated changes.  See what happens
> when you suspend without unbinding ehci-hcd -- and be sure to include
> "no_console_suspend" on the boot command line beforehand.
It suspends and resumes but the screen is not enabled after resume and the
network doesn't seem to work either.

> These changes will prevent the driver from working after resume 
> (assuming the computer survives that long).  That's all right; all I 
> care about is whether the computer _does_ resume.
> 
> Alan Stern
> 
> 
> 
> 
> Index: usb-3.4/drivers/pci/pci-driver.c
> ===================================================================
> --- usb-3.4.orig/drivers/pci/pci-driver.c
> +++ usb-3.4/drivers/pci/pci-driver.c
> @@ -713,6 +713,8 @@ static int pci_pm_suspend_noirq(struct d
>  
>  	if (!pm) {
>  		pci_save_state(pci_dev);
> +		pci_prepare_to_sleep(pci_dev);
> +		pci_pm_set_unknown_state(pci_dev);
>  		return 0;
>  	}
>  
> Index: usb-3.4/drivers/pci/pci.c
> ===================================================================
> --- usb-3.4.orig/drivers/pci/pci.c
> +++ usb-3.4/drivers/pci/pci.c
> @@ -1348,6 +1348,7 @@ void pci_disable_enabled_device(struct p
>  	if (pci_is_enabled(dev))
>  		do_pci_disable_device(dev);
>  }
> +EXPORT_SYMBOL(pci_disable_enabled_device);
>  
>  /**
>   * pci_disable_device - Disable PCI device after use
> @@ -1710,6 +1711,7 @@ pci_power_t pci_target_state(struct pci_
>   */
>  int pci_prepare_to_sleep(struct pci_dev *dev)
>  {
> +	pci_power_t cur_state = dev->current_state;
>  	pci_power_t target_state = pci_target_state(dev);
>  	int error;
>  
> @@ -1723,6 +1725,8 @@ int pci_prepare_to_sleep(struct pci_dev
>  	if (error)
>  		pci_enable_wake(dev, target_state, false);
>  
> +	dev_info(&dev->dev, "cur %d target %d error %d\n", cur_state,
> +			target_state, error);
>  	return error;
>  }
>  
> Index: usb-3.4/drivers/usb/core/hcd-pci.c
> ===================================================================
> --- usb-3.4.orig/drivers/usb/core/hcd-pci.c
> +++ usb-3.4/drivers/usb/core/hcd-pci.c
> @@ -381,6 +381,8 @@ static int check_root_hub_suspended(stru
>  }
>  
>  #if defined(CONFIG_PM_SLEEP) || defined(CONFIG_PM_RUNTIME)
> +extern void pci_disable_enabled_device(struct pci_dev *);
> +
>  static int suspend_common(struct device *dev, bool do_wakeup)
>  {
>  	struct pci_dev		*pci_dev = to_pci_dev(dev);
> @@ -427,12 +429,17 @@ static int suspend_common(struct device
>  	if (!hcd->msix_enabled)
>  		synchronize_irq(pci_dev->irq);
>  
> +	free_irq(hcd->irq, hcd);
> +	iounmap(hcd->regs);
> +	pci_disable_device(pci_dev);
> +
>  	/* Downstream ports from this root hub should already be quiesced, so
>  	 * there will be no DMA activity.  Now we can shut down the upstream
>  	 * link (except maybe for PME# resume signaling).  We'll enter a
>  	 * low power state during suspend_noirq, if the hardware allows.
>  	 */
> -	pci_disable_device(pci_dev);
> +	pci_disable_enabled_device(pci_dev);
> +	pci_dev->current_state = PCI_UNKNOWN;
>  	return retval;
>  }
>  
> Index: usb-3.4/drivers/usb/host/ehci-pci.c
> ===================================================================
> --- usb-3.4.orig/drivers/usb/host/ehci-pci.c
> +++ usb-3.4/drivers/usb/host/ehci-pci.c
> @@ -342,7 +342,6 @@ static int ehci_pci_suspend(struct usb_h
>  	 * mark HW unaccessible.  The PM and USB cores make sure that
>  	 * the root hub is either suspended or stopped.
>  	 */
> -	ehci_prepare_ports_for_controller_suspend(ehci, do_wakeup);
>  	spin_lock_irqsave (&ehci->lock, flags);
>  	ehci_writel(ehci, 0, &ehci->regs->intr_enable);
>  	(void)ehci_readl(ehci, &ehci->regs->intr_enable);
> @@ -350,6 +349,9 @@ static int ehci_pci_suspend(struct usb_h
>  	clear_bit(HCD_FLAG_HW_ACCESSIBLE, &hcd->flags);
>  	spin_unlock_irqrestore (&ehci->lock, flags);
>  
> +	ehci_silence_controller(ehci);
> +	ehci_reset(ehci);
> +
>  	// could save FLADJ in case of Vaux power loss
>  	// ... we'd only use it to handle clock skew
>  
> 
> 

-- 
WBR, wRAR

[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: ehci_hcd related S3 lockup on ASUS laptops, again

[Alan Stern]

On Tue, 17 Apr 2012, Andrey Rahmatullin wrote:

> On Mon, Apr 16, 2012 at 04:07:10PM -0400, Alan Stern wrote:
> > This is my next attempt to make the driver-bound and driver-unbound
> > suspend paths as similar as possible.  Apply this to a vanilla kernel;  
> > it is based on 3.4-rc2 plus a few unrelated changes.  See what happens
> > when you suspend without unbinding ehci-hcd -- and be sure to include
> > "no_console_suspend" on the boot command line beforehand.
> It suspends and resumes but the screen is not enabled after resume and the
> network doesn't seem to work either.

Well, at least it's progress.  It's possible that those other problems 
were caused by the rather drastic things the patch does.

Just to make sure, did you test the patch with the script installed 
(that is, with ehci-hcd unbound)?  I assume that will work normally.

Moving on, the next thing is to remove changes from the patch, one at a 
time, until we find one that prevents the system from resuming.  So, 
testing at each step, please remove from the patch:

	1. This change in hcd-pci.c:
+	pci_dev->current_state = PCI_UNKNOWN;

	2. This change in ehci-pci.c:
+	ehci_silence_controller(ehci);

	3. This change in hcd-pci.c:
+	pci_disable_device(pci_dev);

	4. This change in hcd-pci.c:
+	iounmap(hcd->regs);

	5. This change in hcd-pci.c:
+	free_irq(hcd->irq, hcd);

	6. This change in hcd-pci.c:
-	pci_disable_device(pci_dev);
+	pci_disable_enabled_device(pci_dev);

	7. This change in ehci-pci.c:
-	ehci_prepare_ports_for_controller_suspend(ehci, do_wakeup);

Once all those things have been removed, the patch should be the same 
as one you tried earlier, which did crash the machine.

Alan Stern

Re: ehci_hcd related S3 lockup on ASUS laptops, again

[Andrey Rahmatullin]

[-- Attachment #1.1: Type: text/plain, Size: 1200 bytes --]

On Tue, Apr 17, 2012 at 11:11:04AM -0400, Alan Stern wrote:
> Just to make sure, did you test the patch with the script installed 
> (that is, with ehci-hcd unbound)?  I assume that will work normally.
It works normally, yes.

> 
> Moving on, the next thing is to remove changes from the patch, one at a 
> time, until we find one that prevents the system from resuming.  So, 
> testing at each step, please remove from the patch:
> 
> 	1. This change in hcd-pci.c:
> +	pci_dev->current_state = PCI_UNKNOWN;
It locks up if this line is removed.

> 	2. This change in ehci-pci.c:
> +	ehci_silence_controller(ehci);
> 
> 	3. This change in hcd-pci.c:
> +	pci_disable_device(pci_dev);
> 
> 	4. This change in hcd-pci.c:
> +	iounmap(hcd->regs);
> 
> 	5. This change in hcd-pci.c:
> +	free_irq(hcd->irq, hcd);
> 
> 	6. This change in hcd-pci.c:
> -	pci_disable_device(pci_dev);
> +	pci_disable_enabled_device(pci_dev);
> 
> 	7. This change in ehci-pci.c:
> -	ehci_prepare_ports_for_controller_suspend(ehci, do_wakeup);
> 
> Once all those things have been removed, the patch should be the same 
> as one you tried earlier, which did crash the machine.

-- 
WBR, wRAR

[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: ehci_hcd related S3 lockup on ASUS laptops, again

[Alan Stern]

On Tue, 17 Apr 2012, Andrey Rahmatullin wrote:

> On Tue, Apr 17, 2012 at 11:11:04AM -0400, Alan Stern wrote:
> > Just to make sure, did you test the patch with the script installed 
> > (that is, with ehci-hcd unbound)?  I assume that will work normally.
> It works normally, yes.
> 
> > 
> > Moving on, the next thing is to remove changes from the patch, one at a 
> > time, until we find one that prevents the system from resuming.  So, 
> > testing at each step, please remove from the patch:
> > 
> > 	1. This change in hcd-pci.c:
> > +	pci_dev->current_state = PCI_UNKNOWN;
> It locks up if this line is removed.

Very bizarre indeed.  All right, leave that line in place and try 
removing the other changes, one at a time.  In fact, let's add one more 
thing to remove from the patch

> > 	2. This change in ehci-pci.c:
> > +	ehci_silence_controller(ehci);
> > 
> > 	3. This change in hcd-pci.c:
> > +	pci_disable_device(pci_dev);
> > 
> > 	4. This change in hcd-pci.c:
> > +	iounmap(hcd->regs);
> > 
> > 	5. This change in hcd-pci.c:
> > +	free_irq(hcd->irq, hcd);
> > 
> > 	6. This change in hcd-pci.c:
> > -	pci_disable_device(pci_dev);
> > +	pci_disable_enabled_device(pci_dev);
> > 
> > 	7. This change in ehci-pci.c:
> > -	ehci_prepare_ports_for_controller_suspend(ehci, do_wakeup);

	8. This change in ehci-pci.c:
+	ehci_reset(ehci);

If you manage to reach the end of this list, you'll essentially be
doing a normal suspend (except for the PCI_UNKNOWN part).

Alan Stern

Re: [linux-pm] ehci_hcd related S3 lockup on ASUS laptops, again

[Steven Rostedt]

[-- Attachment #1: Type: text/plain, Size: 921 bytes --]

On Fri, 2012-04-13 at 10:10 -0400, Alan Stern wrote:
> On Thu, 12 Apr 2012, Alan Stern wrote:
> 
> > Tomorrow I'll look through the code more carefully; with those changes
> > there really is very little difference between the two cases.  Things
> > like mmio mappings and IRQs requested; they shouldn't cause a crash.
> 
> Let's start with some basic information.  First, before suspending,
> what shows up in /sys/kernel/debug/usb/devices?

Attached (after gzipping it).

> 
> Second, if you do
> 
> 	echo 0 >/sys/bus/usb/devices/usb1/bConfigurationValue

This never returned. I did the echo, and the command locked up.

(process 3077)

cat /proc/3077/wchan 
usb_disconnect

-- Steve


> 	echo 0 >/sys/bus/usb/devices/usb2/bConfigurationValue
> 
> before suspending (using a vanilla kernel and no script), does it 
> change the behavior?  I expect it won't, but we should check just to be 
> thorough.
> 
> Alan Stern


[-- Attachment #2: devices.gz --]
[-- Type: application/x-gzip, Size: 841 bytes --]

Re: ehci_hcd related S3 lockup on ASUS laptops, again

[Alan Stern]

On Fri, 13 Apr 2012, Steven Rostedt wrote:

> > Second, if you do
> > 
> > 	echo 0 >/sys/bus/usb/devices/usb1/bConfigurationValue
> 
> This never returned. I did the echo, and the command locked up.
> 
> (process 3077)
> 
> cat /proc/3077/wchan 
> usb_disconnect

I found the reason for the deadlock.  The patch below will work around
the problem for now, although it's not a correct fix.  You'll still get
some complaints from lockdep.

Alan Stern



Index: usb-3.4/drivers/usb/core/hub.c
===================================================================
--- usb-3.4.orig/drivers/usb/core/hub.c
+++ usb-3.4/drivers/usb/core/hub.c
@@ -1667,7 +1667,7 @@ void usb_disconnect(struct usb_device **
 {
 	struct usb_device	*udev = *pdev;
 	int			i;
-	struct usb_hcd		*hcd = bus_to_hcd(udev->bus);
+//	struct usb_hcd		*hcd = bus_to_hcd(udev->bus);
 
 	/* mark the device as inactive, so any further urb submissions for
 	 * this device (and any of its children) will fail immediately.
@@ -1690,9 +1690,9 @@ void usb_disconnect(struct usb_device **
 	 * so that the hardware is now fully quiesced.
 	 */
 	dev_dbg (&udev->dev, "unregistering device\n");
-	mutex_lock(hcd->bandwidth_mutex);
+//	mutex_lock(hcd->bandwidth_mutex);
 	usb_disable_device(udev, 0);
-	mutex_unlock(hcd->bandwidth_mutex);
+//	mutex_unlock(hcd->bandwidth_mutex);
 	usb_hcd_synchronize_unlinks(udev);
 
 	usb_remove_ep_devs(&udev->ep0);

Re: [linux-pm] ehci_hcd related S3 lockup on ASUS laptops, again

[Steven Rostedt]

On Thu, 2012-04-12 at 15:11 -0400, Alan Stern wrote:

> > # dmesg | grep target
> > [ 8829.427534] atl1c 0000:04:00.0: target 3 wakeup 0 error 0
> > [ 8829.443524] xhci_hcd 0000:03:00.0: target 3 wakeup 1 error 0
> > [ 8829.459506] iwlwifi 0000:02:00.0: target 3 wakeup 0 error 0
> > [ 8829.459560] pci 0000:00:1f.3: target 0 wakeup 0 error 0
> > [ 8829.459607] pci 0000:00:1f.0: target 0 wakeup 0 error 0
> > [ 8829.475458] ehci_hcd 0000:00:1d.0: target 3 wakeup 1 error 0
> > [ 8829.491433] ehci_hcd 0000:00:1a.0: target 3 wakeup 1 error 0
> > [ 8829.507416] pci 0000:00:16.0: target 3 wakeup 0 error 0
> 
> The entries above are left over from the earlier test.


Yep I knew that. I just figured to post the full dmesg grep instead of
trimming it. ;-)

> 
> > [ 9419.750158] atl1c 0000:04:00.0: target 3 wakeup 0 error 0
> > [ 9419.766134] pci 0000:03:00.0: target 3 wakeup 1 error 0
> > [ 9419.782126] iwlwifi 0000:02:00.0: target 3 wakeup 0 error 0
> > [ 9419.782181] pci 0000:00:1f.3: target 0 wakeup 0 error 0
> > [ 9419.782230] pci 0000:00:1f.0: target 0 wakeup 0 error 0
> > [ 9419.798087] pci 0000:00:1d.0: target 3 wakeup 1 error 0
> > [ 9419.814064] pci 0000:00:1a.0: target 3 wakeup 1 error 0
> > [ 9419.830031] pci 0000:00:16.0: target 3 wakeup 0 error 0
> 
> Evidently the script unbinds xhci-hcd too.  Did you check to make
> sure it is unrelated to the suspend problem?

The script I found on the internet disables both. I just changed it to
only disable ehci and did a full suspend, and it still works:

[13538.700577] atl1c 0000:04:00.0: target 3 wakeup 0 error 0
[13538.716565] xhci_hcd 0000:03:00.0: target 3 wakeup 1 error 0
[13538.732542] iwlwifi 0000:02:00.0: target 3 wakeup 0 error 0
[13538.732596] pci 0000:00:1f.3: target 0 wakeup 0 error 0
[13538.732644] pci 0000:00:1f.0: target 0 wakeup 0 error 0
[13538.748503] pci 0000:00:1d.0: target 3 wakeup 1 error 0
[13538.764481] pci 0000:00:1a.0: target 3 wakeup 1 error 0
[13538.780448] pci 0000:00:16.0: target 3 wakeup 0 error 0

> 
> Anyway, this shows that the EHCI controllers are being set to the same 
> power state with the same wakeup settings in both cases.  And yet one 
> hangs the computer while the other doesn't.
> 
> Here's another rather drastic test you can do.  In 
> drivers/usb/host/ehci-pci.c:ehci_pci_suspend(), call ehci_reset(ehci) 
> just before the final return statement.  That should leave the hardware 
> in exactly the same state as if ehci-hcd had been unbound.

Want me to remove previous updates before doing so? I can keep the
dev_log, but what about the other change you asked about.

-- Steve


--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: ehci_hcd related S3 lockup on ASUS laptops, again

[Alan Stern]

On Thu, 12 Apr 2012, Steven Rostedt wrote:

> > Anyway, this shows that the EHCI controllers are being set to the same 
> > power state with the same wakeup settings in both cases.  And yet one 
> > hangs the computer while the other doesn't.
> > 
> > Here's another rather drastic test you can do.  In 
> > drivers/usb/host/ehci-pci.c:ehci_pci_suspend(), call ehci_reset(ehci) 
> > just before the final return statement.  That should leave the hardware 
> > in exactly the same state as if ehci-hcd had been unbound.
> 
> Want me to remove previous updates before doing so? I can keep the
> dev_log, but what about the other change you asked about.

Keep them.

Asumming you get the same result as Andrey, that the computer still
hangs even with the ehci_reset() call, there's one more thing for the 
two of you to try.

I noted before that with ehci-hcd bound, it would call 
pci_disable_device.  But with the driver unbound, the PCI core calls 
pci_disable_enabled_device instead.

So let's have the driver do the same thing.  At the end of
drivers/usb/core/hcd-pci.c:suspend_common, change pci_disable_device to
pci_disable_enabled_device.  You'll also have to EXPORT that routine;
it's defined in drivers/pci/pci.c.

Do this with the ehci_reset added and all the other changes present as 
well.  Then there should be no difference at all between the two 
scenarios.

Alan Stern

Re: ehci_hcd related S3 lockup on ASUS laptops, again

[Alan Stern]

On Thu, 12 Apr 2012, Alan Stern wrote:

> Do this with the ehci_reset added and all the other changes present as 
> well.

More precisely, keep the ehci_reset call (in both places), the dev_info
call, and the pci_prepare_to_sleep call.  You don't need to set the 
configflag register to 0; the reset will do that anyway.

Alan Stern

Re: ehci_hcd related S3 lockup on ASUS laptops, again

[Andrey Rahmatullin]

[-- Attachment #1.1: Type: text/plain, Size: 401 bytes --]

On Thu, Apr 12, 2012 at 04:09:43PM -0400, Alan Stern wrote:
> > Do this with the ehci_reset added and all the other changes present as 
> > well.
> 
> More precisely, keep the ehci_reset call (in both places),
Which both places?

> the dev_info call, and the pci_prepare_to_sleep call.  You don't need to
> set the configflag register to 0; the reset will do that anyway.


-- 
WBR, wRAR

[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: ehci_hcd related S3 lockup on ASUS laptops, again

[Alan Stern]

On Fri, 13 Apr 2012, Andrey Rahmatullin wrote:

> On Thu, Apr 12, 2012 at 04:09:43PM -0400, Alan Stern wrote:
> > > Do this with the ehci_reset added and all the other changes present as 
> > > well.
> > 
> > More precisely, keep the ehci_reset call (in both places),
> Which both places?
> 
> > the dev_info call, and the pci_prepare_to_sleep call.  You don't need to
> > set the configflag register to 0; the reset will do that anyway.

Sorry, that was an editing error.  I meant to say the
pci_prepare_to_sleep calls should be kept in both places: the existing 
on in hcd-pci.c and the one added to pci-driver.c.  You got the right 
idea, though.

Alan Stern

Re: ehci_hcd related S3 lockup on ASUS laptops, again

[Andrey Rahmatullin]

[-- Attachment #1.1: Type: text/plain, Size: 1035 bytes --]

On Thu, Apr 12, 2012 at 04:02:26PM -0400, Alan Stern wrote:
> Asumming you get the same result as Andrey, that the computer still
> hangs even with the ehci_reset() call, there's one more thing for the 
> two of you to try.
> 
> I noted before that with ehci-hcd bound, it would call 
> pci_disable_device.  But with the driver unbound, the PCI core calls 
> pci_disable_enabled_device instead.
> 
> So let's have the driver do the same thing.  At the end of
> drivers/usb/core/hcd-pci.c:suspend_common, change pci_disable_device to
> pci_disable_enabled_device.  You'll also have to EXPORT that routine;
> it's defined in drivers/pci/pci.c.
> 
> Do this with the ehci_reset added and all the other changes present as 
> well.  Then there should be no difference at all between the two 
> scenarios.
With
- pci_prepare_to_sleep in pci_pm_suspend_noirq
- pci_disable_enabled_device instead of pci_disable_device in
  suspend_common
- ehci_reset at the end of ehci_pci_suspend
it still locks up.

-- 
WBR, wRAR

[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: ehci_hcd related S3 lockup on ASUS laptops, again

[Alan Stern]

On Fri, 13 Apr 2012, Andrey Rahmatullin wrote:

> With
> - pci_prepare_to_sleep in pci_pm_suspend_noirq
> - pci_disable_enabled_device instead of pci_disable_device in
>   suspend_common
> - ehci_reset at the end of ehci_pci_suspend
> it still locks up.

I expected that.  Sigh.

Tomorrow I'll look through the code more carefully; with those changes
there really is very little difference between the two cases.  Things
like mmio mappings and IRQs requested; they shouldn't cause a crash.

Alan Stern

Re: [linux-pm] ehci_hcd related S3 lockup on ASUS laptops, again

[Steven Rostedt]

On Wed, 2012-04-11 at 15:12 -0400, Alan Stern wrote:

> If so, setting the value back to 0 before suspending (or never setting 
> it to 1 in the first place) might be important.  You can test this 
> easily enough.  In drivers/usb/host/ehci-pci.c:ehci_pci_suspend(), add 
> a line saying
> 
> 	ehci_writel(ehci, 0, &ehci->regs->configured_flag);
> 
> just before the spin_lock_irqrestore.  This will invalidate the
> driver's criterion for determining whether or not the controller's
> state got messed up during the suspend; we can worry about that later.

I just tried the above, and it made no difference. Note, I don't even
get to suspend. It locks up in suspend, so I haven't even tried a resume
yet.

> 
> 
> There are other differences, at the PCI level, that might also be 
> significant.  When the driver is not present, the PCI core calls 
> pci_disable_enabled_device.  But when the driver is loaded, instead 
> it calls pci_disable_device and pci_prepare_to_sleep.
> 
> You can try getting rid of the call to pci_prepare_to_sleep in 
> drivers/usb/core/hcd-pci.c:hcd_pci_suspend_noirq.  This will prevent 
> the controller from being put into D3hot and might interfere with 
> wakeup detection.
> 

What do I do with the retval? -EIO, 0, or other?

-- Steve

> I don't know how sigificant the difference is between
> pci_disable_device and pci_disable_enabled_device.  Probably not very, 
> since all it involves is whether or not to disable bus-mastering on the 
> controller.
> 
> Alan Stern


--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [linux-pm] ehci_hcd related S3 lockup on ASUS laptops, again

[Alan Stern]

On Wed, 11 Apr 2012, Steven Rostedt wrote:

> On Wed, 2012-04-11 at 15:12 -0400, Alan Stern wrote:
> 
> > If so, setting the value back to 0 before suspending (or never setting 
> > it to 1 in the first place) might be important.  You can test this 
> > easily enough.  In drivers/usb/host/ehci-pci.c:ehci_pci_suspend(), add 
> > a line saying
> > 
> > 	ehci_writel(ehci, 0, &ehci->regs->configured_flag);
> > 
> > just before the spin_lock_irqrestore.  This will invalidate the
> > driver's criterion for determining whether or not the controller's
> > state got messed up during the suspend; we can worry about that later.
> 
> I just tried the above, and it made no difference. Note, I don't even
> get to suspend. It locks up in suspend, so I haven't even tried a resume
> yet.

What do you mean, you don't get to suspend?  Is that a typo?

If the system locks up during the suspend procedure, it must do so
after this code runs.  I know that because it runs during the "devices"  
phase of suspending, and you said that "echo devices
>/sys/power/pm_test" works.

> > You can try getting rid of the call to pci_prepare_to_sleep in 
> > drivers/usb/core/hcd-pci.c:hcd_pci_suspend_noirq.  This will prevent 
> > the controller from being put into D3hot and might interfere with 
> > wakeup detection.
> > 
> 
> What do I do with the retval? -EIO, 0, or other?

0 or -EIO, either one.


On Thu, 12 Apr 2012, Andrey Rahmatullin wrote:

> I replaced the hcd_pci_suspend_noirq call with retval=0 and suspend/resume
> was successful.
 
This indicates that your computer doesn't like to suspend while the
EHCI controllers are in D3hot.  I have no idea why not.

If you want a really thorough test, try changing 
drivers/pci/pci-driver.c:pci_pm_suspend_noirq.  In the "if (!pm)" 
clause, add a call to

	pci_prepare_to_sleep(pci_dev);

just after the pci_save_state line.  Then try suspending with the 
script enabled (ehci-hcd unbound from the controllers).  If this fails 
then we'll know it is the source of the trouble.

Alan Stern

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: ehci_hcd related S3 lockup on ASUS laptops, again

[Andrey Rahmatullin]

[-- Attachment #1.1: Type: text/plain, Size: 755 bytes --]

On Wed, Apr 11, 2012 at 05:13:51PM -0400, Alan Stern wrote:
> > I replaced the hcd_pci_suspend_noirq call with retval=0 and suspend/resume
> > was successful.
>  
> This indicates that your computer doesn't like to suspend while the
> EHCI controllers are in D3hot.  I have no idea why not.
> 
> If you want a really thorough test, try changing 
> drivers/pci/pci-driver.c:pci_pm_suspend_noirq.  In the "if (!pm)" 
> clause, add a call to
> 
> 	pci_prepare_to_sleep(pci_dev);
> 
> just after the pci_save_state line.  Then try suspending with the 
> script enabled (ehci-hcd unbound from the controllers).  If this fails 
> then we'll know it is the source of the trouble.
Looks like it works even with this line added.

-- 
WBR, wRAR

[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: ehci_hcd related S3 lockup on ASUS laptops, again

[Steven Rostedt]

On Thu, 2012-04-12 at 04:09 +0600, Andrey Rahmatullin wrote:
> On Wed, Apr 11, 2012 at 05:13:51PM -0400, Alan Stern wrote:
> > > I replaced the hcd_pci_suspend_noirq call with retval=0 and suspend/resume
> > > was successful.
> >  
> > This indicates that your computer doesn't like to suspend while the
> > EHCI controllers are in D3hot.  I have no idea why not.
> > 
> > If you want a really thorough test, try changing 
> > drivers/pci/pci-driver.c:pci_pm_suspend_noirq.  In the "if (!pm)" 
> > clause, add a call to
> > 
> > 	pci_prepare_to_sleep(pci_dev);
> > 
> > just after the pci_save_state line.  Then try suspending with the 
> > script enabled (ehci-hcd unbound from the controllers).  If this fails 
> > then we'll know it is the source of the trouble.
> Looks like it works even with this line added.
> 

I reverted the retval change (that worked) and added this line. Put the
script back and did a suspend. The suspend and resume worked without
issue.

Here's my change just in case I did it incorrectly:

diff --git a/drivers/pci/pci-driver.c b/drivers/pci/pci-driver.c
index 12d1e81..e026390 100644
--- a/drivers/pci/pci-driver.c
+++ b/drivers/pci/pci-driver.c
@@ -713,6 +713,7 @@ static int pci_pm_suspend_noirq(struct device *dev)
 
        if (!pm) {
                pci_save_state(pci_dev);
+               pci_prepare_to_sleep(pci_dev);
                return 0;
        }
 
-- Steve

Re: [linux-pm] ehci_hcd related S3 lockup on ASUS laptops, again

[Alan Stern]

On Wed, 11 Apr 2012, Steven Rostedt wrote:

> On Thu, 2012-04-12 at 04:09 +0600, Andrey Rahmatullin wrote:
> > On Wed, Apr 11, 2012 at 05:13:51PM -0400, Alan Stern wrote:
> > > > I replaced the hcd_pci_suspend_noirq call with retval=0 and suspend/resume
> > > > was successful.
> > >  
> > > This indicates that your computer doesn't like to suspend while the
> > > EHCI controllers are in D3hot.  I have no idea why not.
> > > 
> > > If you want a really thorough test, try changing 
> > > drivers/pci/pci-driver.c:pci_pm_suspend_noirq.  In the "if (!pm)" 
> > > clause, add a call to
> > > 
> > > 	pci_prepare_to_sleep(pci_dev);
> > > 
> > > just after the pci_save_state line.  Then try suspending with the 
> > > script enabled (ehci-hcd unbound from the controllers).  If this fails 
> > > then we'll know it is the source of the trouble.
> > Looks like it works even with this line added.
> > 
> 
> I reverted the retval change (that worked) and added this line. Put the
> script back and did a suspend. The suspend and resume worked without
> issue.

Hmmm.  This is a situation where the wakeup setting might matter.  Did 
the /sys/bus/pci/devices/0000:00:1[ad].0/power/wakeup files both 
contain "enabled" when you ran the test?

Here's a diagnostic patch that will give us a little more information.  
Keep the previous change (so that pci_prepare_to_sleep gets called 
whether ehci-hcd is bound or not) and let's see what it says.  Try 
doing it both with and without ehci-hcd bound.  Running this with "echo 
devices >/sys/power/pm_test" ought to be good enough.

Alan Stern



Index: usb-3.4/drivers/pci/pci.c
===================================================================
--- usb-3.4.orig/drivers/pci/pci.c
+++ usb-3.4/drivers/pci/pci.c
@@ -1720,6 +1720,9 @@ int pci_prepare_to_sleep(struct pci_dev
 
 	error = pci_set_power_state(dev, target_state);
 
+	dev_info(&dev->dev, "target %d wakeup %d error %d\n",
+			target_state, device_may_wakeup(&dev->dev), error);
+
 	if (error)
 		pci_enable_wake(dev, target_state, false);
 

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: ehci_hcd related S3 lockup on ASUS laptops, again

[Andrey Rahmatullin]

[-- Attachment #1.1: Type: text/plain, Size: 2194 bytes --]

On Thu, Apr 12, 2012 at 10:28:31AM -0400, Alan Stern wrote:
> > > > > I replaced the hcd_pci_suspend_noirq call with retval=0 and suspend/resume
> > > > > was successful.
> > > >  
> > > > This indicates that your computer doesn't like to suspend while the
> > > > EHCI controllers are in D3hot.  I have no idea why not.
> > > > 
> > > > If you want a really thorough test, try changing 
> > > > drivers/pci/pci-driver.c:pci_pm_suspend_noirq.  In the "if (!pm)" 
> > > > clause, add a call to
> > > > 
> > > > 	pci_prepare_to_sleep(pci_dev);
> > > > 
> > > > just after the pci_save_state line.  Then try suspending with the 
> > > > script enabled (ehci-hcd unbound from the controllers).  If this fails 
> > > > then we'll know it is the source of the trouble.
> > > Looks like it works even with this line added.
> > > 
> > 
> > I reverted the retval change (that worked) and added this line. Put the
> > script back and did a suspend. The suspend and resume worked without
> > issue.
> 
> Hmmm.  This is a situation where the wakeup setting might matter.  Did 
> the /sys/bus/pci/devices/0000:00:1[ad].0/power/wakeup files both 
> contain "enabled" when you ran the test?
Yes.

> Here's a diagnostic patch that will give us a little more information.  
> Keep the previous change (so that pci_prepare_to_sleep gets called 
> whether ehci-hcd is bound or not) and let's see what it says.  Try 
> doing it both with and without ehci-hcd bound.  Running this with "echo 
> devices >/sys/power/pm_test" ought to be good enough.
I don't see that line with ehci_hcd both bound and unbound and both in
'devices' test and in a real S3.

> Index: usb-3.4/drivers/pci/pci.c
> ===================================================================
> --- usb-3.4.orig/drivers/pci/pci.c
> +++ usb-3.4/drivers/pci/pci.c
> @@ -1720,6 +1720,9 @@ int pci_prepare_to_sleep(struct pci_dev
>  
>  	error = pci_set_power_state(dev, target_state);
>  
> +	dev_info(&dev->dev, "target %d wakeup %d error %d\n",
> +			target_state, device_may_wakeup(&dev->dev), error);
> +
>  	if (error)
>  		pci_enable_wake(dev, target_state, false);
>  
> 
> 

-- 
WBR, wRAR

[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: [linux-pm] ehci_hcd related S3 lockup on ASUS laptops, again

[Alan Stern]

On Thu, 12 Apr 2012, Andrey Rahmatullin wrote:

> > Here's a diagnostic patch that will give us a little more information.  
> > Keep the previous change (so that pci_prepare_to_sleep gets called 
> > whether ehci-hcd is bound or not) and let's see what it says.  Try 
> > doing it both with and without ehci-hcd bound.  Running this with "echo 
> > devices >/sys/power/pm_test" ought to be good enough.
> I don't see that line with ehci_hcd both bound and unbound and both in
> 'devices' test and in a real S3.

You mean the new dev_info message did not appear at all?  Is
pci_prepare_to_sleep getting called properly?  Or does the routine exit
early because target_state is equal to PCI_POWER_ERROR?

Alan Stern

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [linux-pm] ehci_hcd related S3 lockup on ASUS laptops, again

[Andrey Rahmatullin]

[-- Attachment #1: Type: text/plain, Size: 877 bytes --]

On Thu, Apr 12, 2012 at 12:09:00PM -0400, Alan Stern wrote:
> > > Here's a diagnostic patch that will give us a little more information.  
> > > Keep the previous change (so that pci_prepare_to_sleep gets called 
> > > whether ehci-hcd is bound or not) and let's see what it says.  Try 
> > > doing it both with and without ehci-hcd bound.  Running this with "echo 
> > > devices >/sys/power/pm_test" ought to be good enough.
> > I don't see that line with ehci_hcd both bound and unbound and both in
> > 'devices' test and in a real S3.
> 
> You mean the new dev_info message did not appear at all?  Is
> pci_prepare_to_sleep getting called properly?  Or does the routine exit
> early because target_state is equal to PCI_POWER_ERROR?
Either dev_info is silenced on my system or pci_pm_suspend_noirq is not
called during the 'devices' pm test.

-- 
WBR, wRAR

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: ehci_hcd related S3 lockup on ASUS laptops, again

[Steven Rostedt]

On Thu, 2012-04-12 at 22:49 +0600, Andrey Rahmatullin wrote:
> On Thu, Apr 12, 2012 at 12:09:00PM -0400, Alan Stern wrote:
> > > > Here's a diagnostic patch that will give us a little more information.  
> > > > Keep the previous change (so that pci_prepare_to_sleep gets called 
> > > > whether ehci-hcd is bound or not) and let's see what it says.  Try 
> > > > doing it both with and without ehci-hcd bound.  Running this with "echo 
> > > > devices >/sys/power/pm_test" ought to be good enough.
> > > I don't see that line with ehci_hcd both bound and unbound and both in
> > > 'devices' test and in a real S3.
> > 
> > You mean the new dev_info message did not appear at all?  Is
> > pci_prepare_to_sleep getting called properly?  Or does the routine exit
> > early because target_state is equal to PCI_POWER_ERROR?
> Either dev_info is silenced on my system or pci_pm_suspend_noirq is not
> called during the 'devices' pm test.
> 

Did you undo the original change that removed the call to
pci_prepare_to_sleep()?

-- Steve

Re: ehci_hcd related S3 lockup on ASUS laptops, again

[Andrey Rahmatullin]

[-- Attachment #1.1: Type: text/plain, Size: 1068 bytes --]

On Thu, Apr 12, 2012 at 12:52:21PM -0400, Steven Rostedt wrote:
> > > > > Here's a diagnostic patch that will give us a little more information.  
> > > > > Keep the previous change (so that pci_prepare_to_sleep gets called 
> > > > > whether ehci-hcd is bound or not) and let's see what it says.  Try 
> > > > > doing it both with and without ehci-hcd bound.  Running this with "echo 
> > > > > devices >/sys/power/pm_test" ought to be good enough.
> > > > I don't see that line with ehci_hcd both bound and unbound and both in
> > > > 'devices' test and in a real S3.
> > > 
> > > You mean the new dev_info message did not appear at all?  Is
> > > pci_prepare_to_sleep getting called properly?  Or does the routine exit
> > > early because target_state is equal to PCI_POWER_ERROR?
> > Either dev_info is silenced on my system or pci_pm_suspend_noirq is not
> > called during the 'devices' pm test.
> 
> Did you undo the original change that removed the call to
> pci_prepare_to_sleep()?
pci_pm_suspend_noirq itself isn't called.

-- 
WBR, wRAR

[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: ehci_hcd related S3 lockup on ASUS laptops, again

[Steven Rostedt]

On Thu, 2012-04-12 at 10:28 -0400, Alan Stern wrote:

> Hmmm.  This is a situation where the wakeup setting might matter.  Did 
> the /sys/bus/pci/devices/0000:00:1[ad].0/power/wakeup files both 
> contain "enabled" when you ran the test?

They're both enabled for me too.

> 
> Here's a diagnostic patch that will give us a little more information.  
> Keep the previous change (so that pci_prepare_to_sleep gets called 
> whether ehci-hcd is bound or not) and let's see what it says.  Try 
> doing it both with and without ehci-hcd bound.  Running this with "echo 
> devices >/sys/power/pm_test" ought to be good enough.

Where do I read out the dev info?

-- Steve

> 
> Alan Stern
> 
> 
> 
> Index: usb-3.4/drivers/pci/pci.c
> ===================================================================
> --- usb-3.4.orig/drivers/pci/pci.c
> +++ usb-3.4/drivers/pci/pci.c
> @@ -1720,6 +1720,9 @@ int pci_prepare_to_sleep(struct pci_dev
>  
>  	error = pci_set_power_state(dev, target_state);
>  
> +	dev_info(&dev->dev, "target %d wakeup %d error %d\n",
> +			target_state, device_may_wakeup(&dev->dev), error);
> +
>  	if (error)
>  		pci_enable_wake(dev, target_state, false);
>  

Re: ehci_hcd related S3 lockup on ASUS laptops, again

[Alan Stern]

On Thu, 12 Apr 2012, Steven Rostedt wrote:

> On Thu, 2012-04-12 at 10:28 -0400, Alan Stern wrote:
> 
> > Hmmm.  This is a situation where the wakeup setting might matter.  Did 
> > the /sys/bus/pci/devices/0000:00:1[ad].0/power/wakeup files both 
> > contain "enabled" when you ran the test?
> 
> They're both enabled for me too.
> 
> > 
> > Here's a diagnostic patch that will give us a little more information.  
> > Keep the previous change (so that pci_prepare_to_sleep gets called 
> > whether ehci-hcd is bound or not) and let's see what it says.  Try 
> > doing it both with and without ehci-hcd bound.  Running this with "echo 
> > devices >/sys/power/pm_test" ought to be good enough.
> 
> Where do I read out the dev info?

It should appear in the dmesg log after the system returns from the 
suspend test.

> > Index: usb-3.4/drivers/pci/pci.c
> > ===================================================================
> > --- usb-3.4.orig/drivers/pci/pci.c
> > +++ usb-3.4/drivers/pci/pci.c
> > @@ -1720,6 +1720,9 @@ int pci_prepare_to_sleep(struct pci_dev
> >  
> >  	error = pci_set_power_state(dev, target_state);
> >  
> > +	dev_info(&dev->dev, "target %d wakeup %d error %d\n",
> > +			target_state, device_may_wakeup(&dev->dev), error);
> > +
> >  	if (error)
> >  		pci_enable_wake(dev, target_state, false);
> >  

Hmmm, looking at the PCI PM implementation more closely, it does seem a 
little strange.

Rafael, evidently pci_pm_suspend and pci_pm_suspend_noirq don't check
to see if the device is already runtime-suspended.  And if it is, 
there's no check to see if the wakeup settings need to be changed.

In addition, pci_pm_resume doesn't set the runtime status back to 
RPM_ACTIVE.

Is this stuff supposed to be handled at the device level?  It seems 
like the sort of thing that the subsystem code should take care of.

Maybe that's the problem here.  Steve and Andrey, does it make any 
difference to the behavior if you do

	echo on >/sys/bus/pci/devices/0000:00:1a.0/power/control

(and likewise for 1d.0) before starting the system suspend?

Alan Stern

Re: ehci_hcd related S3 lockup on ASUS laptops, again

[Steven Rostedt]

On Thu, 2012-04-12 at 13:06 -0400, Alan Stern wrote:

> > Where do I read out the dev info?
> 
> It should appear in the dmesg log after the system returns from the 
> suspend test.

That's what I thought. I didn't see any message there so I had to ask.


> Maybe that's the problem here.  Steve and Andrey, does it make any 
> difference to the behavior if you do
> 
> 	echo on >/sys/bus/pci/devices/0000:00:1a.0/power/control
> 
> (and likewise for 1d.0) before starting the system suspend?

The two files already are set to "on" (without me doing anything)

-- Steve

Re: ehci_hcd related S3 lockup on ASUS laptops, again

[Andrey Rahmatullin]

[-- Attachment #1.1: Type: text/plain, Size: 422 bytes --]

On Thu, Apr 12, 2012 at 01:14:56PM -0400, Steven Rostedt wrote:
> > Maybe that's the problem here.  Steve and Andrey, does it make any 
> > difference to the behavior if you do
> > 
> > 	echo on >/sys/bus/pci/devices/0000:00:1a.0/power/control
> > 
> > (and likewise for 1d.0) before starting the system suspend?
> 
> The two files already are set to "on" (without me doing anything)
Here too.

-- 
WBR, wRAR

[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: ehci_hcd related S3 lockup on ASUS laptops, again

[Alan Stern]

On Thu, 12 Apr 2012, Steven Rostedt wrote:

> On Thu, 2012-04-12 at 13:06 -0400, Alan Stern wrote:
> 
> > > Where do I read out the dev info?
> > 
> > It should appear in the dmesg log after the system returns from the 
> > suspend test.
> 
> That's what I thought. I didn't see any message there so I had to ask.

Oh, my mistake.  This routine doesn't get called when pm_test is set to 
"devices"; you have to set it to "platform".  Sorry about that.

> > Maybe that's the problem here.  Steve and Andrey, does it make any 
> > difference to the behavior if you do
> > 
> > 	echo on >/sys/bus/pci/devices/0000:00:1a.0/power/control
> > 
> > (and likewise for 1d.0) before starting the system suspend?
> 
> The two files already are set to "on" (without me doing anything)

Okay, so that's not the reason...

Alan Stern

Re: ehci_hcd related S3 lockup on ASUS laptops, again

[Steven Rostedt]

On Thu, 2012-04-12 at 13:48 -0400, Alan Stern wrote:
> On Thu, 12 Apr 2012, Steven Rostedt wrote:
> 
> > On Thu, 2012-04-12 at 13:06 -0400, Alan Stern wrote:
> > 
> > > > Where do I read out the dev info?
> > > 
> > > It should appear in the dmesg log after the system returns from the 
> > > suspend test.
> > 
> > That's what I thought. I didn't see any message there so I had to ask.
> 
> Oh, my mistake.  This routine doesn't get called when pm_test is set to 
> "devices"; you have to set it to "platform".  Sorry about that.

And I forgot that the echo isn't enough, and I need to do a pm-suspend
too ;-)

# dmesg | grep target
[ 8829.427534] atl1c 0000:04:00.0: target 3 wakeup 0 error 0
[ 8829.443524] xhci_hcd 0000:03:00.0: target 3 wakeup 1 error 0
[ 8829.459506] iwlwifi 0000:02:00.0: target 3 wakeup 0 error 0
[ 8829.459560] pci 0000:00:1f.3: target 0 wakeup 0 error 0
[ 8829.459607] pci 0000:00:1f.0: target 0 wakeup 0 error 0
[ 8829.475458] ehci_hcd 0000:00:1d.0: target 3 wakeup 1 error 0
[ 8829.491433] ehci_hcd 0000:00:1a.0: target 3 wakeup 1 error 0
[ 8829.507416] pci 0000:00:16.0: target 3 wakeup 0 error 0

-- Steve

> 
> > > Maybe that's the problem here.  Steve and Andrey, does it make any 
> > > difference to the behavior if you do
> > > 
> > > 	echo on >/sys/bus/pci/devices/0000:00:1a.0/power/control
> > > 
> > > (and likewise for 1d.0) before starting the system suspend?
> > 
> > The two files already are set to "on" (without me doing anything)
> 
> Okay, so that's not the reason...
> 
> Alan Stern

Re: ehci_hcd related S3 lockup on ASUS laptops, again

[Steven Rostedt]

On Thu, 2012-04-12 at 14:17 -0400, Steven Rostedt wrote:

> And I forgot that the echo isn't enough, and I need to do a pm-suspend
> too ;-)
> 
> # dmesg | grep target
> [ 8829.427534] atl1c 0000:04:00.0: target 3 wakeup 0 error 0
> [ 8829.443524] xhci_hcd 0000:03:00.0: target 3 wakeup 1 error 0
> [ 8829.459506] iwlwifi 0000:02:00.0: target 3 wakeup 0 error 0
> [ 8829.459560] pci 0000:00:1f.3: target 0 wakeup 0 error 0
> [ 8829.459607] pci 0000:00:1f.0: target 0 wakeup 0 error 0
> [ 8829.475458] ehci_hcd 0000:00:1d.0: target 3 wakeup 1 error 0
> [ 8829.491433] ehci_hcd 0000:00:1a.0: target 3 wakeup 1 error 0
> [ 8829.507416] pci 0000:00:16.0: target 3 wakeup 0 error 0
> 

The above was without the script, with the script:

# dmesg | grep target
[ 8829.427534] atl1c 0000:04:00.0: target 3 wakeup 0 error 0
[ 8829.443524] xhci_hcd 0000:03:00.0: target 3 wakeup 1 error 0
[ 8829.459506] iwlwifi 0000:02:00.0: target 3 wakeup 0 error 0
[ 8829.459560] pci 0000:00:1f.3: target 0 wakeup 0 error 0
[ 8829.459607] pci 0000:00:1f.0: target 0 wakeup 0 error 0
[ 8829.475458] ehci_hcd 0000:00:1d.0: target 3 wakeup 1 error 0
[ 8829.491433] ehci_hcd 0000:00:1a.0: target 3 wakeup 1 error 0
[ 8829.507416] pci 0000:00:16.0: target 3 wakeup 0 error 0
[ 9419.750158] atl1c 0000:04:00.0: target 3 wakeup 0 error 0
[ 9419.766134] pci 0000:03:00.0: target 3 wakeup 1 error 0
[ 9419.782126] iwlwifi 0000:02:00.0: target 3 wakeup 0 error 0
[ 9419.782181] pci 0000:00:1f.3: target 0 wakeup 0 error 0
[ 9419.782230] pci 0000:00:1f.0: target 0 wakeup 0 error 0
[ 9419.798087] pci 0000:00:1d.0: target 3 wakeup 1 error 0
[ 9419.814064] pci 0000:00:1a.0: target 3 wakeup 1 error 0
[ 9419.830031] pci 0000:00:16.0: target 3 wakeup 0 error 0

-- Steve

Re: ehci_hcd related S3 lockup on ASUS laptops, again

[Alan Stern]

On Thu, 12 Apr 2012, Steven Rostedt wrote:

> On Thu, 2012-04-12 at 14:17 -0400, Steven Rostedt wrote:
> 
> > And I forgot that the echo isn't enough, and I need to do a pm-suspend
> > too ;-)
> > 
> > # dmesg | grep target
> > [ 8829.427534] atl1c 0000:04:00.0: target 3 wakeup 0 error 0
> > [ 8829.443524] xhci_hcd 0000:03:00.0: target 3 wakeup 1 error 0
> > [ 8829.459506] iwlwifi 0000:02:00.0: target 3 wakeup 0 error 0
> > [ 8829.459560] pci 0000:00:1f.3: target 0 wakeup 0 error 0
> > [ 8829.459607] pci 0000:00:1f.0: target 0 wakeup 0 error 0
> > [ 8829.475458] ehci_hcd 0000:00:1d.0: target 3 wakeup 1 error 0
> > [ 8829.491433] ehci_hcd 0000:00:1a.0: target 3 wakeup 1 error 0
> > [ 8829.507416] pci 0000:00:16.0: target 3 wakeup 0 error 0
> > 
> 
> The above was without the script, with the script:
> 
> # dmesg | grep target
> [ 8829.427534] atl1c 0000:04:00.0: target 3 wakeup 0 error 0
> [ 8829.443524] xhci_hcd 0000:03:00.0: target 3 wakeup 1 error 0
> [ 8829.459506] iwlwifi 0000:02:00.0: target 3 wakeup 0 error 0
> [ 8829.459560] pci 0000:00:1f.3: target 0 wakeup 0 error 0
> [ 8829.459607] pci 0000:00:1f.0: target 0 wakeup 0 error 0
> [ 8829.475458] ehci_hcd 0000:00:1d.0: target 3 wakeup 1 error 0
> [ 8829.491433] ehci_hcd 0000:00:1a.0: target 3 wakeup 1 error 0
> [ 8829.507416] pci 0000:00:16.0: target 3 wakeup 0 error 0

The entries above are left over from the earlier test.

> [ 9419.750158] atl1c 0000:04:00.0: target 3 wakeup 0 error 0
> [ 9419.766134] pci 0000:03:00.0: target 3 wakeup 1 error 0
> [ 9419.782126] iwlwifi 0000:02:00.0: target 3 wakeup 0 error 0
> [ 9419.782181] pci 0000:00:1f.3: target 0 wakeup 0 error 0
> [ 9419.782230] pci 0000:00:1f.0: target 0 wakeup 0 error 0
> [ 9419.798087] pci 0000:00:1d.0: target 3 wakeup 1 error 0
> [ 9419.814064] pci 0000:00:1a.0: target 3 wakeup 1 error 0
> [ 9419.830031] pci 0000:00:16.0: target 3 wakeup 0 error 0

Evidently the script unbinds xhci-hcd too.  Did you check to make
sure it is unrelated to the suspend problem?

Anyway, this shows that the EHCI controllers are being set to the same 
power state with the same wakeup settings in both cases.  And yet one 
hangs the computer while the other doesn't.

Here's another rather drastic test you can do.  In 
drivers/usb/host/ehci-pci.c:ehci_pci_suspend(), call ehci_reset(ehci) 
just before the final return statement.  That should leave the hardware 
in exactly the same state as if ehci-hcd had been unbound.

Alan Stern

Re: ehci_hcd related S3 lockup on ASUS laptops, again

[Andrey Rahmatullin]

[-- Attachment #1.1: Type: text/plain, Size: 1092 bytes --]

On Thu, Apr 12, 2012 at 10:28:31AM -0400, Alan Stern wrote:
> Here's a diagnostic patch that will give us a little more information.  
> Keep the previous change (so that pci_prepare_to_sleep gets called 
> whether ehci-hcd is bound or not) and let's see what it says.  Try 
> doing it both with and without ehci-hcd bound.  Running this with "echo 
> devices >/sys/power/pm_test" ought to be good enough.
If bound: "target 3 wakeup 1 error 0" for both controllers. If not bound,
pci_prepare_to_sleep is not called for ehci_hcd.
> 
> Alan Stern
> 
> 
> 
> Index: usb-3.4/drivers/pci/pci.c
> ===================================================================
> --- usb-3.4.orig/drivers/pci/pci.c
> +++ usb-3.4/drivers/pci/pci.c
> @@ -1720,6 +1720,9 @@ int pci_prepare_to_sleep(struct pci_dev
>  
>  	error = pci_set_power_state(dev, target_state);
>  
> +	dev_info(&dev->dev, "target %d wakeup %d error %d\n",
> +			target_state, device_may_wakeup(&dev->dev), error);
> +
>  	if (error)
>  		pci_enable_wake(dev, target_state, false);
>  
> 
> 

-- 
WBR, wRAR

[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: ehci_hcd related S3 lockup on ASUS laptops, again

[Alan Stern]

On Fri, 13 Apr 2012, Andrey Rahmatullin wrote:

> On Thu, Apr 12, 2012 at 10:28:31AM -0400, Alan Stern wrote:
> > Here's a diagnostic patch that will give us a little more information.  
> > Keep the previous change (so that pci_prepare_to_sleep gets called 
> > whether ehci-hcd is bound or not) and let's see what it says.  Try 
> > doing it both with and without ehci-hcd bound.  Running this with "echo 
> > devices >/sys/power/pm_test" ought to be good enough.
> If bound: "target 3 wakeup 1 error 0" for both controllers. If not bound,
> pci_prepare_to_sleep is not called for ehci_hcd.

It should be called, because earlier I asked you to add a call to it 
inside pci_pm_suspend_noirq.  Make sure you that line is still present 
when you test.

Alan Stern

Re: ehci_hcd related S3 lockup on ASUS laptops, again

[Andrey Rahmatullin]

[-- Attachment #1.1: Type: text/plain, Size: 909 bytes --]

On Thu, Apr 12, 2012 at 02:17:27PM -0400, Alan Stern wrote:
> > > Here's a diagnostic patch that will give us a little more information.  
> > > Keep the previous change (so that pci_prepare_to_sleep gets called 
> > > whether ehci-hcd is bound or not) and let's see what it says.  Try 
> > > doing it both with and without ehci-hcd bound.  Running this with "echo 
> > > devices >/sys/power/pm_test" ought to be good enough.
> > If bound: "target 3 wakeup 1 error 0" for both controllers. If not bound,
> > pci_prepare_to_sleep is not called for ehci_hcd.
> 
> It should be called, because earlier I asked you to add a call to it 
> inside pci_pm_suspend_noirq.  Make sure you that line is still present 
> when you test.
Right, it just prints "pci" instead of "ehci_hcd". It's still "target 3
wakeup 1 error 0", right after "Refused to change power state, currently
in D0".

-- 
WBR, wRAR

[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

ehci_hcd related S3 lockup on ASUS laptops, again

[Andrey Rahmatullin]

[-- Attachment #1: Type: text/plain, Size: 929 bytes --]

On many ASUS laptops and probably on some non-ASUS ones you need to unload
ehci_hcd or unbind both USB controllers from it before entering S3, else
the system will lockup. Here are some links:

http://thread.gmane.org/gmane.linux.kernel/1222803
https://bugzilla.kernel.org/show_bug.cgi?id=37632
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=658778
http://ubuntuforums.org/showthread.php?t=1444822

This still happens on my K53E on v3.4-rc2-16-ga9e1e53.

Unbinding just one of two controllers doesn't help.

Disabling /sys/bus/pci/devices/0000:00:1[ad].0/power/wakeup doesn't help.
echo mem>/sys/power/state doesn't hang with 'core' in /sys/power/pm_test,
only with 'none'.

Windows 7 enters S3 perfectly well.

I didn't see any other suggestions how to debug this. I can provide any
debug data if that will help. This seems to be a very important problem
for owners of certain devices.

-- 
WBR, wRAR

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: ehci_hcd related S3 lockup on ASUS laptops, again

[Steven Rostedt]

On Wed, 2012-04-11 at 22:55 +0600, Andrey Rahmatullin wrote:
> On many ASUS laptops and probably on some non-ASUS ones you need to unload
> ehci_hcd or unbind both USB controllers from it before entering S3, else
> the system will lockup. Here are some links:
> 
> http://thread.gmane.org/gmane.linux.kernel/1222803
> https://bugzilla.kernel.org/show_bug.cgi?id=37632
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=658778
> http://ubuntuforums.org/showthread.php?t=1444822
> 
> This still happens on my K53E on v3.4-rc2-16-ga9e1e53.
> 
> Unbinding just one of two controllers doesn't help.
> 
> Disabling /sys/bus/pci/devices/0000:00:1[ad].0/power/wakeup doesn't help.
> echo mem>/sys/power/state doesn't hang with 'core' in /sys/power/pm_test,
> only with 'none'.
> 
> Windows 7 enters S3 perfectly well.
> 
> I didn't see any other suggestions how to debug this. I can provide any
> debug data if that will help. This seems to be a very important problem
> for owners of certain devices.
> 

Yeah, I never got a real fix. I'm still using the script that removes
the driver and adds it back during the suspend/resume sequence. That
seems to be a working work-around for me.

That said, I would love to have this fixed for real. Not just for me,
but for anyone else that is suffering from the same issue. I'm a kernel
developer and can easily include work arounds like this. But for anyone
else, this is a total fail for Linux in general.

I'm willing to test fixes, as the issue still exists for my laptop if I
remove the script.

-- Steve


--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: ehci_hcd related S3 lockup on ASUS laptops, again

[Alan Stern]

On Wed, 11 Apr 2012, Steven Rostedt wrote:

> On Wed, 2012-04-11 at 22:55 +0600, Andrey Rahmatullin wrote:
> > On many ASUS laptops and probably on some non-ASUS ones you need to unload
> > ehci_hcd or unbind both USB controllers from it before entering S3, else
> > the system will lockup. Here are some links:
> > 
> > http://thread.gmane.org/gmane.linux.kernel/1222803
> > https://bugzilla.kernel.org/show_bug.cgi?id=37632
> > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=658778
> > http://ubuntuforums.org/showthread.php?t=1444822
> > 
> > This still happens on my K53E on v3.4-rc2-16-ga9e1e53.
> > 
> > Unbinding just one of two controllers doesn't help.
> > 
> > Disabling /sys/bus/pci/devices/0000:00:1[ad].0/power/wakeup doesn't help.
> > echo mem>/sys/power/state doesn't hang with 'core' in /sys/power/pm_test,
> > only with 'none'.
> > 
> > Windows 7 enters S3 perfectly well.
> > 
> > I didn't see any other suggestions how to debug this. I can provide any
> > debug data if that will help. This seems to be a very important problem
> > for owners of certain devices.
> > 
> 
> Yeah, I never got a real fix. I'm still using the script that removes
> the driver and adds it back during the suspend/resume sequence. That
> seems to be a working work-around for me.
> 
> That said, I would love to have this fixed for real. Not just for me,
> but for anyone else that is suffering from the same issue. I'm a kernel
> developer and can easily include work arounds like this. But for anyone
> else, this is a total fail for Linux in general.
> 
> I'm willing to test fixes, as the issue still exists for my laptop if I
> remove the script.

It would be great if we had something to try out.  So far I'm not aware
of any suggestions from anybody as to the underlying cause of the
problem or how to fix it.

Ideas welcome.

Alan Stern

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [linux-pm] ehci_hcd related S3 lockup on ASUS laptops, again

[Alan Stern]

On Wed, 11 Apr 2012, Alan Stern wrote:

> On Wed, 11 Apr 2012, Steven Rostedt wrote:

> > I'm willing to test fixes, as the issue still exists for my laptop if I
> > remove the script.
> 
> It would be great if we had something to try out.  So far I'm not aware
> of any suggestions from anybody as to the underlying cause of the
> problem or how to fix it.
> 
> Ideas welcome.

All right, here are some ideas.  As far as I can tell, there's only a
handful of differences in the EHCI hardware state between a normal
suspend and a suspend in which ehci-hcd has been removed or unbound.

There are several differences in the controller registers that I
seriously doubt will have any effect.  These are things like the
ASYNCLISTADDR register, which contains the address of the start of the
async schedule when the driver is present and 0 when the driver is not 
present.  These registers are ignored when the controller isn't 
actively running.

There's also the port status & control register for port 1.  When the
driver is present, this register indicate that the port is enabled
(it's connected to the built-in "rate-matching" hub), whereas without
the driver the port is disabled.  We could test whether disabling the
port makes any difference, but I hope it doesn't -- disabling the port
has the effect of logically disconnecting everything that was connected
to the controller.

Finally there's one more thing: the CONFIGFLAG register.  Without the
driver this register contains 0, and the driver sets it to 1.  For the
Intel chipset you're using this shouldn't do anything, because this bit
controls port routing between the EHCI controller and the companion
controller, and your chipset has no companion controller.  I haven't
looked at the datasheet for Intel's Cougar Point chipset, and it's
possible they have repurposed this register.

If so, setting the value back to 0 before suspending (or never setting 
it to 1 in the first place) might be important.  You can test this 
easily enough.  In drivers/usb/host/ehci-pci.c:ehci_pci_suspend(), add 
a line saying

	ehci_writel(ehci, 0, &ehci->regs->configured_flag);

just before the spin_lock_irqrestore.  This will invalidate the
driver's criterion for determining whether or not the controller's
state got messed up during the suspend; we can worry about that later.


There are other differences, at the PCI level, that might also be 
significant.  When the driver is not present, the PCI core calls 
pci_disable_enabled_device.  But when the driver is loaded, instead 
it calls pci_disable_device and pci_prepare_to_sleep.

You can try getting rid of the call to pci_prepare_to_sleep in 
drivers/usb/core/hcd-pci.c:hcd_pci_suspend_noirq.  This will prevent 
the controller from being put into D3hot and might interfere with 
wakeup detection.

I don't know how sigificant the difference is between
pci_disable_device and pci_disable_enabled_device.  Probably not very, 
since all it involves is whether or not to disable bus-mastering on the 
controller.

Alan Stern

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: ehci_hcd related S3 lockup on ASUS laptops, again

[Andrey Rahmatullin]

[-- Attachment #1.1: Type: text/plain, Size: 630 bytes --]

On Wed, Apr 11, 2012 at 03:12:13PM -0400, Alan Stern wrote:
> You can try getting rid of the call to pci_prepare_to_sleep in 
> drivers/usb/core/hcd-pci.c:hcd_pci_suspend_noirq.  This will prevent 
> the controller from being put into D3hot and might interfere with 
> wakeup detection.
> 
> I don't know how sigificant the difference is between
> pci_disable_device and pci_disable_enabled_device.  Probably not very, 
> since all it involves is whether or not to disable bus-mastering on the 
> controller.
I replaced the hcd_pci_suspend_noirq call with retval=0 and suspend/resume
was successful.

-- 
WBR, wRAR

[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]