* Re: [linux-pm] ehci_hcd related S3 lockup on ASUS laptops, again
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
In-Reply-To: <Pine.LNX.4.44L0.1204131008010.1185-100000-IYeN2dnnYyZXsRXLowluHWD2FQJk+8+b@public.gmane.org>
[-- 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
* Re: [linux-pm] ehci_hcd related S3 lockup on ASUS laptops, again
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
In-Reply-To: <Pine.LNX.4.44L0.1204122103230.10558-100000-pYrvlCTfrz9XsRXLowluHWD2FQJk+8+b@public.gmane.org>
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
* "i8042: Can't reactivate AUX port" after s2ram on 3.4-rc2
From: Mikko Vinni @ 2012-04-13 9:52 UTC (permalink / raw)
To: linux-pm@lists.linux-foundation.org, linux-input@vger.kernel.org,
linux-kernel@vger.kernel.org
Cc: Dmitry Torokhov, Allen Kay, Jean Guyader, Jesse Barnes
Bug report:
https://bugzilla.kernel.org/show_bug.cgi?id=43099
Briefly:
After s2ram the touchpad on a HP dv5 laptop doesn't work anymore.
dmesg contains this about the touchpad
Apr 11 18:00:05 koni kernel: i8042: Can't write CTR while closing AUX port
Apr 11 18:00:08 koni kernel: i8042: Can't reactivate AUX port
Full log in bugzilla with PCI and i8042 debug turned on.
Bisected to:
commit 26f41062f28de65e11d3cf353e52d0be73442be1
Author: Kay, Allen M <allen.m.kay@intel.com>
Date: Thu Jan 26 10:25:53 2012 -0800
PCI: check for pci bar restore completion and retry
On some OEM systems, pci_restore_state() is called while FLR has not yet
completed. As a result, PCI BAR register restore is not successful. This fix
reads back the restored value and compares it with saved value and re-tries 10
times before giving up.
I will try to update the BIOS on this laptop next week, hoping that it might
fix some of the s2ram issues, but other than that, maybe somebody has an idea?
Thanks,
Mikko
^ permalink raw reply
* Re: [linux-pm] ehci_hcd related S3 lockup on ASUS laptops, again
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
In-Reply-To: <1334262826.23924.351.camel-f9ZlEuEWxVcI6MkJdU+c8EEOCMrvLtNR@public.gmane.org>
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
* Re: ehci_hcd related S3 lockup on ASUS laptops, again
From: Alan Stern @ 2012-04-13 1:09 UTC (permalink / raw)
To: Andrey Rahmatullin; +Cc: jrnieder, Greg KH, USB list, Steven Rostedt, linux-pm
In-Reply-To: <20120412203042.GI12852@belkar.wrar.name>
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
* Re: ehci_hcd related S3 lockup on ASUS laptops, again
From: Alan Stern @ 2012-04-13 1:03 UTC (permalink / raw)
To: Andrey Rahmatullin; +Cc: jrnieder, Greg KH, USB list, Steven Rostedt, linux-pm
In-Reply-To: <20120412202132.GH12852@belkar.wrar.name>
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
* Re: [linux-pm] ehci_hcd related S3 lockup on ASUS laptops, again
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
In-Reply-To: <20120412202132.GH12852-hAV9HEAGFNe6YibBOCjzsw@public.gmane.org>
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
* Re: ehci_hcd related S3 lockup on ASUS laptops, again
From: Andrey Rahmatullin @ 2012-04-12 20:30 UTC (permalink / raw)
To: Alan Stern; +Cc: jrnieder, Greg KH, USB list, Steven Rostedt, linux-pm
In-Reply-To: <Pine.LNX.4.44L0.1204121554320.1496-100000@iolanthe.rowland.org>
[-- 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
* Re: ehci_hcd related S3 lockup on ASUS laptops, again
From: Andrey Rahmatullin @ 2012-04-12 20:21 UTC (permalink / raw)
To: Alan Stern; +Cc: jrnieder, Greg KH, USB list, Steven Rostedt, linux-pm
In-Reply-To: <Pine.LNX.4.44L0.1204121607520.1496-100000@iolanthe.rowland.org>
[-- 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
* Re: ehci_hcd related S3 lockup on ASUS laptops, again
From: Alan Stern @ 2012-04-12 20:09 UTC (permalink / raw)
To: Steven Rostedt; +Cc: jrnieder, Greg KH, USB list, Andrey Rahmatullin, linux-pm
In-Reply-To: <Pine.LNX.4.44L0.1204121554320.1496-100000@iolanthe.rowland.org>
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
* Re: ehci_hcd related S3 lockup on ASUS laptops, again
From: Alan Stern @ 2012-04-12 20:02 UTC (permalink / raw)
To: Steven Rostedt; +Cc: jrnieder, Greg KH, USB list, Andrey Rahmatullin, linux-pm
In-Reply-To: <1334259347.23924.345.camel@gandalf.stny.rr.com>
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
* Re: [linux-pm] ehci_hcd related S3 lockup on ASUS laptops, again
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
In-Reply-To: <Pine.LNX.4.44L0.1204121504550.1496-100000-IYeN2dnnYyZXsRXLowluHWD2FQJk+8+b@public.gmane.org>
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
* Re: [linux-pm] ehci_hcd related S3 lockup on ASUS laptops, again
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
In-Reply-To: <Pine.LNX.4.44L0.1204121504550.1496-100000-IYeN2dnnYyZXsRXLowluHWD2FQJk+8+b@public.gmane.org>
[-- 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
* Re: ehci_hcd related S3 lockup on ASUS laptops, again
From: Alan Stern @ 2012-04-12 19:11 UTC (permalink / raw)
To: Steven Rostedt; +Cc: jrnieder, Greg KH, USB list, Andrey Rahmatullin, linux-pm
In-Reply-To: <1334255150.23924.342.camel@gandalf.stny.rr.com>
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
* Re: ehci_hcd related S3 lockup on ASUS laptops, again
From: Steven Rostedt @ 2012-04-12 18:25 UTC (permalink / raw)
To: Alan Stern; +Cc: jrnieder, Greg KH, USB list, Andrey Rahmatullin, linux-pm
In-Reply-To: <1334254672.23924.341.camel@gandalf.stny.rr.com>
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
* Re: ehci_hcd related S3 lockup on ASUS laptops, again
From: Andrey Rahmatullin @ 2012-04-12 18:21 UTC (permalink / raw)
To: Alan Stern; +Cc: jrnieder, Greg KH, linux-pm, USB list, Steven Rostedt
In-Reply-To: <Pine.LNX.4.44L0.1204121416050.1496-100000@iolanthe.rowland.org>
[-- 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
* Re: ehci_hcd related S3 lockup on ASUS laptops, again
From: Steven Rostedt @ 2012-04-12 18:17 UTC (permalink / raw)
To: Alan Stern; +Cc: jrnieder, Greg KH, USB list, Andrey Rahmatullin, linux-pm
In-Reply-To: <Pine.LNX.4.44L0.1204121337380.1496-100000@iolanthe.rowland.org>
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
* Re: ehci_hcd related S3 lockup on ASUS laptops, again
From: Alan Stern @ 2012-04-12 18:17 UTC (permalink / raw)
To: Andrey Rahmatullin; +Cc: jrnieder, Greg KH, linux-pm, USB list, Steven Rostedt
In-Reply-To: <20120412181031.GE12852@belkar.wrar.name>
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
* Re: ehci_hcd related S3 lockup on ASUS laptops, again
From: Andrey Rahmatullin @ 2012-04-12 18:10 UTC (permalink / raw)
To: Alan Stern; +Cc: jrnieder, Greg KH, linux-pm, USB list, Steven Rostedt
In-Reply-To: <Pine.LNX.4.44L0.1204121017460.1496-100000@iolanthe.rowland.org>
[-- 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
* Re: ehci_hcd related S3 lockup on ASUS laptops, again
From: Alan Stern @ 2012-04-12 17:48 UTC (permalink / raw)
To: Steven Rostedt; +Cc: jrnieder, Greg KH, USB list, Andrey Rahmatullin, linux-pm
In-Reply-To: <1334250896.23924.340.camel@gandalf.stny.rr.com>
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
* Re: ehci_hcd related S3 lockup on ASUS laptops, again
From: Andrey Rahmatullin @ 2012-04-12 17:18 UTC (permalink / raw)
To: Steven Rostedt; +Cc: jrnieder, Greg KH, USB list, linux-pm
In-Reply-To: <1334250896.23924.340.camel@gandalf.stny.rr.com>
[-- 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
* Re: ehci_hcd related S3 lockup on ASUS laptops, again
From: Steven Rostedt @ 2012-04-12 17:14 UTC (permalink / raw)
To: Alan Stern; +Cc: jrnieder, Greg KH, USB list, Andrey Rahmatullin, linux-pm
In-Reply-To: <Pine.LNX.4.44L0.1204121247430.1496-100000@iolanthe.rowland.org>
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
* Re: ehci_hcd related S3 lockup on ASUS laptops, again
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
In-Reply-To: <1334248402.23924.337.camel@gandalf.stny.rr.com>
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
* Re: ehci_hcd related S3 lockup on ASUS laptops, again
From: Andrey Rahmatullin @ 2012-04-12 16:58 UTC (permalink / raw)
To: Steven Rostedt; +Cc: jrnieder, Greg KH, linux-pm, USB list
In-Reply-To: <1334249541.23924.338.camel@gandalf.stny.rr.com>
[-- 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
* Re: ehci_hcd related S3 lockup on ASUS laptops, again
From: Steven Rostedt @ 2012-04-12 16:52 UTC (permalink / raw)
To: Andrey Rahmatullin; +Cc: jrnieder, Greg KH, linux-pm, USB list
In-Reply-To: <20120412164903.GB12852@belkar.wrar.name>
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
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox