* Re: [linux-pm] ehci_hcd related S3 lockup on ASUS laptops, again
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
In-Reply-To: <20120417185149.GO11484-hAV9HEAGFNe6YibBOCjzsw@public.gmane.org>
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
* Re: [linux-pm] ehci_hcd related S3 lockup on ASUS laptops, again
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
In-Reply-To: <Pine.LNX.4.44L0.1204171513230.1163-100000-IYeN2dnnYyZXsRXLowluHWD2FQJk+8+b@public.gmane.org>
[-- 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
* Using swsusp on embedded Linux
From: Alex Levin @ 2012-04-18 10:48 UTC (permalink / raw)
To: linux-pm@lists.linux-foundation.org
Hi,
I'm trying to use swsusp on an embedded Linux system (kernel - 2.6.32) and I encounter a the next problem:
I'm using our own driver for a block device for a swap partition (a partition on a non-volatile memory device e.g. NAND SD) and while mkswap and swapon acturally creates a swap partition on the device, the command echo disk > /sys/power/state gets stuck (cpu_idle() ).
/dev/cb0 is the swap partition.
I would appreciate if you could help me.
Thank you very much,
Alex.
Here if the log: (with logLevel=9 and CONFIG_PM_DEBUG)
~ # echo disk > /sys/power/state
[ 72.273000] device: 'vcs63': device_add
[ 72.274000] PM: Adding info for No Bus:vcs63
[ 72.275000] device: 'vcsa63': device_add
[ 72.275000] PM: Adding info for No Bus:vcsa63
[ 72.293000] PM: Basic memory bitmaps created
[ 72.298000] PM: Syncing filesystems ... done.
[ 72.308000] Freezing user space processes ... (elapsed 0.00 seconds) done.
[ 72.316000] Freezing remaining freezable tasks ... (elapsed 0.00 seconds) done.
[ 72.324000] PM: Preallocating image memory... done (allocated 6708 pages)
[ 72.386000] PM: Allocated 26832 kbytes in 0.05 seconds (536.64 MB/s)
[ 72.392000] platform ci13610-udc.0: preparing freeze
[ 72.398000] serial8250 serial8250: preparing freeze
[ 72.403000] gmac_drv_eth gmac_drv_eth.0: preparing freeze
[ 72.409000] cb cb.0: preparing freeze
[ 72.413000] cb cb.1: preparing freeze
[ 72.416000] platform rtevent.0: preparing freeze
[ 72.421000] platform rtevent.0: freeze
[ 72.425000] cb cb.1: freeze
[ 72.428000] cb cb.0: freeze
[ 72.431000] gmac_drv_eth gmac_drv_eth.0: freeze
[ 72.436000] serial8250 serial8250: freeze
[ 72.440000] platform ci13610-udc.0: freeze
[ 72.445000] platform rtevent.0: LATE freeze
[ 72.450000] cb cb.1: LATE freeze
[ 72.453000] cb cb.0: LATE freeze
[ 72.456000] gmac_drv_eth gmac_drv_eth.0: LATE freeze
[ 72.462000] serial8250 serial8250: LATE freeze
[ 72.466000] platform ci13610-udc.0: LATE freeze
[ 72.471000] Checking wake-up interrupts
[ 72.471000] Suspending System Devices
[ 72.471000] Suspending type 'clocksource':
[ 72.471000] clocksource0
[ 72.471000] Suspending type 'timekeeping':
[ 72.471000] timekeeping0
[ 72.471000] Suspending type 'cpu':
[ 72.471000] cpu0
[ 72.471000] PM: Creating hibernation image:
[ 72.471000] PM: Need to copy 6696 pages
[ 72.471000] PM: Normal pages needed: 6696 + 1024, available pages: 9683
[ 72.471000] PM: Hibernation image created (6696 pages copied)
[ 72.471000] Resuming System Devices
[ 72.471000] Resuming type 'cpu':
[ 72.471000] cpu0
[ 72.471000] Resuming type 'timekeeping':
[ 72.471000] timekeeping0
[ 72.471000] Resuming type 'clocksource':
[ 72.471000] clocksource0
[ 72.499000] platform ci13610-udc.0: EARLY thaw
[ 72.504000] serial8250 serial8250: EARLY thaw
[ 72.508000] gmac_drv_eth gmac_drv_eth.0: EARLY thaw
[ 72.513000] cb cb.0: EARLY thaw
[ 72.517000] cb cb.1: EARLY thaw
[ 72.520000] platform rtevent.0: EARLY thaw
[ 72.524000] platform ci13610-udc.0: thaw
[ 72.529000] serial8250 serial8250: thaw
[ 72.533000] gmac_drv_eth gmac_drv_eth.0: thaw
[ 72.538000] cb cb.0: thaw
[ 72.540000] cb cb.1: thaw
[ 72.543000] platform rtevent.0: thaw
[ 72.547000] platform rtevent.0: completing thaw
[ 72.552000] cb cb.1: completing thaw
[ 72.556000] cb cb.0: completing thaw
[ 72.559000] gmac_drv_eth gmac_drv_eth.0: completing thaw
[ 72.565000] serial8250 serial8250: completing thaw
[ 72.570000] platform ci13610-udc.0: completing thaw
[ 72.575000] PM: writing image.
[ 72.579000] PM: Free swap pages: 8190
Member of the CSR plc group of companies. CSR plc registered in England and Wales, registered number 4187346, registered office Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, United Kingdom
More information can be found at www.csr.com. Follow CSR on Twitter at http://twitter.com/CSR_PLC and read our blog at www.csr.com/blog
^ permalink raw reply
* Re: [linux-pm] ehci_hcd related S3 lockup on ASUS laptops, again
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
In-Reply-To: <20120417195218.GP11484-hAV9HEAGFNe6YibBOCjzsw@public.gmane.org>
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
* Re: [linux-pm] ehci_hcd related S3 lockup on ASUS laptops, again
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
In-Reply-To: <Pine.LNX.4.44L0.1204181048340.1548-100000-IYeN2dnnYyZXsRXLowluHWD2FQJk+8+b@public.gmane.org>
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
* Re: [linux-pm] ehci_hcd related S3 lockup on ASUS laptops, again
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
In-Reply-To: <Pine.LNX.4.44L0.1204181048340.1548-100000-IYeN2dnnYyZXsRXLowluHWD2FQJk+8+b@public.gmane.org>
[-- 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
* Re: [linux-pm] ehci_hcd related S3 lockup on ASUS laptops, again
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
In-Reply-To: <Pine.LNX.4.44L0.1204181048340.1548-100000-IYeN2dnnYyZXsRXLowluHWD2FQJk+8+b@public.gmane.org>
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
* Re: ehci_hcd related S3 lockup on ASUS laptops, again
From: Alan Stern @ 2012-04-18 16:41 UTC (permalink / raw)
To: Andrey Rahmatullin; +Cc: jrnieder, linux-pm, USB list, Steven Rostedt
In-Reply-To: <20120418152455.GT11484@belkar.wrar.name>
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
* Re: [linux-pm] ehci_hcd related S3 lockup on ASUS laptops, again
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
In-Reply-To: <Pine.LNX.4.44L0.1204181228380.1149-100000-IYeN2dnnYyZXsRXLowluHWD2FQJk+8+b@public.gmane.org>
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
* Re: ehci_hcd related S3 lockup on ASUS laptops, again
From: Andrey Rahmatullin @ 2012-04-18 17:10 UTC (permalink / raw)
To: Alan Stern; +Cc: jrnieder, linux-pm, USB list, Steven Rostedt
In-Reply-To: <Pine.LNX.4.44L0.1204181228380.1149-100000@iolanthe.rowland.org>
[-- 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
* Re: [linux-pm] ehci_hcd related S3 lockup on ASUS laptops, again
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
In-Reply-To: <1334768847.28106.45.camel-f9ZlEuEWxVcI6MkJdU+c8EEOCMrvLtNR@public.gmane.org>
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
* Re: [linux-pm] ehci_hcd related S3 lockup on ASUS laptops, again
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
In-Reply-To: <20120418171002.GU11484-hAV9HEAGFNe6YibBOCjzsw@public.gmane.org>
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
* Re: [linux-pm] ehci_hcd related S3 lockup on ASUS laptops, again
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
In-Reply-To: <Pine.LNX.4.44L0.1204181317550.1149-100000-IYeN2dnnYyZXsRXLowluHWD2FQJk+8+b@public.gmane.org>
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
* Re: [linux-pm] ehci_hcd related S3 lockup on ASUS laptops, again
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
In-Reply-To: <1334769847.28106.47.camel-f9ZlEuEWxVcI6MkJdU+c8EEOCMrvLtNR@public.gmane.org>
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
* Re: [linux-pm] ehci_hcd related S3 lockup on ASUS laptops, again
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
In-Reply-To: <20120418174610.GA10142-GFdadSzt00ze9xe1eoZjHA@public.gmane.org>
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
* Re: [linux-pm] ehci_hcd related S3 lockup on ASUS laptops, again
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
In-Reply-To: <1334769632.28106.46.camel-f9ZlEuEWxVcI6MkJdU+c8EEOCMrvLtNR@public.gmane.org>
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
* Re: [linux-pm] ehci_hcd related S3 lockup on ASUS laptops, again
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
In-Reply-To: <20120418174610.GA10142-GFdadSzt00ze9xe1eoZjHA@public.gmane.org>
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
* Re: [linux-pm] ehci_hcd related S3 lockup on ASUS laptops, again
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
In-Reply-To: <Pine.LNX.4.44L0.1204181616430.1149-100000-IYeN2dnnYyZXsRXLowluHWD2FQJk+8+b@public.gmane.org>
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
* Re: [linux-pm] ehci_hcd related S3 lockup on ASUS laptops, again
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
In-Reply-To: <Pine.LNX.4.44L0.1204181616430.1149-100000-IYeN2dnnYyZXsRXLowluHWD2FQJk+8+b@public.gmane.org>
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
* Re: ehci_hcd related S3 lockup on ASUS laptops, again
From: Andrey Rahmatullin @ 2012-04-18 21:10 UTC (permalink / raw)
To: Steven Rostedt; +Cc: jrnieder, linux-pm, USB list
In-Reply-To: <1334769632.28106.46.camel@gandalf.stny.rr.com>
[-- 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
* Re: ehci_hcd related S3 lockup on ASUS laptops, again
From: Andrey Rahmatullin @ 2012-04-18 21:23 UTC (permalink / raw)
To: Alan Stern; +Cc: jrnieder, linux-pm, USB list, Steven Rostedt
In-Reply-To: <Pine.LNX.4.44L0.1204181616430.1149-100000@iolanthe.rowland.org>
[-- 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
* Re: [linux-pm] ehci_hcd related S3 lockup on ASUS laptops, again
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
In-Reply-To: <1334782932.28106.52.camel-f9ZlEuEWxVcI6MkJdU+c8EEOCMrvLtNR@public.gmane.org>
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
* Re: [linux-pm] ehci_hcd related S3 lockup on ASUS laptops, again
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
In-Reply-To: <201204182304.29249.rjw-KKrjLPT3xs0@public.gmane.org>
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
* Re: [linux-pm] ehci_hcd related S3 lockup on ASUS laptops, again
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
In-Reply-To: <20120418212301.GW11484-hAV9HEAGFNe6YibBOCjzsw@public.gmane.org>
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
* Re: [linux-pm] ehci_hcd related S3 lockup on ASUS laptops, again
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
In-Reply-To: <Pine.LNX.4.44L0.1204181724570.1149-100000-IYeN2dnnYyZXsRXLowluHWD2FQJk+8+b@public.gmane.org>
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
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