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

[Andrey Rahmatullin]

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

On Sat, Apr 21, 2012 at 02:50:18PM -0400, Steven Rostedt wrote:
> > > (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.
> Where do you see those checkboxes?
Device Manager

-- 
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 Sat, 2012-04-21 at 14:37 +0600, Andrey Rahmatullin wrote:

> > (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.

Where do you see those checkboxes?

-- 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 Sat, 21 Apr 2012, Andrey Rahmatullin wrote:

> 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.

Ha!  It seems that nobody knows how to make it work.

> > 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'.

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

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 Fri, 20 Apr 2012, Steven Rostedt wrote:

> 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?

No idea.

> > 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?

No patches, and the script doesn't matter because the test doesn't 
involve putting the computer to sleep.

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

[Steven Rostedt]

On Thu, 2012-04-19 at 14:13 -0400, Alan Stern wrote:

> > 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.

Yep, after making the fix, it suspends fine.

But after setting all the power/wakeup to enabled, mine didn't wake up
when putting in a usb device. I had no lights either (unlike Andrey).

I've just set CONFIG_USB_DEBUG and I'm recompiling.

-- 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

[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: [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: [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

[Steven Rostedt]

On Thu, 2012-04-19 at 09:43 -0400, Alan Stern wrote:
> On Wed, 18 Apr 2012, Alan Stern wrote:
> 
> > Tomorrow we can try to figure out the appropriate workaround.
> 
> 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 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.

-- 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 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/.
> Should I change them if they say "disabled"?

Yes, write "enabled" to them.

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: 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: [linux-pm] ehci_hcd related S3 lockup on ASUS laptops, again

[Andrey Rahmatullin]

[-- Attachment #1: Type: text/plain, Size: 406 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/.
Should I change them if they say "disabled"?

-- 
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 Wed, 18 Apr 2012, Alan Stern wrote:

> Tomorrow we can try to figure out the appropriate workaround.

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.

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
@@ -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;
 

--
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: [linux-pm] ehci_hcd related S3 lockup on ASUS laptops, again

[Steven Rostedt]

On Wed, 2012-04-18 at 17:27 -0400, Alan Stern wrote:

> > Below is the dmesg output after running with pm_test set to "platform".
> 
> The part you included didn't show the suspend itself.  It looks like a 
> bunch of stuff following the resume.  But I guess it doesn't much 
> matter, since we now know what needs to be fixed.

Oops sorry. Even though Andrey posted stuff, I'll post this anyway.

Should include everything you need.

-- Steve


[   42.896778] Intel AES-NI instructions are not detected.
[   43.470301] PM: Starting manual resume from disk
[   43.470384] PM: Hibernation image partition 254:2 present
[   43.470386] PM: Looking for hibernation image.
[   43.470862] PM: Image not found (code -22)
[   43.470864] PM: Hibernation image not present or could not be loaded.
[   43.478348] EXT4-fs (dm-1): INFO: recovery required on readonly filesystem
[   43.478434] EXT4-fs (dm-1): write access will be enabled during recovery
[   43.898420] EXT4-fs (dm-1): recovery complete
[   43.899517] EXT4-fs (dm-1): mounted filesystem with ordered data mode. Opts: (null)
[   45.842764] udev[396]: starting version 164
[   46.558691] input: Lid Switch as /devices/LNXSYSTM:00/device:00/PNP0C0D:00/input/input1
[   46.563721] input: PC Speaker as /devices/platform/pcspkr/input/input2
[   46.573988] ACPI: Lid Switch [LID]
[   46.574101] input: Sleep Button as /devices/LNXSYSTM:00/device:00/PNP0C0E:00/input/input3
[   46.574186] ACPI: Sleep Button [SLPB]
[   46.574281] input: Power Button as /devices/LNXSYSTM:00/LNXPWRBN:00/input/input4
[   46.574360] ACPI: Power Button [PWRF]
[   46.580765] wmi: Mapper loaded
[   46.617519] ACPI: AC Adapter [AC0] (on-line)
[   46.635591] Monitor-Mwait will be used to enter C-1 state
[   46.635645] Monitor-Mwait will be used to enter C-2 state
[   46.635673] ACPI: acpi_idle registered with cpuidle
[   46.650782] ACPI: Battery Slot [BAT0] (battery present)
[   46.690831] cfg80211: Calling CRDA to update world regulatory domain
[   46.766509] pci_hotplug: PCI Hot Plug PCI Core version: 0.5
[   46.772575] i801_smbus 0000:00:1f.3: PCI INT C -> GSI 18 (level, low) -> IRQ 18
[   46.772658] ACPI: resource 0000:00:1f.3 [io  0xe040-0xe05f] conflicts with ACPI region SMBI [io 0xe040-0xe04f]
[   46.772740] ACPI: If an ACPI driver is available for this device, you should use it instead of the native driver
[   46.818531] Linux media interface: v0.10
[   46.825793] Bluetooth: Core ver 2.16
[   46.825868] NET: Registered protocol family 31
[   46.825931] Bluetooth: HCI device and connection manager initialized
[   46.825996] Bluetooth: HCI socket layer initialized
[   46.826059] Bluetooth: L2CAP socket layer initialized
[   46.826125] Bluetooth: SCO socket layer initialized
[   46.840697] asus_wmi: ASUS WMI generic driver loaded
[   46.938273] xhci_hcd 0000:03:00.0: PCI INT A -> GSI 19 (level, low) -> IRQ 19
[   46.938427] xhci_hcd 0000:03:00.0: setting latency timer to 64
[   46.938432] xhci_hcd 0000:03:00.0: xHCI Host Controller
[   46.938505] xhci_hcd 0000:03:00.0: new USB bus registered, assigned bus number 3
[   46.948266] xhci_hcd 0000:03:00.0: irq 19, io mem 0xdde00000
[   46.948397] xhci_hcd 0000:03:00.0: irq 45 for MSI/MSI-X
[   46.948400] xhci_hcd 0000:03:00.0: irq 46 for MSI/MSI-X
[   46.948404] xhci_hcd 0000:03:00.0: irq 47 for MSI/MSI-X
[   46.948407] xhci_hcd 0000:03:00.0: irq 48 for MSI/MSI-X
[   46.948410] xhci_hcd 0000:03:00.0: irq 49 for MSI/MSI-X
[   46.948518] usb usb3: New USB device found, idVendor=1d6b, idProduct=0002
[   46.948586] usb usb3: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[   46.948664] usb usb3: Product: xHCI Host Controller
[   46.948725] usb usb3: Manufacturer: Linux 3.2.5-custom+ xhci_hcd
[   46.948790] usb usb3: SerialNumber: 0000:03:00.0
[   46.948929] xHCI xhci_add_endpoint called for root hub
[   46.948931] xHCI xhci_check_bandwidth called for root hub
[   46.948959] hub 3-0:1.0: USB hub found
[   46.949027] hub 3-0:1.0: 2 ports detected
[   46.949144] xhci_hcd 0000:03:00.0: xHCI Host Controller
[   46.949216] xhci_hcd 0000:03:00.0: new USB bus registered, assigned bus number 4
[   46.949316] usb usb4: New USB device found, idVendor=1d6b, idProduct=0003
[   46.949384] usb usb4: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[   46.949462] usb usb4: Product: xHCI Host Controller
[   46.949524] usb usb4: Manufacturer: Linux 3.2.5-custom+ xhci_hcd
[   46.949588] usb usb4: SerialNumber: 0000:03:00.0
[   46.949706] xHCI xhci_add_endpoint called for root hub
[   46.949708] xHCI xhci_check_bandwidth called for root hub
[   46.949731] hub 4-0:1.0: USB hub found
[   46.949798] hub 4-0:1.0: 2 ports detected
[   46.979554] asus_wmi: Initialization: 0x1
[   46.979632] asus_wmi: BIOS WMI version: 7.6
[   46.979788] asus_wmi: SFUN value: 0xa0877
[   46.980446] input: Asus WMI hotkeys as /devices/platform/asus-nb-wmi/input/input5
[   47.042230] asus_wmi: Backlight controlled by ACPI video driver
[   47.117511] Bluetooth: Generic Bluetooth USB driver ver 0.6
[   47.117715] usbcore: registered new interface driver btusb
[   47.139336] Intel(R) Wireless WiFi Link AGN driver for Linux, in-tree:
[   47.139398] Copyright(c) 2003-2011 Intel Corporation
[   47.139488] iwlwifi 0000:02:00.0: PCI INT A -> GSI 17 (level, low) -> IRQ 17
[   47.139553] iwlwifi 0000:02:00.0: setting latency timer to 64
[   47.139575] iwlwifi 0000:02:00.0: pci_resource_len = 0x00002000
[   47.139633] iwlwifi 0000:02:00.0: pci_resource_base = ffffc90005790000
[   47.139691] iwlwifi 0000:02:00.0: HW Revision ID = 0x34
[   47.139821] iwlwifi 0000:02:00.0: irq 50 for MSI/MSI-X
[   47.139852] iwlwifi 0000:02:00.0: Detected Intel(R) Centrino(R) Wireless-N 1030 BGN, REV=0xB0
[   47.139983] iwlwifi 0000:02:00.0: L1 Disabled; Enabling L0S
[   47.155846] iwlwifi 0000:02:00.0: device EEPROM VER=0x716, CALIB=0x6
[   47.155908] iwlwifi 0000:02:00.0: Device SKU: 0X150
[   47.155967] iwlwifi 0000:02:00.0: Valid Tx ant: 0X1, Valid Rx ant: 0X3
[   47.156035] iwlwifi 0000:02:00.0: Tunable channels: 13 802.11bg, 0 802.11a channels
[   47.199920] snd_hda_intel 0000:00:1b.0: PCI INT A -> GSI 22 (level, low) -> IRQ 22
[   47.200042] snd_hda_intel 0000:00:1b.0: irq 51 for MSI/MSI-X
[   47.200067] snd_hda_intel 0000:00:1b.0: setting latency timer to 64
[   47.275349] Linux video capture interface: v2.00
[   47.303064] uvcvideo: Found UVC 1.00 device USB 2.0 UVC VGA WebCam (13d3:5710)
[   47.309669] input: USB 2.0 UVC VGA WebCam as /devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.2/1-1.2:1.0/input/input6
[   47.309818] usbcore: registered new interface driver uvcvideo
[   47.309881] USB Video Class driver (1.1.1)
[   47.310221] [drm] Initialized drm 1.1.0 20060810
[   47.392764] psmouse serio4: synaptics: Touchpad model: 1, fw: 7.5, id: 0x1e0b1, caps: 0xd00073/0x240000/0xa0400
[   47.426245] input: SynPS/2 Synaptics TouchPad as /devices/platform/i8042/serio4/input/input7
[   47.661923] iwlwifi 0000:02:00.0: loaded firmware version 17.168.5.1 build 33993
[   47.662161] Registered led device: phy0-led
[   47.694429] ieee80211 phy0: Selected rate control algorithm 'iwl-agn-rs'
[   47.963645] HDMI status: Codec=3 Pin=6 Presence_Detect=0 ELD_Valid=0
[   47.963854] input: HDA Intel PCH HDMI/DP,pcm=3 as /devices/pci0000:00/0000:00:1b.0/sound/card0/input8
[   47.964240] input: HDA Intel PCH Mic as /devices/pci0000:00/0000:00:1b.0/sound/card0/input9
[   47.964430] input: HDA Intel PCH Headphone as /devices/pci0000:00/0000:00:1b.0/sound/card0/input10
[   47.964770] i915 0000:00:02.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16
[   47.964834] i915 0000:00:02.0: setting latency timer to 64
[   48.048682] i915 0000:00:02.0: irq 52 for MSI/MSI-X
[   48.048687] [drm] Supports vblank timestamp caching Rev 1 (10.10.2010).
[   48.048748] [drm] Driver supports precise vblank timestamp query.
[   48.048838] vgaarb: device changed decodes: PCI:0000:00:02.0,olddecodes=io+mem,decodes=io+mem:owns=io+mem
[   48.683726] fbcon: inteldrmfb (fb0) is primary device
[   48.924618] Console: switching to colour frame buffer device 170x48
[   48.926877] fb0: inteldrmfb frame buffer device
[   48.926878] drm: registered panic notifier
[   48.979505] ACPI Warning: _BQC returned an invalid level (20110623/video-472)
[   48.979864] acpi device:40: registered as cooling_device4
[   48.980218] input: Video Bus as /devices/LNXSYSTM:00/device:00/PNP0A08:00/LNXVIDEO:00/input/input11
[   48.980302] ACPI: Video Device [GFX0] (multi-head: yes  rom: no  post: no)
[   48.980411] [drm] Initialized i915 1.6.0 20080730 for 0000:00:02.0 on minor 0
[   49.417304] EXT4-fs (dm-1): re-mounted. Opts: (null)
[   49.610562] EXT4-fs (dm-1): re-mounted. Opts: errors=remount-ro
[   49.833738] loop: module loaded
[   50.257032] Adding 7811068k swap on /dev/mapper/VG00-Swap.  Priority:-1 extents:1 across:7811068k 
[   51.068930] kjournald starting.  Commit interval 5 seconds
[   51.069511] EXT3-fs (sda5): using internal journal
[   51.069516] EXT3-fs (sda5): mounted filesystem with ordered data mode
[   51.137232] EXT4-fs (dm-3): mounted filesystem with ordered data mode. Opts: (null)
[   52.829790] fuse init (API version 7.17)
[   54.025020] RPC: Registered named UNIX socket transport module.
[   54.025801] RPC: Registered udp transport module.
[   54.026556] RPC: Registered tcp transport module.
[   54.027316] RPC: Registered tcp NFSv4.1 backchannel transport module.
[   54.396007] Installing knfsd (copyright (C) 1996 okir-pn4DOG8n3UYbFoVRYvo4fw@public.gmane.org).
[   54.759224] input: ACPI Virtual Keyboard Device as /devices/virtual/input/input12
[   56.352662] svc: failed to register lockdv1 RPC service (errno 97).
[   56.353371] NFSD: Using /var/lib/nfs/v4recovery as the NFSv4 state recovery directory
[   56.366818] NFSD: starting 90-second grace period
[   58.198428] iwlwifi 0000:02:00.0: L1 Disabled; Enabling L0S
[   58.206338] iwlwifi 0000:02:00.0: Radio type=0x2-0x2-0x1
[   58.298416] iwlwifi 0000:02:00.0: L1 Disabled; Enabling L0S
[   58.307383] iwlwifi 0000:02:00.0: Radio type=0x2-0x2-0x1
[   58.395490] ADDRCONF(NETDEV_UP): wlan0: link is not ready
[   58.404550] atl1c 0000:04:00.0: irq 53 for MSI/MSI-X
[   58.489997] ADDRCONF(NETDEV_UP): eth0: link is not ready
[   67.638348] Bluetooth: BNEP (Ethernet Emulation) ver 1.3
[   67.638352] Bluetooth: BNEP filters: protocol multicast
[   67.710164] Bridge firewalling registered
[   67.777648] Bluetooth: RFCOMM TTY layer initialized
[   67.777664] Bluetooth: RFCOMM socket layer initialized
[   67.777668] Bluetooth: RFCOMM ver 1.11
[   70.854657] lp: driver loaded but no devices found
[   70.871763] ppdev: user-space parallel port driver
[   74.010024] sshd (2152): /proc/2152/oom_adj is deprecated, please use /proc/2152/oom_score_adj instead.
[   88.946287] wlan0: authenticate with e0:91:f5:5e:86:d4 (try 1)
[   88.949046] wlan0: authenticated
[   88.949130] wlan0: associate with e0:91:f5:5e:86:d4 (try 1)
[   88.952812] wlan0: RX AssocResp from e0:91:f5:5e:86:d4 (capab=0x411 status=0 aid=6)
[   88.952815] wlan0: associated
[   88.959397] ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready
[   99.259619] wlan0: no IPv6 routers present
[  126.278905] iwlwifi 0000:02:00.0: Tx aggregation enabled on ra = e0:91:f5:5e:86:d4 tid = 6
[  157.542516] ehci_hcd 0000:00:1a.0: remove, state 1
[  157.544628] usb usb1: USB disconnect, device number 1
[  157.546782] usb 1-1: USB disconnect, device number 2
[  157.549045] usb 1-1.1: USB disconnect, device number 3
[  157.551452] usb 1-1: clear tt 1 (9032) error -19
[  157.551485] Bluetooth: hci0 urb ffff88022f4d1d80 submission failed
[  157.802999] usb 1-1.2: USB disconnect, device number 4
[  157.866578] ehci_hcd 0000:00:1a.0: USB bus 1 deregistered
[  157.869037] ehci_hcd 0000:00:1a.0: PCI INT A disabled
[  157.871489] ehci_hcd 0000:00:1d.0: remove, state 4
[  157.873594] usb usb2: USB disconnect, device number 1
[  157.875670] usb 2-1: USB disconnect, device number 2
[  157.882492] ehci_hcd 0000:00:1d.0: USB bus 2 deregistered
[  157.884674] ehci_hcd 0000:00:1d.0: PCI INT A disabled
[  158.215336] wlan0: deauthenticating from e0:91:f5:5e:86:d4 by local choice (reason=3)
[  158.427757] cfg80211: Calling CRDA to update world regulatory domain
[  158.949659] PM: Syncing filesystems ... done.
[  158.950715] PM: Preparing system for mem sleep
[  158.951081] Freezing user space processes ... (elapsed 0.01 seconds) done.
[  158.966690] Freezing remaining freezable tasks ... (elapsed 0.01 seconds) done.
[  158.982673] PM: Entering mem sleep
[  158.982783] Suspending console(s) (use no_console_suspend to debug)
[  158.983044] sd 0:0:0:0: [sda] Synchronizing SCSI cache
[  159.025372] pci 0000:00:1f.3: PCI INT C disabled
[  159.173746] sd 0:0:0:0: [sda] Stopping disk
[  159.230634] snd_hda_intel 0000:00:1b.0: PCI INT A disabled
[  159.585813] PM: suspend of devices complete after 603.884 msecs
[  159.601635] atl1c 0000:04:00.0: cur 0 target 3 error 0
[  159.601762] xhci_hcd 0000:03:00.0: PME# enabled
[  159.601769] pcieport 0000:00:1c.3: wake-up capability enabled by ACPI
[  159.617624] xhci_hcd 0000:03:00.0: cur 0 target 3 error 0
[  159.633600] iwlwifi 0000:02:00.0: cur 0 target 3 error 0
[  159.633654] pci 0000:00:1f.3: cur 0 target 0 error 0
[  159.633703] pci 0000:00:1f.0: cur 5 target 0 error 0
[  159.633734] pci 0000:00:1d.0: PME# enabled
[  159.633739] pci 0000:00:1d.0: wake-up capability enabled by ACPI
[  159.649551] pci 0000:00:1d.0: cur 0 target 3 error 0
[  159.649629] pci 0000:00:1a.0: PME# enabled
[  159.649656] pci 0000:00:1a.0: wake-up capability enabled by ACPI
[  159.665525] pci 0000:00:1a.0: cur 0 target 3 error 0
[  159.681497] pci 0000:00:16.0: Refused to change power state, currently in D0
[  159.681506] pci 0000:00:16.0: cur 5 target 3 error 0
[  159.681571] PM: late suspend of devices complete after 95.909 msecs
[  159.682243] ACPI: Preparing to enter system sleep state S3
[  161.191414] PM: Saving platform NVS memory
[  161.192356] suspend debug: Waiting for 5 seconds.
[  166.142910] ACPI: Waking up from system sleep state S3
[  166.230892] i915 0000:00:02.0: BAR 0: set to [mem 0xdd000000-0xdd3fffff 64bit] (PCI address [0xdd000000-0xdd3fffff])
[  166.230907] i915 0000:00:02.0: BAR 2: set to [mem 0xc0000000-0xcfffffff 64bit pref] (PCI address [0xc0000000-0xcfffffff])
[  166.230917] i915 0000:00:02.0: BAR 4: set to [io  0xe000-0xe03f] (PCI address [0xe000-0xe03f])
[  166.230951] i915 0000:00:02.0: restoring config space at offset 0x1 (was 0x900403, writing 0x900407)
[  166.246866] pci 0000:00:1a.0: BAR 0: set to [mem 0xdfc08000-0xdfc083ff] (PCI address [0xdfc08000-0xdfc083ff])
[  166.246900] pci 0000:00:1a.0: restoring config space at offset 0xf (was 0x100, writing 0x10b)
[  166.246942] pci 0000:00:1a.0: restoring config space at offset 0x1 (was 0x2900000, writing 0x2900002)
[  166.262844] snd_hda_intel 0000:00:1b.0: BAR 0: set to [mem 0xdfc00000-0xdfc03fff 64bit] (PCI address [0xdfc00000-0xdfc03fff])
[  166.262883] snd_hda_intel 0000:00:1b.0: restoring config space at offset 0xf (was 0x100, writing 0x105)
[  166.262920] snd_hda_intel 0000:00:1b.0: restoring config space at offset 0x3 (was 0x0, writing 0x10)
[  166.262941] snd_hda_intel 0000:00:1b.0: restoring config space at offset 0x1 (was 0x100000, writing 0x100002)
[  166.278813] pci 0000:00:1d.0: BAR 0: set to [mem 0xdfc07000-0xdfc073ff] (PCI address [0xdfc07000-0xdfc073ff])
[  166.278848] pci 0000:00:1d.0: restoring config space at offset 0xf (was 0x100, writing 0x105)
[  166.278889] pci 0000:00:1d.0: restoring config space at offset 0x1 (was 0x2900000, writing 0x2900002)
[  166.294842] ahci 0000:00:1f.2: restoring config space at offset 0x1 (was 0x2b00403, writing 0x2b00407)
[  166.310776] iwlwifi 0000:02:00.0: BAR 0: set to [mem 0xde800000-0xde801fff 64bit] (PCI address [0xde800000-0xde801fff])
[  166.310837] iwlwifi 0000:02:00.0: restoring config space at offset 0xf (was 0x100, writing 0x105)
[  166.310901] iwlwifi 0000:02:00.0: restoring config space at offset 0x1 (was 0x100000, writing 0x100006)
[  166.326745] xhci_hcd 0000:03:00.0: BAR 0: set to [mem 0xdde00000-0xdde07fff 64bit] (PCI address [0xdde00000-0xdde07fff])
[  166.326906] pcieport 0000:00:1c.3: wake-up capability disabled by ACPI
[  166.326912] xhci_hcd 0000:03:00.0: PME# disabled
[  166.342863] PM: early resume of devices complete after 127.606 msecs
[  166.342935] i915 0000:00:02.0: setting latency timer to 64
[  166.342940] pci 0000:00:1a.0: wake-up capability disabled by ACPI
[  166.342947] pci 0000:00:1a.0: PME# disabled
[  166.342950] snd_hda_intel 0000:00:1b.0: PCI INT A -> GSI 22 (level, low) -> IRQ 22
[  166.342961] snd_hda_intel 0000:00:1b.0: setting latency timer to 64
[  166.342970] pci 0000:00:1d.0: wake-up capability disabled by ACPI
[  166.342976] pci 0000:00:1d.0: PME# disabled
[  166.342984] pci 0000:00:1f.3: PCI INT C -> GSI 18 (level, low) -> IRQ 18
[  166.342987] ahci 0000:00:1f.2: setting latency timer to 64
[  166.343018] xhci_hcd 0000:03:00.0: setting latency timer to 64
[  166.343039] snd_hda_intel 0000:00:1b.0: irq 51 for MSI/MSI-X
[  166.343042] usb usb3: root hub lost power or was reset
[  166.343043] usb usb4: root hub lost power or was reset
[  166.343140] sd 0:0:0:0: [sda] Starting disk
[  166.347650] xhci_hcd 0000:03:00.0: irq 45 for MSI/MSI-X
[  166.347653] xhci_hcd 0000:03:00.0: irq 46 for MSI/MSI-X
[  166.347657] xhci_hcd 0000:03:00.0: irq 47 for MSI/MSI-X
[  166.347661] xhci_hcd 0000:03:00.0: irq 48 for MSI/MSI-X
[  166.347665] xhci_hcd 0000:03:00.0: irq 49 for MSI/MSI-X
[  166.662204] ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
[  166.670183] ata3: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
[  166.673729] ata1.00: ACPI cmd f5/00:00:00:00:00:a0 (SECURITY FREEZE LOCK) filtered out
[  166.683187] ata1.00: ACPI cmd ef/10:06:00:00:00:a0 (SET FEATURES) succeeded
[  166.683190] ata1.00: ACPI cmd ef/10:03:00:00:00:a0 (SET FEATURES) filtered out
[  166.684986] ata3.00: ACPI cmd ef/10:06:00:00:00:a0 (SET FEATURES) succeeded
[  166.684996] ata3.00: ACPI cmd ef/10:03:00:00:00:a0 (SET FEATURES) filtered out
[  166.713928] ata3.00: ACPI cmd ef/10:06:00:00:00:a0 (SET FEATURES) succeeded
[  166.713938] ata3.00: ACPI cmd ef/10:03:00:00:00:a0 (SET FEATURES) filtered out
[  166.726782] ata3.00: configured for UDMA/100
[  168.627624] ata1.00: ACPI cmd f5/00:00:00:00:00:a0 (SECURITY FREEZE LOCK) filtered out
[  168.627913] ata1.00: ACPI cmd ef/10:06:00:00:00:a0 (SET FEATURES) succeeded
[  168.627923] ata1.00: ACPI cmd ef/10:03:00:00:00:a0 (SET FEATURES) filtered out
[  168.628796] ata1.00: configured for UDMA/133
[  168.660546] PM: resume of devices complete after 2321.391 msecs
[  168.660712] PM: Finishing wakeup.
[  168.660713] Restarting tasks ... done.
[  168.665650] video LNXVIDEO:00: Restoring backlight state
[  168.701530] iwlwifi 0000:02:00.0: L1 Disabled; Enabling L0S
[  168.709187] iwlwifi 0000:02:00.0: Radio type=0x2-0x2-0x1
[  168.801144] ADDRCONF(NETDEV_UP): wlan0: link is not ready
[  168.803561] atl1c 0000:04:00.0: irq 53 for MSI/MSI-X
[  168.888515] ADDRCONF(NETDEV_UP): eth0: link is not ready
[  168.898150] ehci_hcd 0000:00:1a.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16
[  168.900556] ehci_hcd 0000:00:1a.0: setting latency timer to 64
[  168.900566] ehci_hcd 0000:00:1a.0: EHCI Host Controller
[  168.902803] ehci_hcd 0000:00:1a.0: new USB bus registered, assigned bus number 1
[  168.905033] ehci_hcd 0000:00:1a.0: debug port 2
[  168.911060] ehci_hcd 0000:00:1a.0: cache line size of 64 is not supported
[  168.911074] ehci_hcd 0000:00:1a.0: irq 16, io mem 0xdfc08000
[  168.926501] ehci_hcd 0000:00:1a.0: USB 2.0 started, EHCI 1.00
[  168.927782] usb usb1: New USB device found, idVendor=1d6b, idProduct=0002
[  168.929028] usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[  168.930280] usb usb1: Product: EHCI Host Controller
[  168.931159] usb usb1: Manufacturer: Linux 3.2.5-custom+ ehci_hcd
[  168.931825] usb usb1: SerialNumber: 0000:00:1a.0
[  168.932636] hub 1-0:1.0: USB hub found
[  168.933580] hub 1-0:1.0: 2 ports detected
[  168.958631] ehci_hcd 0000:00:1d.0: PCI INT A -> GSI 23 (level, low) -> IRQ 23
[  168.959979] ehci_hcd 0000:00:1d.0: setting latency timer to 64
[  168.959985] ehci_hcd 0000:00:1d.0: EHCI Host Controller
[  168.961010] ehci_hcd 0000:00:1d.0: new USB bus registered, assigned bus number 2
[  168.961888] ehci_hcd 0000:00:1d.0: debug port 2
[  168.966644] ehci_hcd 0000:00:1d.0: cache line size of 64 is not supported
[  168.966659] ehci_hcd 0000:00:1d.0: irq 23, io mem 0xdfc07000
[  168.982442] ehci_hcd 0000:00:1d.0: USB 2.0 started, EHCI 1.00
[  168.984712] usb usb2: New USB device found, idVendor=1d6b, idProduct=0002
[  168.986937] usb usb2: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[  168.989072] usb usb2: Product: EHCI Host Controller
[  168.991221] usb usb2: Manufacturer: Linux 3.2.5-custom+ ehci_hcd
[  168.993345] usb usb2: SerialNumber: 0000:00:1d.0
[  168.995824] hub 2-0:1.0: USB hub found
[  168.996495] hub 2-0:1.0: 2 ports detected
[  169.246068] usb 1-1: new high-speed USB device number 2 using ehci_hcd
[  169.378364] usb 1-1: New USB device found, idVendor=8087, idProduct=0024
[  169.380124] usb 1-1: New USB device strings: Mfr=0, Product=0, SerialNumber=0
[  169.382318] hub 1-1:1.0: USB hub found
[  169.384196] hub 1-1:1.0: 6 ports detected
[  169.497629] usb 2-1: new high-speed USB device number 2 using ehci_hcd
[  169.629894] usb 2-1: New USB device found, idVendor=8087, idProduct=0024
[  169.632100] usb 2-1: New USB device strings: Mfr=0, Product=0, SerialNumber=0
[  169.635009] hub 2-1:1.0: USB hub found
[  169.637506] hub 2-1:1.0: 6 ports detected
[  169.713401] usb 1-1.1: new full-speed USB device number 3 using ehci_hcd
[  169.809382] usb 1-1.1: New USB device found, idVendor=8086, idProduct=0189
[  169.811659] usb 1-1.1: New USB device strings: Mfr=0, Product=0, SerialNumber=0
[  169.822285] wlan0: authenticate with e0:91:f5:5e:86:d4 (try 1)
[  169.825100] wlan0: authenticated
[  169.825502] wlan0: waiting for beacon from e0:91:f5:5e:86:d4
[  169.835059] wlan0: beacon received
[  169.873008] wlan0: associate with e0:91:f5:5e:86:d4 (try 1)
[  169.876767] wlan0: RX AssocResp from e0:91:f5:5e:86:d4 (capab=0x411 status=0 aid=6)
[  169.876776] wlan0: associated
[  169.881390] ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready
[  169.889131] usb 1-1.2: new high-speed USB device number 4 using ehci_hcd
[  170.042023] usb 1-1.2: New USB device found, idVendor=13d3, idProduct=5710
[  170.044334] usb 1-1.2: New USB device strings: Mfr=3, Product=1, SerialNumber=2
[  170.046665] usb 1-1.2: Product: USB 2.0 UVC VGA WebCam
[  170.048996] usb 1-1.2: Manufacturer: Azurewave
[  170.051261] usb 1-1.2: SerialNumber: 0x0001
[  170.055819] uvcvideo: Found UVC 1.00 device USB 2.0 UVC VGA WebCam (13d3:5710)
[  170.066505] input: USB 2.0 UVC VGA WebCam as /devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.2/1-1.2:1.0/input/input13
[  179.996624] wlan0: no IPv6 routers present


--
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 Thu, 19 Apr 2012, Andrey Rahmatullin wrote:

> 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.

Good, this confirms that the patch really does cause the unbound device 
to be put into D3.

Tomorrow we can try to figure out the appropriate workaround.

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, 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

[Alan Stern]

On Wed, 18 Apr 2012, Steven Rostedt wrote:

> On Wed, 2012-04-18 at 16:23 -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.
> 
> Confirmed. The suspend locked up even with the script.

Okay, now I'm certain that this is the problem.

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

The part you included didn't show the suspend itself.  It looks like a 
bunch of stuff following the resume.  But I guess it doesn't much 
matter, since we now know what needs to be fixed.

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, 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...

Are they put into D3 by ACPI or using the native PCI PM?

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: [linux-pm] ehci_hcd related S3 lockup on ASUS laptops, again

[Steven Rostedt]

On Wed, 2012-04-18 at 16:23 -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.

Confirmed. The suspend locked up even with the script.

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

Below is the dmesg output after running with pm_test set to "platform".

-- Steve


[  168.898150] ehci_hcd 0000:00:1a.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16
[  168.900556] ehci_hcd 0000:00:1a.0: setting latency timer to 64
[  168.900566] ehci_hcd 0000:00:1a.0: EHCI Host Controller
[  168.902803] ehci_hcd 0000:00:1a.0: new USB bus registered, assigned bus number 1
[  168.905033] ehci_hcd 0000:00:1a.0: debug port 2
[  168.911060] ehci_hcd 0000:00:1a.0: cache line size of 64 is not supported
[  168.911074] ehci_hcd 0000:00:1a.0: irq 16, io mem 0xdfc08000
[  168.926501] ehci_hcd 0000:00:1a.0: USB 2.0 started, EHCI 1.00
[  168.927782] usb usb1: New USB device found, idVendor=1d6b, idProduct=0002
[  168.929028] usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[  168.930280] usb usb1: Product: EHCI Host Controller
[  168.931159] usb usb1: Manufacturer: Linux 3.2.5-custom+ ehci_hcd
[  168.931825] usb usb1: SerialNumber: 0000:00:1a.0
[  168.932636] hub 1-0:1.0: USB hub found
[  168.933580] hub 1-0:1.0: 2 ports detected
[  168.958631] ehci_hcd 0000:00:1d.0: PCI INT A -> GSI 23 (level, low) -> IRQ 23
[  168.959979] ehci_hcd 0000:00:1d.0: setting latency timer to 64
[  168.959985] ehci_hcd 0000:00:1d.0: EHCI Host Controller
[  168.961010] ehci_hcd 0000:00:1d.0: new USB bus registered, assigned bus number 2
[  168.961888] ehci_hcd 0000:00:1d.0: debug port 2
[  168.966644] ehci_hcd 0000:00:1d.0: cache line size of 64 is not supported
[  168.966659] ehci_hcd 0000:00:1d.0: irq 23, io mem 0xdfc07000
[  168.982442] ehci_hcd 0000:00:1d.0: USB 2.0 started, EHCI 1.00
[  168.984712] usb usb2: New USB device found, idVendor=1d6b, idProduct=0002
[  168.986937] usb usb2: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[  168.989072] usb usb2: Product: EHCI Host Controller
[  168.991221] usb usb2: Manufacturer: Linux 3.2.5-custom+ ehci_hcd
[  168.993345] usb usb2: SerialNumber: 0000:00:1d.0
[  168.995824] hub 2-0:1.0: USB hub found
[  168.996495] hub 2-0:1.0: 2 ports detected
[  169.246068] usb 1-1: new high-speed USB device number 2 using ehci_hcd
[  169.378364] usb 1-1: New USB device found, idVendor=8087, idProduct=0024
[  169.380124] usb 1-1: New USB device strings: Mfr=0, Product=0, SerialNumber=0
[  169.382318] hub 1-1:1.0: USB hub found
[  169.384196] hub 1-1:1.0: 6 ports detected
[  169.497629] usb 2-1: new high-speed USB device number 2 using ehci_hcd
[  169.629894] usb 2-1: New USB device found, idVendor=8087, idProduct=0024
[  169.632100] usb 2-1: New USB device strings: Mfr=0, Product=0, SerialNumber=0
[  169.635009] hub 2-1:1.0: USB hub found
[  169.637506] hub 2-1:1.0: 6 ports detected
[  169.713401] usb 1-1.1: new full-speed USB device number 3 using ehci_hcd
[  169.809382] usb 1-1.1: New USB device found, idVendor=8086, idProduct=0189
[  169.811659] usb 1-1.1: New USB device strings: Mfr=0, Product=0, SerialNumber=0
[  169.822285] wlan0: authenticate with e0:91:f5:5e:86:d4 (try 1)
[  169.825100] wlan0: authenticated
[  169.825502] wlan0: waiting for beacon from e0:91:f5:5e:86:d4
[  169.835059] wlan0: beacon received
[  169.873008] wlan0: associate with e0:91:f5:5e:86:d4 (try 1)
[  169.876767] wlan0: RX AssocResp from e0:91:f5:5e:86:d4 (capab=0x411 status=0 aid=6)
[  169.876776] wlan0: associated
[  169.881390] ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready
[  169.889131] usb 1-1.2: new high-speed USB device number 4 using ehci_hcd
[  170.042023] usb 1-1.2: New USB device found, idVendor=13d3, idProduct=5710
[  170.044334] usb 1-1.2: New USB device strings: Mfr=3, Product=1, SerialNumber=2
[  170.046665] usb 1-1.2: Product: USB 2.0 UVC VGA WebCam
[  170.048996] usb 1-1.2: Manufacturer: Azurewave
[  170.051261] usb 1-1.2: SerialNumber: 0x0001
[  170.055819] uvcvideo: Found UVC 1.00 device USB 2.0 UVC VGA WebCam (13d3:5710)
[  170.066505] input: USB 2.0 UVC VGA WebCam as /devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.2/1-1.2:1.0/input/input13
[  179.996624] wlan0: no IPv6 routers present


--
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, Mark Brown wrote:

> On Wed, Apr 18, 2012 at 01:24:07PM -0400, Steven Rostedt wrote:
> 
> > Hmm, if the system is going down into suspend, what's the purpose of
> > putting the individual devices into low-power states. The entire system
> > will become a low-power state once it hits suspend, wont it?
> 
> Embedded platforms tend to rely on drivers doing this, either because
> the system suspend just suspends a portion of the system or because
> suspending the core on the system relies on the devices having being
> quiesced (or a combination of both).

Right.  One reasonable workaround might be simply to avoid putting PCI 
devices into D3 before suspend if the system uses ACPI.  But I don't 
know if that would interfere with the wakeup mechanism.

On the whole, it seems like a better idea to treat this particular 
chipset specially.

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, 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: [linux-pm] ehci_hcd related S3 lockup on ASUS laptops, again

[Steven Rostedt]

On Wed, 2012-04-18 at 18:46 +0100, Mark Brown wrote:
> On Wed, Apr 18, 2012 at 01:24:07PM -0400, Steven Rostedt wrote:
> 
> > Hmm, if the system is going down into suspend, what's the purpose of
> > putting the individual devices into low-power states. The entire system
> > will become a low-power state once it hits suspend, wont it?
> 
> Embedded platforms tend to rely on drivers doing this, either because
> the system suspend just suspends a portion of the system or because
> suspending the core on the system relies on the devices having being
> quiesced (or a combination of both).

I guess this explains why MS has a separate OS for embedded devices.

-- 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

[Mark Brown]

On Wed, Apr 18, 2012 at 01:24:07PM -0400, Steven Rostedt wrote:

> Hmm, if the system is going down into suspend, what's the purpose of
> putting the individual devices into low-power states. The entire system
> will become a low-power state once it hits suspend, wont it?

Embedded platforms tend to rely on drivers doing this, either because
the system suspend just suspends a portion of the system or because
suspending the core on the system relies on the devices having being
quiesced (or a combination of both).
--
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 Wed, 2012-04-18 at 13:19 -0400, Alan Stern wrote:

> > What do you think Windows does for this?
> 
> I have no idea.  I don't even know how to find out.
> 
> Maybe Windows doesn't bother putting the individual devices into
> low-power states before suspending the entire system.

Hmm, if the system is going down into suspend, what's the purpose of
putting the individual devices into low-power states. The entire system
will become a low-power state once it hits suspend, wont it?

-- 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

[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 12:41 -0400, Alan Stern wrote:
> 
> > 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?
> > 
> 
> Looks to be a new bios available. I've never had the guts to update a
> bios on a laptop before. I guess I should try now ;-)
> 
> http://support.asus.com/download.aspx?SLanguage=en&p=3&s=343&m=U56E&os=&hashedid=6KBv9FLOCOczEXLJ
> 
> What do you think Windows does for this?

I have no idea.  I don't even know how to find out.

Maybe Windows doesn't bother putting the individual devices into
low-power states before suspending the entire system.

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

[Steven Rostedt]

On Wed, 2012-04-18 at 12:41 -0400, Alan Stern wrote:

> 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?
> 

Looks to be a new bios available. I've never had the guts to update a
bios on a laptop before. I guess I should try now ;-)

http://support.asus.com/download.aspx?SLanguage=en&p=3&s=343&m=U56E&os=&hashedid=6KBv9FLOCOczEXLJ

What do you think Windows does for this?

-- 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

[Steven Rostedt]

On Wed, 2012-04-18 at 10:51 -0400, Alan Stern wrote:

> Steve?  Does the last patch fix the problem on your machine too?
> 

I applied just the patch with the message id:

 Pine.LNX.4.44L0.1204171423310.1163-100000-IYeN2dnnYyZXsRXLowluHWD2FQJk+8+b@public.gmane.org

and I was able to suspend with and without 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: [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: [linux-pm] ehci_hcd related S3 lockup on ASUS laptops, again

[Steven Rostedt]

On Wed, 2012-04-18 at 10:51 -0400, Alan Stern wrote:

> 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?
> 
> And come to think of it, we haven't heard anything from Steve recently.
> 
> Steve?  Does the last patch fix the problem on your machine too?

Sorry I've been working on other things :-/

I'll try it out.

-- 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, Andrey Rahmatullin wrote:

> On Tue, Apr 17, 2012 at 03:20:32PM -0400, Alan Stern 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: Refused to change power state, currently in D0
> > > ehci_hcd 0000:00:1d.0: cur 5 target 3 error 0
> > > ehci_hcd 0000:00:1a.0: wake-up capability enabled by ACPI
> > > ehci_hcd 0000:00:1a.0: Refused to change power state, currently in D0
> > > ehci_hcd 0000:00:1a.0: cur 5 target 3 error 0
> > 
> > Very good.  The two behaviors are the same.
> > 
> > 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?

And come to think of it, we haven't heard anything from Steve recently.

Steve?  Does the last patch fix the problem on your machine too?

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: 1219 bytes --]

On Tue, Apr 17, 2012 at 03:20:32PM -0400, Alan Stern 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: Refused to change power state, currently in D0
> > ehci_hcd 0000:00:1d.0: cur 5 target 3 error 0
> > ehci_hcd 0000:00:1a.0: wake-up capability enabled by ACPI
> > ehci_hcd 0000:00:1a.0: Refused to change power state, currently in D0
> > ehci_hcd 0000:00:1a.0: cur 5 target 3 error 0
> 
> Very good.  The two behaviors are the same.
> 
> 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.

-- 
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 Wed, 18 Apr 2012, Andrey Rahmatullin wrote:

> > Wow.  Okay, I have boiled this down to a single patch.  You should 
> > try this both with and without unbinding ehci-hcd, and post the dmesg 
> > log output that it generates in the two cases.
> 
> 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: Refused to change power state, currently in D0
> ehci_hcd 0000:00:1d.0: cur 5 target 3 error 0
> ehci_hcd 0000:00:1a.0: wake-up capability enabled by ACPI
> ehci_hcd 0000:00:1a.0: Refused to change power state, currently in D0
> ehci_hcd 0000:00:1a.0: cur 5 target 3 error 0

Very good.  The two behaviors are the same.

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?

Steven reported that the power state does get set to D3hot; he did not
get the "Refused to change power state" lines.

I have a strong feeling that your computer crashes during suspend 
whenever the EHCI controllers are in a low-power state.  We'll see.

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: 1193 bytes --]

On Tue, Apr 17, 2012 at 02:26:24PM -0400, Alan Stern wrote:
> > > If you manage to reach the end of this list, you'll essentially be
> > > doing a normal suspend (except for the PCI_UNKNOWN part).
> > It works without changes #2..8. I'm attaching the resulting patch.
> 
> Wow.  Okay, I have boiled this down to a single patch.  You should 
> try this both with and without unbinding ehci-hcd, and post the dmesg 
> log output that it generates in the two cases.

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: Refused to change power state, currently in D0
ehci_hcd 0000:00:1d.0: cur 5 target 3 error 0
ehci_hcd 0000:00:1a.0: wake-up capability enabled by ACPI
ehci_hcd 0000:00:1a.0: Refused to change power state, currently in D0
ehci_hcd 0000:00:1a.0: cur 5 target 3 error 0

-- 
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 Tue, 17 Apr 2012, Andrey Rahmatullin wrote:

> > If you manage to reach the end of this list, you'll essentially be
> > doing a normal suspend (except for the PCI_UNKNOWN part).
> It works without changes #2..8. I'm attaching the resulting patch.

Wow.  Okay, I have boiled this down to a single patch.  You should 
try this both with and without unbinding ehci-hcd, and post the dmesg 
log output that it generates in the two cases.

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
@@ -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;
 }
 
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
@@ -433,6 +433,7 @@ static int suspend_common(struct device
 	 * low power state during suspend_noirq, if the hardware allows.
 	 */
 	pci_disable_device(pci_dev);
+	pci_dev->current_state = PCI_UNKNOWN;
 	return retval;
 }
 

--
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.1: Type: text/plain, Size: 1215 bytes --]

On Tue, Apr 17, 2012 at 12:58:03PM -0400, Alan Stern wrote:
> > > 	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).
It works without changes #2..8. I'm attaching the resulting patch.

-- 
WBR, wRAR

[-- Attachment #1.2: current.patch --]
[-- Type: text/x-diff, Size: 3465 bytes --]

diff --git a/drivers/pci/pci-driver.c b/drivers/pci/pci-driver.c
index 6b54b23..8a9edf4 100644
--- a/drivers/pci/pci-driver.c
+++ b/drivers/pci/pci-driver.c
@@ -713,6 +713,8 @@ static int pci_pm_suspend_noirq(struct device *dev)
 
 	if (!pm) {
 		pci_save_state(pci_dev);
+		pci_prepare_to_sleep(pci_dev);
+		pci_pm_set_unknown_state(pci_dev);
 		return 0;
 	}
 
diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index 8156744..3111105 100644
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -1348,6 +1348,7 @@ void pci_disable_enabled_device(struct pci_dev *dev)
 	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_dev *dev)
  */
 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 *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;
 }
 
diff --git a/drivers/usb/core/hcd-pci.c b/drivers/usb/core/hcd-pci.c
index 622b4a4..d7dc939 100644
--- a/drivers/usb/core/hcd-pci.c
+++ b/drivers/usb/core/hcd-pci.c
@@ -381,6 +381,8 @@ static int check_root_hub_suspended(struct device *dev)
 }
 
 #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,18 @@ static int suspend_common(struct device *dev, bool do_wakeup)
 	if (!hcd->msix_enabled)
 		synchronize_irq(pci_dev->irq);
 
+//	free_irq(hcd->irq, hcd); // 5
+//	iounmap(hcd->regs); // 4
+//	pci_disable_device(pci_dev); // 3
+
 	/* 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_enabled_device(pci_dev); // 6
 	pci_disable_device(pci_dev);
+	pci_dev->current_state = PCI_UNKNOWN; // 1
 	return retval;
 }
 
diff --git a/drivers/usb/host/ehci-pci.c b/drivers/usb/host/ehci-pci.c
index 01bb7241d..5fbfc3e 100644
--- a/drivers/usb/host/ehci-pci.c
+++ b/drivers/usb/host/ehci-pci.c
@@ -342,7 +342,7 @@ static int ehci_pci_suspend(struct usb_hcd *hcd, bool do_wakeup)
 	 * 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);
+	ehci_prepare_ports_for_controller_suspend(ehci, do_wakeup); // 7
 	spin_lock_irqsave (&ehci->lock, flags);
 	ehci_writel(ehci, 0, &ehci->regs->intr_enable);
 	(void)ehci_readl(ehci, &ehci->regs->intr_enable);
@@ -350,6 +350,9 @@ static int ehci_pci_suspend(struct usb_hcd *hcd, bool do_wakeup)
 	clear_bit(HCD_FLAG_HW_ACCESSIBLE, &hcd->flags);
 	spin_unlock_irqrestore (&ehci->lock, flags);
 
+//	ehci_silence_controller(ehci); // 2
+//	ehci_reset(ehci); // 8
+
 	// could save FLADJ in case of Vaux power loss
 	// ... we'd only use it to handle clock skew
 

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 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: [linux-pm] ehci_hcd related S3 lockup on ASUS laptops, again

[Alan Stern]

On Fri, 13 Apr 2012, Steven Rostedt wrote:

> 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).

Okay, you've got Bluetooth device and a USB webcam, in addition to the 
internal "rate-matching" hub on each EHCI bus.

> > 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 just did the same thing here, with the same result.  I'm trying to
track it down now.  It may take a while...

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

[Steven Rostedt]

On Fri, 2012-04-13 at 11:32 -0400, Steven Rostedt wrote:
> On Fri, 2012-04-13 at 11:29 -0400, 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
> > 

Oh, and the "non modified" kernel I used was 3.1.4. The modified ones
was 3.2.5 (instead of removing the changes, I just used this one).

-- 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

[Steven Rostedt]

On Fri, 2012-04-13 at 11:29 -0400, 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
> 

A sysrq-t gives this:

[ 4468.680789] bash            D ffff88022837d7d0     0  3077   3071 0x00000004
[ 4468.680792]  ffff88022c0f7af8 0000000000000086 0000000000000001 ffff88022837d4c0
[ 4468.680796]  ffff88022c0f7fd8 000000000000000a ffff88022c0f7fd8 ffff88022c0f7fd8
[ 4468.680800]  ffff88022837f810 ffff88022837d4c0 ffff88022837d4c0 ffff88022c0f7fd8
[ 4468.680804] Call Trace:
[ 4468.680807]  [<ffffffff813f5a3f>] schedule+0x3f/0x60
[ 4468.680810]  [<ffffffff813f6974>] __mutex_lock_slowpath+0x104/0x1a0
[ 4468.680813]  [<ffffffff813f64a2>] mutex_lock+0x22/0x40
[ 4468.680821]  [<ffffffffa00111a6>] usb_disconnect+0x96/0x140 [usbcore]
[ 4468.680830]  [<ffffffffa001118c>] usb_disconnect+0x7c/0x140 [usbcore]
[ 4468.680837]  [<ffffffffa00112b0>] hub_quiesce+0x60/0xc0 [usbcore]
[ 4468.680844]  [<ffffffffa001147c>] hub_disconnect+0x7c/0x100 [usbcore]
[ 4468.680853]  [<ffffffffa001b092>] usb_unbind_interface+0x52/0x180 [usbcore]
[ 4468.680861]  [<ffffffff812b650c>] __device_release_driver+0x7c/0xe0
[ 4468.680864]  [<ffffffff812b659c>] device_release_driver+0x2c/0x40
[ 4468.680867]  [<ffffffff812b6048>] bus_remove_device+0x78/0xb0
[ 4468.680870]  [<ffffffff812b338d>] device_del+0x12d/0x1b0
[ 4468.680878]  [<ffffffffa0018def>] usb_disable_device+0xaf/0x1d0 [usbcore]
[ 4468.680886]  [<ffffffffa0019778>] usb_set_configuration+0x278/0x6d0 [usbcore]
[ 4468.680890]  [<ffffffff8120f448>] ? sscanf+0x38/0x40
[ 4468.680898]  [<ffffffffa001e5ca>] set_bConfigurationValue+0x6a/0x90 [usbcore]
[ 4468.680901]  [<ffffffff812b24b8>] dev_attr_store+0x18/0x30
[ 4468.680905]  [<ffffffff811a81d2>] sysfs_write_file+0xe2/0x170
[ 4468.680909]  [<ffffffff81139673>] vfs_write+0xb3/0x180
[ 4468.680913]  [<ffffffff8113999a>] sys_write+0x4a/0x90
[ 4468.680916]  [<ffffffff813fe7ab>] system_call_fastpath+0x16/0x1b

-- 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

[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: [linux-pm] ehci_hcd related S3 lockup on ASUS laptops, again

[Alan Stern]

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?

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.

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 Thu, 12 Apr 2012, Steven Rostedt wrote:

> Alan,
> 
> We're not experts in this code. Would it be possible to just send us a
> patch to what you want changed?

Sorry; I'll be more explicit in the future.

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

[Steven Rostedt]

On Fri, 2012-04-13 at 02:21 +0600, 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?

Alan,

We're not experts in this code. Would it be possible to just send us a
patch to what you want changed?

Shouldn't be too hard to just make a temporary change in a git
repository, do a 'git diff' and then revert the change:

  <- make changes ->
  git diff > temp.patch
  patch -p1 -R < temp.patch


Thanks!

-- Steve

> 
> > 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.
> 
> 


--
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 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: [linux-pm] ehci_hcd related S3 lockup on ASUS laptops, again

[Andrey Rahmatullin]

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

On Thu, Apr 12, 2012 at 03:11:42PM -0400, Alan Stern wrote:
> 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.
What should we do with that? I tried to suspend and it locked up.

-- 
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

[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: [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

[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: [linux-pm] ehci_hcd related S3 lockup on ASUS laptops, again

[Steven Rostedt]

On Wed, 2012-04-11 at 17:13 -0400, Alan Stern wrote:
> 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?

I mean, as I hit suspend, the screen goes blank, but the backlight stays
on, and the system just hangs there. It never gets to the point where
the machine is in "suspend" mode. I have to press and hold the power
button to force a shutdown.

> 
> 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.

I set it to 0 and it worked! (was able to suspend and resume)

> 
> 
> 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.

I have to go for a few hours, but I can try this when I get back. Even
if Andrey does it first. I'll verify it it too.

Thanks Alan and Andrey!

-- 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

[Steven Rostedt]

On Thu, 2012-04-12 at 02:52 +0600, Andrey Rahmatullin wrote:
> 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.
> 

I just did the update and it was successful for me as well.

Seems there's some kind of issue with the hcd_pci_suspend_noirq() call.

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

[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: [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, 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