All of lore.kernel.org
 help / color / mirror / Atom feed
* ehci_hcd related S3 lockup on ASUS laptops, again
@ 2012-04-11 16:55 Andrey Rahmatullin
       [not found] ` <20120411165531.GA3717-hAV9HEAGFNe6YibBOCjzsw@public.gmane.org>
  0 siblings, 1 reply; 148+ messages in thread
From: Andrey Rahmatullin @ 2012-04-11 16:55 UTC (permalink / raw)
  To: linux-usb-u79uwXL29TY76Z2rM5mHXA,
	linux-pm-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA
  Cc: jrnieder-Re5JQEeQqe8AvxtiuMwx3w, greg-U8xfFu+wG4EAvxtiuMwx3w,
	rostedt-nx8X9YLhiw1AfugRpC6u6w

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

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

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

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

Unbinding just one of two controllers doesn't help.

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

Windows 7 enters S3 perfectly well.

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

-- 
WBR, wRAR

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

^ permalink raw reply	[flat|nested] 148+ messages in thread

* Re: ehci_hcd related S3 lockup on ASUS laptops, again
       [not found] ` <20120411165531.GA3717-hAV9HEAGFNe6YibBOCjzsw@public.gmane.org>
@ 2012-04-11 17:06   ` Steven Rostedt
       [not found]     ` <1334164013.23924.271.camel-f9ZlEuEWxVcI6MkJdU+c8EEOCMrvLtNR@public.gmane.org>
  0 siblings, 1 reply; 148+ messages in thread
From: Steven Rostedt @ 2012-04-11 17:06 UTC (permalink / raw)
  To: Andrey Rahmatullin
  Cc: linux-usb-u79uwXL29TY76Z2rM5mHXA,
	linux-pm-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA,
	jrnieder-Re5JQEeQqe8AvxtiuMwx3w, greg-U8xfFu+wG4EAvxtiuMwx3w

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

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

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

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

-- Steve


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

^ permalink raw reply	[flat|nested] 148+ messages in thread

* Re: ehci_hcd related S3 lockup on ASUS laptops, again
       [not found]     ` <1334164013.23924.271.camel-f9ZlEuEWxVcI6MkJdU+c8EEOCMrvLtNR@public.gmane.org>
@ 2012-04-11 17:25       ` Alan Stern
       [not found]         ` <Pine.LNX.4.44L0.1204111324100.1351-100000-IYeN2dnnYyZXsRXLowluHWD2FQJk+8+b@public.gmane.org>
  0 siblings, 1 reply; 148+ messages in thread
From: Alan Stern @ 2012-04-11 17:25 UTC (permalink / raw)
  To: Steven Rostedt
  Cc: Andrey Rahmatullin, linux-usb-u79uwXL29TY76Z2rM5mHXA,
	linux-pm-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA,
	jrnieder-Re5JQEeQqe8AvxtiuMwx3w, greg-U8xfFu+wG4EAvxtiuMwx3w

On Wed, 11 Apr 2012, Steven Rostedt wrote:

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

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

Ideas welcome.

Alan Stern

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

^ permalink raw reply	[flat|nested] 148+ messages in thread

* Re: [linux-pm] ehci_hcd related S3 lockup on ASUS laptops, again
       [not found]         ` <Pine.LNX.4.44L0.1204111324100.1351-100000-IYeN2dnnYyZXsRXLowluHWD2FQJk+8+b@public.gmane.org>
@ 2012-04-11 19:12           ` Alan Stern
       [not found]             ` <Pine.LNX.4.44L0.1204111429510.1351-100000-IYeN2dnnYyZXsRXLowluHWD2FQJk+8+b@public.gmane.org>
  2012-04-11 20:52             ` Andrey Rahmatullin
  0 siblings, 2 replies; 148+ messages in thread
From: Alan Stern @ 2012-04-11 19:12 UTC (permalink / raw)
  To: Steven Rostedt
  Cc: jrnieder-Re5JQEeQqe8AvxtiuMwx3w, Andrey Rahmatullin,
	linux-pm-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA,
	linux-usb-u79uwXL29TY76Z2rM5mHXA, greg-U8xfFu+wG4EAvxtiuMwx3w

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

^ permalink raw reply	[flat|nested] 148+ messages in thread

* Re: [linux-pm] ehci_hcd related S3 lockup on ASUS laptops, again
       [not found]             ` <Pine.LNX.4.44L0.1204111429510.1351-100000-IYeN2dnnYyZXsRXLowluHWD2FQJk+8+b@public.gmane.org>
@ 2012-04-11 20:43               ` Steven Rostedt
       [not found]                 ` <1334177035.23924.299.camel-f9ZlEuEWxVcI6MkJdU+c8EEOCMrvLtNR@public.gmane.org>
  0 siblings, 1 reply; 148+ messages in thread
From: Steven Rostedt @ 2012-04-11 20:43 UTC (permalink / raw)
  To: Alan Stern
  Cc: jrnieder-Re5JQEeQqe8AvxtiuMwx3w, Andrey Rahmatullin,
	linux-pm-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA,
	linux-usb-u79uwXL29TY76Z2rM5mHXA, greg-U8xfFu+wG4EAvxtiuMwx3w

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

^ permalink raw reply	[flat|nested] 148+ messages in thread

* Re: ehci_hcd related S3 lockup on ASUS laptops, again
  2012-04-11 19:12           ` [linux-pm] " Alan Stern
       [not found]             ` <Pine.LNX.4.44L0.1204111429510.1351-100000-IYeN2dnnYyZXsRXLowluHWD2FQJk+8+b@public.gmane.org>
@ 2012-04-11 20:52             ` Andrey Rahmatullin
       [not found]               ` <20120411205204.GB3677-hAV9HEAGFNe6YibBOCjzsw@public.gmane.org>
  1 sibling, 1 reply; 148+ messages in thread
From: Andrey Rahmatullin @ 2012-04-11 20:52 UTC (permalink / raw)
  To: Alan Stern; +Cc: jrnieder, greg, linux-pm, linux-usb, Steven Rostedt


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

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

-- 
WBR, wRAR

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

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



^ permalink raw reply	[flat|nested] 148+ messages in thread

* Re: [linux-pm] ehci_hcd related S3 lockup on ASUS laptops, again
       [not found]                 ` <1334177035.23924.299.camel-f9ZlEuEWxVcI6MkJdU+c8EEOCMrvLtNR@public.gmane.org>
@ 2012-04-11 21:13                   ` Alan Stern
       [not found]                     ` <Pine.LNX.4.44L0.1204111703180.1351-100000-IYeN2dnnYyZXsRXLowluHWD2FQJk+8+b@public.gmane.org>
  2012-04-11 22:09                     ` Andrey Rahmatullin
  0 siblings, 2 replies; 148+ messages in thread
From: Alan Stern @ 2012-04-11 21:13 UTC (permalink / raw)
  To: Andrey Rahmatullin, Steven Rostedt
  Cc: jrnieder-Re5JQEeQqe8AvxtiuMwx3w,
	linux-pm-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA, USB list,
	Greg KH

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

^ permalink raw reply	[flat|nested] 148+ messages in thread

* Re: [linux-pm] ehci_hcd related S3 lockup on ASUS laptops, again
       [not found]               ` <20120411205204.GB3677-hAV9HEAGFNe6YibBOCjzsw@public.gmane.org>
@ 2012-04-11 21:15                 ` Steven Rostedt
  0 siblings, 0 replies; 148+ messages in thread
From: Steven Rostedt @ 2012-04-11 21:15 UTC (permalink / raw)
  To: Andrey Rahmatullin
  Cc: Alan Stern, jrnieder-Re5JQEeQqe8AvxtiuMwx3w,
	linux-pm-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA,
	linux-usb-u79uwXL29TY76Z2rM5mHXA, greg-U8xfFu+wG4EAvxtiuMwx3w

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

^ permalink raw reply	[flat|nested] 148+ messages in thread

* Re: [linux-pm] ehci_hcd related S3 lockup on ASUS laptops, again
       [not found]                     ` <Pine.LNX.4.44L0.1204111703180.1351-100000-IYeN2dnnYyZXsRXLowluHWD2FQJk+8+b@public.gmane.org>
@ 2012-04-11 21:19                       ` Steven Rostedt
  0 siblings, 0 replies; 148+ messages in thread
From: Steven Rostedt @ 2012-04-11 21:19 UTC (permalink / raw)
  To: Alan Stern
  Cc: Andrey Rahmatullin, jrnieder-Re5JQEeQqe8AvxtiuMwx3w,
	linux-pm-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA, USB list,
	Greg KH

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

^ permalink raw reply	[flat|nested] 148+ messages in thread

* Re: ehci_hcd related S3 lockup on ASUS laptops, again
  2012-04-11 21:13                   ` Alan Stern
       [not found]                     ` <Pine.LNX.4.44L0.1204111703180.1351-100000-IYeN2dnnYyZXsRXLowluHWD2FQJk+8+b@public.gmane.org>
@ 2012-04-11 22:09                     ` Andrey Rahmatullin
  2012-04-12  1:22                       ` Steven Rostedt
  1 sibling, 1 reply; 148+ messages in thread
From: Andrey Rahmatullin @ 2012-04-11 22:09 UTC (permalink / raw)
  To: Alan Stern; +Cc: jrnieder, Greg KH, linux-pm, USB list, Steven Rostedt


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

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

-- 
WBR, wRAR

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

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



^ permalink raw reply	[flat|nested] 148+ messages in thread

* Re: ehci_hcd related S3 lockup on ASUS laptops, again
  2012-04-11 22:09                     ` Andrey Rahmatullin
@ 2012-04-12  1:22                       ` Steven Rostedt
       [not found]                         ` <1334193773.23924.316.camel-f9ZlEuEWxVcI6MkJdU+c8EEOCMrvLtNR@public.gmane.org>
  0 siblings, 1 reply; 148+ messages in thread
From: Steven Rostedt @ 2012-04-12  1:22 UTC (permalink / raw)
  To: Andrey Rahmatullin; +Cc: jrnieder, Greg KH, linux-pm, USB list

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

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

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

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

^ permalink raw reply related	[flat|nested] 148+ messages in thread

* Re: [linux-pm] ehci_hcd related S3 lockup on ASUS laptops, again
       [not found]                         ` <1334193773.23924.316.camel-f9ZlEuEWxVcI6MkJdU+c8EEOCMrvLtNR@public.gmane.org>
@ 2012-04-12 14:28                           ` Alan Stern
  2012-04-12 15:37                             ` Andrey Rahmatullin
                                               ` (2 more replies)
  0 siblings, 3 replies; 148+ messages in thread
From: Alan Stern @ 2012-04-12 14:28 UTC (permalink / raw)
  To: Steven Rostedt
  Cc: Andrey Rahmatullin, jrnieder-Re5JQEeQqe8AvxtiuMwx3w,
	linux-pm-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA, USB list,
	Greg KH

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

^ permalink raw reply	[flat|nested] 148+ messages in thread

* Re: ehci_hcd related S3 lockup on ASUS laptops, again
  2012-04-12 14:28                           ` [linux-pm] " Alan Stern
@ 2012-04-12 15:37                             ` Andrey Rahmatullin
       [not found]                               ` <20120412153750.GA12852-hAV9HEAGFNe6YibBOCjzsw@public.gmane.org>
  2012-04-12 16:33                             ` Steven Rostedt
  2012-04-12 18:10                             ` Andrey Rahmatullin
  2 siblings, 1 reply; 148+ messages in thread
From: Andrey Rahmatullin @ 2012-04-12 15:37 UTC (permalink / raw)
  To: Alan Stern; +Cc: jrnieder, Greg KH, linux-pm, USB list, Steven Rostedt


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

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

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

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

-- 
WBR, wRAR

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

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



^ permalink raw reply	[flat|nested] 148+ messages in thread

* Re: [linux-pm] ehci_hcd related S3 lockup on ASUS laptops, again
       [not found]                               ` <20120412153750.GA12852-hAV9HEAGFNe6YibBOCjzsw@public.gmane.org>
@ 2012-04-12 16:09                                 ` Alan Stern
       [not found]                                   ` <Pine.LNX.4.44L0.1204121203530.1496-100000-IYeN2dnnYyZXsRXLowluHWD2FQJk+8+b@public.gmane.org>
  0 siblings, 1 reply; 148+ messages in thread
From: Alan Stern @ 2012-04-12 16:09 UTC (permalink / raw)
  To: Andrey Rahmatullin
  Cc: Steven Rostedt, jrnieder-Re5JQEeQqe8AvxtiuMwx3w,
	linux-pm-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA, USB list,
	Greg KH

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

^ permalink raw reply	[flat|nested] 148+ messages in thread

* Re: ehci_hcd related S3 lockup on ASUS laptops, again
  2012-04-12 14:28                           ` [linux-pm] " Alan Stern
  2012-04-12 15:37                             ` Andrey Rahmatullin
@ 2012-04-12 16:33                             ` Steven Rostedt
  2012-04-12 17:06                               ` Alan Stern
  2012-04-12 18:10                             ` Andrey Rahmatullin
  2 siblings, 1 reply; 148+ messages in thread
From: Steven Rostedt @ 2012-04-12 16:33 UTC (permalink / raw)
  To: Alan Stern; +Cc: jrnieder, Andrey Rahmatullin, linux-pm, USB list, Greg KH

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

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

They're both enabled for me too.

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

Where do I read out the dev info?

-- Steve

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

^ permalink raw reply	[flat|nested] 148+ messages in thread

* Re: [linux-pm] ehci_hcd related S3 lockup on ASUS laptops, again
       [not found]                                   ` <Pine.LNX.4.44L0.1204121203530.1496-100000-IYeN2dnnYyZXsRXLowluHWD2FQJk+8+b@public.gmane.org>
@ 2012-04-12 16:49                                     ` Andrey Rahmatullin
  2012-04-12 16:52                                       ` Steven Rostedt
  0 siblings, 1 reply; 148+ messages in thread
From: Andrey Rahmatullin @ 2012-04-12 16:49 UTC (permalink / raw)
  To: Alan Stern
  Cc: Steven Rostedt, jrnieder-Re5JQEeQqe8AvxtiuMwx3w,
	linux-pm-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA, USB list,
	Greg KH

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

^ permalink raw reply	[flat|nested] 148+ messages in thread

* Re: ehci_hcd related S3 lockup on ASUS laptops, again
  2012-04-12 16:49                                     ` Andrey Rahmatullin
@ 2012-04-12 16:52                                       ` Steven Rostedt
  2012-04-12 16:58                                         ` Andrey Rahmatullin
  0 siblings, 1 reply; 148+ messages in thread
From: Steven Rostedt @ 2012-04-12 16:52 UTC (permalink / raw)
  To: Andrey Rahmatullin; +Cc: jrnieder, Greg KH, linux-pm, USB list

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

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

-- Steve

^ permalink raw reply	[flat|nested] 148+ messages in thread

* Re: ehci_hcd related S3 lockup on ASUS laptops, again
  2012-04-12 16:52                                       ` Steven Rostedt
@ 2012-04-12 16:58                                         ` Andrey Rahmatullin
  0 siblings, 0 replies; 148+ messages in thread
From: Andrey Rahmatullin @ 2012-04-12 16:58 UTC (permalink / raw)
  To: Steven Rostedt; +Cc: jrnieder, Greg KH, linux-pm, USB list


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

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

-- 
WBR, wRAR

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

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



^ permalink raw reply	[flat|nested] 148+ messages in thread

* Re: ehci_hcd related S3 lockup on ASUS laptops, again
  2012-04-12 16:33                             ` Steven Rostedt
@ 2012-04-12 17:06                               ` Alan Stern
  2012-04-12 17:14                                 ` Steven Rostedt
  0 siblings, 1 reply; 148+ messages in thread
From: Alan Stern @ 2012-04-12 17:06 UTC (permalink / raw)
  To: Rafael J. Wysocki, Steven Rostedt
  Cc: jrnieder, Andrey Rahmatullin, linux-pm, USB list, Greg KH

On Thu, 12 Apr 2012, Steven Rostedt wrote:

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

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

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

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

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

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

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

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

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

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

Alan Stern

^ permalink raw reply	[flat|nested] 148+ messages in thread

* Re: ehci_hcd related S3 lockup on ASUS laptops, again
  2012-04-12 17:06                               ` Alan Stern
@ 2012-04-12 17:14                                 ` Steven Rostedt
  2012-04-12 17:18                                   ` Andrey Rahmatullin
  2012-04-12 17:48                                   ` Alan Stern
  0 siblings, 2 replies; 148+ messages in thread
From: Steven Rostedt @ 2012-04-12 17:14 UTC (permalink / raw)
  To: Alan Stern; +Cc: jrnieder, Greg KH, USB list, Andrey Rahmatullin, linux-pm

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

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

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


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

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

-- Steve

^ permalink raw reply	[flat|nested] 148+ messages in thread

* Re: ehci_hcd related S3 lockup on ASUS laptops, again
  2012-04-12 17:14                                 ` Steven Rostedt
@ 2012-04-12 17:18                                   ` Andrey Rahmatullin
  2012-04-12 17:48                                   ` Alan Stern
  1 sibling, 0 replies; 148+ messages in thread
From: Andrey Rahmatullin @ 2012-04-12 17:18 UTC (permalink / raw)
  To: Steven Rostedt; +Cc: jrnieder, Greg KH, USB list, linux-pm


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

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

-- 
WBR, wRAR

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

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



^ permalink raw reply	[flat|nested] 148+ messages in thread

* Re: ehci_hcd related S3 lockup on ASUS laptops, again
  2012-04-12 17:14                                 ` Steven Rostedt
  2012-04-12 17:18                                   ` Andrey Rahmatullin
@ 2012-04-12 17:48                                   ` Alan Stern
  2012-04-12 18:17                                     ` Steven Rostedt
  1 sibling, 1 reply; 148+ messages in thread
From: Alan Stern @ 2012-04-12 17:48 UTC (permalink / raw)
  To: Steven Rostedt; +Cc: jrnieder, Greg KH, USB list, Andrey Rahmatullin, linux-pm

On Thu, 12 Apr 2012, Steven Rostedt wrote:

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

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

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

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

Alan Stern

^ permalink raw reply	[flat|nested] 148+ messages in thread

* Re: ehci_hcd related S3 lockup on ASUS laptops, again
  2012-04-12 14:28                           ` [linux-pm] " Alan Stern
  2012-04-12 15:37                             ` Andrey Rahmatullin
  2012-04-12 16:33                             ` Steven Rostedt
@ 2012-04-12 18:10                             ` Andrey Rahmatullin
  2012-04-12 18:17                               ` Alan Stern
  2 siblings, 1 reply; 148+ messages in thread
From: Andrey Rahmatullin @ 2012-04-12 18:10 UTC (permalink / raw)
  To: Alan Stern; +Cc: jrnieder, Greg KH, linux-pm, USB list, Steven Rostedt


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

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

-- 
WBR, wRAR

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

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



^ permalink raw reply	[flat|nested] 148+ messages in thread

* Re: ehci_hcd related S3 lockup on ASUS laptops, again
  2012-04-12 18:10                             ` Andrey Rahmatullin
@ 2012-04-12 18:17                               ` Alan Stern
  2012-04-12 18:21                                 ` Andrey Rahmatullin
  0 siblings, 1 reply; 148+ messages in thread
From: Alan Stern @ 2012-04-12 18:17 UTC (permalink / raw)
  To: Andrey Rahmatullin; +Cc: jrnieder, Greg KH, linux-pm, USB list, Steven Rostedt

On Fri, 13 Apr 2012, Andrey Rahmatullin wrote:

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

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

Alan Stern

^ permalink raw reply	[flat|nested] 148+ messages in thread

* Re: ehci_hcd related S3 lockup on ASUS laptops, again
  2012-04-12 17:48                                   ` Alan Stern
@ 2012-04-12 18:17                                     ` Steven Rostedt
  2012-04-12 18:25                                       ` Steven Rostedt
  0 siblings, 1 reply; 148+ messages in thread
From: Steven Rostedt @ 2012-04-12 18:17 UTC (permalink / raw)
  To: Alan Stern; +Cc: jrnieder, Greg KH, USB list, Andrey Rahmatullin, linux-pm

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

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

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

-- Steve

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

^ permalink raw reply	[flat|nested] 148+ messages in thread

* Re: ehci_hcd related S3 lockup on ASUS laptops, again
  2012-04-12 18:17                               ` Alan Stern
@ 2012-04-12 18:21                                 ` Andrey Rahmatullin
  0 siblings, 0 replies; 148+ messages in thread
From: Andrey Rahmatullin @ 2012-04-12 18:21 UTC (permalink / raw)
  To: Alan Stern; +Cc: jrnieder, Greg KH, linux-pm, USB list, Steven Rostedt


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

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

-- 
WBR, wRAR

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

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



^ permalink raw reply	[flat|nested] 148+ messages in thread

* Re: ehci_hcd related S3 lockup on ASUS laptops, again
  2012-04-12 18:17                                     ` Steven Rostedt
@ 2012-04-12 18:25                                       ` Steven Rostedt
  2012-04-12 19:11                                         ` Alan Stern
  0 siblings, 1 reply; 148+ messages in thread
From: Steven Rostedt @ 2012-04-12 18:25 UTC (permalink / raw)
  To: Alan Stern; +Cc: jrnieder, Greg KH, USB list, Andrey Rahmatullin, linux-pm

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

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

The above was without the script, with the script:

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

-- Steve

^ permalink raw reply	[flat|nested] 148+ messages in thread

* Re: ehci_hcd related S3 lockup on ASUS laptops, again
  2012-04-12 18:25                                       ` Steven Rostedt
@ 2012-04-12 19:11                                         ` Alan Stern
       [not found]                                           ` <Pine.LNX.4.44L0.1204121504550.1496-100000-IYeN2dnnYyZXsRXLowluHWD2FQJk+8+b@public.gmane.org>
  0 siblings, 1 reply; 148+ messages in thread
From: Alan Stern @ 2012-04-12 19:11 UTC (permalink / raw)
  To: Steven Rostedt; +Cc: jrnieder, Greg KH, USB list, Andrey Rahmatullin, linux-pm

On Thu, 12 Apr 2012, Steven Rostedt wrote:

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

The entries above are left over from the earlier test.

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

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

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

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

Alan Stern

^ permalink raw reply	[flat|nested] 148+ messages in thread

* Re: [linux-pm] ehci_hcd related S3 lockup on ASUS laptops, again
       [not found]                                           ` <Pine.LNX.4.44L0.1204121504550.1496-100000-IYeN2dnnYyZXsRXLowluHWD2FQJk+8+b@public.gmane.org>
@ 2012-04-12 19:24                                             ` Andrey Rahmatullin
  2012-04-12 19:35                                             ` Steven Rostedt
  1 sibling, 0 replies; 148+ messages in thread
From: Andrey Rahmatullin @ 2012-04-12 19:24 UTC (permalink / raw)
  To: Alan Stern
  Cc: Steven Rostedt, Rafael J. Wysocki,
	jrnieder-Re5JQEeQqe8AvxtiuMwx3w,
	linux-pm-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA, USB list,
	Greg KH

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

^ permalink raw reply	[flat|nested] 148+ messages in thread

* Re: [linux-pm] ehci_hcd related S3 lockup on ASUS laptops, again
       [not found]                                           ` <Pine.LNX.4.44L0.1204121504550.1496-100000-IYeN2dnnYyZXsRXLowluHWD2FQJk+8+b@public.gmane.org>
  2012-04-12 19:24                                             ` [linux-pm] " Andrey Rahmatullin
@ 2012-04-12 19:35                                             ` Steven Rostedt
  2012-04-12 20:02                                               ` Alan Stern
  1 sibling, 1 reply; 148+ messages in thread
From: Steven Rostedt @ 2012-04-12 19:35 UTC (permalink / raw)
  To: Alan Stern
  Cc: Rafael J. Wysocki, Andrey Rahmatullin,
	jrnieder-Re5JQEeQqe8AvxtiuMwx3w,
	linux-pm-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA, USB list,
	Greg KH

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

^ permalink raw reply	[flat|nested] 148+ messages in thread

* Re: ehci_hcd related S3 lockup on ASUS laptops, again
  2012-04-12 19:35                                             ` Steven Rostedt
@ 2012-04-12 20:02                                               ` Alan Stern
  2012-04-12 20:09                                                 ` Alan Stern
  2012-04-12 20:30                                                 ` Andrey Rahmatullin
  0 siblings, 2 replies; 148+ messages in thread
From: Alan Stern @ 2012-04-12 20:02 UTC (permalink / raw)
  To: Steven Rostedt; +Cc: jrnieder, Greg KH, USB list, Andrey Rahmatullin, linux-pm

On Thu, 12 Apr 2012, Steven Rostedt wrote:

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

Keep them.

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

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

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

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

Alan Stern

^ permalink raw reply	[flat|nested] 148+ messages in thread

* Re: ehci_hcd related S3 lockup on ASUS laptops, again
  2012-04-12 20:02                                               ` Alan Stern
@ 2012-04-12 20:09                                                 ` Alan Stern
  2012-04-12 20:21                                                   ` Andrey Rahmatullin
  2012-04-12 20:30                                                 ` Andrey Rahmatullin
  1 sibling, 1 reply; 148+ messages in thread
From: Alan Stern @ 2012-04-12 20:09 UTC (permalink / raw)
  To: Steven Rostedt; +Cc: jrnieder, Greg KH, USB list, Andrey Rahmatullin, linux-pm

On Thu, 12 Apr 2012, Alan Stern wrote:

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

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

Alan Stern

^ permalink raw reply	[flat|nested] 148+ messages in thread

* Re: ehci_hcd related S3 lockup on ASUS laptops, again
  2012-04-12 20:09                                                 ` Alan Stern
@ 2012-04-12 20:21                                                   ` Andrey Rahmatullin
       [not found]                                                     ` <20120412202132.GH12852-hAV9HEAGFNe6YibBOCjzsw@public.gmane.org>
  2012-04-13  1:03                                                     ` Alan Stern
  0 siblings, 2 replies; 148+ messages in thread
From: Andrey Rahmatullin @ 2012-04-12 20:21 UTC (permalink / raw)
  To: Alan Stern; +Cc: jrnieder, Greg KH, USB list, Steven Rostedt, linux-pm


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

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

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


-- 
WBR, wRAR

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

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



^ permalink raw reply	[flat|nested] 148+ messages in thread

* Re: ehci_hcd related S3 lockup on ASUS laptops, again
  2012-04-12 20:02                                               ` Alan Stern
  2012-04-12 20:09                                                 ` Alan Stern
@ 2012-04-12 20:30                                                 ` Andrey Rahmatullin
  2012-04-13  1:09                                                   ` Alan Stern
  1 sibling, 1 reply; 148+ messages in thread
From: Andrey Rahmatullin @ 2012-04-12 20:30 UTC (permalink / raw)
  To: Alan Stern; +Cc: jrnieder, Greg KH, USB list, Steven Rostedt, linux-pm


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

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

-- 
WBR, wRAR

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

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



^ permalink raw reply	[flat|nested] 148+ messages in thread

* Re: [linux-pm] ehci_hcd related S3 lockup on ASUS laptops, again
       [not found]                                                     ` <20120412202132.GH12852-hAV9HEAGFNe6YibBOCjzsw@public.gmane.org>
@ 2012-04-12 20:33                                                       ` Steven Rostedt
       [not found]                                                         ` <1334262826.23924.351.camel-f9ZlEuEWxVcI6MkJdU+c8EEOCMrvLtNR@public.gmane.org>
  0 siblings, 1 reply; 148+ messages in thread
From: Steven Rostedt @ 2012-04-12 20:33 UTC (permalink / raw)
  To: Andrey Rahmatullin
  Cc: Alan Stern, Rafael J. Wysocki, jrnieder-Re5JQEeQqe8AvxtiuMwx3w,
	linux-pm-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA, USB list,
	Greg KH

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

^ permalink raw reply	[flat|nested] 148+ messages in thread

* Re: ehci_hcd related S3 lockup on ASUS laptops, again
  2012-04-12 20:21                                                   ` Andrey Rahmatullin
       [not found]                                                     ` <20120412202132.GH12852-hAV9HEAGFNe6YibBOCjzsw@public.gmane.org>
@ 2012-04-13  1:03                                                     ` Alan Stern
  1 sibling, 0 replies; 148+ messages in thread
From: Alan Stern @ 2012-04-13  1:03 UTC (permalink / raw)
  To: Andrey Rahmatullin; +Cc: jrnieder, Greg KH, USB list, Steven Rostedt, linux-pm

On Fri, 13 Apr 2012, Andrey Rahmatullin wrote:

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

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

Alan Stern

^ permalink raw reply	[flat|nested] 148+ messages in thread

* Re: ehci_hcd related S3 lockup on ASUS laptops, again
  2012-04-12 20:30                                                 ` Andrey Rahmatullin
@ 2012-04-13  1:09                                                   ` Alan Stern
       [not found]                                                     ` <Pine.LNX.4.44L0.1204122103230.10558-100000-pYrvlCTfrz9XsRXLowluHWD2FQJk+8+b@public.gmane.org>
  0 siblings, 1 reply; 148+ messages in thread
From: Alan Stern @ 2012-04-13  1:09 UTC (permalink / raw)
  To: Andrey Rahmatullin; +Cc: jrnieder, Greg KH, USB list, Steven Rostedt, linux-pm

On Fri, 13 Apr 2012, Andrey Rahmatullin wrote:

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

I expected that.  Sigh.

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

Alan Stern

^ permalink raw reply	[flat|nested] 148+ messages in thread

* Re: [linux-pm] ehci_hcd related S3 lockup on ASUS laptops, again
       [not found]                                                         ` <1334262826.23924.351.camel-f9ZlEuEWxVcI6MkJdU+c8EEOCMrvLtNR@public.gmane.org>
@ 2012-04-13  1:09                                                           ` Alan Stern
  0 siblings, 0 replies; 148+ messages in thread
From: Alan Stern @ 2012-04-13  1:09 UTC (permalink / raw)
  To: Steven Rostedt
  Cc: Andrey Rahmatullin, Rafael J. Wysocki,
	jrnieder-Re5JQEeQqe8AvxtiuMwx3w,
	linux-pm-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA, USB list,
	Greg KH

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

^ permalink raw reply	[flat|nested] 148+ messages in thread

* Re: [linux-pm] ehci_hcd related S3 lockup on ASUS laptops, again
       [not found]                                                     ` <Pine.LNX.4.44L0.1204122103230.10558-100000-pYrvlCTfrz9XsRXLowluHWD2FQJk+8+b@public.gmane.org>
@ 2012-04-13 14:10                                                       ` Alan Stern
       [not found]                                                         ` <Pine.LNX.4.44L0.1204131008010.1185-100000-IYeN2dnnYyZXsRXLowluHWD2FQJk+8+b@public.gmane.org>
  0 siblings, 1 reply; 148+ messages in thread
From: Alan Stern @ 2012-04-13 14:10 UTC (permalink / raw)
  To: Andrey Rahmatullin
  Cc: Steven Rostedt, jrnieder-Re5JQEeQqe8AvxtiuMwx3w,
	linux-pm-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA, USB list

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

^ permalink raw reply	[flat|nested] 148+ messages in thread

* Re: [linux-pm] ehci_hcd related S3 lockup on ASUS laptops, again
       [not found]                                                         ` <Pine.LNX.4.44L0.1204131008010.1185-100000-IYeN2dnnYyZXsRXLowluHWD2FQJk+8+b@public.gmane.org>
@ 2012-04-13 15:29                                                           ` Steven Rostedt
       [not found]                                                             ` <1334330949.23924.360.camel-f9ZlEuEWxVcI6MkJdU+c8EEOCMrvLtNR@public.gmane.org>
  2012-04-13 21:04                                                             ` Alan Stern
  2012-04-13 22:43                                                           ` [linux-pm] " Andrey Rahmatullin
  1 sibling, 2 replies; 148+ messages in thread
From: Steven Rostedt @ 2012-04-13 15:29 UTC (permalink / raw)
  To: Alan Stern
  Cc: Andrey Rahmatullin, jrnieder-Re5JQEeQqe8AvxtiuMwx3w,
	linux-pm-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA, USB list

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

^ permalink raw reply	[flat|nested] 148+ messages in thread

* Re: [linux-pm] ehci_hcd related S3 lockup on ASUS laptops, again
       [not found]                                                             ` <1334330949.23924.360.camel-f9ZlEuEWxVcI6MkJdU+c8EEOCMrvLtNR@public.gmane.org>
@ 2012-04-13 15:32                                                               ` Steven Rostedt
       [not found]                                                                 ` <1334331148.23924.361.camel-f9ZlEuEWxVcI6MkJdU+c8EEOCMrvLtNR@public.gmane.org>
  2012-04-13 15:42                                                               ` Alan Stern
  1 sibling, 1 reply; 148+ messages in thread
From: Steven Rostedt @ 2012-04-13 15:32 UTC (permalink / raw)
  To: Alan Stern
  Cc: Andrey Rahmatullin, jrnieder-Re5JQEeQqe8AvxtiuMwx3w,
	linux-pm-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA, USB list

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

^ permalink raw reply	[flat|nested] 148+ messages in thread

* Re: [linux-pm] ehci_hcd related S3 lockup on ASUS laptops, again
       [not found]                                                                 ` <1334331148.23924.361.camel-f9ZlEuEWxVcI6MkJdU+c8EEOCMrvLtNR@public.gmane.org>
@ 2012-04-13 15:35                                                                   ` Steven Rostedt
  0 siblings, 0 replies; 148+ messages in thread
From: Steven Rostedt @ 2012-04-13 15:35 UTC (permalink / raw)
  To: Alan Stern
  Cc: Andrey Rahmatullin, jrnieder-Re5JQEeQqe8AvxtiuMwx3w,
	linux-pm-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA, USB list

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

^ permalink raw reply	[flat|nested] 148+ messages in thread

* Re: [linux-pm] ehci_hcd related S3 lockup on ASUS laptops, again
       [not found]                                                             ` <1334330949.23924.360.camel-f9ZlEuEWxVcI6MkJdU+c8EEOCMrvLtNR@public.gmane.org>
  2012-04-13 15:32                                                               ` Steven Rostedt
@ 2012-04-13 15:42                                                               ` Alan Stern
  1 sibling, 0 replies; 148+ messages in thread
From: Alan Stern @ 2012-04-13 15:42 UTC (permalink / raw)
  To: Steven Rostedt
  Cc: Andrey Rahmatullin, jrnieder-Re5JQEeQqe8AvxtiuMwx3w,
	linux-pm-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA, USB list

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

^ permalink raw reply	[flat|nested] 148+ messages in thread

* Re: ehci_hcd related S3 lockup on ASUS laptops, again
  2012-04-13 15:29                                                           ` Steven Rostedt
       [not found]                                                             ` <1334330949.23924.360.camel-f9ZlEuEWxVcI6MkJdU+c8EEOCMrvLtNR@public.gmane.org>
@ 2012-04-13 21:04                                                             ` Alan Stern
  1 sibling, 0 replies; 148+ messages in thread
From: Alan Stern @ 2012-04-13 21:04 UTC (permalink / raw)
  To: Steven Rostedt; +Cc: jrnieder, Andrey Rahmatullin, linux-pm, USB list

On Fri, 13 Apr 2012, Steven Rostedt wrote:

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

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

Alan Stern



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

^ permalink raw reply	[flat|nested] 148+ messages in thread

* Re: [linux-pm] ehci_hcd related S3 lockup on ASUS laptops, again
       [not found]                                                         ` <Pine.LNX.4.44L0.1204131008010.1185-100000-IYeN2dnnYyZXsRXLowluHWD2FQJk+8+b@public.gmane.org>
  2012-04-13 15:29                                                           ` Steven Rostedt
@ 2012-04-13 22:43                                                           ` Andrey Rahmatullin
  2012-04-16 20:07                                                             ` Alan Stern
  1 sibling, 1 reply; 148+ messages in thread
From: Andrey Rahmatullin @ 2012-04-13 22:43 UTC (permalink / raw)
  To: Alan Stern
  Cc: Steven Rostedt, jrnieder-Re5JQEeQqe8AvxtiuMwx3w,
	linux-pm-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA, USB list

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

^ permalink raw reply	[flat|nested] 148+ messages in thread

* Re: ehci_hcd related S3 lockup on ASUS laptops, again
  2012-04-13 22:43                                                           ` [linux-pm] " Andrey Rahmatullin
@ 2012-04-16 20:07                                                             ` Alan Stern
  2012-04-16 21:19                                                               ` Andrey Rahmatullin
  0 siblings, 1 reply; 148+ messages in thread
From: Alan Stern @ 2012-04-16 20:07 UTC (permalink / raw)
  To: Andrey Rahmatullin; +Cc: jrnieder, linux-pm, USB list, Steven Rostedt

On Sat, 14 Apr 2012, Andrey Rahmatullin wrote:

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

Okay.

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

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

Alan Stern




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

^ permalink raw reply	[flat|nested] 148+ messages in thread

* Re: ehci_hcd related S3 lockup on ASUS laptops, again
  2012-04-16 20:07                                                             ` Alan Stern
@ 2012-04-16 21:19                                                               ` Andrey Rahmatullin
  2012-04-17 15:11                                                                 ` Alan Stern
  0 siblings, 1 reply; 148+ messages in thread
From: Andrey Rahmatullin @ 2012-04-16 21:19 UTC (permalink / raw)
  To: Alan Stern; +Cc: jrnieder, linux-pm, USB list, Steven Rostedt


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

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

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

-- 
WBR, wRAR

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

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



^ permalink raw reply	[flat|nested] 148+ messages in thread

* Re: ehci_hcd related S3 lockup on ASUS laptops, again
  2012-04-16 21:19                                                               ` Andrey Rahmatullin
@ 2012-04-17 15:11                                                                 ` Alan Stern
  2012-04-17 16:25                                                                   ` Andrey Rahmatullin
  0 siblings, 1 reply; 148+ messages in thread
From: Alan Stern @ 2012-04-17 15:11 UTC (permalink / raw)
  To: Andrey Rahmatullin; +Cc: jrnieder, linux-pm, USB list, Steven Rostedt

On Tue, 17 Apr 2012, Andrey Rahmatullin wrote:

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

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

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

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

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

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

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

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

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

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

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

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

Alan Stern

^ permalink raw reply	[flat|nested] 148+ messages in thread

* Re: ehci_hcd related S3 lockup on ASUS laptops, again
  2012-04-17 15:11                                                                 ` Alan Stern
@ 2012-04-17 16:25                                                                   ` Andrey Rahmatullin
  2012-04-17 16:58                                                                     ` Alan Stern
  0 siblings, 1 reply; 148+ messages in thread
From: Andrey Rahmatullin @ 2012-04-17 16:25 UTC (permalink / raw)
  To: Alan Stern; +Cc: jrnieder, linux-pm, USB list, Steven Rostedt


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

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

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

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

-- 
WBR, wRAR

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

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



^ permalink raw reply	[flat|nested] 148+ messages in thread

* Re: ehci_hcd related S3 lockup on ASUS laptops, again
  2012-04-17 16:25                                                                   ` Andrey Rahmatullin
@ 2012-04-17 16:58                                                                     ` Alan Stern
       [not found]                                                                       ` <Pine.LNX.4.44L0.1204171251330.1364-100000-IYeN2dnnYyZXsRXLowluHWD2FQJk+8+b@public.gmane.org>
  0 siblings, 1 reply; 148+ messages in thread
From: Alan Stern @ 2012-04-17 16:58 UTC (permalink / raw)
  To: Andrey Rahmatullin; +Cc: jrnieder, linux-pm, USB list, Steven Rostedt

On Tue, 17 Apr 2012, Andrey Rahmatullin wrote:

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

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

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

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

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

Alan Stern

^ permalink raw reply	[flat|nested] 148+ messages in thread

* Re: [linux-pm] ehci_hcd related S3 lockup on ASUS laptops, again
       [not found]                                                                       ` <Pine.LNX.4.44L0.1204171251330.1364-100000-IYeN2dnnYyZXsRXLowluHWD2FQJk+8+b@public.gmane.org>
@ 2012-04-17 17:51                                                                         ` Andrey Rahmatullin
       [not found]                                                                           ` <20120417175122.GM11484-hAV9HEAGFNe6YibBOCjzsw@public.gmane.org>
  0 siblings, 1 reply; 148+ messages in thread
From: Andrey Rahmatullin @ 2012-04-17 17:51 UTC (permalink / raw)
  To: Alan Stern
  Cc: Steven Rostedt, jrnieder-Re5JQEeQqe8AvxtiuMwx3w,
	linux-pm-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA, USB list


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

^ permalink raw reply related	[flat|nested] 148+ messages in thread

* Re: [linux-pm] ehci_hcd related S3 lockup on ASUS laptops, again
       [not found]                                                                           ` <20120417175122.GM11484-hAV9HEAGFNe6YibBOCjzsw@public.gmane.org>
@ 2012-04-17 18:26                                                                             ` Alan Stern
       [not found]                                                                               ` <Pine.LNX.4.44L0.1204171423310.1163-100000-IYeN2dnnYyZXsRXLowluHWD2FQJk+8+b@public.gmane.org>
  0 siblings, 1 reply; 148+ messages in thread
From: Alan Stern @ 2012-04-17 18:26 UTC (permalink / raw)
  To: Andrey Rahmatullin
  Cc: Steven Rostedt, jrnieder-Re5JQEeQqe8AvxtiuMwx3w,
	linux-pm-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA, USB list

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

^ permalink raw reply	[flat|nested] 148+ messages in thread

* Re: [linux-pm] ehci_hcd related S3 lockup on ASUS laptops, again
       [not found]                                                                               ` <Pine.LNX.4.44L0.1204171423310.1163-100000-IYeN2dnnYyZXsRXLowluHWD2FQJk+8+b@public.gmane.org>
@ 2012-04-17 18:51                                                                                 ` Andrey Rahmatullin
       [not found]                                                                                   ` <20120417185149.GO11484-hAV9HEAGFNe6YibBOCjzsw@public.gmane.org>
  0 siblings, 1 reply; 148+ messages in thread
From: Andrey Rahmatullin @ 2012-04-17 18:51 UTC (permalink / raw)
  To: Alan Stern
  Cc: Steven Rostedt, jrnieder-Re5JQEeQqe8AvxtiuMwx3w,
	linux-pm-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA, USB list

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

^ permalink raw reply	[flat|nested] 148+ messages in thread

* Re: [linux-pm] ehci_hcd related S3 lockup on ASUS laptops, again
       [not found]                                                                                   ` <20120417185149.GO11484-hAV9HEAGFNe6YibBOCjzsw@public.gmane.org>
@ 2012-04-17 19:20                                                                                     ` Alan Stern
       [not found]                                                                                       ` <Pine.LNX.4.44L0.1204171513230.1163-100000-IYeN2dnnYyZXsRXLowluHWD2FQJk+8+b@public.gmane.org>
  0 siblings, 1 reply; 148+ messages in thread
From: Alan Stern @ 2012-04-17 19:20 UTC (permalink / raw)
  To: Andrey Rahmatullin
  Cc: Steven Rostedt, jrnieder-Re5JQEeQqe8AvxtiuMwx3w,
	linux-pm-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA, USB list

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

^ permalink raw reply	[flat|nested] 148+ messages in thread

* Re: [linux-pm] ehci_hcd related S3 lockup on ASUS laptops, again
       [not found]                                                                                       ` <Pine.LNX.4.44L0.1204171513230.1163-100000-IYeN2dnnYyZXsRXLowluHWD2FQJk+8+b@public.gmane.org>
@ 2012-04-17 19:52                                                                                         ` Andrey Rahmatullin
       [not found]                                                                                           ` <20120417195218.GP11484-hAV9HEAGFNe6YibBOCjzsw@public.gmane.org>
  0 siblings, 1 reply; 148+ messages in thread
From: Andrey Rahmatullin @ 2012-04-17 19:52 UTC (permalink / raw)
  To: Alan Stern
  Cc: Steven Rostedt, jrnieder-Re5JQEeQqe8AvxtiuMwx3w,
	linux-pm-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA, USB list

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

^ permalink raw reply	[flat|nested] 148+ messages in thread

* Re: [linux-pm] ehci_hcd related S3 lockup on ASUS laptops, again
       [not found]                                                                                           ` <20120417195218.GP11484-hAV9HEAGFNe6YibBOCjzsw@public.gmane.org>
@ 2012-04-18 14:51                                                                                             ` Alan Stern
       [not found]                                                                                               ` <Pine.LNX.4.44L0.1204181048340.1548-100000-IYeN2dnnYyZXsRXLowluHWD2FQJk+8+b@public.gmane.org>
  0 siblings, 1 reply; 148+ messages in thread
From: Alan Stern @ 2012-04-18 14:51 UTC (permalink / raw)
  To: Andrey Rahmatullin
  Cc: Steven Rostedt, jrnieder-Re5JQEeQqe8AvxtiuMwx3w,
	linux-pm-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA, USB list

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

^ permalink raw reply	[flat|nested] 148+ messages in thread

* Re: [linux-pm] ehci_hcd related S3 lockup on ASUS laptops, again
       [not found]                                                                                               ` <Pine.LNX.4.44L0.1204181048340.1548-100000-IYeN2dnnYyZXsRXLowluHWD2FQJk+8+b@public.gmane.org>
@ 2012-04-18 15:08                                                                                                 ` Steven Rostedt
  2012-04-18 15:24                                                                                                 ` Andrey Rahmatullin
  2012-04-18 15:39                                                                                                 ` [linux-pm] " Steven Rostedt
  2 siblings, 0 replies; 148+ messages in thread
From: Steven Rostedt @ 2012-04-18 15:08 UTC (permalink / raw)
  To: Alan Stern
  Cc: Andrey Rahmatullin, jrnieder-Re5JQEeQqe8AvxtiuMwx3w,
	linux-pm-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA, USB list

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

^ permalink raw reply	[flat|nested] 148+ messages in thread

* Re: [linux-pm] ehci_hcd related S3 lockup on ASUS laptops, again
       [not found]                                                                                               ` <Pine.LNX.4.44L0.1204181048340.1548-100000-IYeN2dnnYyZXsRXLowluHWD2FQJk+8+b@public.gmane.org>
  2012-04-18 15:08                                                                                                 ` Steven Rostedt
@ 2012-04-18 15:24                                                                                                 ` Andrey Rahmatullin
  2012-04-18 16:41                                                                                                   ` Alan Stern
  2012-04-18 15:39                                                                                                 ` [linux-pm] " Steven Rostedt
  2 siblings, 1 reply; 148+ messages in thread
From: Andrey Rahmatullin @ 2012-04-18 15:24 UTC (permalink / raw)
  To: Alan Stern
  Cc: Steven Rostedt, jrnieder-Re5JQEeQqe8AvxtiuMwx3w,
	linux-pm-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA, USB list

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

^ permalink raw reply	[flat|nested] 148+ messages in thread

* Re: [linux-pm] ehci_hcd related S3 lockup on ASUS laptops, again
       [not found]                                                                                               ` <Pine.LNX.4.44L0.1204181048340.1548-100000-IYeN2dnnYyZXsRXLowluHWD2FQJk+8+b@public.gmane.org>
  2012-04-18 15:08                                                                                                 ` Steven Rostedt
  2012-04-18 15:24                                                                                                 ` Andrey Rahmatullin
@ 2012-04-18 15:39                                                                                                 ` Steven Rostedt
  2 siblings, 0 replies; 148+ messages in thread
From: Steven Rostedt @ 2012-04-18 15:39 UTC (permalink / raw)
  To: Alan Stern
  Cc: Andrey Rahmatullin, jrnieder-Re5JQEeQqe8AvxtiuMwx3w,
	linux-pm-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA, USB list

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

^ permalink raw reply	[flat|nested] 148+ messages in thread

* Re: ehci_hcd related S3 lockup on ASUS laptops, again
  2012-04-18 15:24                                                                                                 ` Andrey Rahmatullin
@ 2012-04-18 16:41                                                                                                   ` Alan Stern
       [not found]                                                                                                     ` <Pine.LNX.4.44L0.1204181228380.1149-100000-IYeN2dnnYyZXsRXLowluHWD2FQJk+8+b@public.gmane.org>
  2012-04-18 17:10                                                                                                     ` Andrey Rahmatullin
  0 siblings, 2 replies; 148+ messages in thread
From: Alan Stern @ 2012-04-18 16:41 UTC (permalink / raw)
  To: Andrey Rahmatullin; +Cc: jrnieder, linux-pm, USB list, Steven Rostedt

On Wed, 18 Apr 2012, Andrey Rahmatullin wrote:

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

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

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

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

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

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

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

Alan Stern

^ permalink raw reply	[flat|nested] 148+ messages in thread

* Re: [linux-pm] ehci_hcd related S3 lockup on ASUS laptops, again
       [not found]                                                                                                     ` <Pine.LNX.4.44L0.1204181228380.1149-100000-IYeN2dnnYyZXsRXLowluHWD2FQJk+8+b@public.gmane.org>
@ 2012-04-18 17:07                                                                                                       ` Steven Rostedt
       [not found]                                                                                                         ` <1334768847.28106.45.camel-f9ZlEuEWxVcI6MkJdU+c8EEOCMrvLtNR@public.gmane.org>
  0 siblings, 1 reply; 148+ messages in thread
From: Steven Rostedt @ 2012-04-18 17:07 UTC (permalink / raw)
  To: Alan Stern
  Cc: Andrey Rahmatullin, jrnieder-Re5JQEeQqe8AvxtiuMwx3w,
	linux-pm-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA, USB list

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

^ permalink raw reply	[flat|nested] 148+ messages in thread

* Re: ehci_hcd related S3 lockup on ASUS laptops, again
  2012-04-18 16:41                                                                                                   ` Alan Stern
       [not found]                                                                                                     ` <Pine.LNX.4.44L0.1204181228380.1149-100000-IYeN2dnnYyZXsRXLowluHWD2FQJk+8+b@public.gmane.org>
@ 2012-04-18 17:10                                                                                                     ` Andrey Rahmatullin
       [not found]                                                                                                       ` <20120418171002.GU11484-hAV9HEAGFNe6YibBOCjzsw@public.gmane.org>
  1 sibling, 1 reply; 148+ messages in thread
From: Andrey Rahmatullin @ 2012-04-18 17:10 UTC (permalink / raw)
  To: Alan Stern; +Cc: jrnieder, linux-pm, USB list, Steven Rostedt


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

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

-- 
WBR, wRAR

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

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



^ permalink raw reply	[flat|nested] 148+ messages in thread

* Re: [linux-pm] ehci_hcd related S3 lockup on ASUS laptops, again
       [not found]                                                                                                         ` <1334768847.28106.45.camel-f9ZlEuEWxVcI6MkJdU+c8EEOCMrvLtNR@public.gmane.org>
@ 2012-04-18 17:19                                                                                                           ` Alan Stern
       [not found]                                                                                                             ` <Pine.LNX.4.44L0.1204181317550.1149-100000-IYeN2dnnYyZXsRXLowluHWD2FQJk+8+b@public.gmane.org>
  0 siblings, 1 reply; 148+ messages in thread
From: Alan Stern @ 2012-04-18 17:19 UTC (permalink / raw)
  To: Steven Rostedt
  Cc: Andrey Rahmatullin, jrnieder-Re5JQEeQqe8AvxtiuMwx3w,
	linux-pm-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA, USB list

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

^ permalink raw reply	[flat|nested] 148+ messages in thread

* Re: [linux-pm] ehci_hcd related S3 lockup on ASUS laptops, again
       [not found]                                                                                                       ` <20120418171002.GU11484-hAV9HEAGFNe6YibBOCjzsw@public.gmane.org>
@ 2012-04-18 17:20                                                                                                         ` Steven Rostedt
       [not found]                                                                                                           ` <1334769632.28106.46.camel-f9ZlEuEWxVcI6MkJdU+c8EEOCMrvLtNR@public.gmane.org>
  2012-04-18 21:10                                                                                                           ` Andrey Rahmatullin
  0 siblings, 2 replies; 148+ messages in thread
From: Steven Rostedt @ 2012-04-18 17:20 UTC (permalink / raw)
  To: Andrey Rahmatullin
  Cc: Alan Stern, jrnieder-Re5JQEeQqe8AvxtiuMwx3w,
	linux-pm-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA, USB list

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

^ permalink raw reply	[flat|nested] 148+ messages in thread

* Re: [linux-pm] ehci_hcd related S3 lockup on ASUS laptops, again
       [not found]                                                                                                             ` <Pine.LNX.4.44L0.1204181317550.1149-100000-IYeN2dnnYyZXsRXLowluHWD2FQJk+8+b@public.gmane.org>
@ 2012-04-18 17:24                                                                                                               ` Steven Rostedt
       [not found]                                                                                                                 ` <1334769847.28106.47.camel-f9ZlEuEWxVcI6MkJdU+c8EEOCMrvLtNR@public.gmane.org>
  0 siblings, 1 reply; 148+ messages in thread
From: Steven Rostedt @ 2012-04-18 17:24 UTC (permalink / raw)
  To: Alan Stern
  Cc: Andrey Rahmatullin, jrnieder-Re5JQEeQqe8AvxtiuMwx3w,
	linux-pm-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA, USB list

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

^ permalink raw reply	[flat|nested] 148+ messages in thread

* Re: [linux-pm] ehci_hcd related S3 lockup on ASUS laptops, again
       [not found]                                                                                                                 ` <1334769847.28106.47.camel-f9ZlEuEWxVcI6MkJdU+c8EEOCMrvLtNR@public.gmane.org>
@ 2012-04-18 17:46                                                                                                                   ` Mark Brown
       [not found]                                                                                                                     ` <20120418174610.GA10142-GFdadSzt00ze9xe1eoZjHA@public.gmane.org>
  0 siblings, 1 reply; 148+ messages in thread
From: Mark Brown @ 2012-04-18 17:46 UTC (permalink / raw)
  To: Steven Rostedt
  Cc: Alan Stern, jrnieder-Re5JQEeQqe8AvxtiuMwx3w, Andrey Rahmatullin,
	linux-pm-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA, USB list

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

^ permalink raw reply	[flat|nested] 148+ messages in thread

* Re: [linux-pm] ehci_hcd related S3 lockup on ASUS laptops, again
       [not found]                                                                                                                     ` <20120418174610.GA10142-GFdadSzt00ze9xe1eoZjHA@public.gmane.org>
@ 2012-04-18 18:11                                                                                                                       ` Steven Rostedt
  2012-04-18 20:25                                                                                                                       ` Alan Stern
  1 sibling, 0 replies; 148+ messages in thread
From: Steven Rostedt @ 2012-04-18 18:11 UTC (permalink / raw)
  To: Mark Brown
  Cc: Alan Stern, jrnieder-Re5JQEeQqe8AvxtiuMwx3w, Andrey Rahmatullin,
	linux-pm-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA, USB list

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

^ permalink raw reply	[flat|nested] 148+ messages in thread

* Re: [linux-pm] ehci_hcd related S3 lockup on ASUS laptops, again
       [not found]                                                                                                           ` <1334769632.28106.46.camel-f9ZlEuEWxVcI6MkJdU+c8EEOCMrvLtNR@public.gmane.org>
@ 2012-04-18 20:23                                                                                                             ` Alan Stern
       [not found]                                                                                                               ` <Pine.LNX.4.44L0.1204181616430.1149-100000-IYeN2dnnYyZXsRXLowluHWD2FQJk+8+b@public.gmane.org>
  2012-04-18 21:23                                                                                                               ` Andrey Rahmatullin
  0 siblings, 2 replies; 148+ messages in thread
From: Alan Stern @ 2012-04-18 20:23 UTC (permalink / raw)
  To: Steven Rostedt
  Cc: Andrey Rahmatullin, jrnieder-Re5JQEeQqe8AvxtiuMwx3w,
	linux-pm-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA, USB list

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

^ permalink raw reply	[flat|nested] 148+ messages in thread

* Re: [linux-pm] ehci_hcd related S3 lockup on ASUS laptops, again
       [not found]                                                                                                                     ` <20120418174610.GA10142-GFdadSzt00ze9xe1eoZjHA@public.gmane.org>
  2012-04-18 18:11                                                                                                                       ` Steven Rostedt
@ 2012-04-18 20:25                                                                                                                       ` Alan Stern
  1 sibling, 0 replies; 148+ messages in thread
From: Alan Stern @ 2012-04-18 20:25 UTC (permalink / raw)
  To: Mark Brown
  Cc: Steven Rostedt, jrnieder-Re5JQEeQqe8AvxtiuMwx3w,
	Andrey Rahmatullin,
	linux-pm-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA, USB list

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

^ permalink raw reply	[flat|nested] 148+ messages in thread

* Re: [linux-pm] ehci_hcd related S3 lockup on ASUS laptops, again
       [not found]                                                                                                               ` <Pine.LNX.4.44L0.1204181616430.1149-100000-IYeN2dnnYyZXsRXLowluHWD2FQJk+8+b@public.gmane.org>
@ 2012-04-18 21:02                                                                                                                 ` Steven Rostedt
       [not found]                                                                                                                   ` <1334782932.28106.52.camel-f9ZlEuEWxVcI6MkJdU+c8EEOCMrvLtNR@public.gmane.org>
  2012-04-18 21:04                                                                                                                 ` Rafael J. Wysocki
  1 sibling, 1 reply; 148+ messages in thread
From: Steven Rostedt @ 2012-04-18 21:02 UTC (permalink / raw)
  To: Alan Stern
  Cc: Andrey Rahmatullin, jrnieder-Re5JQEeQqe8AvxtiuMwx3w,
	linux-pm-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA, USB list

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

^ permalink raw reply	[flat|nested] 148+ messages in thread

* Re: [linux-pm] ehci_hcd related S3 lockup on ASUS laptops, again
       [not found]                                                                                                               ` <Pine.LNX.4.44L0.1204181616430.1149-100000-IYeN2dnnYyZXsRXLowluHWD2FQJk+8+b@public.gmane.org>
  2012-04-18 21:02                                                                                                                 ` Steven Rostedt
@ 2012-04-18 21:04                                                                                                                 ` Rafael J. Wysocki
       [not found]                                                                                                                   ` <201204182304.29249.rjw-KKrjLPT3xs0@public.gmane.org>
  1 sibling, 1 reply; 148+ messages in thread
From: Rafael J. Wysocki @ 2012-04-18 21:04 UTC (permalink / raw)
  To: linux-pm-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA
  Cc: Alan Stern, Steven Rostedt, jrnieder-Re5JQEeQqe8AvxtiuMwx3w,
	Andrey Rahmatullin, USB list

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

^ permalink raw reply	[flat|nested] 148+ messages in thread

* Re: ehci_hcd related S3 lockup on ASUS laptops, again
  2012-04-18 17:20                                                                                                         ` [linux-pm] " Steven Rostedt
       [not found]                                                                                                           ` <1334769632.28106.46.camel-f9ZlEuEWxVcI6MkJdU+c8EEOCMrvLtNR@public.gmane.org>
@ 2012-04-18 21:10                                                                                                           ` Andrey Rahmatullin
  1 sibling, 0 replies; 148+ messages in thread
From: Andrey Rahmatullin @ 2012-04-18 21:10 UTC (permalink / raw)
  To: Steven Rostedt; +Cc: jrnieder, linux-pm, USB list


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

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

-- 
WBR, wRAR

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

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



^ permalink raw reply	[flat|nested] 148+ messages in thread

* Re: ehci_hcd related S3 lockup on ASUS laptops, again
  2012-04-18 20:23                                                                                                             ` Alan Stern
       [not found]                                                                                                               ` <Pine.LNX.4.44L0.1204181616430.1149-100000-IYeN2dnnYyZXsRXLowluHWD2FQJk+8+b@public.gmane.org>
@ 2012-04-18 21:23                                                                                                               ` Andrey Rahmatullin
       [not found]                                                                                                                 ` <20120418212301.GW11484-hAV9HEAGFNe6YibBOCjzsw@public.gmane.org>
  1 sibling, 1 reply; 148+ messages in thread
From: Andrey Rahmatullin @ 2012-04-18 21:23 UTC (permalink / raw)
  To: Alan Stern; +Cc: jrnieder, linux-pm, USB list, Steven Rostedt


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

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

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

With "none" it locks up.

-- 
WBR, wRAR

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

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



^ permalink raw reply	[flat|nested] 148+ messages in thread

* Re: [linux-pm] ehci_hcd related S3 lockup on ASUS laptops, again
       [not found]                                                                                                                   ` <1334782932.28106.52.camel-f9ZlEuEWxVcI6MkJdU+c8EEOCMrvLtNR@public.gmane.org>
@ 2012-04-18 21:27                                                                                                                     ` Alan Stern
       [not found]                                                                                                                       ` <Pine.LNX.4.44L0.1204181724570.1149-100000-IYeN2dnnYyZXsRXLowluHWD2FQJk+8+b@public.gmane.org>
  0 siblings, 1 reply; 148+ messages in thread
From: Alan Stern @ 2012-04-18 21:27 UTC (permalink / raw)
  To: Steven Rostedt
  Cc: Andrey Rahmatullin, jrnieder-Re5JQEeQqe8AvxtiuMwx3w,
	linux-pm-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA, USB list

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

^ permalink raw reply	[flat|nested] 148+ messages in thread

* Re: [linux-pm] ehci_hcd related S3 lockup on ASUS laptops, again
       [not found]                                                                                                                   ` <201204182304.29249.rjw-KKrjLPT3xs0@public.gmane.org>
@ 2012-04-18 21:29                                                                                                                     ` Alan Stern
       [not found]                                                                                                                       ` <Pine.LNX.4.44L0.1204181727580.1149-100000-IYeN2dnnYyZXsRXLowluHWD2FQJk+8+b@public.gmane.org>
  0 siblings, 1 reply; 148+ messages in thread
From: Alan Stern @ 2012-04-18 21:29 UTC (permalink / raw)
  To: Rafael J. Wysocki
  Cc: linux-pm-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA,
	Steven Rostedt, jrnieder-Re5JQEeQqe8AvxtiuMwx3w,
	Andrey Rahmatullin, USB list

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

^ permalink raw reply	[flat|nested] 148+ messages in thread

* Re: [linux-pm] ehci_hcd related S3 lockup on ASUS laptops, again
       [not found]                                                                                                                 ` <20120418212301.GW11484-hAV9HEAGFNe6YibBOCjzsw@public.gmane.org>
@ 2012-04-18 21:30                                                                                                                   ` Alan Stern
       [not found]                                                                                                                     ` <Pine.LNX.4.44L0.1204181729400.1149-100000-IYeN2dnnYyZXsRXLowluHWD2FQJk+8+b@public.gmane.org>
  0 siblings, 1 reply; 148+ messages in thread
From: Alan Stern @ 2012-04-18 21:30 UTC (permalink / raw)
  To: Andrey Rahmatullin
  Cc: Steven Rostedt, jrnieder-Re5JQEeQqe8AvxtiuMwx3w,
	linux-pm-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA, USB list

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

^ permalink raw reply	[flat|nested] 148+ messages in thread

* Re: [linux-pm] ehci_hcd related S3 lockup on ASUS laptops, again
       [not found]                                                                                                                       ` <Pine.LNX.4.44L0.1204181724570.1149-100000-IYeN2dnnYyZXsRXLowluHWD2FQJk+8+b@public.gmane.org>
@ 2012-04-18 21:41                                                                                                                         ` Steven Rostedt
  0 siblings, 0 replies; 148+ messages in thread
From: Steven Rostedt @ 2012-04-18 21:41 UTC (permalink / raw)
  To: Alan Stern
  Cc: Andrey Rahmatullin, jrnieder-Re5JQEeQqe8AvxtiuMwx3w,
	linux-pm-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA, USB list

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

^ permalink raw reply	[flat|nested] 148+ messages in thread

* Re: [linux-pm] ehci_hcd related S3 lockup on ASUS laptops, again
       [not found]                                                                                                                       ` <Pine.LNX.4.44L0.1204181727580.1149-100000-IYeN2dnnYyZXsRXLowluHWD2FQJk+8+b@public.gmane.org>
@ 2012-04-18 21:44                                                                                                                         ` Rafael J. Wysocki
  2012-04-18 21:47                                                                                                                           ` Andrey Rahmatullin
  0 siblings, 1 reply; 148+ messages in thread
From: Rafael J. Wysocki @ 2012-04-18 21:44 UTC (permalink / raw)
  To: Alan Stern
  Cc: linux-pm-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA,
	Steven Rostedt, jrnieder-Re5JQEeQqe8AvxtiuMwx3w,
	Andrey Rahmatullin, USB list

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

^ permalink raw reply	[flat|nested] 148+ messages in thread

* Re: ehci_hcd related S3 lockup on ASUS laptops, again
  2012-04-18 21:44                                                                                                                         ` Rafael J. Wysocki
@ 2012-04-18 21:47                                                                                                                           ` Andrey Rahmatullin
  0 siblings, 0 replies; 148+ messages in thread
From: Andrey Rahmatullin @ 2012-04-18 21:47 UTC (permalink / raw)
  To: Rafael J. Wysocki; +Cc: jrnieder, linux-pm, USB list, Steven Rostedt


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

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

-- 
WBR, wRAR

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

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



^ permalink raw reply	[flat|nested] 148+ messages in thread

* Re: [linux-pm] ehci_hcd related S3 lockup on ASUS laptops, again
       [not found]                                                                                                                     ` <Pine.LNX.4.44L0.1204181729400.1149-100000-IYeN2dnnYyZXsRXLowluHWD2FQJk+8+b@public.gmane.org>
@ 2012-04-19 13:43                                                                                                                       ` Alan Stern
       [not found]                                                                                                                         ` <Pine.LNX.4.44L0.1204190934500.2070-100000-IYeN2dnnYyZXsRXLowluHWD2FQJk+8+b@public.gmane.org>
  0 siblings, 1 reply; 148+ messages in thread
From: Alan Stern @ 2012-04-19 13:43 UTC (permalink / raw)
  To: Andrey Rahmatullin
  Cc: jrnieder-Re5JQEeQqe8AvxtiuMwx3w,
	linux-pm-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA, USB list,
	Steven Rostedt

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

^ permalink raw reply	[flat|nested] 148+ messages in thread

* Re: [linux-pm] ehci_hcd related S3 lockup on ASUS laptops, again
       [not found]                                                                                                                         ` <Pine.LNX.4.44L0.1204190934500.2070-100000-IYeN2dnnYyZXsRXLowluHWD2FQJk+8+b@public.gmane.org>
@ 2012-04-19 15:44                                                                                                                           ` Andrey Rahmatullin
       [not found]                                                                                                                             ` <20120419154453.GZ11484-hAV9HEAGFNe6YibBOCjzsw@public.gmane.org>
  2012-04-19 15:53                                                                                                                           ` Andrey Rahmatullin
                                                                                                                                             ` (2 subsequent siblings)
  3 siblings, 1 reply; 148+ messages in thread
From: Andrey Rahmatullin @ 2012-04-19 15:44 UTC (permalink / raw)
  To: Alan Stern
  Cc: jrnieder-Re5JQEeQqe8AvxtiuMwx3w,
	linux-pm-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA, USB list,
	Steven Rostedt

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

^ permalink raw reply	[flat|nested] 148+ messages in thread

* Re: [linux-pm] ehci_hcd related S3 lockup on ASUS laptops, again
       [not found]                                                                                                                         ` <Pine.LNX.4.44L0.1204190934500.2070-100000-IYeN2dnnYyZXsRXLowluHWD2FQJk+8+b@public.gmane.org>
  2012-04-19 15:44                                                                                                                           ` Andrey Rahmatullin
@ 2012-04-19 15:53                                                                                                                           ` Andrey Rahmatullin
  2012-04-19 16:06                                                                                                                             ` Alan Stern
  2012-04-19 16:22                                                                                                                           ` [linux-pm] " Steven Rostedt
  2012-04-19 16:30                                                                                                                           ` Andrey Rahmatullin
  3 siblings, 1 reply; 148+ messages in thread
From: Andrey Rahmatullin @ 2012-04-19 15:53 UTC (permalink / raw)
  To: Alan Stern
  Cc: jrnieder-Re5JQEeQqe8AvxtiuMwx3w,
	linux-pm-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA, USB list,
	Steven Rostedt

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

^ permalink raw reply	[flat|nested] 148+ messages in thread

* Re: [linux-pm] ehci_hcd related S3 lockup on ASUS laptops, again
       [not found]                                                                                                                             ` <20120419154453.GZ11484-hAV9HEAGFNe6YibBOCjzsw@public.gmane.org>
@ 2012-04-19 16:05                                                                                                                               ` Alan Stern
  0 siblings, 0 replies; 148+ messages in thread
From: Alan Stern @ 2012-04-19 16:05 UTC (permalink / raw)
  To: Andrey Rahmatullin
  Cc: jrnieder-Re5JQEeQqe8AvxtiuMwx3w,
	linux-pm-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA, USB list,
	Steven Rostedt

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

^ permalink raw reply	[flat|nested] 148+ messages in thread

* Re: ehci_hcd related S3 lockup on ASUS laptops, again
  2012-04-19 15:53                                                                                                                           ` Andrey Rahmatullin
@ 2012-04-19 16:06                                                                                                                             ` Alan Stern
  0 siblings, 0 replies; 148+ messages in thread
From: Alan Stern @ 2012-04-19 16:06 UTC (permalink / raw)
  To: Andrey Rahmatullin; +Cc: jrnieder, linux-pm, USB list, Steven Rostedt

On Thu, 19 Apr 2012, Andrey Rahmatullin wrote:

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

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

Alan Stern

^ permalink raw reply	[flat|nested] 148+ messages in thread

* Re: [linux-pm] ehci_hcd related S3 lockup on ASUS laptops, again
       [not found]                                                                                                                         ` <Pine.LNX.4.44L0.1204190934500.2070-100000-IYeN2dnnYyZXsRXLowluHWD2FQJk+8+b@public.gmane.org>
  2012-04-19 15:44                                                                                                                           ` Andrey Rahmatullin
  2012-04-19 15:53                                                                                                                           ` Andrey Rahmatullin
@ 2012-04-19 16:22                                                                                                                           ` Steven Rostedt
       [not found]                                                                                                                             ` <1334852575.28106.62.camel-f9ZlEuEWxVcI6MkJdU+c8EEOCMrvLtNR@public.gmane.org>
  2012-04-19 16:30                                                                                                                           ` Andrey Rahmatullin
  3 siblings, 1 reply; 148+ messages in thread
From: Steven Rostedt @ 2012-04-19 16:22 UTC (permalink / raw)
  To: Alan Stern
  Cc: Andrey Rahmatullin, jrnieder-Re5JQEeQqe8AvxtiuMwx3w,
	linux-pm-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA, USB list

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

^ permalink raw reply	[flat|nested] 148+ messages in thread

* Re: [linux-pm] ehci_hcd related S3 lockup on ASUS laptops, again
       [not found]                                                                                                                         ` <Pine.LNX.4.44L0.1204190934500.2070-100000-IYeN2dnnYyZXsRXLowluHWD2FQJk+8+b@public.gmane.org>
                                                                                                                                             ` (2 preceding siblings ...)
  2012-04-19 16:22                                                                                                                           ` [linux-pm] " Steven Rostedt
@ 2012-04-19 16:30                                                                                                                           ` Andrey Rahmatullin
       [not found]                                                                                                                             ` <20120419163055.GB11484-hAV9HEAGFNe6YibBOCjzsw@public.gmane.org>
  2012-05-26  2:01                                                                                                                             ` Alan Stern
  3 siblings, 2 replies; 148+ messages in thread
From: Andrey Rahmatullin @ 2012-04-19 16:30 UTC (permalink / raw)
  To: Alan Stern
  Cc: jrnieder-Re5JQEeQqe8AvxtiuMwx3w,
	linux-pm-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA, USB list,
	Steven Rostedt

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

^ permalink raw reply	[flat|nested] 148+ messages in thread

* Re: [linux-pm] ehci_hcd related S3 lockup on ASUS laptops, again
       [not found]                                                                                                                             ` <20120419163055.GB11484-hAV9HEAGFNe6YibBOCjzsw@public.gmane.org>
@ 2012-04-19 18:07                                                                                                                               ` Alan Stern
  2012-04-19 21:48                                                                                                                                 ` Andrey Rahmatullin
  0 siblings, 1 reply; 148+ messages in thread
From: Alan Stern @ 2012-04-19 18:07 UTC (permalink / raw)
  To: Andrey Rahmatullin
  Cc: jrnieder-Re5JQEeQqe8AvxtiuMwx3w,
	linux-pm-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA, USB list,
	Steven Rostedt

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

^ permalink raw reply	[flat|nested] 148+ messages in thread

* Re: [linux-pm] ehci_hcd related S3 lockup on ASUS laptops, again
       [not found]                                                                                                                             ` <1334852575.28106.62.camel-f9ZlEuEWxVcI6MkJdU+c8EEOCMrvLtNR@public.gmane.org>
@ 2012-04-19 18:08                                                                                                                               ` Steven Rostedt
  2012-04-19 18:13                                                                                                                                 ` Alan Stern
  0 siblings, 1 reply; 148+ messages in thread
From: Steven Rostedt @ 2012-04-19 18:08 UTC (permalink / raw)
  To: Alan Stern
  Cc: Andrey Rahmatullin, jrnieder-Re5JQEeQqe8AvxtiuMwx3w,
	linux-pm-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA, USB list

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

^ permalink raw reply	[flat|nested] 148+ messages in thread

* Re: ehci_hcd related S3 lockup on ASUS laptops, again
  2012-04-19 18:08                                                                                                                               ` Steven Rostedt
@ 2012-04-19 18:13                                                                                                                                 ` Alan Stern
       [not found]                                                                                                                                   ` <Pine.LNX.4.44L0.1204191411360.1154-100000-IYeN2dnnYyZXsRXLowluHWD2FQJk+8+b@public.gmane.org>
  0 siblings, 1 reply; 148+ messages in thread
From: Alan Stern @ 2012-04-19 18:13 UTC (permalink / raw)
  To: Steven Rostedt; +Cc: jrnieder, Andrey Rahmatullin, linux-pm, USB list

On Thu, 19 Apr 2012, Steven Rostedt wrote:

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

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

Alan Stern

^ permalink raw reply	[flat|nested] 148+ messages in thread

* Re: [linux-pm] ehci_hcd related S3 lockup on ASUS laptops, again
       [not found]                                                                                                                                   ` <Pine.LNX.4.44L0.1204191411360.1154-100000-IYeN2dnnYyZXsRXLowluHWD2FQJk+8+b@public.gmane.org>
@ 2012-04-19 18:30                                                                                                                                     ` Steven Rostedt
  0 siblings, 0 replies; 148+ messages in thread
From: Steven Rostedt @ 2012-04-19 18:30 UTC (permalink / raw)
  To: Alan Stern
  Cc: Andrey Rahmatullin, jrnieder-Re5JQEeQqe8AvxtiuMwx3w,
	linux-pm-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA, USB list

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

^ permalink raw reply	[flat|nested] 148+ messages in thread

* Re: ehci_hcd related S3 lockup on ASUS laptops, again
  2012-04-19 18:07                                                                                                                               ` Alan Stern
@ 2012-04-19 21:48                                                                                                                                 ` Andrey Rahmatullin
  2012-04-21  0:42                                                                                                                                   ` Alan Stern
  0 siblings, 1 reply; 148+ messages in thread
From: Andrey Rahmatullin @ 2012-04-19 21:48 UTC (permalink / raw)
  To: Alan Stern; +Cc: jrnieder, linux-pm, USB list, Steven Rostedt


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

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

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


-- 
WBR, wRAR

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

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

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

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



^ permalink raw reply	[flat|nested] 148+ messages in thread

* Re: ehci_hcd related S3 lockup on ASUS laptops, again
  2012-04-19 21:48                                                                                                                                 ` Andrey Rahmatullin
@ 2012-04-21  0:42                                                                                                                                   ` Alan Stern
  2012-04-21  0:53                                                                                                                                     ` Steven Rostedt
  2012-04-21  8:37                                                                                                                                     ` Andrey Rahmatullin
  0 siblings, 2 replies; 148+ messages in thread
From: Alan Stern @ 2012-04-21  0:42 UTC (permalink / raw)
  To: Andrey Rahmatullin; +Cc: jrnieder, linux-pm, USB list, Steven Rostedt

On Fri, 20 Apr 2012, Andrey Rahmatullin wrote:

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

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

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

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

Alan Stern

^ permalink raw reply	[flat|nested] 148+ messages in thread

* Re: ehci_hcd related S3 lockup on ASUS laptops, again
  2012-04-21  0:42                                                                                                                                   ` Alan Stern
@ 2012-04-21  0:53                                                                                                                                     ` Steven Rostedt
       [not found]                                                                                                                                       ` <1334969624.28106.82.camel-f9ZlEuEWxVcI6MkJdU+c8EEOCMrvLtNR@public.gmane.org>
  2012-04-21  8:37                                                                                                                                     ` Andrey Rahmatullin
  1 sibling, 1 reply; 148+ messages in thread
From: Steven Rostedt @ 2012-04-21  0:53 UTC (permalink / raw)
  To: Alan Stern; +Cc: jrnieder, Andrey Rahmatullin, linux-pm, USB list

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

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

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

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

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

-- Steve

^ permalink raw reply	[flat|nested] 148+ messages in thread

* Re: ehci_hcd related S3 lockup on ASUS laptops, again
  2012-04-21  0:42                                                                                                                                   ` Alan Stern
  2012-04-21  0:53                                                                                                                                     ` Steven Rostedt
@ 2012-04-21  8:37                                                                                                                                     ` Andrey Rahmatullin
       [not found]                                                                                                                                       ` <20120421083751.GA4570-hAV9HEAGFNe6YibBOCjzsw@public.gmane.org>
  1 sibling, 1 reply; 148+ messages in thread
From: Andrey Rahmatullin @ 2012-04-21  8:37 UTC (permalink / raw)
  To: Alan Stern; +Cc: jrnieder, linux-pm, USB list, Steven Rostedt


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

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

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

-- 
WBR, wRAR

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

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



^ permalink raw reply	[flat|nested] 148+ messages in thread

* Re: [linux-pm] ehci_hcd related S3 lockup on ASUS laptops, again
       [not found]                                                                                                                                       ` <1334969624.28106.82.camel-f9ZlEuEWxVcI6MkJdU+c8EEOCMrvLtNR@public.gmane.org>
@ 2012-04-21 17:22                                                                                                                                         ` Alan Stern
  0 siblings, 0 replies; 148+ messages in thread
From: Alan Stern @ 2012-04-21 17:22 UTC (permalink / raw)
  To: Steven Rostedt
  Cc: Andrey Rahmatullin, jrnieder-Re5JQEeQqe8AvxtiuMwx3w,
	linux-pm-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA, USB list

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

^ permalink raw reply	[flat|nested] 148+ messages in thread

* Re: [linux-pm] ehci_hcd related S3 lockup on ASUS laptops, again
       [not found]                                                                                                                                       ` <20120421083751.GA4570-hAV9HEAGFNe6YibBOCjzsw@public.gmane.org>
@ 2012-04-21 17:26                                                                                                                                         ` Alan Stern
  2012-04-21 18:50                                                                                                                                         ` Steven Rostedt
  1 sibling, 0 replies; 148+ messages in thread
From: Alan Stern @ 2012-04-21 17:26 UTC (permalink / raw)
  To: Andrey Rahmatullin
  Cc: jrnieder-Re5JQEeQqe8AvxtiuMwx3w,
	linux-pm-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA, USB list,
	Steven Rostedt

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

^ permalink raw reply	[flat|nested] 148+ messages in thread

* Re: [linux-pm] ehci_hcd related S3 lockup on ASUS laptops, again
       [not found]                                                                                                                                       ` <20120421083751.GA4570-hAV9HEAGFNe6YibBOCjzsw@public.gmane.org>
  2012-04-21 17:26                                                                                                                                         ` [linux-pm] " Alan Stern
@ 2012-04-21 18:50                                                                                                                                         ` Steven Rostedt
       [not found]                                                                                                                                           ` <1335034218.28106.91.camel-f9ZlEuEWxVcI6MkJdU+c8EEOCMrvLtNR@public.gmane.org>
  1 sibling, 1 reply; 148+ messages in thread
From: Steven Rostedt @ 2012-04-21 18:50 UTC (permalink / raw)
  To: Andrey Rahmatullin
  Cc: Alan Stern, jrnieder-Re5JQEeQqe8AvxtiuMwx3w,
	linux-pm-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA, USB list

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

^ permalink raw reply	[flat|nested] 148+ messages in thread

* Re: [linux-pm] ehci_hcd related S3 lockup on ASUS laptops, again
       [not found]                                                                                                                                           ` <1335034218.28106.91.camel-f9ZlEuEWxVcI6MkJdU+c8EEOCMrvLtNR@public.gmane.org>
@ 2012-04-21 21:51                                                                                                                                             ` Andrey Rahmatullin
  0 siblings, 0 replies; 148+ messages in thread
From: Andrey Rahmatullin @ 2012-04-21 21:51 UTC (permalink / raw)
  To: Steven Rostedt
  Cc: Alan Stern, jrnieder-Re5JQEeQqe8AvxtiuMwx3w,
	linux-pm-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA, USB list

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

^ permalink raw reply	[flat|nested] 148+ messages in thread

* Re: ehci_hcd related S3 lockup on ASUS laptops, again
  2012-04-19 16:30                                                                                                                           ` Andrey Rahmatullin
       [not found]                                                                                                                             ` <20120419163055.GB11484-hAV9HEAGFNe6YibBOCjzsw@public.gmane.org>
@ 2012-05-26  2:01                                                                                                                             ` Alan Stern
  2012-05-26  4:03                                                                                                                               ` Steven Rostedt
  2012-05-26  8:51                                                                                                                               ` ehci_hcd related S3 lockup on ASUS laptops, again Andrey Rahmatullin
  1 sibling, 2 replies; 148+ messages in thread
From: Alan Stern @ 2012-05-26  2:01 UTC (permalink / raw)
  To: Steven Rostedt, Andrey Rahmatullin; +Cc: linux-pm

Steve and Andrey:

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

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

Alan Stern

^ permalink raw reply	[flat|nested] 148+ messages in thread

* Re: ehci_hcd related S3 lockup on ASUS laptops, again
  2012-05-26  2:01                                                                                                                             ` Alan Stern
@ 2012-05-26  4:03                                                                                                                               ` Steven Rostedt
  2012-05-26 20:27                                                                                                                                 ` Rafael J. Wysocki
  2012-05-26  8:51                                                                                                                               ` ehci_hcd related S3 lockup on ASUS laptops, again Andrey Rahmatullin
  1 sibling, 1 reply; 148+ messages in thread
From: Steven Rostedt @ 2012-05-26  4:03 UTC (permalink / raw)
  To: Alan Stern; +Cc: Andrey Rahmatullin, linux-pm

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

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

And no, wakeup still doesn't work.

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

-- Steve

^ permalink raw reply	[flat|nested] 148+ messages in thread

* Re: ehci_hcd related S3 lockup on ASUS laptops, again
  2012-05-26  2:01                                                                                                                             ` Alan Stern
  2012-05-26  4:03                                                                                                                               ` Steven Rostedt
@ 2012-05-26  8:51                                                                                                                               ` Andrey Rahmatullin
  2012-05-26 20:28                                                                                                                                 ` Rafael J. Wysocki
  1 sibling, 1 reply; 148+ messages in thread
From: Andrey Rahmatullin @ 2012-05-26  8:51 UTC (permalink / raw)
  To: Alan Stern; +Cc: linux-pm, Steven Rostedt


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

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

-- 
WBR, wRAR

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

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



^ permalink raw reply	[flat|nested] 148+ messages in thread

* Re: ehci_hcd related S3 lockup on ASUS laptops, again
  2012-05-26  4:03                                                                                                                               ` Steven Rostedt
@ 2012-05-26 20:27                                                                                                                                 ` Rafael J. Wysocki
  2012-05-26 21:16                                                                                                                                   ` [RFT] PCI changes related to wakeup (was: Re: ehci_hcd related S3 lockup on ASUS laptops, again) Rafael J. Wysocki
  0 siblings, 1 reply; 148+ messages in thread
From: Rafael J. Wysocki @ 2012-05-26 20:27 UTC (permalink / raw)
  To: linux-pm; +Cc: Andrey Rahmatullin, Steven Rostedt

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

Thanks!

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

Rafael

^ permalink raw reply	[flat|nested] 148+ messages in thread

* Re: ehci_hcd related S3 lockup on ASUS laptops, again
  2012-05-26  8:51                                                                                                                               ` ehci_hcd related S3 lockup on ASUS laptops, again Andrey Rahmatullin
@ 2012-05-26 20:28                                                                                                                                 ` Rafael J. Wysocki
  0 siblings, 0 replies; 148+ messages in thread
From: Rafael J. Wysocki @ 2012-05-26 20:28 UTC (permalink / raw)
  To: linux-pm; +Cc: Andrey Rahmatullin, Steven Rostedt

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

Thanks for testing!

Rafael

^ permalink raw reply	[flat|nested] 148+ messages in thread

* [RFT] PCI changes related to wakeup (was: Re: ehci_hcd related S3 lockup on ASUS laptops, again)
  2012-05-26 20:27                                                                                                                                 ` Rafael J. Wysocki
@ 2012-05-26 21:16                                                                                                                                   ` Rafael J. Wysocki
  2012-05-26 21:19                                                                                                                                     ` [RFT][PATCH 1/4] ACPI / PM: Make acpi_pm_device_sleep_state() follow the specification Rafael J. Wysocki
                                                                                                                                                       ` (4 more replies)
  0 siblings, 5 replies; 148+ messages in thread
From: Rafael J. Wysocki @ 2012-05-26 21:16 UTC (permalink / raw)
  To: Andrey Rahmatullin, Steven Rostedt; +Cc: ACPI Devel Mailing List, linux-pm

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

Andrey, Stephen,

We still have problems with this patch in https://bugzilla.kernel.org/show_bug.cgi?id=43278
so some more testing will be necessary, I'm afraid.

I will send a series of ACPI and PCI patches I have collected so far,
that I'd like you to test on top of kernel 3.4.0 with commit
151b61284776 reverted.

Please let me know if suspend/wakeup work for you with these patches applied.

Thanks,
Rafael

^ permalink raw reply	[flat|nested] 148+ messages in thread

* [RFT][PATCH 1/4] ACPI / PM: Make acpi_pm_device_sleep_state() follow the specification
  2012-05-26 21:16                                                                                                                                   ` [RFT] PCI changes related to wakeup (was: Re: ehci_hcd related S3 lockup on ASUS laptops, again) Rafael J. Wysocki
@ 2012-05-26 21:19                                                                                                                                     ` Rafael J. Wysocki
  2012-05-26 21:20                                                                                                                                     ` [RFT][PATCH 2/4] PCI / PM: Make platform choose target low-power states of more devices Rafael J. Wysocki
                                                                                                                                                       ` (3 subsequent siblings)
  4 siblings, 0 replies; 148+ messages in thread
From: Rafael J. Wysocki @ 2012-05-26 21:19 UTC (permalink / raw)
  To: Andrey Rahmatullin; +Cc: ACPI Devel Mailing List, linux-pm, Steven Rostedt

From: Rafael J. Wysocki <rjw@sisk.pl>

The comparison between the system sleep state being entered
and the lowest system sleep state the given device may wake up
from in acpi_pm_device_sleep_state() is reversed, because the
specification (ACPI 5.0) says that for wakeup to work:

"The sleeping state being entered must be less than or equal to the
 power state declared in element 1 of the _PRW object."

In other words, the state returned by _PRW is the deepest
(lowest-power) system sleep state the device is capable of waking up
the system from.

Moreover, acpi_pm_device_sleep_state() also should check if the
wakeup capability is supported through ACPI, because in principle it
may be done via native PCIe PME, for example, in which case _SxW
should not be evaluated.

Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
---
 drivers/acpi/sleep.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

Index: linux/drivers/acpi/sleep.c
===================================================================
--- linux.orig/drivers/acpi/sleep.c
+++ linux/drivers/acpi/sleep.c
@@ -732,8 +732,8 @@ int acpi_pm_device_sleep_state(struct de
 	 * can wake the system.  _S0W may be valid, too.
 	 */
 	if (acpi_target_sleep_state == ACPI_STATE_S0 ||
-	    (device_may_wakeup(dev) &&
-	     adev->wakeup.sleep_state <= acpi_target_sleep_state)) {
+	    (device_may_wakeup(dev) && adev->wakeup.flags.valid &&
+	     adev->wakeup.sleep_state >= acpi_target_sleep_state)) {
 		acpi_status status;
 
 		acpi_method[3] = 'W';

^ permalink raw reply	[flat|nested] 148+ messages in thread

* [RFT][PATCH 2/4] PCI / PM: Make platform choose target low-power states of more devices
  2012-05-26 21:16                                                                                                                                   ` [RFT] PCI changes related to wakeup (was: Re: ehci_hcd related S3 lockup on ASUS laptops, again) Rafael J. Wysocki
  2012-05-26 21:19                                                                                                                                     ` [RFT][PATCH 1/4] ACPI / PM: Make acpi_pm_device_sleep_state() follow the specification Rafael J. Wysocki
@ 2012-05-26 21:20                                                                                                                                     ` Rafael J. Wysocki
  2012-05-26 21:21                                                                                                                                     ` [RFT][PATCH 3/4] ACPI / PM: Shorten variable name in acpi_pm_device_sleep_state() Rafael J. Wysocki
                                                                                                                                                       ` (2 subsequent siblings)
  4 siblings, 0 replies; 148+ messages in thread
From: Rafael J. Wysocki @ 2012-05-26 21:20 UTC (permalink / raw)
  To: Andrey Rahmatullin
  Cc: Steven Rostedt, linux-pm, Alan Stern, ACPI Devel Mailing List

From: Rafael J. Wysocki <rjw@sisk.pl>

It turns out that there are devices whose power states cannot be set
by ACPI (the _PRn and _PSn methods are not available for them), but
it still is necessary to use ACPI for setting up those devices to
wake up the system from sleep states.  Then, according to the ACPI
specification (ACPI 5.0 and earlier), if there are _SxD and/or _SxW
methods defined for those devices, the results returned by them
should be taken into consideration.  Moreover, some hardware vendors
seem to use this requirement to work around hardware and/or firmware
bugs, so it's better to follow it (which we don't do at the moment)
to avoid some nasty suspend/resume issues that are quite difficult to
debug.

This change is based on a patch from Oleksij Rempel.

References: https://bugzilla.kernel.org/show_bug.cgi?id=42728
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
---
 drivers/pci/pci.c |   12 +++++++++---
 1 file changed, 9 insertions(+), 3 deletions(-)

Index: linux/drivers/pci/pci.c
===================================================================
--- linux.orig/drivers/pci/pci.c
+++ linux/drivers/pci/pci.c
@@ -1691,10 +1691,16 @@ pci_power_t pci_target_state(struct pci_
 {
 	pci_power_t target_state = PCI_D3hot;
 
-	if (platform_pci_power_manageable(dev)) {
+	/*
+	 * It turns out that there are devices whose power states cannot be set
+	 * by the platform, although their wakeup capabilities depend on it.
+	 * The platform should be called to choose the target low-power states
+	 * of those devices too.
+	 */
+	if (platform_pci_power_manageable(dev)
+	    || (device_may_wakeup(&dev->dev) && platform_pci_can_wakeup(dev))) {
 		/*
-		 * Call the platform to choose the target state of the device
-		 * and enable wake-up from this state if supported.
+		 * Call the platform to choose the target state of the device.
 		 */
 		pci_power_t state = platform_pci_choose_state(dev);
 


^ permalink raw reply	[flat|nested] 148+ messages in thread

* [RFT][PATCH 3/4] ACPI / PM: Shorten variable name in acpi_pm_device_sleep_state()
  2012-05-26 21:16                                                                                                                                   ` [RFT] PCI changes related to wakeup (was: Re: ehci_hcd related S3 lockup on ASUS laptops, again) Rafael J. Wysocki
  2012-05-26 21:19                                                                                                                                     ` [RFT][PATCH 1/4] ACPI / PM: Make acpi_pm_device_sleep_state() follow the specification Rafael J. Wysocki
  2012-05-26 21:20                                                                                                                                     ` [RFT][PATCH 2/4] PCI / PM: Make platform choose target low-power states of more devices Rafael J. Wysocki
@ 2012-05-26 21:21                                                                                                                                     ` Rafael J. Wysocki
  2012-05-26 21:21                                                                                                                                     ` [RFT][PATCH 4/4] ACPI / PM: Fix interactions between _SxD and _SxW Rafael J. Wysocki
  2012-05-26 21:47                                                                                                                                     ` [RFT] PCI changes related to wakeup (was: Re: ehci_hcd related S3 lockup on ASUS laptops, again) Andrey Rahmatullin
  4 siblings, 0 replies; 148+ messages in thread
From: Rafael J. Wysocki @ 2012-05-26 21:21 UTC (permalink / raw)
  To: Andrey Rahmatullin; +Cc: ACPI Devel Mailing List, linux-pm, Steven Rostedt

From: Rafael J. Wysocki <rjw@sisk.pl>

Save a couple of code lines by using a more concise name for the
variable representing the ACPI method to evaluate.

Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
---
 drivers/acpi/sleep.c |   14 ++++++--------
 1 file changed, 6 insertions(+), 8 deletions(-)

Index: linux/drivers/acpi/sleep.c
===================================================================
--- linux.orig/drivers/acpi/sleep.c
+++ linux/drivers/acpi/sleep.c
@@ -697,7 +697,7 @@ int acpi_pm_device_sleep_state(struct de
 {
 	acpi_handle handle = DEVICE_ACPI_HANDLE(dev);
 	struct acpi_device *adev;
-	char acpi_method[] = "_SxD";
+	char method[] = "_SxD";
 	unsigned long long d_min, d_max;
 
 	if (!handle || ACPI_FAILURE(acpi_bus_get_device(handle, &adev))) {
@@ -705,7 +705,7 @@ int acpi_pm_device_sleep_state(struct de
 		return -ENODEV;
 	}
 
-	acpi_method[2] = '0' + acpi_target_sleep_state;
+	method[2] = '0' + acpi_target_sleep_state;
 	/*
 	 * If the sleep state is S0, we will return D3, but if the device has
 	 * _S0W, we will use the value from _S0W
@@ -722,7 +722,7 @@ int acpi_pm_device_sleep_state(struct de
 	 * provided -- that's our fault recovery, we ignore retval.
 	 */
 	if (acpi_target_sleep_state > ACPI_STATE_S0)
-		acpi_evaluate_integer(handle, acpi_method, NULL, &d_min);
+		acpi_evaluate_integer(handle, method, NULL, &d_min);
 
 	/*
 	 * If _PRW says we can wake up the system from the target sleep state,
@@ -736,17 +736,15 @@ int acpi_pm_device_sleep_state(struct de
 	     adev->wakeup.sleep_state >= acpi_target_sleep_state)) {
 		acpi_status status;
 
-		acpi_method[3] = 'W';
-		status = acpi_evaluate_integer(handle, acpi_method, NULL,
-						&d_max);
+		method[3] = 'W';
+		status = acpi_evaluate_integer(handle, method, NULL, &d_max);
 		if (ACPI_FAILURE(status)) {
 			if (acpi_target_sleep_state != ACPI_STATE_S0 ||
 			    status != AE_NOT_FOUND)
 				d_max = d_min;
 		} else if (d_max < d_min) {
 			/* Warn the user of the broken DSDT */
-			printk(KERN_WARNING "ACPI: Wrong value from %s\n",
-				acpi_method);
+			pr_warning("ACPI: Wrong value from %s\n", method);
 			/* Sanitize it */
 			d_min = d_max;
 		}

^ permalink raw reply	[flat|nested] 148+ messages in thread

* [RFT][PATCH 4/4] ACPI / PM: Fix interactions between _SxD and _SxW
  2012-05-26 21:16                                                                                                                                   ` [RFT] PCI changes related to wakeup (was: Re: ehci_hcd related S3 lockup on ASUS laptops, again) Rafael J. Wysocki
                                                                                                                                                       ` (2 preceding siblings ...)
  2012-05-26 21:21                                                                                                                                     ` [RFT][PATCH 3/4] ACPI / PM: Shorten variable name in acpi_pm_device_sleep_state() Rafael J. Wysocki
@ 2012-05-26 21:21                                                                                                                                     ` Rafael J. Wysocki
  2012-05-26 21:47                                                                                                                                     ` [RFT] PCI changes related to wakeup (was: Re: ehci_hcd related S3 lockup on ASUS laptops, again) Andrey Rahmatullin
  4 siblings, 0 replies; 148+ messages in thread
From: Rafael J. Wysocki @ 2012-05-26 21:21 UTC (permalink / raw)
  To: Andrey Rahmatullin
  Cc: Steven Rostedt, linux-pm, Alan Stern, ACPI Devel Mailing List

From: Rafael J. Wysocki <rjw@sisk.pl>

The ACPI specification (ACPI 5.0 and earlier) tells us to use the
value returned by the _SxD method for the given device as the
lowest-power state the device can be put into before transitioning
the system into the given sleep state if (1) the device is supposed
to wake up the system and (2) the _SxW method is not present for it.
However, if both _SxD and _SxW are not present, we are free to use
D3cold as the lowest-power state to put the device into.

Unfortunately, acpi_pm_device_sleep_state() returns D0 as the
lowest-power state to put the device into if both _SxD and _SxW are
not present, which is incorrect.  Prevent this from happening by
making acpi_pm_device_sleep_state() check whether or not _SxD is
present while deciding what value to use as the lowest-power state
to put the device into.

Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
---
 drivers/acpi/sleep.c |   16 +++++++++-------
 1 file changed, 9 insertions(+), 7 deletions(-)

Index: linux/drivers/acpi/sleep.c
===================================================================
--- linux.orig/drivers/acpi/sleep.c
+++ linux/drivers/acpi/sleep.c
@@ -699,6 +699,8 @@ int acpi_pm_device_sleep_state(struct de
 	struct acpi_device *adev;
 	char method[] = "_SxD";
 	unsigned long long d_min, d_max;
+	acpi_status status;
+	bool sxd_present = false;
 
 	if (!handle || ACPI_FAILURE(acpi_bus_get_device(handle, &adev))) {
 		printk(KERN_DEBUG "ACPI handle has no context!\n");
@@ -719,10 +721,13 @@ int acpi_pm_device_sleep_state(struct de
 	 * minimum D-state is D0 (ACPI 3.x).
 	 *
 	 * NOTE: We rely on acpi_evaluate_integer() not clobbering the integer
-	 * provided -- that's our fault recovery, we ignore retval.
+	 * provided in case of an error.
 	 */
-	if (acpi_target_sleep_state > ACPI_STATE_S0)
-		acpi_evaluate_integer(handle, method, NULL, &d_min);
+	if (acpi_target_sleep_state > ACPI_STATE_S0) {
+		status = acpi_evaluate_integer(handle, method, NULL, &d_min);
+		if (status != AE_NOT_FOUND)
+			sxd_present = true;
+	}
 
 	/*
 	 * If _PRW says we can wake up the system from the target sleep state,
@@ -734,13 +739,10 @@ int acpi_pm_device_sleep_state(struct de
 	if (acpi_target_sleep_state == ACPI_STATE_S0 ||
 	    (device_may_wakeup(dev) && adev->wakeup.flags.valid &&
 	     adev->wakeup.sleep_state >= acpi_target_sleep_state)) {
-		acpi_status status;
-
 		method[3] = 'W';
 		status = acpi_evaluate_integer(handle, method, NULL, &d_max);
 		if (ACPI_FAILURE(status)) {
-			if (acpi_target_sleep_state != ACPI_STATE_S0 ||
-			    status != AE_NOT_FOUND)
+			if (sxd_present || status != AE_NOT_FOUND)
 				d_max = d_min;
 		} else if (d_max < d_min) {
 			/* Warn the user of the broken DSDT */


^ permalink raw reply	[flat|nested] 148+ messages in thread

* Re: [RFT] PCI changes related to wakeup (was: Re: ehci_hcd related S3 lockup on ASUS laptops, again)
  2012-05-26 21:16                                                                                                                                   ` [RFT] PCI changes related to wakeup (was: Re: ehci_hcd related S3 lockup on ASUS laptops, again) Rafael J. Wysocki
                                                                                                                                                       ` (3 preceding siblings ...)
  2012-05-26 21:21                                                                                                                                     ` [RFT][PATCH 4/4] ACPI / PM: Fix interactions between _SxD and _SxW Rafael J. Wysocki
@ 2012-05-26 21:47                                                                                                                                     ` Andrey Rahmatullin
  2012-05-26 22:06                                                                                                                                       ` [RFT] PCI changes related to wakeup (was: Re: [linux-pm] " Rafael J. Wysocki
  4 siblings, 1 reply; 148+ messages in thread
From: Andrey Rahmatullin @ 2012-05-26 21:47 UTC (permalink / raw)
  To: Rafael J. Wysocki; +Cc: ACPI Devel Mailing List, linux-pm, Steven Rostedt


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

On Sat, May 26, 2012 at 11:16:29PM +0200, Rafael J. Wysocki wrote:
> Andrey, Stephen,
> 
> We still have problems with this patch in https://bugzilla.kernel.org/show_bug.cgi?id=43278
> so some more testing will be necessary, I'm afraid.
> 
> I will send a series of ACPI and PCI patches I have collected so far,
> that I'd like you to test on top of kernel 3.4.0 with commit
> 151b61284776 reverted.
> 
> Please let me know if suspend/wakeup work for you with these patches applied.
I get the usual freeze on suspending with these patches.

-- 
WBR, wRAR

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

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



^ permalink raw reply	[flat|nested] 148+ messages in thread

* Re: [RFT] PCI changes related to wakeup (was: Re: [linux-pm] ehci_hcd related S3 lockup on ASUS laptops, again)
  2012-05-26 21:47                                                                                                                                     ` [RFT] PCI changes related to wakeup (was: Re: ehci_hcd related S3 lockup on ASUS laptops, again) Andrey Rahmatullin
@ 2012-05-26 22:06                                                                                                                                       ` Rafael J. Wysocki
  2012-05-26 22:36                                                                                                                                         ` [RFT] PCI changes related to wakeup (was: " Andrey Rahmatullin
  0 siblings, 1 reply; 148+ messages in thread
From: Rafael J. Wysocki @ 2012-05-26 22:06 UTC (permalink / raw)
  To: Andrey Rahmatullin
  Cc: Steven Rostedt, linux-pm, Alan Stern, ACPI Devel Mailing List

On Saturday, May 26, 2012, Andrey Rahmatullin wrote:
> On Sat, May 26, 2012 at 11:16:29PM +0200, Rafael J. Wysocki wrote:
> > Andrey, Stephen,
> > 
> > We still have problems with this patch in https://bugzilla.kernel.org/show_bug.cgi?id=43278
> > so some more testing will be necessary, I'm afraid.
> > 
> > I will send a series of ACPI and PCI patches I have collected so far,
> > that I'd like you to test on top of kernel 3.4.0 with commit
> > 151b61284776 reverted.
> > 
> > Please let me know if suspend/wakeup work for you with these patches applied.
> I get the usual freeze on suspending with these patches.

I see.

Please try to unapply [4/4] and see if that helps.  If it doesn't,
please try to enable the problematic USB controller to wake up
(e.g. by writing "enabled" to its /sys/power/.../wakeup file before the
suspend) and see if that helps.

Thanks,
Rafael

^ permalink raw reply	[flat|nested] 148+ messages in thread

* Re: [RFT] PCI changes related to wakeup (was: Re: ehci_hcd related S3 lockup on ASUS laptops, again)
  2012-05-26 22:06                                                                                                                                       ` [RFT] PCI changes related to wakeup (was: Re: [linux-pm] " Rafael J. Wysocki
@ 2012-05-26 22:36                                                                                                                                         ` Andrey Rahmatullin
  2012-05-26 22:40                                                                                                                                           ` [RFT] PCI changes related to wakeup (was: Re: [linux-pm] " Alan Stern
  2012-05-27 16:41                                                                                                                                           ` [RFT] PCI changes related to wakeup (was: Re: [linux-pm] ehci_hcd related S3 lockup on ASUS laptops, again) Alan Stern
  0 siblings, 2 replies; 148+ messages in thread
From: Andrey Rahmatullin @ 2012-05-26 22:36 UTC (permalink / raw)
  To: Rafael J. Wysocki; +Cc: ACPI Devel Mailing List, linux-pm, Steven Rostedt


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

On Sun, May 27, 2012 at 12:06:01AM +0200, Rafael J. Wysocki wrote:
> > > Andrey, Stephen,
> > > 
> > > We still have problems with this patch in https://bugzilla.kernel.org/show_bug.cgi?id=43278
> > > so some more testing will be necessary, I'm afraid.
> > > 
> > > I will send a series of ACPI and PCI patches I have collected so far,
> > > that I'd like you to test on top of kernel 3.4.0 with commit
> > > 151b61284776 reverted.
> > > 
> > > Please let me know if suspend/wakeup work for you with these patches applied.
> > I get the usual freeze on suspending with these patches.
> 
> I see.
> 
> Please try to unapply [4/4] and see if that helps.
It helps.

-- 
WBR, wRAR

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

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



^ permalink raw reply	[flat|nested] 148+ messages in thread

* Re: [RFT] PCI changes related to wakeup (was: Re: [linux-pm] ehci_hcd related S3 lockup on ASUS laptops, again)
  2012-05-26 22:36                                                                                                                                         ` [RFT] PCI changes related to wakeup (was: " Andrey Rahmatullin
@ 2012-05-26 22:40                                                                                                                                           ` Alan Stern
  2012-05-26 22:59                                                                                                                                             ` [RFT] PCI changes related to wakeup (was: " Rafael J. Wysocki
  2012-05-27 16:41                                                                                                                                           ` [RFT] PCI changes related to wakeup (was: Re: [linux-pm] ehci_hcd related S3 lockup on ASUS laptops, again) Alan Stern
  1 sibling, 1 reply; 148+ messages in thread
From: Alan Stern @ 2012-05-26 22:40 UTC (permalink / raw)
  To: Andrey Rahmatullin
  Cc: Rafael J. Wysocki, Steven Rostedt, linux-pm, ACPI Devel Mailing List

On Sun, 27 May 2012, Andrey Rahmatullin wrote:

> On Sun, May 27, 2012 at 12:06:01AM +0200, Rafael J. Wysocki wrote:
> > > > Andrey, Stephen,
> > > > 
> > > > We still have problems with this patch in https://bugzilla.kernel.org/show_bug.cgi?id=43278
> > > > so some more testing will be necessary, I'm afraid.
> > > > 
> > > > I will send a series of ACPI and PCI patches I have collected so far,
> > > > that I'd like you to test on top of kernel 3.4.0 with commit
> > > > 151b61284776 reverted.
> > > > 
> > > > Please let me know if suspend/wakeup work for you with these patches applied.
> > > I get the usual freeze on suspending with these patches.
> > 
> > I see.
> > 
> > Please try to unapply [4/4] and see if that helps.
> It helps.

Trying to follow the ACPI spec too closely may be a bad idea.  We 
should try to copy what Windows does (whatever that is!).

Alan Stern


^ permalink raw reply	[flat|nested] 148+ messages in thread

* Re: [RFT] PCI changes related to wakeup (was: Re: ehci_hcd related S3 lockup on ASUS laptops, again)
  2012-05-26 22:40                                                                                                                                           ` [RFT] PCI changes related to wakeup (was: Re: [linux-pm] " Alan Stern
@ 2012-05-26 22:59                                                                                                                                             ` Rafael J. Wysocki
  2012-05-29 14:23                                                                                                                                               ` [RFT] PCI changes related to wakeup (was: Re: [linux-pm] " Alan Stern
  0 siblings, 1 reply; 148+ messages in thread
From: Rafael J. Wysocki @ 2012-05-26 22:59 UTC (permalink / raw)
  To: Alan Stern
  Cc: Andrey Rahmatullin, linux-pm, Steven Rostedt, ACPI Devel Mailing List

On Sunday, May 27, 2012, Alan Stern wrote:
> On Sun, 27 May 2012, Andrey Rahmatullin wrote:
> 
> > On Sun, May 27, 2012 at 12:06:01AM +0200, Rafael J. Wysocki wrote:
> > > > > Andrey, Stephen,
> > > > > 
> > > > > We still have problems with this patch in https://bugzilla.kernel.org/show_bug.cgi?id=43278
> > > > > so some more testing will be necessary, I'm afraid.
> > > > > 
> > > > > I will send a series of ACPI and PCI patches I have collected so far,
> > > > > that I'd like you to test on top of kernel 3.4.0 with commit
> > > > > 151b61284776 reverted.
> > > > > 
> > > > > Please let me know if suspend/wakeup work for you with these patches applied.
> > > > I get the usual freeze on suspending with these patches.
> > > 
> > > I see.
> > > 
> > > Please try to unapply [4/4] and see if that helps.
> > It helps.
> 
> Trying to follow the ACPI spec too closely may be a bad idea.  We 
> should try to copy what Windows does (whatever that is!).

Well, that's why I made it a separate patch, among other things. :-)

So, do you think we should apply [1/4] and [2/4] and try to work around the
BIOS bug from https://bugzilla.kernel.org/show_bug.cgi?id=43278 (I suppose
we can do that by double checking if the target state returned by ACPI is
in agreement with the capabilities returned by the PCI layer)?

Rafael

^ permalink raw reply	[flat|nested] 148+ messages in thread

* Re: [RFT] PCI changes related to wakeup (was: Re: [linux-pm] ehci_hcd related S3 lockup on ASUS laptops, again)
  2012-05-26 22:36                                                                                                                                         ` [RFT] PCI changes related to wakeup (was: " Andrey Rahmatullin
  2012-05-26 22:40                                                                                                                                           ` [RFT] PCI changes related to wakeup (was: Re: [linux-pm] " Alan Stern
@ 2012-05-27 16:41                                                                                                                                           ` Alan Stern
  2012-05-27 21:17                                                                                                                                             ` Andrey Rahmatullin
  1 sibling, 1 reply; 148+ messages in thread
From: Alan Stern @ 2012-05-27 16:41 UTC (permalink / raw)
  To: Andrey Rahmatullin
  Cc: Rafael J. Wysocki, Steven Rostedt, linux-pm, ACPI Devel Mailing List

On Sun, 27 May 2012, Andrey Rahmatullin wrote:

> On Sun, May 27, 2012 at 12:06:01AM +0200, Rafael J. Wysocki wrote:
> > > > Andrey, Stephen,
> > > > 
> > > > We still have problems with this patch in https://bugzilla.kernel.org/show_bug.cgi?id=43278
> > > > so some more testing will be necessary, I'm afraid.
> > > > 
> > > > I will send a series of ACPI and PCI patches I have collected so far,
> > > > that I'd like you to test on top of kernel 3.4.0 with commit
> > > > 151b61284776 reverted.
> > > > 
> > > > Please let me know if suspend/wakeup work for you with these patches applied.
> > > I get the usual freeze on suspending with these patches.
> > 
> > I see.
> > 
> > Please try to unapply [4/4] and see if that helps.
> It helps.

Andrey, can you try out Rafael's patches 1-3 (with 151b... reverted)  
and see what happens if the EHCI controllers' power/wakeup sysfs
atributes are first set to "disabled"?

Alan Stern


^ permalink raw reply	[flat|nested] 148+ messages in thread

* Re: [RFT] PCI changes related to wakeup (was: Re: [linux-pm] ehci_hcd related S3 lockup on ASUS laptops, again)
  2012-05-27 16:41                                                                                                                                           ` [RFT] PCI changes related to wakeup (was: Re: [linux-pm] ehci_hcd related S3 lockup on ASUS laptops, again) Alan Stern
@ 2012-05-27 21:17                                                                                                                                             ` Andrey Rahmatullin
  2012-05-28 20:13                                                                                                                                               ` [RFT] PCI changes related to wakeup (was: " Rafael J. Wysocki
  0 siblings, 1 reply; 148+ messages in thread
From: Andrey Rahmatullin @ 2012-05-27 21:17 UTC (permalink / raw)
  To: Alan Stern
  Cc: Rafael J. Wysocki, Steven Rostedt, linux-pm, ACPI Devel Mailing List

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

On Sun, May 27, 2012 at 12:41:43PM -0400, Alan Stern wrote:
> > > > > Andrey, Stephen,
> > > > > 
> > > > > We still have problems with this patch in https://bugzilla.kernel.org/show_bug.cgi?id=43278
> > > > > so some more testing will be necessary, I'm afraid.
> > > > > 
> > > > > I will send a series of ACPI and PCI patches I have collected so far,
> > > > > that I'd like you to test on top of kernel 3.4.0 with commit
> > > > > 151b61284776 reverted.
> > > > > 
> > > > > Please let me know if suspend/wakeup work for you with these patches applied.
> > > > I get the usual freeze on suspending with these patches.
> > > 
> > > I see.
> > > 
> > > Please try to unapply [4/4] and see if that helps.
> > It helps.
> 
> Andrey, can you try out Rafael's patches 1-3 (with 151b... reverted)  
> and see what happens if the EHCI controllers' power/wakeup sysfs
> atributes are first set to "disabled"?
It freezes.

-- 
WBR, wRAR

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

^ permalink raw reply	[flat|nested] 148+ messages in thread

* Re: [RFT] PCI changes related to wakeup (was: Re: ehci_hcd related S3 lockup on ASUS laptops, again)
  2012-05-27 21:17                                                                                                                                             ` Andrey Rahmatullin
@ 2012-05-28 20:13                                                                                                                                               ` Rafael J. Wysocki
  2012-05-29  7:48                                                                                                                                                 ` Andrey Rahmatullin
  2012-05-29 22:39                                                                                                                                                 ` [RFT] PCI changes related to wakeup (was: " Steven Rostedt
  0 siblings, 2 replies; 148+ messages in thread
From: Rafael J. Wysocki @ 2012-05-28 20:13 UTC (permalink / raw)
  To: Andrey Rahmatullin, Steven Rostedt; +Cc: ACPI Devel Mailing List, linux-pm

On Sunday, May 27, 2012, Andrey Rahmatullin wrote:
> On Sun, May 27, 2012 at 12:41:43PM -0400, Alan Stern wrote:
> > > > > > Andrey, Stephen,
> > > > > > 
> > > > > > We still have problems with this patch in https://bugzilla.kernel.org/show_bug.cgi?id=43278
> > > > > > so some more testing will be necessary, I'm afraid.
> > > > > > 
> > > > > > I will send a series of ACPI and PCI patches I have collected so far,
> > > > > > that I'd like you to test on top of kernel 3.4.0 with commit
> > > > > > 151b61284776 reverted.
> > > > > > 
> > > > > > Please let me know if suspend/wakeup work for you with these patches applied.
> > > > > I get the usual freeze on suspending with these patches.
> > > > 
> > > > I see.
> > > > 
> > > > Please try to unapply [4/4] and see if that helps.
> > > It helps.
> > 
> > Andrey, can you try out Rafael's patches 1-3 (with 151b... reverted)  
> > and see what happens if the EHCI controllers' power/wakeup sysfs
> > atributes are first set to "disabled"?
> It freezes.

Well, that means trying to work around this through changing the algorithm
of selecting the target state of a device wasn't a good idea after all.

Still, we've found some bugs in the process, so it was worth the effort.

Please attach the output of dmidecode from your machine.
Steven, please do that too.

Thanks,
Rafael

^ permalink raw reply	[flat|nested] 148+ messages in thread

* Re: [RFT] PCI changes related to wakeup (was: Re: ehci_hcd related S3 lockup on ASUS laptops, again)
  2012-05-28 20:13                                                                                                                                               ` [RFT] PCI changes related to wakeup (was: " Rafael J. Wysocki
@ 2012-05-29  7:48                                                                                                                                                 ` Andrey Rahmatullin
  2012-05-29 17:30                                                                                                                                                   ` [RFT] PCI changes related to wakeup (was: Re: [linux-pm] " Rafael J. Wysocki
  2012-05-29 22:39                                                                                                                                                 ` [RFT] PCI changes related to wakeup (was: " Steven Rostedt
  1 sibling, 1 reply; 148+ messages in thread
From: Andrey Rahmatullin @ 2012-05-29  7:48 UTC (permalink / raw)
  To: Rafael J. Wysocki; +Cc: ACPI Devel Mailing List, linux-pm, Steven Rostedt


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

On Mon, May 28, 2012 at 10:13:01PM +0200, Rafael J. Wysocki wrote:
> > > > > > > Andrey, Stephen,
> > > > > > > 
> > > > > > > We still have problems with this patch in https://bugzilla.kernel.org/show_bug.cgi?id=43278
> > > > > > > so some more testing will be necessary, I'm afraid.
> > > > > > > 
> > > > > > > I will send a series of ACPI and PCI patches I have collected so far,
> > > > > > > that I'd like you to test on top of kernel 3.4.0 with commit
> > > > > > > 151b61284776 reverted.
> > > > > > > 
> > > > > > > Please let me know if suspend/wakeup work for you with these patches applied.
> > > > > > I get the usual freeze on suspending with these patches.
> > > > > 
> > > > > I see.
> > > > > 
> > > > > Please try to unapply [4/4] and see if that helps.
> > > > It helps.
> > > 
> > > Andrey, can you try out Rafael's patches 1-3 (with 151b... reverted)  
> > > and see what happens if the EHCI controllers' power/wakeup sysfs
> > > atributes are first set to "disabled"?
> > It freezes.
> 
> Well, that means trying to work around this through changing the algorithm
> of selecting the target state of a device wasn't a good idea after all.
> 
> Still, we've found some bugs in the process, so it was worth the effort.
> 
> Please attach the output of dmidecode from your machine.
Attached.


-- 
WBR, wRAR

[-- Attachment #1.1.2: dmidecode-K53E.txt.gz --]
[-- Type: application/octet-stream, Size: 3902 bytes --]

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

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



^ permalink raw reply	[flat|nested] 148+ messages in thread

* Re: [RFT] PCI changes related to wakeup (was: Re: [linux-pm] ehci_hcd related S3 lockup on ASUS laptops, again)
  2012-05-26 22:59                                                                                                                                             ` [RFT] PCI changes related to wakeup (was: " Rafael J. Wysocki
@ 2012-05-29 14:23                                                                                                                                               ` Alan Stern
  2012-05-29 17:29                                                                                                                                                 ` Rafael J. Wysocki
  0 siblings, 1 reply; 148+ messages in thread
From: Alan Stern @ 2012-05-29 14:23 UTC (permalink / raw)
  To: Rafael J. Wysocki
  Cc: Oleksij Rempel (fishor),
	Dâniel Fraga, Andrey Rahmatullin, Steven Rostedt, linux-pm,
	ACPI Devel Mailing List

On Sun, 27 May 2012, Rafael J. Wysocki wrote:

> So, do you think we should apply [1/4] and [2/4] and try to work around the
> BIOS bug from https://bugzilla.kernel.org/show_bug.cgi?id=43278 (I suppose
> we can do that by double checking if the target state returned by ACPI is
> in agreement with the capabilities returned by the PCI layer)?

Here's one possible approach.  It only solves part of the problem, but
it ought to help with Bugzilla 43278 (Dâniel's case).  I suggest that
we don't believe the output from _SxW if the PCI PM capability
indicates that PME is supported in a higher-numbered D state than _SxW
says.

On Dâniel's smachine, _SxW returns D2 but the controller supports PME 
in D3; therefore we would use D3.

This still leaves the original problem.  It seems clear that ACPI
won't be sufficient to solve this -- at least, it won't help in the
case where the controller isn't enabled for wakeup.

Therefore we really do need a quirk, probably in ehci-hcd like the 
original patch.  If it is restricted to apply only in cases where the 
DMI information lists ASUSTeK as the manufacturer, perhaps that will be 
sufficient.  (For some reason, the manufacturer field in Dâniel's BIOS 
isn't initialized.)

Alan Stern

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

^ permalink raw reply	[flat|nested] 148+ messages in thread

* Re: [RFT] PCI changes related to wakeup (was: Re: [linux-pm] ehci_hcd related S3 lockup on ASUS laptops, again)
  2012-05-29 14:23                                                                                                                                               ` [RFT] PCI changes related to wakeup (was: Re: [linux-pm] " Alan Stern
@ 2012-05-29 17:29                                                                                                                                                 ` Rafael J. Wysocki
  2012-05-29 18:50                                                                                                                                                   ` Alan Stern
  0 siblings, 1 reply; 148+ messages in thread
From: Rafael J. Wysocki @ 2012-05-29 17:29 UTC (permalink / raw)
  To: Alan Stern
  Cc: Oleksij Rempel (fishor),
	Dâniel Fraga, Andrey Rahmatullin, Steven Rostedt, linux-pm,
	ACPI Devel Mailing List

On Tuesday, May 29, 2012, Alan Stern wrote:
> On Sun, 27 May 2012, Rafael J. Wysocki wrote:
> 
> > So, do you think we should apply [1/4] and [2/4] and try to work around the
> > BIOS bug from https://bugzilla.kernel.org/show_bug.cgi?id=43278 (I suppose
> > we can do that by double checking if the target state returned by ACPI is
> > in agreement with the capabilities returned by the PCI layer)?
> 
> Here's one possible approach.  It only solves part of the problem, but
> it ought to help with Bugzilla 43278 (Dâniel's case).  I suggest that
> we don't believe the output from _SxW if the PCI PM capability
> indicates that PME is supported in a higher-numbered D state than _SxW
> says.
> 
> On Dâniel's smachine, _SxW returns D2

No, it doesn't.  In fact, _SxW is not present for that device in his DSDT.

> but the controller supports PME in D3; therefore we would use D3.

Yes, we can do that.  This goes along the lines of what I said in the bug
entry.

> This still leaves the original problem.  It seems clear that ACPI
> won't be sufficient to solve this -- at least, it won't help in the
> case where the controller isn't enabled for wakeup.
> 
> Therefore we really do need a quirk, probably in ehci-hcd like the 
> original patch.  If it is restricted to apply only in cases where the 
> DMI information lists ASUSTeK as the manufacturer, perhaps that will be 
> sufficient.  (For some reason, the manufacturer field in Dâniel's BIOS 
> isn't initialized.)

Yeah.

I'll have a deeper look at this later today, I think.

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

^ permalink raw reply	[flat|nested] 148+ messages in thread

* Re: [RFT] PCI changes related to wakeup (was: Re: [linux-pm] ehci_hcd related S3 lockup on ASUS laptops, again)
  2012-05-29  7:48                                                                                                                                                 ` Andrey Rahmatullin
@ 2012-05-29 17:30                                                                                                                                                   ` Rafael J. Wysocki
  0 siblings, 0 replies; 148+ messages in thread
From: Rafael J. Wysocki @ 2012-05-29 17:30 UTC (permalink / raw)
  To: Andrey Rahmatullin
  Cc: Steven Rostedt, Alan Stern, linux-pm, ACPI Devel Mailing List

On Tuesday, May 29, 2012, Andrey Rahmatullin wrote:
> On Mon, May 28, 2012 at 10:13:01PM +0200, Rafael J. Wysocki wrote:
> > > > > > > > Andrey, Stephen,
> > > > > > > > 
> > > > > > > > We still have problems with this patch in https://bugzilla.kernel.org/show_bug.cgi?id=43278
> > > > > > > > so some more testing will be necessary, I'm afraid.
> > > > > > > > 
> > > > > > > > I will send a series of ACPI and PCI patches I have collected so far,
> > > > > > > > that I'd like you to test on top of kernel 3.4.0 with commit
> > > > > > > > 151b61284776 reverted.
> > > > > > > > 
> > > > > > > > Please let me know if suspend/wakeup work for you with these patches applied.
> > > > > > > I get the usual freeze on suspending with these patches.
> > > > > > 
> > > > > > I see.
> > > > > > 
> > > > > > Please try to unapply [4/4] and see if that helps.
> > > > > It helps.
> > > > 
> > > > Andrey, can you try out Rafael's patches 1-3 (with 151b... reverted)  
> > > > and see what happens if the EHCI controllers' power/wakeup sysfs
> > > > atributes are first set to "disabled"?
> > > It freezes.
> > 
> > Well, that means trying to work around this through changing the algorithm
> > of selecting the target state of a device wasn't a good idea after all.
> > 
> > Still, we've found some bugs in the process, so it was worth the effort.
> > 
> > Please attach the output of dmidecode from your machine.
> Attached.

Cool, thanks!

^ permalink raw reply	[flat|nested] 148+ messages in thread

* Re: [RFT] PCI changes related to wakeup (was: Re: [linux-pm] ehci_hcd related S3 lockup on ASUS laptops, again)
  2012-05-29 17:29                                                                                                                                                 ` Rafael J. Wysocki
@ 2012-05-29 18:50                                                                                                                                                   ` Alan Stern
  2012-05-29 19:16                                                                                                                                                     ` Rafael J. Wysocki
  0 siblings, 1 reply; 148+ messages in thread
From: Alan Stern @ 2012-05-29 18:50 UTC (permalink / raw)
  To: Rafael J. Wysocki
  Cc: Oleksij Rempel (fishor),
	Dâniel Fraga, Andrey Rahmatullin, Steven Rostedt, linux-pm,
	ACPI Devel Mailing List

On Tue, 29 May 2012, Rafael J. Wysocki wrote:

> On Tuesday, May 29, 2012, Alan Stern wrote:
> > On Sun, 27 May 2012, Rafael J. Wysocki wrote:
> > 
> > > So, do you think we should apply [1/4] and [2/4] and try to work around the
> > > BIOS bug from https://bugzilla.kernel.org/show_bug.cgi?id=43278 (I suppose
> > > we can do that by double checking if the target state returned by ACPI is
> > > in agreement with the capabilities returned by the PCI layer)?
> > 
> > Here's one possible approach.  It only solves part of the problem, but
> > it ought to help with Bugzilla 43278 (Dâniel's case).  I suggest that
> > we don't believe the output from _SxW if the PCI PM capability
> > indicates that PME is supported in a higher-numbered D state than _SxW
> > says.
> > 
> > On Dâniel's smachine, _SxW returns D2
> 
> No, it doesn't.  In fact, _SxW is not present for that device in his DSDT.

Oh -- I guess I got the machines mixed up.  Since _SxW isn't present
and _SxD is, we accept the value of _SxD as the only state in which
wakeup is supported.

ACPI apparently doesn't have any way to express: "The device is allowed 
to be in either D2 or D3 during S3 sleep, but it supports wakeup only 
in D3."  And trying to express the inexpressible, the BIOS ended up 
being buggy.

ACPI also apparently doesn't have any way to express: "The device is 
allowed be in D2 but not D3 during S3 sleep, even if wakeup is not 
enabled."

> > but the controller supports PME in D3; therefore we would use D3.
> 
> Yes, we can do that.  This goes along the lines of what I said in the bug
> entry.
> 
> > This still leaves the original problem.  It seems clear that ACPI
> > won't be sufficient to solve this -- at least, it won't help in the
> > case where the controller isn't enabled for wakeup.
> > 
> > Therefore we really do need a quirk, probably in ehci-hcd like the 
> > original patch.  If it is restricted to apply only in cases where the 
> > DMI information lists ASUSTeK as the manufacturer, perhaps that will be 
> > sufficient.  (For some reason, the manufacturer field in Dâniel's BIOS 
> > isn't initialized.)
> 
> Yeah.
> 
> I'll have a deeper look at this later today, I think.

It's easy enough to write such a check (or perhaps more reliably, check
for a product name matching "P8Z68-V").  More difficult is knowing
whether it's the right thing to do.  We don't know the extent of the
underlying problem.

Alan Stern

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

^ permalink raw reply	[flat|nested] 148+ messages in thread

* Re: [RFT] PCI changes related to wakeup (was: Re: [linux-pm] ehci_hcd related S3 lockup on ASUS laptops, again)
  2012-05-29 18:50                                                                                                                                                   ` Alan Stern
@ 2012-05-29 19:16                                                                                                                                                     ` Rafael J. Wysocki
  2012-05-31 21:07                                                                                                                                                       ` Alan Stern
  0 siblings, 1 reply; 148+ messages in thread
From: Rafael J. Wysocki @ 2012-05-29 19:16 UTC (permalink / raw)
  To: Alan Stern
  Cc: Oleksij Rempel (fishor),
	Dâniel Fraga, Andrey Rahmatullin, Steven Rostedt, linux-pm,
	ACPI Devel Mailing List

On Tuesday, May 29, 2012, Alan Stern wrote:
> On Tue, 29 May 2012, Rafael J. Wysocki wrote:
> 
> > On Tuesday, May 29, 2012, Alan Stern wrote:
> > > On Sun, 27 May 2012, Rafael J. Wysocki wrote:
> > > 
> > > > So, do you think we should apply [1/4] and [2/4] and try to work around the
> > > > BIOS bug from https://bugzilla.kernel.org/show_bug.cgi?id=43278 (I suppose
> > > > we can do that by double checking if the target state returned by ACPI is
> > > > in agreement with the capabilities returned by the PCI layer)?
> > > 
> > > Here's one possible approach.  It only solves part of the problem, but
> > > it ought to help with Bugzilla 43278 (Dâniel's case).  I suggest that
> > > we don't believe the output from _SxW if the PCI PM capability
> > > indicates that PME is supported in a higher-numbered D state than _SxW
> > > says.
> > > 
> > > On Dâniel's smachine, _SxW returns D2
> > 
> > No, it doesn't.  In fact, _SxW is not present for that device in his DSDT.
> 
> Oh -- I guess I got the machines mixed up.  Since _SxW isn't present
> and _SxD is, we accept the value of _SxD as the only state in which
> wakeup is supported.

Precisely.

> ACPI apparently doesn't have any way to express: "The device is allowed 
> to be in either D2 or D3 during S3 sleep, but it supports wakeup only 
> in D3."  And trying to express the inexpressible, the BIOS ended up 
> being buggy.

Yeah.

> ACPI also apparently doesn't have any way to express: "The device is 
> allowed be in D2 but not D3 during S3 sleep, even if wakeup is not 
> enabled."

That's my understanding too.

> > > but the controller supports PME in D3; therefore we would use D3.
> > 
> > Yes, we can do that.  This goes along the lines of what I said in the bug
> > entry.
> > 
> > > This still leaves the original problem.  It seems clear that ACPI
> > > won't be sufficient to solve this -- at least, it won't help in the
> > > case where the controller isn't enabled for wakeup.
> > > 
> > > Therefore we really do need a quirk, probably in ehci-hcd like the 
> > > original patch.  If it is restricted to apply only in cases where the 
> > > DMI information lists ASUSTeK as the manufacturer, perhaps that will be 
> > > sufficient.  (For some reason, the manufacturer field in Dâniel's BIOS 
> > > isn't initialized.)
> > 
> > Yeah.
> > 
> > I'll have a deeper look at this later today, I think.
> 
> It's easy enough to write such a check (or perhaps more reliably, check
> for a product name matching "P8Z68-V").

I think we should try to express it as a PCI quirk in quirks.c, though.

> More difficult is knowing whether it's the right thing to do.  We don't
> know the extent of the underlying problem.

Well, we can only learn that by experience, so we should address the know
cases and then try to find patterns, if they exist.

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

^ permalink raw reply	[flat|nested] 148+ messages in thread

* Re: [RFT] PCI changes related to wakeup (was: Re: ehci_hcd related S3 lockup on ASUS laptops, again)
  2012-05-28 20:13                                                                                                                                               ` [RFT] PCI changes related to wakeup (was: " Rafael J. Wysocki
  2012-05-29  7:48                                                                                                                                                 ` Andrey Rahmatullin
@ 2012-05-29 22:39                                                                                                                                                 ` Steven Rostedt
  1 sibling, 0 replies; 148+ messages in thread
From: Steven Rostedt @ 2012-05-29 22:39 UTC (permalink / raw)
  To: Rafael J. Wysocki; +Cc: Andrey Rahmatullin, linux-pm, ACPI Devel Mailing List

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

On Mon, 2012-05-28 at 22:13 +0200, Rafael J. Wysocki wrote:

> Please attach the output of dmidecode from your machine.
> Steven, please do that too.

Attached.

-- Steve


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

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



^ permalink raw reply	[flat|nested] 148+ messages in thread

* Re: [RFT] PCI changes related to wakeup (was: Re: [linux-pm] ehci_hcd related S3 lockup on ASUS laptops, again)
  2012-05-29 19:16                                                                                                                                                     ` Rafael J. Wysocki
@ 2012-05-31 21:07                                                                                                                                                       ` Alan Stern
  2012-05-31 21:29                                                                                                                                                         ` Rafael J. Wysocki
                                                                                                                                                                           ` (3 more replies)
  0 siblings, 4 replies; 148+ messages in thread
From: Alan Stern @ 2012-05-31 21:07 UTC (permalink / raw)
  To: Rafael J. Wysocki
  Cc: Oleksij Rempel (fishor),
	Dâniel Fraga, Andrey Rahmatullin, Steven Rostedt, linux-pm,
	ACPI Devel Mailing List

On Tue, 29 May 2012, Rafael J. Wysocki wrote:

> > > > Therefore we really do need a quirk, probably in ehci-hcd like the 
> > > > original patch.  If it is restricted to apply only in cases where the 
> > > > DMI information lists ASUSTeK as the manufacturer, perhaps that will be 
> > > > sufficient.  (For some reason, the manufacturer field in Dâniel's BIOS 
> > > > isn't initialized.)
> > > 
> > > Yeah.
> > > 
> > > I'll have a deeper look at this later today, I think.
> > 
> > It's easy enough to write such a check (or perhaps more reliably, check
> > for a product name matching "P8Z68-V").
> 
> I think we should try to express it as a PCI quirk in quirks.c, though.

Here's my attempt.  Everybody, please try this patch with the
151b61284776 commit removed.  Make sure that CONFIG_USB_DEBUG is
enabled so we can check the controller's power state during suspend, 
and check that the "broken D3 during system sleep on ASUS" message 
shows up during booting.

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
@@ -1743,6 +1743,11 @@ int pci_prepare_to_sleep(struct pci_dev
 	if (target_state == PCI_POWER_ERROR)
 		return -EIO;
 
+	/* Some devices mustn't be in D3 during system sleep */
+	if (target_state == PCI_D3hot &&
+			(dev->dev_flags & PCI_DEV_FLAGS_NO_D3_DURING_SLEEP))
+		return 0;
+
 	pci_enable_wake(dev, target_state, device_may_wakeup(&dev->dev));
 
 	error = pci_set_power_state(dev, target_state);
Index: usb-3.4/drivers/pci/quirks.c
===================================================================
--- usb-3.4.orig/drivers/pci/quirks.c
+++ usb-3.4/drivers/pci/quirks.c
@@ -2917,6 +2917,32 @@ static void __devinit disable_igfx_irq(s
 DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL, 0x0102, disable_igfx_irq);
 DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL, 0x010a, disable_igfx_irq);
 
+/*
+ * The Intel 6 Series/C200 Series chipset's EHCI controllers on many
+ * ASUS motherboards will cause memory corruption or a system crash
+ * if they are in D3 while the system is put into S3 sleep.
+ */
+static void __devinit asus_ehci_no_d3(struct pci_dev *dev)
+{
+	const char *sys_info;
+	static const char good_Asus_board[] = "P8Z68-V";
+
+	if (dev->dev_flags & PCI_DEV_FLAGS_NO_D3_DURING_SLEEP)
+		return;
+	if (dev->subsystem_vendor != PCI_VENDOR_ID_ASUSTEK)
+		return;
+	sys_info = dmi_get_system_info(DMI_BOARD_NAME);
+	if (sys_info && memcmp(sys_info, good_Asus_board,
+			sizeof(good_Asus_board) - 1) == 0)
+		return;
+
+	dev_info(&dev->dev, "broken D3 during system sleep on ASUS\n");
+	dev->dev_flags |= PCI_DEV_FLAGS_NO_D3_DURING_SLEEP;
+	device_set_wakeup_capable(&dev->dev, false);
+}
+DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL, 0x1c26, asus_ehci_no_d3);
+DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL, 0x1c2d, asus_ehci_no_d3);
+
 static void pci_do_fixups(struct pci_dev *dev, struct pci_fixup *f,
 			  struct pci_fixup *end)
 {
Index: usb-3.4/include/linux/pci.h
===================================================================
--- usb-3.4.orig/include/linux/pci.h
+++ usb-3.4/include/linux/pci.h
@@ -176,6 +176,8 @@ enum pci_dev_flags {
 	PCI_DEV_FLAGS_NO_D3 = (__force pci_dev_flags_t) 2,
 	/* Provide indication device is assigned by a Virtual Machine Manager */
 	PCI_DEV_FLAGS_ASSIGNED = (__force pci_dev_flags_t) 4,
+	/* Device causes system crash if in D3 during S3 sleep */
+	PCI_DEV_FLAGS_NO_D3_DURING_SLEEP = (__force pci_dev_flags_t) 8,
 };
 
 enum pci_irq_reroute_variant {

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

^ permalink raw reply	[flat|nested] 148+ messages in thread

* Re: [RFT] PCI changes related to wakeup (was: Re: [linux-pm] ehci_hcd related S3 lockup on ASUS laptops, again)
  2012-05-31 21:07                                                                                                                                                       ` Alan Stern
@ 2012-05-31 21:29                                                                                                                                                         ` Rafael J. Wysocki
  2012-06-01 15:13                                                                                                                                                           ` Alan Stern
  2012-05-31 22:02                                                                                                                                                         ` [RFT] PCI changes related to wakeup (was: Re: [linux-pm] " Dâniel Fraga
                                                                                                                                                                           ` (2 subsequent siblings)
  3 siblings, 1 reply; 148+ messages in thread
From: Rafael J. Wysocki @ 2012-05-31 21:29 UTC (permalink / raw)
  To: Alan Stern
  Cc: Oleksij Rempel (fishor),
	Dâniel Fraga, Andrey Rahmatullin, Steven Rostedt, linux-pm,
	ACPI Devel Mailing List

On Thursday, May 31, 2012, Alan Stern wrote:
> On Tue, 29 May 2012, Rafael J. Wysocki wrote:
> 
> > > > > Therefore we really do need a quirk, probably in ehci-hcd like the 
> > > > > original patch.  If it is restricted to apply only in cases where the 
> > > > > DMI information lists ASUSTeK as the manufacturer, perhaps that will be 
> > > > > sufficient.  (For some reason, the manufacturer field in Dâniel's BIOS 
> > > > > isn't initialized.)
> > > > 
> > > > Yeah.
> > > > 
> > > > I'll have a deeper look at this later today, I think.
> > > 
> > > It's easy enough to write such a check (or perhaps more reliably, check
> > > for a product name matching "P8Z68-V").
> > 
> > I think we should try to express it as a PCI quirk in quirks.c, though.
> 
> Here's my attempt.  Everybody, please try this patch with the
> 151b61284776 commit removed.  Make sure that CONFIG_USB_DEBUG is
> enabled so we can check the controller's power state during suspend, 
> and check that the "broken D3 during system sleep on ASUS" message 
> shows up during booting.
> 
> 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
> @@ -1743,6 +1743,11 @@ int pci_prepare_to_sleep(struct pci_dev
>  	if (target_state == PCI_POWER_ERROR)
>  		return -EIO;
>  
> +	/* Some devices mustn't be in D3 during system sleep */
> +	if (target_state == PCI_D3hot &&
> +			(dev->dev_flags & PCI_DEV_FLAGS_NO_D3_DURING_SLEEP))
> +		return 0;
> +

Why do you want to skip the wakeup setting in that case?

>  	pci_enable_wake(dev, target_state, device_may_wakeup(&dev->dev));
>  
>  	error = pci_set_power_state(dev, target_state);
> Index: usb-3.4/drivers/pci/quirks.c
> ===================================================================
> --- usb-3.4.orig/drivers/pci/quirks.c
> +++ usb-3.4/drivers/pci/quirks.c
> @@ -2917,6 +2917,32 @@ static void __devinit disable_igfx_irq(s
>  DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL, 0x0102, disable_igfx_irq);
>  DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL, 0x010a, disable_igfx_irq);
>  
> +/*
> + * The Intel 6 Series/C200 Series chipset's EHCI controllers on many
> + * ASUS motherboards will cause memory corruption or a system crash
> + * if they are in D3 while the system is put into S3 sleep.
> + */
> +static void __devinit asus_ehci_no_d3(struct pci_dev *dev)
> +{
> +	const char *sys_info;
> +	static const char good_Asus_board[] = "P8Z68-V";
> +
> +	if (dev->dev_flags & PCI_DEV_FLAGS_NO_D3_DURING_SLEEP)
> +		return;
> +	if (dev->subsystem_vendor != PCI_VENDOR_ID_ASUSTEK)
> +		return;
> +	sys_info = dmi_get_system_info(DMI_BOARD_NAME);
> +	if (sys_info && memcmp(sys_info, good_Asus_board,
> +			sizeof(good_Asus_board) - 1) == 0)
> +		return;
> +
> +	dev_info(&dev->dev, "broken D3 during system sleep on ASUS\n");
> +	dev->dev_flags |= PCI_DEV_FLAGS_NO_D3_DURING_SLEEP;
> +	device_set_wakeup_capable(&dev->dev, false);
> +}
> +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL, 0x1c26, asus_ehci_no_d3);
> +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL, 0x1c2d, asus_ehci_no_d3);
> +
>  static void pci_do_fixups(struct pci_dev *dev, struct pci_fixup *f,
>  			  struct pci_fixup *end)
>  {
> Index: usb-3.4/include/linux/pci.h
> ===================================================================
> --- usb-3.4.orig/include/linux/pci.h
> +++ usb-3.4/include/linux/pci.h
> @@ -176,6 +176,8 @@ enum pci_dev_flags {
>  	PCI_DEV_FLAGS_NO_D3 = (__force pci_dev_flags_t) 2,
>  	/* Provide indication device is assigned by a Virtual Machine Manager */
>  	PCI_DEV_FLAGS_ASSIGNED = (__force pci_dev_flags_t) 4,
> +	/* Device causes system crash if in D3 during S3 sleep */
> +	PCI_DEV_FLAGS_NO_D3_DURING_SLEEP = (__force pci_dev_flags_t) 8,
>  };
>  
>  enum pci_irq_reroute_variant {

The quirks part looks good to me.

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

^ permalink raw reply	[flat|nested] 148+ messages in thread

* Re: [RFT] PCI changes related to wakeup (was: Re: [linux-pm] ehci_hcd related S3 lockup on ASUS laptops, again)
  2012-05-31 21:07                                                                                                                                                       ` Alan Stern
  2012-05-31 21:29                                                                                                                                                         ` Rafael J. Wysocki
@ 2012-05-31 22:02                                                                                                                                                         ` Dâniel Fraga
  2012-06-01 14:55                                                                                                                                                           ` Alan Stern
  2012-05-31 22:25                                                                                                                                                         ` Andrey Rahmatullin
  2012-06-13  9:22                                                                                                                                                         ` Rafael J. Wysocki
  3 siblings, 1 reply; 148+ messages in thread
From: Dâniel Fraga @ 2012-05-31 22:02 UTC (permalink / raw)
  To: Alan Stern
  Cc: Rafael J. Wysocki, Oleksij Rempel (fishor),
	Andrey Rahmatullin, Steven Rostedt, linux-pm,
	ACPI Devel Mailing List

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

On Thu, 31 May 2012 17:07:36 -0400 (EDT)
Alan Stern <stern@rowland.harvard.edu> wrote:

> Here's my attempt.  Everybody, please try this patch with the
> 151b61284776 commit removed.  Make sure that CONFIG_USB_DEBUG is
> enabled so we can check the controller's power state during suspend, 
> and check that the "broken D3 during system sleep on ASUS" message 
> shows up during booting.

	Hi Alan, I tested your patch. It wakes up fine through
keyboard, but it didn't write the "broken D3 during..." message. I
attached the dmesg output.

-- 
Linux 3.4.0: Saber-toothed Squirrel
http://www.youtube.com/DanielFragaBR

[-- Attachment #2: dmesg-alan.txt --]
[-- Type: application/octet-stream, Size: 9987 bytes --]

usb 2-1.6: unlink qh8-0601/ffff8802148f9700 start 0 [1/2 us]
ehci_hcd 0000:00:1d.0: reused qh ffff880212aefd00 schedule
usb 2-1.3: link qh8-0601/ffff880212aefd00 start 7 [1/2 us]
usb 2-1.3: unlink qh8-0601/ffff880212aefd00 start 7 [1/2 us]
PM: Syncing filesystems ... done.
Freezing user space processes ... (elapsed 0.13 seconds) done.
Freezing remaining freezable tasks ... (elapsed 0.93 seconds) done.
Suspending console(s) (use no_console_suspend to debug)
usb 2-1.5: unlink qh32-0601/ffff880213868980 start 6 [1/2 us]
usb 2-1.5: unlink qh8-0601/ffff880215cda180 start 5 [1/2 us]
usb 2-1.2.1.1: usb suspend, wakeup 0
usb 2-1.3: usb suspend, wakeup 0
usb 2-1.6: usb suspend, wakeup 0
usb 2-1.1: usb suspend, wakeup 0
usb 2-1.5: usb suspend, wakeup 1
usb usb1: usb auto-resume
ehci_hcd 0000:00:1a.0: resume root hub
sd 4:0:0:0: [sda] Synchronizing SCSI cache
sd 4:0:0:0: [sda] Stopping disk
ACPI handle has no context!
hub 2-1.2.1:1.0: hub_suspend
usb 2-1.2.1: unlink qh256-0001/ffff880213868b00 start 3 [1/0 us]
usb 2-1.2.1: usb suspend, wakeup 0
hub 1-0:1.0: hub_resume
hub 1-0:1.0: port 1: status 0507 change 0000
usb 1-1: usb auto-resume
hub 2-1.2:1.0: hub_suspend
usb 2-1.2: unlink qh256-0001/ffff8802161b0e80 start 2 [1/0 us]
usb 2-1.2: usb suspend, wakeup 0
hub 2-1:1.0: hub_suspend
usb 2-1: unlink qh256-0001/ffff880216089900 start 1 [1/0 us]
usb 2-1: usb suspend, wakeup 0
hub 2-0:1.0: hub_suspend
usb usb2: bus suspend, wakeup 0
ehci_hcd 0000:00:1d.0: suspend root hub
ehci_hcd 0000:00:1a.0: GetStatus port:1 status 001005 0  ACK POWER sig=se0 PE CONNECT
usb 1-1: finish resume
hub 1-1:1.0: hub_resume
ehci_hcd 0000:00:1a.0: reused qh ffff88021509ca00 schedule
usb 1-1: link qh256-0001/ffff88021509ca00 start 1 [1/0 us]
hub 1-1:1.0: hub_suspend
usb 1-1: unlink qh256-0001/ffff88021509ca00 start 1 [1/0 us]
usb 1-1: usb suspend, wakeup 0
hub 1-0:1.0: hub_suspend
usb usb1: bus suspend, wakeup 0
ehci_hcd 0000:00:1a.0: suspend root hub
e1000e 0000:00:19.0: wake-up capability enabled by ACPI
PM: suspend of devices complete after 215.730 msecs
PM: late suspend of devices complete after 0.058 msecs
ehci_hcd 0000:00:1d.0: wakeup: 1
ehci_hcd 0000:00:1d.0: wake-up capability enabled by ACPI
ehci_hcd 0000:00:1d.0: --> PCI D3hot
ehci_hcd 0000:00:1a.0: wakeup: 1
ehci_hcd 0000:00:1a.0: wake-up capability enabled by ACPI
ehci_hcd 0000:00:1a.0: --> PCI D3hot
PM: noirq suspend of devices complete after 21.999 msecs
ACPI: Preparing to enter system sleep state S3
PM: Saving platform NVS memory
Disabling non-boot CPUs ...
CPU 1 is now offline
CPU 2 is now offline
CPU 3 is now offline
CPU 4 is now offline
CPU 5 is now offline
CPU 6 is now offline
CPU 7 is now offline
Extended CMOS year: 2000
ACPI: Low-level resume complete
PM: Restoring platform NVS memory
Extended CMOS year: 2000
Enabling non-boot CPUs ...
Booting Node 0 Processor 1 APIC 0x2
CPU1 is up
Booting Node 0 Processor 2 APIC 0x4
CPU2 is up
Booting Node 0 Processor 3 APIC 0x6
CPU3 is up
Booting Node 0 Processor 4 APIC 0x1
CPU4 is up
Booting Node 0 Processor 5 APIC 0x3
CPU5 is up
Booting Node 0 Processor 6 APIC 0x5
CPU6 is up
Booting Node 0 Processor 7 APIC 0x7
CPU7 is up
ACPI: Waking up from system sleep state S3
ehci_hcd 0000:00:1a.0: wake-up capability disabled by ACPI
ehci_hcd 0000:00:1d.0: wake-up capability disabled by ACPI
PM: noirq resume of devices complete after 0.553 msecs
PM: early resume of devices complete after 0.024 msecs
i915 0000:00:02.0: setting latency timer to 64
e1000e 0000:00:19.0: wake-up capability disabled by ACPI
ehci_hcd 0000:00:1a.0: setting latency timer to 64
ehci_hcd 0000:00:1d.0: setting latency timer to 64
ahci 0000:00:1f.2: setting latency timer to 64
pci 0000:03:00.0: setting latency timer to 64
snd_hda_intel 0000:00:1b.0: irq 42 for MSI/MSI-X
e1000e 0000:00:19.0: irq 43 for MSI/MSI-X
usb usb1: usb resume
ehci_hcd 0000:00:1a.0: resume root hub
usb usb2: usb resume
ehci_hcd 0000:00:1d.0: resume root hub
ehci_hcd 0000:00:1d.0: port 1 remote wakeup
hub 2-0:1.0: hub_resume
hub 1-0:1.0: hub_resume
hub 2-0:1.0: port 1: status 0507 change 0000
hub 1-0:1.0: port 1: status 0507 change 0000
usb 2-1: usb resume
usb 1-1: usb resume
[drm] Enabling RC6 states: RC6 on, RC6p off, RC6pp off
ehci_hcd 0000:00:1d.0: GetStatus port:1 status 001005 0  ACK POWER sig=se0 PE CONNECT
ehci_hcd 0000:00:1a.0: GetStatus port:1 status 001005 0  ACK POWER sig=se0 PE CONNECT
usb 1-1: finish resume
usb 2-1: finish resume
hub 2-1:1.0: hub_resume
hub 1-1:1.0: hub_resume
hub 2-1:1.0: port 1: status 0507 change 0000
hub 2-1:1.0: port 2: status 0507 change 0000
hub 2-1:1.0: port 3: status 0307 change 0000
hub 2-1:1.0: port 5: status 0303 change 0004
hub 2-1:1.0: port 6: status 0307 change 0000
ehci_hcd 0000:00:1a.0: reused qh ffff88021509ca00 schedule
usb 1-1: link qh256-0001/ffff88021509ca00 start 1 [1/0 us]
ehci_hcd 0000:00:1d.0: reused qh ffff880216089900 schedule
usb 2-1: link qh256-0001/ffff880216089900 start 1 [1/0 us]
usb 2-1.5: finish resume
usb 2-1.3: usb resume
usb 2-1.6: usb resume
usb 2-1.2: usb resume
usb 2-1.1: usb resume
ehci_hcd 0000:00:1d.0: reused qh ffff880215cda180 schedule
usb 2-1.5: link qh8-0601/ffff880215cda180 start 5 [1/2 us]
ehci_hcd 0000:00:1d.0: reused qh ffff880213868980 schedule
usb 2-1.5: link qh32-0601/ffff880213868980 start 6 [1/2 us]
usb 2-1.6: finish resume
usb 2-1.1: finish reset-resume
usb 2-1.2: finish resume
usb 2-1.3: finish resume
hub 2-1.2:1.0: hub_resume
hub 2-1.2:1.0: port 1: status 0507 change 0000
ehci_hcd 0000:00:1d.0: reused qh ffff8802161b0e80 schedule
usb 2-1.2: link qh256-0001/ffff8802161b0e80 start 2 [1/0 us]
usb 2-1.2.1: usb resume
hub 2-1:1.0: port 1 not reset yet, waiting 10ms
usb 2-1.2.1: finish resume
hub 2-1.2.1:1.0: hub_resume
hub 2-1.2.1:1.0: port 1: status 0507 change 0000
ehci_hcd 0000:00:1d.0: reused qh ffff880213868b00 schedule
usb 2-1.2.1: link qh256-0001/ffff880213868b00 start 3 [1/0 us]
usb 2-1.2.1.1: usb resume
usb 2-1.1: reset high-speed USB device number 3 using ehci_hcd
usb 2-1.2.1.1: finish resume
hub 2-1:1.0: port 1 not reset yet, waiting 10ms
ata3: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
ACPI Error: [DSSP] Namespace lookup failure, AE_NOT_FOUND (20120320/psargs-359)
ACPI Error: Method parse/execution failed [\_SB_.PCI0.SAT0.SPT2._GTF] (Node ffff88021606b618), AE_NOT_FOUND (20120320/psparse-536)
ACPI Error: [DSSP] Namespace lookup failure, AE_NOT_FOUND (20120320/psargs-359)
ACPI Error: Method parse/execution failed [\_SB_.PCI0.SAT0.SPT2._GTF] (Node ffff88021606b618), AE_NOT_FOUND (20120320/psparse-536)
ata3.00: configured for UDMA/133
restoring control 00000000-0000-0000-0000-000000000001/1/2
restoring control 00000000-0000-0000-0000-000000000001/2/3
restoring control 00000000-0000-0000-0000-000000000001/3/4
uvcvideo: Failed to query (SET_CUR) UVC control 4 on unit 1: -32 (exp. 4).
uvcvideo 2-1.1:1.0: reset_resume error -5
snd-usb-audio 2-1.1:1.2: no reset_resume for driver snd-usb-audio?
snd-usb-audio 2-1.1:1.3: no reset_resume for driver snd-usb-audio?
snd-usb-audio 2-1.1:1.2: forced unbind
snd-usb-audio 2-1.1:1.3: forced unbind
e1000e: eth0 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: Rx/Tx
DROP INPUT: IN=eth0 OUT= MAC=01:00:5e:00:00:01:d8:5d:4c:b9:dc:ce:08:00 SRC=192.168.1.1 DST=224.0.0.1 LEN=32 TOS=0x00 PREC=0xC0 TTL=1 ID=0 DF PROTO=2 
ata5: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
ACPI Error: [DSSP] Namespace lookup failure, AE_NOT_FOUND (20120320/psargs-359)
ACPI Error: Method parse/execution failed [\_SB_.PCI0.SAT0.SPT4._GTF] (Node ffff88021606b708), AE_NOT_FOUND (20120320/psparse-536)
ACPI Error: [DSSP] Namespace lookup failure, AE_NOT_FOUND (20120320/psargs-359)
ACPI Error: Method parse/execution failed [\_SB_.PCI0.SAT0.SPT4._GTF] (Node ffff88021606b708), AE_NOT_FOUND (20120320/psparse-536)
ata5.00: configured for UDMA/133
sd 4:0:0:0: [sda] Starting disk
PM: resume of devices complete after 4539.833 msecs
snd-usb-audio 2-1.1:1.2: usb_probe_interface
snd-usb-audio 2-1.1:1.2: usb_probe_interface - got id
Restarting tasks ... 
hub 1-0:1.0: state 7 ports 2 chg 0000 evt 0000
hub 1-1:1.0: state 7 ports 6 chg 0000 evt 0000
hub 2-0:1.0: state 7 ports 2 chg 0000 evt 0000
hub 2-1:1.0: state 7 ports 8 chg 0020 evt 0000
hub 2-1:1.0: port 5, status 0303, change 0000, 1.5 Mb/s
hub 2-1.2:1.0: state 7 ports 2 chg 0000 evt 0000
hub 2-1.2.1:1.0: state 7 ports 4 chg 0000 evt 0000
ehci_hcd 0000:00:1d.0: reused qh ffff880212aefd00 schedule
usb 2-1.3: link qh8-0601/ffff880212aefd00 start 7 [1/2 us]
ehci_hcd 0000:00:1d.0: reused qh ffff8802148f9700 schedule
usb 2-1.6: link qh8-0601/ffff8802148f9700 start 0 [1/2 us]
done.
video LNXVIDEO:00: Restoring backlight state
usb 2-1.3: unlink qh8-0601/ffff880212aefd00 start 7 [1/2 us]
usb 2-1.6: unlink qh8-0601/ffff8802148f9700 start 0 [1/2 us]
ehci_hcd 0000:00:1d.0: reused qh ffff8802148f9700 schedule
usb 2-1.6: link qh8-0601/ffff8802148f9700 start 0 [1/2 us]
ehci_hcd 0000:00:1d.0: reused qh ffff880212aefd00 schedule
usb 2-1.3: link qh8-0601/ffff880212aefd00 start 7 [1/2 us]
usb 2-1.3: unlink qh8-0601/ffff880212aefd00 start 7 [1/2 us]
hub 1-1:1.0: hub_suspend
usb 1-1: unlink qh256-0001/ffff88021509ca00 start 1 [1/0 us]
usb 1-1: usb auto-suspend, wakeup 1
ehci_hcd 0000:00:1d.0: reused qh ffff880212aefd00 schedule
usb 2-1.3: link qh8-0601/ffff880212aefd00 start 7 [1/2 us]
usb 2-1.3: unlink qh8-0601/ffff880212aefd00 start 7 [1/2 us]
hub 1-0:1.0: hub_suspend
usb usb1: bus auto-suspend, wakeup 1
ehci_hcd 0000:00:1a.0: suspend root hub
ehci_hcd 0000:00:1d.0: reused qh ffff880212aefd00 schedule
usb 2-1.3: link qh8-0601/ffff880212aefd00 start 7 [1/2 us]
usb 2-1.3: unlink qh8-0601/ffff880212aefd00 start 7 [1/2 us]
ehci_hcd 0000:00:1d.0: reused qh ffff880212aefd00 schedule
usb 2-1.3: link qh8-0601/ffff880212aefd00 start 7 [1/2 us]
usb 2-1.3: unlink qh8-0601/ffff880212aefd00 start 7 [1/2 us]
ehci_hcd 0000:00:1d.0: reused qh ffff880212aefd00 schedule
usb 2-1.3: link qh8-0601/ffff880212aefd00 start 7 [1/2 us]
usb 2-1.3: unlink qh8-0601/ffff880212aefd00 start 7 [1/2 us]

^ permalink raw reply	[flat|nested] 148+ messages in thread

* Re: [RFT] PCI changes related to wakeup (was: Re: [linux-pm] ehci_hcd related S3 lockup on ASUS laptops, again)
  2012-05-31 21:07                                                                                                                                                       ` Alan Stern
  2012-05-31 21:29                                                                                                                                                         ` Rafael J. Wysocki
  2012-05-31 22:02                                                                                                                                                         ` [RFT] PCI changes related to wakeup (was: Re: [linux-pm] " Dâniel Fraga
@ 2012-05-31 22:25                                                                                                                                                         ` Andrey Rahmatullin
  2012-06-13  9:22                                                                                                                                                         ` Rafael J. Wysocki
  3 siblings, 0 replies; 148+ messages in thread
From: Andrey Rahmatullin @ 2012-05-31 22:25 UTC (permalink / raw)
  To: Alan Stern
  Cc: Rafael J. Wysocki, Oleksij Rempel (fishor),
	Dâniel Fraga, Steven Rostedt, linux-pm,
	ACPI Devel Mailing List


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

On Thu, May 31, 2012 at 05:07:36PM -0400, Alan Stern wrote:
> Here's my attempt.  Everybody, please try this patch with the
> 151b61284776 commit removed.  Make sure that CONFIG_USB_DEBUG is
> enabled so we can check the controller's power state during suspend, 
> and check that the "broken D3 during system sleep on ASUS" message 
> shows up during booting.
dmesg attached

-- 
WBR, wRAR

[-- Attachment #1.2: dmesg.gz --]
[-- Type: application/octet-stream, Size: 2417 bytes --]

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

^ permalink raw reply	[flat|nested] 148+ messages in thread

* Re: [RFT] PCI changes related to wakeup (was: Re: [linux-pm] ehci_hcd related S3 lockup on ASUS laptops, again)
  2012-05-31 22:02                                                                                                                                                         ` [RFT] PCI changes related to wakeup (was: Re: [linux-pm] " Dâniel Fraga
@ 2012-06-01 14:55                                                                                                                                                           ` Alan Stern
  0 siblings, 0 replies; 148+ messages in thread
From: Alan Stern @ 2012-06-01 14:55 UTC (permalink / raw)
  To: Dâniel Fraga
  Cc: Rafael J. Wysocki, Oleksij Rempel (fishor),
	Andrey Rahmatullin, Steven Rostedt, linux-pm,
	ACPI Devel Mailing List

On Thu, 31 May 2012, Dâniel Fraga wrote:

> On Thu, 31 May 2012 17:07:36 -0400 (EDT)
> Alan Stern <stern@rowland.harvard.edu> wrote:
> 
> > Here's my attempt.  Everybody, please try this patch with the
> > 151b61284776 commit removed.  Make sure that CONFIG_USB_DEBUG is
> > enabled so we can check the controller's power state during suspend, 
> > and check that the "broken D3 during system sleep on ASUS" message 
> > shows up during booting.
> 
> 	Hi Alan, I tested your patch. It wakes up fine through
> keyboard, but it didn't write the "broken D3 during..." message. I
> attached the dmesg output.

That's good.  The message isn't supposed to appear on your system 
because your system works properly without any special treatment.

Alan Stern

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

^ permalink raw reply	[flat|nested] 148+ messages in thread

* Re: [RFT] PCI changes related to wakeup (was: Re: [linux-pm] ehci_hcd related S3 lockup on ASUS laptops, again)
  2012-05-31 21:29                                                                                                                                                         ` Rafael J. Wysocki
@ 2012-06-01 15:13                                                                                                                                                           ` Alan Stern
  2012-06-01 15:50                                                                                                                                                             ` Steven Rostedt
  0 siblings, 1 reply; 148+ messages in thread
From: Alan Stern @ 2012-06-01 15:13 UTC (permalink / raw)
  To: Rafael J. Wysocki
  Cc: Oleksij Rempel (fishor),
	Dâniel Fraga, Andrey Rahmatullin, Steven Rostedt, linux-pm,
	ACPI Devel Mailing List

On Thu, 31 May 2012, Rafael J. Wysocki wrote:

> > @@ -1743,6 +1743,11 @@ int pci_prepare_to_sleep(struct pci_dev
> >  	if (target_state == PCI_POWER_ERROR)
> >  		return -EIO;
> >  
> > +	/* Some devices mustn't be in D3 during system sleep */
> > +	if (target_state == PCI_D3hot &&
> > +			(dev->dev_flags & PCI_DEV_FLAGS_NO_D3_DURING_SLEEP))
> > +		return 0;
> > +
> 
> Why do you want to skip the wakeup setting in that case?

Because that's what the 151b61284776 commit did.  Also, the quirk marks 
the controller as not wakeup-capable.

Still, it's worth testing.  Andrey and Steve, here's an updated patch 
which should leave wakeup enabled on your EHCI controllers.  If you 
don't have a USB keyboard handy for generating a wakeup signal, you 
can test the wakeup functionality by doing:

	echo enabled >/sys/bus/usb/devices/usb1/power/wakeup
	echo enabled >/sys/bus/usb/devices/usb2/power/wakeup

before suspending.  (In fact you need only one of those two lines, but
at the moment I forget which -- probably the usb2 one.)  Then while
the system is asleep, either plugging or unplugging a USB device
directly into the computer should cause it to wake up.

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
@@ -1745,6 +1745,11 @@ int pci_prepare_to_sleep(struct pci_dev
 
 	pci_enable_wake(dev, target_state, device_may_wakeup(&dev->dev));
 
+	/* Some devices mustn't be in D3 during system sleep */
+	if (target_state == PCI_D3hot &&
+			(dev->dev_flags & PCI_DEV_FLAGS_NO_D3_DURING_SLEEP))
+		return 0;
+
 	error = pci_set_power_state(dev, target_state);
 
 	if (error)
Index: usb-3.4/drivers/pci/quirks.c
===================================================================
--- usb-3.4.orig/drivers/pci/quirks.c
+++ usb-3.4/drivers/pci/quirks.c
@@ -2917,6 +2917,31 @@ static void __devinit disable_igfx_irq(s
 DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL, 0x0102, disable_igfx_irq);
 DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL, 0x010a, disable_igfx_irq);
 
+/*
+ * The Intel 6 Series/C200 Series chipset's EHCI controllers on many
+ * ASUS motherboards will cause memory corruption or a system crash
+ * if they are in D3 while the system is put into S3 sleep.
+ */
+static void __devinit asus_ehci_no_d3(struct pci_dev *dev)
+{
+	const char *sys_info;
+	static const char good_Asus_board[] = "P8Z68-V";
+
+	if (dev->dev_flags & PCI_DEV_FLAGS_NO_D3_DURING_SLEEP)
+		return;
+	if (dev->subsystem_vendor != PCI_VENDOR_ID_ASUSTEK)
+		return;
+	sys_info = dmi_get_system_info(DMI_BOARD_NAME);
+	if (sys_info && memcmp(sys_info, good_Asus_board,
+			sizeof(good_Asus_board) - 1) == 0)
+		return;
+
+	dev_info(&dev->dev, "broken D3 during system sleep on ASUS\n");
+	dev->dev_flags |= PCI_DEV_FLAGS_NO_D3_DURING_SLEEP;
+}
+DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL, 0x1c26, asus_ehci_no_d3);
+DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL, 0x1c2d, asus_ehci_no_d3);
+
 static void pci_do_fixups(struct pci_dev *dev, struct pci_fixup *f,
 			  struct pci_fixup *end)
 {
Index: usb-3.4/include/linux/pci.h
===================================================================
--- usb-3.4.orig/include/linux/pci.h
+++ usb-3.4/include/linux/pci.h
@@ -176,6 +176,8 @@ enum pci_dev_flags {
 	PCI_DEV_FLAGS_NO_D3 = (__force pci_dev_flags_t) 2,
 	/* Provide indication device is assigned by a Virtual Machine Manager */
 	PCI_DEV_FLAGS_ASSIGNED = (__force pci_dev_flags_t) 4,
+	/* Device causes system crash if in D3 during S3 sleep */
+	PCI_DEV_FLAGS_NO_D3_DURING_SLEEP = (__force pci_dev_flags_t) 8,
 };
 
 enum pci_irq_reroute_variant {


^ permalink raw reply	[flat|nested] 148+ messages in thread

* Re: [RFT] PCI changes related to wakeup (was: Re: [linux-pm] ehci_hcd related S3 lockup on ASUS laptops, again)
  2012-06-01 15:13                                                                                                                                                           ` Alan Stern
@ 2012-06-01 15:50                                                                                                                                                             ` Steven Rostedt
  2012-06-01 15:59                                                                                                                                                               ` [RFT] PCI changes related to wakeup (was: " Alan Stern
  2012-06-01 16:01                                                                                                                                                               ` [RFT] PCI changes related to wakeup (was: " Andrey Rahmatullin
  0 siblings, 2 replies; 148+ messages in thread
From: Steven Rostedt @ 2012-06-01 15:50 UTC (permalink / raw)
  To: Alan Stern
  Cc: Rafael J. Wysocki, Oleksij Rempel (fishor),
	Dâniel Fraga, Andrey Rahmatullin, linux-pm,
	ACPI Devel Mailing List

On Fri, 2012-06-01 at 11:13 -0400, Alan Stern wrote:
> On Thu, 31 May 2012, Rafael J. Wysocki wrote:
> 
> > > @@ -1743,6 +1743,11 @@ int pci_prepare_to_sleep(struct pci_dev
> > >  	if (target_state == PCI_POWER_ERROR)
> > >  		return -EIO;
> > >  
> > > +	/* Some devices mustn't be in D3 during system sleep */
> > > +	if (target_state == PCI_D3hot &&
> > > +			(dev->dev_flags & PCI_DEV_FLAGS_NO_D3_DURING_SLEEP))
> > > +		return 0;
> > > +
> > 
> > Why do you want to skip the wakeup setting in that case?
> 
> Because that's what the 151b61284776 commit did.  Also, the quirk marks 
> the controller as not wakeup-capable.
> 
> Still, it's worth testing.  Andrey and Steve, here's an updated patch 
> which should leave wakeup enabled on your EHCI controllers.  If you 
> don't have a USB keyboard handy for generating a wakeup signal, you 
> can test the wakeup functionality by doing:
> 
> 	echo enabled >/sys/bus/usb/devices/usb1/power/wakeup
> 	echo enabled >/sys/bus/usb/devices/usb2/power/wakeup
> 
> before suspending.  (In fact you need only one of those two lines, but
> at the moment I forget which -- probably the usb2 one.)  Then while
> the system is asleep, either plugging or unplugging a USB device
> directly into the computer should cause it to wake up.

I applied the patch, it suspends and resumes fine, but still no wakeup.

I even plugged in a USB keyboard, suspended, and tried to wake it up
with that. That did not work. I even enabled what you stated above, with
no effect (with keyboard or usb storage).

-- Steve



^ permalink raw reply	[flat|nested] 148+ messages in thread

* Re: [RFT] PCI changes related to wakeup (was: Re: ehci_hcd related S3 lockup on ASUS laptops, again)
  2012-06-01 15:50                                                                                                                                                             ` Steven Rostedt
@ 2012-06-01 15:59                                                                                                                                                               ` Alan Stern
  2012-06-01 17:01                                                                                                                                                                 ` [RFT] PCI changes related to wakeup (was: Re: [linux-pm] " Steven Rostedt
  2012-06-01 16:01                                                                                                                                                               ` [RFT] PCI changes related to wakeup (was: " Andrey Rahmatullin
  1 sibling, 1 reply; 148+ messages in thread
From: Alan Stern @ 2012-06-01 15:59 UTC (permalink / raw)
  To: Steven Rostedt
  Cc: ACPI Devel Mailing List, Dâniel Fraga, Andrey Rahmatullin,
	Oleksij Rempel (fishor),
	linux-pm

On Fri, 1 Jun 2012, Steven Rostedt wrote:

> > > Why do you want to skip the wakeup setting in that case?
> > 
> > Because that's what the 151b61284776 commit did.  Also, the quirk marks 
> > the controller as not wakeup-capable.
> > 
> > Still, it's worth testing.  Andrey and Steve, here's an updated patch 
> > which should leave wakeup enabled on your EHCI controllers.  If you 
> > don't have a USB keyboard handy for generating a wakeup signal, you 
> > can test the wakeup functionality by doing:
> > 
> > 	echo enabled >/sys/bus/usb/devices/usb1/power/wakeup
> > 	echo enabled >/sys/bus/usb/devices/usb2/power/wakeup
> > 
> > before suspending.  (In fact you need only one of those two lines, but
> > at the moment I forget which -- probably the usb2 one.)  Then while
> > the system is asleep, either plugging or unplugging a USB device
> > directly into the computer should cause it to wake up.
> 
> I applied the patch, it suspends and resumes fine, but still no wakeup.
> 
> I even plugged in a USB keyboard, suspended, and tried to wake it up
> with that. That did not work. I even enabled what you stated above, with
> no effect (with keyboard or usb storage).

This suggests that the original version of the patch is superior.  
There's not point in saying the controller is wakeup-capable and trying 
to enable wakeup if it's not going to work.

Alan Stern

^ permalink raw reply	[flat|nested] 148+ messages in thread

* Re: [RFT] PCI changes related to wakeup (was: Re: ehci_hcd related S3 lockup on ASUS laptops, again)
  2012-06-01 15:50                                                                                                                                                             ` Steven Rostedt
  2012-06-01 15:59                                                                                                                                                               ` [RFT] PCI changes related to wakeup (was: " Alan Stern
@ 2012-06-01 16:01                                                                                                                                                               ` Andrey Rahmatullin
  2012-06-01 16:33                                                                                                                                                                 ` Alan Stern
  1 sibling, 1 reply; 148+ messages in thread
From: Andrey Rahmatullin @ 2012-06-01 16:01 UTC (permalink / raw)
  To: Steven Rostedt
  Cc: Dâniel Fraga, ACPI Devel Mailing List,
	Oleksij Rempel (fishor),
	linux-pm


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

On Fri, Jun 01, 2012 at 11:50:44AM -0400, Steven Rostedt wrote:
> > > > @@ -1743,6 +1743,11 @@ int pci_prepare_to_sleep(struct pci_dev
> > > >  	if (target_state == PCI_POWER_ERROR)
> > > >  		return -EIO;
> > > >  
> > > > +	/* Some devices mustn't be in D3 during system sleep */
> > > > +	if (target_state == PCI_D3hot &&
> > > > +			(dev->dev_flags & PCI_DEV_FLAGS_NO_D3_DURING_SLEEP))
> > > > +		return 0;
> > > > +
> > > 
> > > Why do you want to skip the wakeup setting in that case?
> > 
> > Because that's what the 151b61284776 commit did.  Also, the quirk marks 
> > the controller as not wakeup-capable.
> > 
> > Still, it's worth testing.  Andrey and Steve, here's an updated patch 
> > which should leave wakeup enabled on your EHCI controllers.  If you 
> > don't have a USB keyboard handy for generating a wakeup signal, you 
> > can test the wakeup functionality by doing:
> > 
> > 	echo enabled >/sys/bus/usb/devices/usb1/power/wakeup
> > 	echo enabled >/sys/bus/usb/devices/usb2/power/wakeup
> > 
> > before suspending.  (In fact you need only one of those two lines, but
> > at the moment I forget which -- probably the usb2 one.)  Then while
> > the system is asleep, either plugging or unplugging a USB device
> > directly into the computer should cause it to wake up.
> 
> I applied the patch, it suspends and resumes fine, but still no wakeup.
> 
> I even plugged in a USB keyboard, suspended, and tried to wake it up
> with that. That did not work. I even enabled what you stated above, with
> no effect (with keyboard or usb storage).
The same here, and the keyboard LEDs turn off on suspending.

-- 
WBR, wRAR

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

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



^ permalink raw reply	[flat|nested] 148+ messages in thread

* Re: [RFT] PCI changes related to wakeup (was: Re: ehci_hcd related S3 lockup on ASUS laptops, again)
  2012-06-01 16:01                                                                                                                                                               ` [RFT] PCI changes related to wakeup (was: " Andrey Rahmatullin
@ 2012-06-01 16:33                                                                                                                                                                 ` Alan Stern
  0 siblings, 0 replies; 148+ messages in thread
From: Alan Stern @ 2012-06-01 16:33 UTC (permalink / raw)
  To: Andrey Rahmatullin
  Cc: Dâniel Fraga, Steven Rostedt, ACPI Devel Mailing List,
	Oleksij Rempel (fishor),
	linux-pm

On Fri, 1 Jun 2012, Andrey Rahmatullin wrote:

> > I applied the patch, it suspends and resumes fine, but still no wakeup.
> > 
> > I even plugged in a USB keyboard, suspended, and tried to wake it up
> > with that. That did not work. I even enabled what you stated above, with
> > no effect (with keyboard or usb storage).
> The same here, and the keyboard LEDs turn off on suspending.

The LEDs are expected to turn off during suspend; that's normal.  
Otherwise they would use up unnecessary electrical power.

Alan Stern

^ permalink raw reply	[flat|nested] 148+ messages in thread

* Re: [RFT] PCI changes related to wakeup (was: Re: [linux-pm] ehci_hcd related S3 lockup on ASUS laptops, again)
  2012-06-01 15:59                                                                                                                                                               ` [RFT] PCI changes related to wakeup (was: " Alan Stern
@ 2012-06-01 17:01                                                                                                                                                                 ` Steven Rostedt
  2012-06-01 17:17                                                                                                                                                                   ` [RFT] PCI changes related to wakeup (was: " Alan Stern
  0 siblings, 1 reply; 148+ messages in thread
From: Steven Rostedt @ 2012-06-01 17:01 UTC (permalink / raw)
  To: Alan Stern
  Cc: Rafael J. Wysocki, Oleksij Rempel (fishor),
	Dâniel Fraga, Andrey Rahmatullin, linux-pm,
	ACPI Devel Mailing List

On Fri, 2012-06-01 at 11:59 -0400, Alan Stern wrote:
>  
> > I even plugged in a USB keyboard, suspended, and tried to wake it up
> > with that. That did not work. I even enabled what you stated above, with
> > no effect (with keyboard or usb storage).
> 
> This suggests that the original version of the patch is superior.  
> There's not point in saying the controller is wakeup-capable and trying 
> to enable wakeup if it's not going to work.

I would point out that I have yet to get wakeup via usb to work with any
patch.

Maybe I missed a patch, which one is suppose to work?

-- Steve



^ permalink raw reply	[flat|nested] 148+ messages in thread

* Re: [RFT] PCI changes related to wakeup (was: Re: ehci_hcd related S3 lockup on ASUS laptops, again)
  2012-06-01 17:01                                                                                                                                                                 ` [RFT] PCI changes related to wakeup (was: Re: [linux-pm] " Steven Rostedt
@ 2012-06-01 17:17                                                                                                                                                                   ` Alan Stern
  2012-06-01 17:23                                                                                                                                                                     ` [RFT] PCI changes related to wakeup (was: Re: [linux-pm] " Steven Rostedt
  0 siblings, 1 reply; 148+ messages in thread
From: Alan Stern @ 2012-06-01 17:17 UTC (permalink / raw)
  To: Steven Rostedt
  Cc: ACPI Devel Mailing List, Dâniel Fraga, Andrey Rahmatullin,
	Oleksij Rempel (fishor),
	linux-pm

On Fri, 1 Jun 2012, Steven Rostedt wrote:

> On Fri, 2012-06-01 at 11:59 -0400, Alan Stern wrote:
> >  
> > > I even plugged in a USB keyboard, suspended, and tried to wake it up
> > > with that. That did not work. I even enabled what you stated above, with
> > > no effect (with keyboard or usb storage).
> > 
> > This suggests that the original version of the patch is superior.  
> > There's not point in saying the controller is wakeup-capable and trying 
> > to enable wakeup if it's not going to work.
> 
> I would point out that I have yet to get wakeup via usb to work with any
> patch.
> 
> Maybe I missed a patch, which one is suppose to work?

No, I think it's more likely that USB wakeup simply can't be made to
work on your computer.  Whatever caused the original suspend problem
also interferes with wakeup.

Alan Stern

^ permalink raw reply	[flat|nested] 148+ messages in thread

* Re: [RFT] PCI changes related to wakeup (was: Re: [linux-pm] ehci_hcd related S3 lockup on ASUS laptops, again)
  2012-06-01 17:17                                                                                                                                                                   ` [RFT] PCI changes related to wakeup (was: " Alan Stern
@ 2012-06-01 17:23                                                                                                                                                                     ` Steven Rostedt
  0 siblings, 0 replies; 148+ messages in thread
From: Steven Rostedt @ 2012-06-01 17:23 UTC (permalink / raw)
  To: Alan Stern
  Cc: Rafael J. Wysocki, Oleksij Rempel (fishor),
	Dâniel Fraga, Andrey Rahmatullin, linux-pm,
	ACPI Devel Mailing List

On Fri, 2012-06-01 at 13:17 -0400, Alan Stern wrote:
>  
> > Maybe I missed a patch, which one is suppose to work?
> 
> No, I think it's more likely that USB wakeup simply can't be made to
> work on your computer.  Whatever caused the original suspend problem
> also interferes with wakeup.

OK, that's what I thought, as it doesn't even work with Windows.

-- Steve



^ permalink raw reply	[flat|nested] 148+ messages in thread

* Re: [RFT] PCI changes related to wakeup (was: Re: [linux-pm] ehci_hcd related S3 lockup on ASUS laptops, again)
  2012-05-31 21:07                                                                                                                                                       ` Alan Stern
                                                                                                                                                                           ` (2 preceding siblings ...)
  2012-05-31 22:25                                                                                                                                                         ` Andrey Rahmatullin
@ 2012-06-13  9:22                                                                                                                                                         ` Rafael J. Wysocki
  2012-06-13 14:21                                                                                                                                                           ` [RFT] PCI changes related to wakeup (was: " Alan Stern
  2012-06-13 15:20                                                                                                                                                           ` [PATCH] PCI: add NO_D3_DURING_SLEEP flag and revert 151b61284776be2 Alan Stern
  3 siblings, 2 replies; 148+ messages in thread
From: Rafael J. Wysocki @ 2012-06-13  9:22 UTC (permalink / raw)
  To: Alan Stern
  Cc: Oleksij Rempel (fishor),
	Dâniel Fraga, Andrey Rahmatullin, Steven Rostedt, linux-pm,
	ACPI Devel Mailing List

Hi Alan,

On Thursday, May 31, 2012, Alan Stern wrote:
> On Tue, 29 May 2012, Rafael J. Wysocki wrote:
> 
> > > > > Therefore we really do need a quirk, probably in ehci-hcd like the 
> > > > > original patch.  If it is restricted to apply only in cases where the 
> > > > > DMI information lists ASUSTeK as the manufacturer, perhaps that will be 
> > > > > sufficient.  (For some reason, the manufacturer field in Dâniel's BIOS 
> > > > > isn't initialized.)
> > > > 
> > > > Yeah.
> > > > 
> > > > I'll have a deeper look at this later today, I think.
> > > 
> > > It's easy enough to write such a check (or perhaps more reliably, check
> > > for a product name matching "P8Z68-V").
> > 
> > I think we should try to express it as a PCI quirk in quirks.c, though.
> 
> Here's my attempt.  Everybody, please try this patch with the
> 151b61284776 commit removed.  Make sure that CONFIG_USB_DEBUG is
> enabled so we can check the controller's power state during suspend, 
> and check that the "broken D3 during system sleep on ASUS" message 
> shows up during booting.

It looks like this worked for everyone concerned, is that correct?

In that case, do you intend to send this patch for inclusion any time soon?
It would be good to have this particular issue taken care of.

Thanks,
Rafael


> Index: usb-3.4/drivers/pci/pci.c
> ===================================================================
> --- usb-3.4.orig/drivers/pci/pci.c
> +++ usb-3.4/drivers/pci/pci.c
> @@ -1743,6 +1743,11 @@ int pci_prepare_to_sleep(struct pci_dev
>  	if (target_state == PCI_POWER_ERROR)
>  		return -EIO;
>  
> +	/* Some devices mustn't be in D3 during system sleep */
> +	if (target_state == PCI_D3hot &&
> +			(dev->dev_flags & PCI_DEV_FLAGS_NO_D3_DURING_SLEEP))
> +		return 0;
> +
>  	pci_enable_wake(dev, target_state, device_may_wakeup(&dev->dev));
>  
>  	error = pci_set_power_state(dev, target_state);
> Index: usb-3.4/drivers/pci/quirks.c
> ===================================================================
> --- usb-3.4.orig/drivers/pci/quirks.c
> +++ usb-3.4/drivers/pci/quirks.c
> @@ -2917,6 +2917,32 @@ static void __devinit disable_igfx_irq(s
>  DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL, 0x0102, disable_igfx_irq);
>  DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL, 0x010a, disable_igfx_irq);
>  
> +/*
> + * The Intel 6 Series/C200 Series chipset's EHCI controllers on many
> + * ASUS motherboards will cause memory corruption or a system crash
> + * if they are in D3 while the system is put into S3 sleep.
> + */
> +static void __devinit asus_ehci_no_d3(struct pci_dev *dev)
> +{
> +	const char *sys_info;
> +	static const char good_Asus_board[] = "P8Z68-V";
> +
> +	if (dev->dev_flags & PCI_DEV_FLAGS_NO_D3_DURING_SLEEP)
> +		return;
> +	if (dev->subsystem_vendor != PCI_VENDOR_ID_ASUSTEK)
> +		return;
> +	sys_info = dmi_get_system_info(DMI_BOARD_NAME);
> +	if (sys_info && memcmp(sys_info, good_Asus_board,
> +			sizeof(good_Asus_board) - 1) == 0)
> +		return;
> +
> +	dev_info(&dev->dev, "broken D3 during system sleep on ASUS\n");
> +	dev->dev_flags |= PCI_DEV_FLAGS_NO_D3_DURING_SLEEP;
> +	device_set_wakeup_capable(&dev->dev, false);
> +}
> +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL, 0x1c26, asus_ehci_no_d3);
> +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL, 0x1c2d, asus_ehci_no_d3);
> +
>  static void pci_do_fixups(struct pci_dev *dev, struct pci_fixup *f,
>  			  struct pci_fixup *end)
>  {
> Index: usb-3.4/include/linux/pci.h
> ===================================================================
> --- usb-3.4.orig/include/linux/pci.h
> +++ usb-3.4/include/linux/pci.h
> @@ -176,6 +176,8 @@ enum pci_dev_flags {
>  	PCI_DEV_FLAGS_NO_D3 = (__force pci_dev_flags_t) 2,
>  	/* Provide indication device is assigned by a Virtual Machine Manager */
>  	PCI_DEV_FLAGS_ASSIGNED = (__force pci_dev_flags_t) 4,
> +	/* Device causes system crash if in D3 during S3 sleep */
> +	PCI_DEV_FLAGS_NO_D3_DURING_SLEEP = (__force pci_dev_flags_t) 8,
>  };
>  
>  enum pci_irq_reroute_variant {
> 
> 
> 

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

^ permalink raw reply	[flat|nested] 148+ messages in thread

* Re: [RFT] PCI changes related to wakeup (was: Re: ehci_hcd related S3 lockup on ASUS laptops, again)
  2012-06-13  9:22                                                                                                                                                         ` Rafael J. Wysocki
@ 2012-06-13 14:21                                                                                                                                                           ` Alan Stern
  2012-06-13 15:20                                                                                                                                                           ` [PATCH] PCI: add NO_D3_DURING_SLEEP flag and revert 151b61284776be2 Alan Stern
  1 sibling, 0 replies; 148+ messages in thread
From: Alan Stern @ 2012-06-13 14:21 UTC (permalink / raw)
  To: Rafael J. Wysocki
  Cc: ACPI Devel Mailing List, Dâniel Fraga, Steven Rostedt,
	Andrey Rahmatullin, Oleksij Rempel (fishor),
	linux-pm

On Wed, 13 Jun 2012, Rafael J. Wysocki wrote:

> Hi Alan,

> It looks like this worked for everyone concerned, is that correct?

Apparently.

> In that case, do you intend to send this patch for inclusion any time soon?
> It would be good to have this particular issue taken care of.

Thanks for reminding me.  I'll send it soon.

Alan Stern

^ permalink raw reply	[flat|nested] 148+ messages in thread

* [PATCH] PCI: add NO_D3_DURING_SLEEP flag and revert 151b61284776be2
  2012-06-13  9:22                                                                                                                                                         ` Rafael J. Wysocki
  2012-06-13 14:21                                                                                                                                                           ` [RFT] PCI changes related to wakeup (was: " Alan Stern
@ 2012-06-13 15:20                                                                                                                                                           ` Alan Stern
       [not found]                                                                                                                                                             ` <Pine.LNX.4.44L0.1206131117260.1401-100000-IYeN2dnnYyZXsRXLowluHWD2FQJk+8+b@public.gmane.org>
  1 sibling, 1 reply; 148+ messages in thread
From: Alan Stern @ 2012-06-13 15:20 UTC (permalink / raw)
  To: Rafael J. Wysocki
  Cc: Dâniel Fraga, Greg KH, USB list, Steven Rostedt,
	Andrey Rahmatullin, Oleksij Rempel (fishor),
	linux-pm

This patch (as1558) fixes a problem affecting several ASUS computers:
The machine crashes or corrupts memory when going into suspend if the
ehci-hcd driver is bound to any controllers.  Users have been forced
to unbind or unload ehci-hcd before putting their systems to sleep.

After extensive testing, it was determined that the machines don't
like going into suspend when any EHCI controllers are in the PCI D3
power state.  Presumably this is a firmware bug, but there's nothing
we can do about it except to avoid putting the controllers in D3
during system sleep.

The patch adds a new flag to indicate whether the problem is present,
and avoids changing the controller's power state if the flag is set.
Runtime suspend is unaffected; this matters only for system suspend.
However as a side effect, the controller will not respond to remote
wakeup requests while the system is asleep.  Hence USB wakeup is not
functional -- but of course, this is already true in the current state
of affairs.

A similar patch has already been applied as commit
151b61284776be2d6f02d48c23c3625678960b97 (USB: EHCI: fix crash during
suspend on ASUS computers).  The patch supersedes that one and reverts
it.  There are two differences:

	The old patch added the flag at the USB level; this patch
	adds it at the PCI level.

	The old patch applied to all chipsets with the same vendor,
	subsystem vendor, and product IDs; this patch makes an
	exception for a known-good system (based on DMI information).

Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Tested-by: Dâniel Fraga <fragabr@gmail.com>
Tested-by: Andrey Rahmatullin <wrar@wrar.name>
Tested-by: Steven Rostedt <rostedt@goodmis.org>
CC: Greg KH <greg@kroah.com>
CC: <stable@vger.kernel.org>

---

Greg, do you mind if this goes in through Rafael's tree?


 drivers/pci/pci.c           |    5 +++++
 drivers/pci/quirks.c        |   26 ++++++++++++++++++++++++++
 drivers/usb/core/hcd-pci.c  |    9 ---------
 drivers/usb/host/ehci-pci.c |    8 --------
 include/linux/pci.h         |    2 ++
 include/linux/usb/hcd.h     |    2 --
 6 files changed, 33 insertions(+), 19 deletions(-)

Index: usb-3.4/include/linux/pci.h
===================================================================
--- usb-3.4.orig/include/linux/pci.h
+++ usb-3.4/include/linux/pci.h
@@ -176,6 +176,8 @@ enum pci_dev_flags {
 	PCI_DEV_FLAGS_NO_D3 = (__force pci_dev_flags_t) 2,
 	/* Provide indication device is assigned by a Virtual Machine Manager */
 	PCI_DEV_FLAGS_ASSIGNED = (__force pci_dev_flags_t) 4,
+	/* Device causes system crash if in D3 during S3 sleep */
+	PCI_DEV_FLAGS_NO_D3_DURING_SLEEP = (__force pci_dev_flags_t) 8,
 };
 
 enum pci_irq_reroute_variant {
Index: usb-3.4/drivers/pci/pci.c
===================================================================
--- usb-3.4.orig/drivers/pci/pci.c
+++ usb-3.4/drivers/pci/pci.c
@@ -1743,6 +1743,11 @@ int pci_prepare_to_sleep(struct pci_dev
 	if (target_state == PCI_POWER_ERROR)
 		return -EIO;
 
+	/* Some devices mustn't be in D3 during system sleep */
+	if (target_state == PCI_D3hot &&
+			(dev->dev_flags & PCI_DEV_FLAGS_NO_D3_DURING_SLEEP))
+		return 0;
+
 	pci_enable_wake(dev, target_state, device_may_wakeup(&dev->dev));
 
 	error = pci_set_power_state(dev, target_state);
Index: usb-3.4/drivers/pci/quirks.c
===================================================================
--- usb-3.4.orig/drivers/pci/quirks.c
+++ usb-3.4/drivers/pci/quirks.c
@@ -2917,6 +2917,32 @@ static void __devinit disable_igfx_irq(s
 DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL, 0x0102, disable_igfx_irq);
 DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL, 0x010a, disable_igfx_irq);
 
+/*
+ * The Intel 6 Series/C200 Series chipset's EHCI controllers on many
+ * ASUS motherboards will cause memory corruption or a system crash
+ * if they are in D3 while the system is put into S3 sleep.
+ */
+static void __devinit asus_ehci_no_d3(struct pci_dev *dev)
+{
+	const char *sys_info;
+	static const char good_Asus_board[] = "P8Z68-V";
+
+	if (dev->dev_flags & PCI_DEV_FLAGS_NO_D3_DURING_SLEEP)
+		return;
+	if (dev->subsystem_vendor != PCI_VENDOR_ID_ASUSTEK)
+		return;
+	sys_info = dmi_get_system_info(DMI_BOARD_NAME);
+	if (sys_info && memcmp(sys_info, good_Asus_board,
+			sizeof(good_Asus_board) - 1) == 0)
+		return;
+
+	dev_info(&dev->dev, "broken D3 during system sleep on ASUS\n");
+	dev->dev_flags |= PCI_DEV_FLAGS_NO_D3_DURING_SLEEP;
+	device_set_wakeup_capable(&dev->dev, false);
+}
+DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL, 0x1c26, asus_ehci_no_d3);
+DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL, 0x1c2d, asus_ehci_no_d3);
+
 static void pci_do_fixups(struct pci_dev *dev, struct pci_fixup *f,
 			  struct pci_fixup *end)
 {
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,15 +493,6 @@ 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
@@ -151,14 +151,6 @@ 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;
-				device_set_wakeup_capable(&pdev->dev, false);
-			}
-		}
 		break;
 	case PCI_VENDOR_ID_TDI:
 		if (pdev->device == PCI_DEVICE_ID_TDI_EHCI) {
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,8 +126,6 @@ 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 */

_______________________________________________
linux-pm mailing list
linux-pm@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/linux-pm

^ permalink raw reply	[flat|nested] 148+ messages in thread

* Re: [PATCH] PCI: add NO_D3_DURING_SLEEP flag and revert 151b61284776be2
       [not found]                                                                                                                                                             ` <Pine.LNX.4.44L0.1206131117260.1401-100000-IYeN2dnnYyZXsRXLowluHWD2FQJk+8+b@public.gmane.org>
@ 2012-06-13 15:27                                                                                                                                                               ` Greg KH
  2012-06-13 20:04                                                                                                                                                                 ` Rafael J. Wysocki
  2012-06-23 21:20                                                                                                                                                               ` Pavel Pisa
  1 sibling, 1 reply; 148+ messages in thread
From: Greg KH @ 2012-06-13 15:27 UTC (permalink / raw)
  To: Alan Stern
  Cc: Rafael J. Wysocki, Oleksij Rempel (fishor),
	Dâniel Fraga, Andrey Rahmatullin, Steven Rostedt,
	linux-pm-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA, USB list

On Wed, Jun 13, 2012 at 11:20:19AM -0400, Alan Stern wrote:
> This patch (as1558) fixes a problem affecting several ASUS computers:
> The machine crashes or corrupts memory when going into suspend if the
> ehci-hcd driver is bound to any controllers.  Users have been forced
> to unbind or unload ehci-hcd before putting their systems to sleep.
> 
> After extensive testing, it was determined that the machines don't
> like going into suspend when any EHCI controllers are in the PCI D3
> power state.  Presumably this is a firmware bug, but there's nothing
> we can do about it except to avoid putting the controllers in D3
> during system sleep.
> 
> The patch adds a new flag to indicate whether the problem is present,
> and avoids changing the controller's power state if the flag is set.
> Runtime suspend is unaffected; this matters only for system suspend.
> However as a side effect, the controller will not respond to remote
> wakeup requests while the system is asleep.  Hence USB wakeup is not
> functional -- but of course, this is already true in the current state
> of affairs.
> 
> A similar patch has already been applied as commit
> 151b61284776be2d6f02d48c23c3625678960b97 (USB: EHCI: fix crash during
> suspend on ASUS computers).  The patch supersedes that one and reverts
> it.  There are two differences:
> 
> 	The old patch added the flag at the USB level; this patch
> 	adds it at the PCI level.
> 
> 	The old patch applied to all chipsets with the same vendor,
> 	subsystem vendor, and product IDs; this patch makes an
> 	exception for a known-good system (based on DMI information).
> 
> Signed-off-by: Alan Stern <stern-nwvwT67g6+6dFdvTe/nMLpVzexx5G7lz@public.gmane.org>
> Tested-by: Dâniel Fraga <fragabr-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> Tested-by: Andrey Rahmatullin <wrar-Bxt/JK/G85ezQB+pC5nmwQ@public.gmane.org>
> Tested-by: Steven Rostedt <rostedt-nx8X9YLhiw1AfugRpC6u6w@public.gmane.org>
> CC: Greg KH <greg-U8xfFu+wG4EAvxtiuMwx3w@public.gmane.org>
> CC: <stable-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>
> 
> ---
> 
> Greg, do you mind if this goes in through Rafael's tree?

Not at all, but I can also take it.

Rafael, if you want to take it, please add:

Acked-by: Greg Kroah-Hartman <gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r@public.gmane.org>

to it, or let me know, and I can take this through my tree.

thanks,

greg k-h
--
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

^ permalink raw reply	[flat|nested] 148+ messages in thread

* Re: [PATCH] PCI: add NO_D3_DURING_SLEEP flag and revert 151b61284776be2
  2012-06-13 20:04                                                                                                                                                                 ` Rafael J. Wysocki
@ 2012-06-13 20:03                                                                                                                                                                   ` Greg KH
       [not found]                                                                                                                                                                     ` <20120613200310.GA11110-U8xfFu+wG4EAvxtiuMwx3w@public.gmane.org>
  0 siblings, 1 reply; 148+ messages in thread
From: Greg KH @ 2012-06-13 20:03 UTC (permalink / raw)
  To: Rafael J. Wysocki
  Cc: Dâniel Fraga, USB list, Steven Rostedt, Andrey Rahmatullin,
	Oleksij Rempel (fishor),
	linux-pm

On Wed, Jun 13, 2012 at 10:04:43PM +0200, Rafael J. Wysocki wrote:
> On Wednesday, June 13, 2012, Greg KH wrote:
> > On Wed, Jun 13, 2012 at 11:20:19AM -0400, Alan Stern wrote:
> > > This patch (as1558) fixes a problem affecting several ASUS computers:
> > > The machine crashes or corrupts memory when going into suspend if the
> > > ehci-hcd driver is bound to any controllers.  Users have been forced
> > > to unbind or unload ehci-hcd before putting their systems to sleep.
> > > 
> > > After extensive testing, it was determined that the machines don't
> > > like going into suspend when any EHCI controllers are in the PCI D3
> > > power state.  Presumably this is a firmware bug, but there's nothing
> > > we can do about it except to avoid putting the controllers in D3
> > > during system sleep.
> > > 
> > > The patch adds a new flag to indicate whether the problem is present,
> > > and avoids changing the controller's power state if the flag is set.
> > > Runtime suspend is unaffected; this matters only for system suspend.
> > > However as a side effect, the controller will not respond to remote
> > > wakeup requests while the system is asleep.  Hence USB wakeup is not
> > > functional -- but of course, this is already true in the current state
> > > of affairs.
> > > 
> > > A similar patch has already been applied as commit
> > > 151b61284776be2d6f02d48c23c3625678960b97 (USB: EHCI: fix crash during
> > > suspend on ASUS computers).  The patch supersedes that one and reverts
> > > it.  There are two differences:
> > > 
> > > 	The old patch added the flag at the USB level; this patch
> > > 	adds it at the PCI level.
> > > 
> > > 	The old patch applied to all chipsets with the same vendor,
> > > 	subsystem vendor, and product IDs; this patch makes an
> > > 	exception for a known-good system (based on DMI information).
> > > 
> > > Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
> > > Tested-by: Dâniel Fraga <fragabr@gmail.com>
> > > Tested-by: Andrey Rahmatullin <wrar@wrar.name>
> > > Tested-by: Steven Rostedt <rostedt@goodmis.org>
> > > CC: Greg KH <greg@kroah.com>
> > > CC: <stable@vger.kernel.org>
> > > 
> > > ---
> > > 
> > > Greg, do you mind if this goes in through Rafael's tree?
> > 
> > Not at all, but I can also take it.
> > 
> > Rafael, if you want to take it, please add:
> > 
> > Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> > 
> > to it, or let me know, and I can take this through my tree.
> 
> Please take it, if that's not a problem, I don't have any other
> patches for 3.5 pending.  And please add:
> 
> Reviewed-by: Rafael J. Wysocki <rjw@sisk.pl>

Ok, I'll go queue it up right now.

greg k-h

^ permalink raw reply	[flat|nested] 148+ messages in thread

* Re: [PATCH] PCI: add NO_D3_DURING_SLEEP flag and revert 151b61284776be2
  2012-06-13 15:27                                                                                                                                                               ` Greg KH
@ 2012-06-13 20:04                                                                                                                                                                 ` Rafael J. Wysocki
  2012-06-13 20:03                                                                                                                                                                   ` Greg KH
  0 siblings, 1 reply; 148+ messages in thread
From: Rafael J. Wysocki @ 2012-06-13 20:04 UTC (permalink / raw)
  To: Greg KH
  Cc: Dâniel Fraga, USB list, Steven Rostedt, Andrey Rahmatullin,
	Oleksij Rempel (fishor),
	linux-pm

On Wednesday, June 13, 2012, Greg KH wrote:
> On Wed, Jun 13, 2012 at 11:20:19AM -0400, Alan Stern wrote:
> > This patch (as1558) fixes a problem affecting several ASUS computers:
> > The machine crashes or corrupts memory when going into suspend if the
> > ehci-hcd driver is bound to any controllers.  Users have been forced
> > to unbind or unload ehci-hcd before putting their systems to sleep.
> > 
> > After extensive testing, it was determined that the machines don't
> > like going into suspend when any EHCI controllers are in the PCI D3
> > power state.  Presumably this is a firmware bug, but there's nothing
> > we can do about it except to avoid putting the controllers in D3
> > during system sleep.
> > 
> > The patch adds a new flag to indicate whether the problem is present,
> > and avoids changing the controller's power state if the flag is set.
> > Runtime suspend is unaffected; this matters only for system suspend.
> > However as a side effect, the controller will not respond to remote
> > wakeup requests while the system is asleep.  Hence USB wakeup is not
> > functional -- but of course, this is already true in the current state
> > of affairs.
> > 
> > A similar patch has already been applied as commit
> > 151b61284776be2d6f02d48c23c3625678960b97 (USB: EHCI: fix crash during
> > suspend on ASUS computers).  The patch supersedes that one and reverts
> > it.  There are two differences:
> > 
> > 	The old patch added the flag at the USB level; this patch
> > 	adds it at the PCI level.
> > 
> > 	The old patch applied to all chipsets with the same vendor,
> > 	subsystem vendor, and product IDs; this patch makes an
> > 	exception for a known-good system (based on DMI information).
> > 
> > Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
> > Tested-by: Dâniel Fraga <fragabr@gmail.com>
> > Tested-by: Andrey Rahmatullin <wrar@wrar.name>
> > Tested-by: Steven Rostedt <rostedt@goodmis.org>
> > CC: Greg KH <greg@kroah.com>
> > CC: <stable@vger.kernel.org>
> > 
> > ---
> > 
> > Greg, do you mind if this goes in through Rafael's tree?
> 
> Not at all, but I can also take it.
> 
> Rafael, if you want to take it, please add:
> 
> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> 
> to it, or let me know, and I can take this through my tree.

Please take it, if that's not a problem, I don't have any other
patches for 3.5 pending.  And please add:

Reviewed-by: Rafael J. Wysocki <rjw@sisk.pl>

to it.

Thanks,
Rafael

^ permalink raw reply	[flat|nested] 148+ messages in thread

* Re: [PATCH] PCI: add NO_D3_DURING_SLEEP flag and revert 151b61284776be2
       [not found]                                                                                                                                                                     ` <20120613200310.GA11110-U8xfFu+wG4EAvxtiuMwx3w@public.gmane.org>
@ 2012-06-13 20:15                                                                                                                                                                       ` Steven Rostedt
       [not found]                                                                                                                                                                         ` <1339618548.13377.162.camel-f9ZlEuEWxVcI6MkJdU+c8EEOCMrvLtNR@public.gmane.org>
  0 siblings, 1 reply; 148+ messages in thread
From: Steven Rostedt @ 2012-06-13 20:15 UTC (permalink / raw)
  To: Greg KH
  Cc: Rafael J. Wysocki, Alan Stern, Oleksij Rempel (fishor),
	Dâniel Fraga, Andrey Rahmatullin,
	linux-pm-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA, USB list

On Wed, 2012-06-13 at 13:03 -0700, Greg KH wrote:
> On Wed, Jun 13, 2012 at 10:04:43PM +0200, Rafael J. Wysocki wrote:

13:03 -0700                  == 20:03 UTC
10:04PM +0200 == 22:04 +0200 == 20:04 UTC

> > 
> > Please take it, if that's not a problem, I don't have any other
> > patches for 3.5 pending.  And please add:
> > 
> > Reviewed-by: Rafael J. Wysocki <rjw-KKrjLPT3xs0@public.gmane.org>
> 
> Ok, I'll go queue it up right now.
> 
> greg k-h

One of you (or both) need to learn to use NTP, or perhaps, as we all
suspect, Greg is really psychic.

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

^ permalink raw reply	[flat|nested] 148+ messages in thread

* Re: [PATCH] PCI: add NO_D3_DURING_SLEEP flag and revert 151b61284776be2
       [not found]                                                                                                                                                                         ` <1339618548.13377.162.camel-f9ZlEuEWxVcI6MkJdU+c8EEOCMrvLtNR@public.gmane.org>
@ 2012-06-13 20:17                                                                                                                                                                           ` Steven Rostedt
  0 siblings, 0 replies; 148+ messages in thread
From: Steven Rostedt @ 2012-06-13 20:17 UTC (permalink / raw)
  To: Greg KH
  Cc: Rafael J. Wysocki, Alan Stern, Oleksij Rempel (fishor),
	Dâniel Fraga, Andrey Rahmatullin,
	linux-pm-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA, USB list

On Wed, 2012-06-13 at 16:15 -0400, Steven Rostedt wrote:
> One of you (or both) need to learn to use NTP, or perhaps, as we all
> suspect, Greg is really psychic.

Or maybe it's just that time moves faster at GregKH altitude.

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

^ permalink raw reply	[flat|nested] 148+ messages in thread

* Re: [PATCH] PCI: add NO_D3_DURING_SLEEP flag and revert 151b61284776be2
       [not found]                                                                                                                                                             ` <Pine.LNX.4.44L0.1206131117260.1401-100000-IYeN2dnnYyZXsRXLowluHWD2FQJk+8+b@public.gmane.org>
  2012-06-13 15:27                                                                                                                                                               ` Greg KH
@ 2012-06-23 21:20                                                                                                                                                               ` Pavel Pisa
       [not found]                                                                                                                                                                 ` <201206232320.15186.pisa-/N2ztlQkxE7Ub/6JBqosbQ@public.gmane.org>
  1 sibling, 1 reply; 148+ messages in thread
From: Pavel Pisa @ 2012-06-23 21:20 UTC (permalink / raw)
  To: linux-pm-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA, Alan Stern
  Cc: Greg KH, USB list

Hello Alan and all others,

I have observed similar lock during suspend to RAM on ASUS K52F

Handle 0x0002, DMI type 2, 15 bytes
Base Board Information
        Manufacturer: ASUSTeK Computer Inc.
        Product Name: K52F

BIOS Information
        Vendor: American Megatrends Inc.
        Version: K52F.218
        Release Date: 07/12/2011

00:00.0 Host bridge [0600]: Intel Corporation Core Processor DRAM Controller [8086:0044] (rev 18)
00:02.0 VGA compatible controller [0300]: Intel Corporation Core Processor Integrated Graphics Controller [8086:0046] (rev 18)
00:16.0 Communication controller [0780]: Intel Corporation 5 Series/3400 Series Chipset HECI Controller [8086:3b64] (rev 06)
...
00:1a.0 USB Controller [0c03]: Intel Corporation 5 Series/3400 Series Chipset USB2 Enhanced Host Controller [8086:3b3c] (rev 06)
00:1d.0 USB Controller [0c03]: Intel Corporation 5 Series/3400 Series Chipset USB2 Enhanced Host Controller [8086:3b34] (rev 06)

When I unbind EHCI controllers
  # Unbind ehci_hcd for first device 0000:00:1a.0:
  echo -n "0000:00:1a.0" >/sys/bus/pci/drivers/ehci_hcd/unbind
  # Unbind ehci_hcd for second device 0000:00:1d.0:
  echo -n "0000:00:1d.0" >/sys/bus/pci/drivers/ehci_hcd/unbind
then laptop goes to suspend after
  echo mem >/sys/power/state  
and when power button is pressed it restores to functional state.
It works quite stable repeatedly.

This is similar to the problem solved by your patch.

I have tried 3.4.4 with kernel and added quirk

---
 drivers/pci/quirks.c |    2 ++
 1 file changed, 2 insertions(+)

Index: linux-3.4/drivers/pci/quirks.c
===================================================================
--- linux-3.4.orig/drivers/pci/quirks.c 2012-06-23 16:37:14.582568585 +0200
+++ linux-3.4/drivers/pci/quirks.c      2012-06-23 16:38:38.378571372 +0200
@@ -2942,6 +2942,8 @@
 }
 DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL, 0x1c26, asus_ehci_no_d3);
 DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL, 0x1c2d, asus_ehci_no_d3);
+DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL, 0x3b3c, asus_ehci_no_d3);
+DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL, 0x3b34, asus_ehci_no_d3);

 static void pci_do_fixups(struct pci_dev *dev, struct pci_fixup *f,
                          struct pci_fixup *end)

This quirk allows laptop suspend and resume correctly when nothing
is connected to the USB or even when mounted FLASH disk is connected.
The USB drive works correctly after resume.

DVB tuner is connected

Bus 002 Device 003: ID 0b48:300d TechnoTrend AG TT-connect CT-3650 CI

then suspend proceeds correctly but resume locks hard again.

This seems to be problem in dvb_usb_ttusb2 driver.

But anyway I think, that adding 0x3b3c and 0x3b34 to the quirk list
could help more people.

Best wishes

                Pavel Pisa
    e-mail:     pisa-/N2ztlQkxE7Ub/6JBqosbQ@public.gmane.org
    www:        http://cmp.felk.cvut.cz/~pisa
    university: http://dce.fel.cvut.cz/
    company:    http://www.pikron.com/
--
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

^ permalink raw reply	[flat|nested] 148+ messages in thread

* Re: [PATCH] PCI: add NO_D3_DURING_SLEEP flag and revert 151b61284776be2
       [not found]                                                                                                                                                                 ` <201206232320.15186.pisa-/N2ztlQkxE7Ub/6JBqosbQ@public.gmane.org>
@ 2012-06-24  1:52                                                                                                                                                                   ` Alan Stern
       [not found]                                                                                                                                                                     ` <Pine.LNX.4.44L0.1206232147420.4446-100000-pYrvlCTfrz9XsRXLowluHWD2FQJk+8+b@public.gmane.org>
  0 siblings, 1 reply; 148+ messages in thread
From: Alan Stern @ 2012-06-24  1:52 UTC (permalink / raw)
  To: Pavel Pisa
  Cc: linux-pm-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA, Greg KH, USB list

On Sat, 23 Jun 2012, Pavel Pisa wrote:

> Hello Alan and all others,
> 
> I have observed similar lock during suspend to RAM on ASUS K52F
> 
> Handle 0x0002, DMI type 2, 15 bytes
> Base Board Information
>         Manufacturer: ASUSTeK Computer Inc.
>         Product Name: K52F
> 
> BIOS Information
>         Vendor: American Megatrends Inc.
>         Version: K52F.218
>         Release Date: 07/12/2011
> 
> 00:00.0 Host bridge [0600]: Intel Corporation Core Processor DRAM Controller [8086:0044] (rev 18)
> 00:02.0 VGA compatible controller [0300]: Intel Corporation Core Processor Integrated Graphics Controller [8086:0046] (rev 18)
> 00:16.0 Communication controller [0780]: Intel Corporation 5 Series/3400 Series Chipset HECI Controller [8086:3b64] (rev 06)
> ...
> 00:1a.0 USB Controller [0c03]: Intel Corporation 5 Series/3400 Series Chipset USB2 Enhanced Host Controller [8086:3b3c] (rev 06)
> 00:1d.0 USB Controller [0c03]: Intel Corporation 5 Series/3400 Series Chipset USB2 Enhanced Host Controller [8086:3b34] (rev 06)
> 
> When I unbind EHCI controllers
>   # Unbind ehci_hcd for first device 0000:00:1a.0:
>   echo -n "0000:00:1a.0" >/sys/bus/pci/drivers/ehci_hcd/unbind
>   # Unbind ehci_hcd for second device 0000:00:1d.0:
>   echo -n "0000:00:1d.0" >/sys/bus/pci/drivers/ehci_hcd/unbind
> then laptop goes to suspend after
>   echo mem >/sys/power/state  
> and when power button is pressed it restores to functional state.
> It works quite stable repeatedly.
> 
> This is similar to the problem solved by your patch.
> 
> I have tried 3.4.4 with kernel and added quirk
> 
> ---
>  drivers/pci/quirks.c |    2 ++
>  1 file changed, 2 insertions(+)
> 
> Index: linux-3.4/drivers/pci/quirks.c
> ===================================================================
> --- linux-3.4.orig/drivers/pci/quirks.c 2012-06-23 16:37:14.582568585 +0200
> +++ linux-3.4/drivers/pci/quirks.c      2012-06-23 16:38:38.378571372 +0200
> @@ -2942,6 +2942,8 @@
>  }
>  DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL, 0x1c26, asus_ehci_no_d3);
>  DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL, 0x1c2d, asus_ehci_no_d3);
> +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL, 0x3b3c, asus_ehci_no_d3);
> +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL, 0x3b34, asus_ehci_no_d3);
> 
>  static void pci_do_fixups(struct pci_dev *dev, struct pci_fixup *f,
>                           struct pci_fixup *end)
> 
> This quirk allows laptop suspend and resume correctly when nothing
> is connected to the USB or even when mounted FLASH disk is connected.
> The USB drive works correctly after resume.

Do you want to submit your patch for inclusion in the kernel?  If you 
do, you should follow the instructions in 
Documentation/SubmittingPatches.

Also, you should modify the comment before the asus_ehci_no_d3() 
routine.  Mention the 5 Series/3400 Series chipset in addition to the 6 
Series/C200 Series chipset.

Or if you prefer, I could submit a modified version of your patch.

> DVB tuner is connected
> 
> Bus 002 Device 003: ID 0b48:300d TechnoTrend AG TT-connect CT-3650 CI
> 
> then suspend proceeds correctly but resume locks hard again.
> 
> This seems to be problem in dvb_usb_ttusb2 driver.
> 
> But anyway I think, that adding 0x3b3c and 0x3b34 to the quirk list
> could help more people.

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

^ permalink raw reply	[flat|nested] 148+ messages in thread

* Re: [PATCH] PCI: add NO_D3_DURING_SLEEP flag and revert 151b61284776be2
       [not found]                                                                                                                                                                     ` <Pine.LNX.4.44L0.1206232147420.4446-100000-pYrvlCTfrz9XsRXLowluHWD2FQJk+8+b@public.gmane.org>
@ 2012-06-24  7:00                                                                                                                                                                       ` Pavel Pisa
  0 siblings, 0 replies; 148+ messages in thread
From: Pavel Pisa @ 2012-06-24  7:00 UTC (permalink / raw)
  To: Alan Stern
  Cc: linux-pm-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA, Greg KH, USB list

Hello Alan,

On Sunday 24 June 2012 03:52:23 Alan Stern wrote:
> > Index: linux-3.4/drivers/pci/quirks.c
> > ===================================================================
> > --- linux-3.4.orig/drivers/pci/quirks.c 2012-06-23 16:37:14.582568585
> > +0200 +++ linux-3.4/drivers/pci/quirks.c      2012-06-23
> > 16:38:38.378571372 +0200 @@ -2942,6 +2942,8 @@
> >  }
> >  DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL, 0x1c26, asus_ehci_no_d3);
> >  DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL, 0x1c2d, asus_ehci_no_d3);
> > +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL, 0x3b3c, asus_ehci_no_d3);
> > +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL, 0x3b34, asus_ehci_no_d3);
> >
> >  static void pci_do_fixups(struct pci_dev *dev, struct pci_fixup *f,
> >                           struct pci_fixup *end)
> >
> > This quirk allows laptop suspend and resume correctly when nothing
> > is connected to the USB or even when mounted FLASH disk is connected.
> > The USB drive works correctly after resume.
>
> Do you want to submit your patch for inclusion in the kernel?  If you
> do, you should follow the instructions in
> Documentation/SubmittingPatches.
>
> Also, you should modify the comment before the asus_ehci_no_d3()
> routine.  Mention the 5 Series/3400 Series chipset in addition to the 6
> Series/C200 Series chipset.
>
> Or if you prefer, I could submit a modified version of your patch.

I know formal patch procedure but I expect, that it would be much
faster and simpler if you collect the list and add them yourself.
I expect, that there is potential to solve problems of many
other (at least ASUS) laptop configurations.

By the way, I have similar problem with my MSI laptop. So I try
to check if EHCI unbind does not help there as well.

Best wishes,

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

^ permalink raw reply	[flat|nested] 148+ messages in thread

* Re: ehci_hcd related S3 lockup on ASUS laptops, again
  2012-04-23 16:29 Alan Stern
@ 2012-04-23 18:30 ` Steven Rostedt
  0 siblings, 0 replies; 148+ messages in thread
From: Steven Rostedt @ 2012-04-23 18:30 UTC (permalink / raw)
  To: Alan Stern; +Cc: jrnieder, Andrey Rahmatullin, linux-pm, USB list

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

^ permalink raw reply	[flat|nested] 148+ messages in thread

end of thread, other threads:[~2012-06-24  7:00 UTC | newest]

Thread overview: 148+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2012-04-11 16:55 ehci_hcd related S3 lockup on ASUS laptops, again Andrey Rahmatullin
     [not found] ` <20120411165531.GA3717-hAV9HEAGFNe6YibBOCjzsw@public.gmane.org>
2012-04-11 17:06   ` Steven Rostedt
     [not found]     ` <1334164013.23924.271.camel-f9ZlEuEWxVcI6MkJdU+c8EEOCMrvLtNR@public.gmane.org>
2012-04-11 17:25       ` Alan Stern
     [not found]         ` <Pine.LNX.4.44L0.1204111324100.1351-100000-IYeN2dnnYyZXsRXLowluHWD2FQJk+8+b@public.gmane.org>
2012-04-11 19:12           ` [linux-pm] " Alan Stern
     [not found]             ` <Pine.LNX.4.44L0.1204111429510.1351-100000-IYeN2dnnYyZXsRXLowluHWD2FQJk+8+b@public.gmane.org>
2012-04-11 20:43               ` Steven Rostedt
     [not found]                 ` <1334177035.23924.299.camel-f9ZlEuEWxVcI6MkJdU+c8EEOCMrvLtNR@public.gmane.org>
2012-04-11 21:13                   ` Alan Stern
     [not found]                     ` <Pine.LNX.4.44L0.1204111703180.1351-100000-IYeN2dnnYyZXsRXLowluHWD2FQJk+8+b@public.gmane.org>
2012-04-11 21:19                       ` Steven Rostedt
2012-04-11 22:09                     ` Andrey Rahmatullin
2012-04-12  1:22                       ` Steven Rostedt
     [not found]                         ` <1334193773.23924.316.camel-f9ZlEuEWxVcI6MkJdU+c8EEOCMrvLtNR@public.gmane.org>
2012-04-12 14:28                           ` [linux-pm] " Alan Stern
2012-04-12 15:37                             ` Andrey Rahmatullin
     [not found]                               ` <20120412153750.GA12852-hAV9HEAGFNe6YibBOCjzsw@public.gmane.org>
2012-04-12 16:09                                 ` [linux-pm] " Alan Stern
     [not found]                                   ` <Pine.LNX.4.44L0.1204121203530.1496-100000-IYeN2dnnYyZXsRXLowluHWD2FQJk+8+b@public.gmane.org>
2012-04-12 16:49                                     ` Andrey Rahmatullin
2012-04-12 16:52                                       ` Steven Rostedt
2012-04-12 16:58                                         ` Andrey Rahmatullin
2012-04-12 16:33                             ` Steven Rostedt
2012-04-12 17:06                               ` Alan Stern
2012-04-12 17:14                                 ` Steven Rostedt
2012-04-12 17:18                                   ` Andrey Rahmatullin
2012-04-12 17:48                                   ` Alan Stern
2012-04-12 18:17                                     ` Steven Rostedt
2012-04-12 18:25                                       ` Steven Rostedt
2012-04-12 19:11                                         ` Alan Stern
     [not found]                                           ` <Pine.LNX.4.44L0.1204121504550.1496-100000-IYeN2dnnYyZXsRXLowluHWD2FQJk+8+b@public.gmane.org>
2012-04-12 19:24                                             ` [linux-pm] " Andrey Rahmatullin
2012-04-12 19:35                                             ` Steven Rostedt
2012-04-12 20:02                                               ` Alan Stern
2012-04-12 20:09                                                 ` Alan Stern
2012-04-12 20:21                                                   ` Andrey Rahmatullin
     [not found]                                                     ` <20120412202132.GH12852-hAV9HEAGFNe6YibBOCjzsw@public.gmane.org>
2012-04-12 20:33                                                       ` [linux-pm] " Steven Rostedt
     [not found]                                                         ` <1334262826.23924.351.camel-f9ZlEuEWxVcI6MkJdU+c8EEOCMrvLtNR@public.gmane.org>
2012-04-13  1:09                                                           ` Alan Stern
2012-04-13  1:03                                                     ` Alan Stern
2012-04-12 20:30                                                 ` Andrey Rahmatullin
2012-04-13  1:09                                                   ` Alan Stern
     [not found]                                                     ` <Pine.LNX.4.44L0.1204122103230.10558-100000-pYrvlCTfrz9XsRXLowluHWD2FQJk+8+b@public.gmane.org>
2012-04-13 14:10                                                       ` [linux-pm] " Alan Stern
     [not found]                                                         ` <Pine.LNX.4.44L0.1204131008010.1185-100000-IYeN2dnnYyZXsRXLowluHWD2FQJk+8+b@public.gmane.org>
2012-04-13 15:29                                                           ` Steven Rostedt
     [not found]                                                             ` <1334330949.23924.360.camel-f9ZlEuEWxVcI6MkJdU+c8EEOCMrvLtNR@public.gmane.org>
2012-04-13 15:32                                                               ` Steven Rostedt
     [not found]                                                                 ` <1334331148.23924.361.camel-f9ZlEuEWxVcI6MkJdU+c8EEOCMrvLtNR@public.gmane.org>
2012-04-13 15:35                                                                   ` Steven Rostedt
2012-04-13 15:42                                                               ` Alan Stern
2012-04-13 21:04                                                             ` Alan Stern
2012-04-13 22:43                                                           ` [linux-pm] " Andrey Rahmatullin
2012-04-16 20:07                                                             ` Alan Stern
2012-04-16 21:19                                                               ` Andrey Rahmatullin
2012-04-17 15:11                                                                 ` Alan Stern
2012-04-17 16:25                                                                   ` Andrey Rahmatullin
2012-04-17 16:58                                                                     ` Alan Stern
     [not found]                                                                       ` <Pine.LNX.4.44L0.1204171251330.1364-100000-IYeN2dnnYyZXsRXLowluHWD2FQJk+8+b@public.gmane.org>
2012-04-17 17:51                                                                         ` [linux-pm] " Andrey Rahmatullin
     [not found]                                                                           ` <20120417175122.GM11484-hAV9HEAGFNe6YibBOCjzsw@public.gmane.org>
2012-04-17 18:26                                                                             ` Alan Stern
     [not found]                                                                               ` <Pine.LNX.4.44L0.1204171423310.1163-100000-IYeN2dnnYyZXsRXLowluHWD2FQJk+8+b@public.gmane.org>
2012-04-17 18:51                                                                                 ` Andrey Rahmatullin
     [not found]                                                                                   ` <20120417185149.GO11484-hAV9HEAGFNe6YibBOCjzsw@public.gmane.org>
2012-04-17 19:20                                                                                     ` Alan Stern
     [not found]                                                                                       ` <Pine.LNX.4.44L0.1204171513230.1163-100000-IYeN2dnnYyZXsRXLowluHWD2FQJk+8+b@public.gmane.org>
2012-04-17 19:52                                                                                         ` Andrey Rahmatullin
     [not found]                                                                                           ` <20120417195218.GP11484-hAV9HEAGFNe6YibBOCjzsw@public.gmane.org>
2012-04-18 14:51                                                                                             ` Alan Stern
     [not found]                                                                                               ` <Pine.LNX.4.44L0.1204181048340.1548-100000-IYeN2dnnYyZXsRXLowluHWD2FQJk+8+b@public.gmane.org>
2012-04-18 15:08                                                                                                 ` Steven Rostedt
2012-04-18 15:24                                                                                                 ` Andrey Rahmatullin
2012-04-18 16:41                                                                                                   ` Alan Stern
     [not found]                                                                                                     ` <Pine.LNX.4.44L0.1204181228380.1149-100000-IYeN2dnnYyZXsRXLowluHWD2FQJk+8+b@public.gmane.org>
2012-04-18 17:07                                                                                                       ` [linux-pm] " Steven Rostedt
     [not found]                                                                                                         ` <1334768847.28106.45.camel-f9ZlEuEWxVcI6MkJdU+c8EEOCMrvLtNR@public.gmane.org>
2012-04-18 17:19                                                                                                           ` Alan Stern
     [not found]                                                                                                             ` <Pine.LNX.4.44L0.1204181317550.1149-100000-IYeN2dnnYyZXsRXLowluHWD2FQJk+8+b@public.gmane.org>
2012-04-18 17:24                                                                                                               ` Steven Rostedt
     [not found]                                                                                                                 ` <1334769847.28106.47.camel-f9ZlEuEWxVcI6MkJdU+c8EEOCMrvLtNR@public.gmane.org>
2012-04-18 17:46                                                                                                                   ` Mark Brown
     [not found]                                                                                                                     ` <20120418174610.GA10142-GFdadSzt00ze9xe1eoZjHA@public.gmane.org>
2012-04-18 18:11                                                                                                                       ` Steven Rostedt
2012-04-18 20:25                                                                                                                       ` Alan Stern
2012-04-18 17:10                                                                                                     ` Andrey Rahmatullin
     [not found]                                                                                                       ` <20120418171002.GU11484-hAV9HEAGFNe6YibBOCjzsw@public.gmane.org>
2012-04-18 17:20                                                                                                         ` [linux-pm] " Steven Rostedt
     [not found]                                                                                                           ` <1334769632.28106.46.camel-f9ZlEuEWxVcI6MkJdU+c8EEOCMrvLtNR@public.gmane.org>
2012-04-18 20:23                                                                                                             ` Alan Stern
     [not found]                                                                                                               ` <Pine.LNX.4.44L0.1204181616430.1149-100000-IYeN2dnnYyZXsRXLowluHWD2FQJk+8+b@public.gmane.org>
2012-04-18 21:02                                                                                                                 ` Steven Rostedt
     [not found]                                                                                                                   ` <1334782932.28106.52.camel-f9ZlEuEWxVcI6MkJdU+c8EEOCMrvLtNR@public.gmane.org>
2012-04-18 21:27                                                                                                                     ` Alan Stern
     [not found]                                                                                                                       ` <Pine.LNX.4.44L0.1204181724570.1149-100000-IYeN2dnnYyZXsRXLowluHWD2FQJk+8+b@public.gmane.org>
2012-04-18 21:41                                                                                                                         ` Steven Rostedt
2012-04-18 21:04                                                                                                                 ` Rafael J. Wysocki
     [not found]                                                                                                                   ` <201204182304.29249.rjw-KKrjLPT3xs0@public.gmane.org>
2012-04-18 21:29                                                                                                                     ` Alan Stern
     [not found]                                                                                                                       ` <Pine.LNX.4.44L0.1204181727580.1149-100000-IYeN2dnnYyZXsRXLowluHWD2FQJk+8+b@public.gmane.org>
2012-04-18 21:44                                                                                                                         ` Rafael J. Wysocki
2012-04-18 21:47                                                                                                                           ` Andrey Rahmatullin
2012-04-18 21:23                                                                                                               ` Andrey Rahmatullin
     [not found]                                                                                                                 ` <20120418212301.GW11484-hAV9HEAGFNe6YibBOCjzsw@public.gmane.org>
2012-04-18 21:30                                                                                                                   ` [linux-pm] " Alan Stern
     [not found]                                                                                                                     ` <Pine.LNX.4.44L0.1204181729400.1149-100000-IYeN2dnnYyZXsRXLowluHWD2FQJk+8+b@public.gmane.org>
2012-04-19 13:43                                                                                                                       ` Alan Stern
     [not found]                                                                                                                         ` <Pine.LNX.4.44L0.1204190934500.2070-100000-IYeN2dnnYyZXsRXLowluHWD2FQJk+8+b@public.gmane.org>
2012-04-19 15:44                                                                                                                           ` Andrey Rahmatullin
     [not found]                                                                                                                             ` <20120419154453.GZ11484-hAV9HEAGFNe6YibBOCjzsw@public.gmane.org>
2012-04-19 16:05                                                                                                                               ` Alan Stern
2012-04-19 15:53                                                                                                                           ` Andrey Rahmatullin
2012-04-19 16:06                                                                                                                             ` Alan Stern
2012-04-19 16:22                                                                                                                           ` [linux-pm] " Steven Rostedt
     [not found]                                                                                                                             ` <1334852575.28106.62.camel-f9ZlEuEWxVcI6MkJdU+c8EEOCMrvLtNR@public.gmane.org>
2012-04-19 18:08                                                                                                                               ` Steven Rostedt
2012-04-19 18:13                                                                                                                                 ` Alan Stern
     [not found]                                                                                                                                   ` <Pine.LNX.4.44L0.1204191411360.1154-100000-IYeN2dnnYyZXsRXLowluHWD2FQJk+8+b@public.gmane.org>
2012-04-19 18:30                                                                                                                                     ` [linux-pm] " Steven Rostedt
2012-04-19 16:30                                                                                                                           ` Andrey Rahmatullin
     [not found]                                                                                                                             ` <20120419163055.GB11484-hAV9HEAGFNe6YibBOCjzsw@public.gmane.org>
2012-04-19 18:07                                                                                                                               ` Alan Stern
2012-04-19 21:48                                                                                                                                 ` Andrey Rahmatullin
2012-04-21  0:42                                                                                                                                   ` Alan Stern
2012-04-21  0:53                                                                                                                                     ` Steven Rostedt
     [not found]                                                                                                                                       ` <1334969624.28106.82.camel-f9ZlEuEWxVcI6MkJdU+c8EEOCMrvLtNR@public.gmane.org>
2012-04-21 17:22                                                                                                                                         ` [linux-pm] " Alan Stern
2012-04-21  8:37                                                                                                                                     ` Andrey Rahmatullin
     [not found]                                                                                                                                       ` <20120421083751.GA4570-hAV9HEAGFNe6YibBOCjzsw@public.gmane.org>
2012-04-21 17:26                                                                                                                                         ` [linux-pm] " Alan Stern
2012-04-21 18:50                                                                                                                                         ` Steven Rostedt
     [not found]                                                                                                                                           ` <1335034218.28106.91.camel-f9ZlEuEWxVcI6MkJdU+c8EEOCMrvLtNR@public.gmane.org>
2012-04-21 21:51                                                                                                                                             ` Andrey Rahmatullin
2012-05-26  2:01                                                                                                                             ` Alan Stern
2012-05-26  4:03                                                                                                                               ` Steven Rostedt
2012-05-26 20:27                                                                                                                                 ` Rafael J. Wysocki
2012-05-26 21:16                                                                                                                                   ` [RFT] PCI changes related to wakeup (was: Re: ehci_hcd related S3 lockup on ASUS laptops, again) Rafael J. Wysocki
2012-05-26 21:19                                                                                                                                     ` [RFT][PATCH 1/4] ACPI / PM: Make acpi_pm_device_sleep_state() follow the specification Rafael J. Wysocki
2012-05-26 21:20                                                                                                                                     ` [RFT][PATCH 2/4] PCI / PM: Make platform choose target low-power states of more devices Rafael J. Wysocki
2012-05-26 21:21                                                                                                                                     ` [RFT][PATCH 3/4] ACPI / PM: Shorten variable name in acpi_pm_device_sleep_state() Rafael J. Wysocki
2012-05-26 21:21                                                                                                                                     ` [RFT][PATCH 4/4] ACPI / PM: Fix interactions between _SxD and _SxW Rafael J. Wysocki
2012-05-26 21:47                                                                                                                                     ` [RFT] PCI changes related to wakeup (was: Re: ehci_hcd related S3 lockup on ASUS laptops, again) Andrey Rahmatullin
2012-05-26 22:06                                                                                                                                       ` [RFT] PCI changes related to wakeup (was: Re: [linux-pm] " Rafael J. Wysocki
2012-05-26 22:36                                                                                                                                         ` [RFT] PCI changes related to wakeup (was: " Andrey Rahmatullin
2012-05-26 22:40                                                                                                                                           ` [RFT] PCI changes related to wakeup (was: Re: [linux-pm] " Alan Stern
2012-05-26 22:59                                                                                                                                             ` [RFT] PCI changes related to wakeup (was: " Rafael J. Wysocki
2012-05-29 14:23                                                                                                                                               ` [RFT] PCI changes related to wakeup (was: Re: [linux-pm] " Alan Stern
2012-05-29 17:29                                                                                                                                                 ` Rafael J. Wysocki
2012-05-29 18:50                                                                                                                                                   ` Alan Stern
2012-05-29 19:16                                                                                                                                                     ` Rafael J. Wysocki
2012-05-31 21:07                                                                                                                                                       ` Alan Stern
2012-05-31 21:29                                                                                                                                                         ` Rafael J. Wysocki
2012-06-01 15:13                                                                                                                                                           ` Alan Stern
2012-06-01 15:50                                                                                                                                                             ` Steven Rostedt
2012-06-01 15:59                                                                                                                                                               ` [RFT] PCI changes related to wakeup (was: " Alan Stern
2012-06-01 17:01                                                                                                                                                                 ` [RFT] PCI changes related to wakeup (was: Re: [linux-pm] " Steven Rostedt
2012-06-01 17:17                                                                                                                                                                   ` [RFT] PCI changes related to wakeup (was: " Alan Stern
2012-06-01 17:23                                                                                                                                                                     ` [RFT] PCI changes related to wakeup (was: Re: [linux-pm] " Steven Rostedt
2012-06-01 16:01                                                                                                                                                               ` [RFT] PCI changes related to wakeup (was: " Andrey Rahmatullin
2012-06-01 16:33                                                                                                                                                                 ` Alan Stern
2012-05-31 22:02                                                                                                                                                         ` [RFT] PCI changes related to wakeup (was: Re: [linux-pm] " Dâniel Fraga
2012-06-01 14:55                                                                                                                                                           ` Alan Stern
2012-05-31 22:25                                                                                                                                                         ` Andrey Rahmatullin
2012-06-13  9:22                                                                                                                                                         ` Rafael J. Wysocki
2012-06-13 14:21                                                                                                                                                           ` [RFT] PCI changes related to wakeup (was: " Alan Stern
2012-06-13 15:20                                                                                                                                                           ` [PATCH] PCI: add NO_D3_DURING_SLEEP flag and revert 151b61284776be2 Alan Stern
     [not found]                                                                                                                                                             ` <Pine.LNX.4.44L0.1206131117260.1401-100000-IYeN2dnnYyZXsRXLowluHWD2FQJk+8+b@public.gmane.org>
2012-06-13 15:27                                                                                                                                                               ` Greg KH
2012-06-13 20:04                                                                                                                                                                 ` Rafael J. Wysocki
2012-06-13 20:03                                                                                                                                                                   ` Greg KH
     [not found]                                                                                                                                                                     ` <20120613200310.GA11110-U8xfFu+wG4EAvxtiuMwx3w@public.gmane.org>
2012-06-13 20:15                                                                                                                                                                       ` Steven Rostedt
     [not found]                                                                                                                                                                         ` <1339618548.13377.162.camel-f9ZlEuEWxVcI6MkJdU+c8EEOCMrvLtNR@public.gmane.org>
2012-06-13 20:17                                                                                                                                                                           ` Steven Rostedt
2012-06-23 21:20                                                                                                                                                               ` Pavel Pisa
     [not found]                                                                                                                                                                 ` <201206232320.15186.pisa-/N2ztlQkxE7Ub/6JBqosbQ@public.gmane.org>
2012-06-24  1:52                                                                                                                                                                   ` Alan Stern
     [not found]                                                                                                                                                                     ` <Pine.LNX.4.44L0.1206232147420.4446-100000-pYrvlCTfrz9XsRXLowluHWD2FQJk+8+b@public.gmane.org>
2012-06-24  7:00                                                                                                                                                                       ` Pavel Pisa
2012-05-27 16:41                                                                                                                                           ` [RFT] PCI changes related to wakeup (was: Re: [linux-pm] ehci_hcd related S3 lockup on ASUS laptops, again) Alan Stern
2012-05-27 21:17                                                                                                                                             ` Andrey Rahmatullin
2012-05-28 20:13                                                                                                                                               ` [RFT] PCI changes related to wakeup (was: " Rafael J. Wysocki
2012-05-29  7:48                                                                                                                                                 ` Andrey Rahmatullin
2012-05-29 17:30                                                                                                                                                   ` [RFT] PCI changes related to wakeup (was: Re: [linux-pm] " Rafael J. Wysocki
2012-05-29 22:39                                                                                                                                                 ` [RFT] PCI changes related to wakeup (was: " Steven Rostedt
2012-05-26  8:51                                                                                                                               ` ehci_hcd related S3 lockup on ASUS laptops, again Andrey Rahmatullin
2012-05-26 20:28                                                                                                                                 ` Rafael J. Wysocki
2012-04-18 21:10                                                                                                           ` Andrey Rahmatullin
2012-04-18 15:39                                                                                                 ` [linux-pm] " Steven Rostedt
2012-04-12 18:10                             ` Andrey Rahmatullin
2012-04-12 18:17                               ` Alan Stern
2012-04-12 18:21                                 ` Andrey Rahmatullin
2012-04-11 20:52             ` Andrey Rahmatullin
     [not found]               ` <20120411205204.GB3677-hAV9HEAGFNe6YibBOCjzsw@public.gmane.org>
2012-04-11 21:15                 ` [linux-pm] " Steven Rostedt
2012-04-23 16:29 Alan Stern
2012-04-23 18:30 ` Steven Rostedt

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.