USB D3 vs system S3
Len Brown
reviewerFYI,
I think we may have an issue here where the entire Linux suspend order is being proposed to change, when in fact the underlying issue may really be that USB is in D3 on S3 for this box when it is not supposed to be deeper below D1.
http://bugzilla.kernel.org/show_bug.cgi?id=9528
-Len
-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
_______________________________________________
[email protected]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Quoted 7 lines · Len Brown
FYI,
I think we may have an issue here where the entire Linux suspend order is being proposed to change, when in fact the underlying issue may really be that USB is in D3 on S3 for this box when it is not supposed to be deeper below D1.
Bug #9528 is not the only test case, though.
Please have a look at this thread:
http://marc.info/?t=119945995300002&r=1&w=2
Thanks,
Rafael
Quoted 8 lines · Len Brown
FYI,
I think we may have an issue here where the entire Linux suspend order is being proposed to change, when in fact the underlying issue may really be that USB is in D3 on S3 for this box when it is not supposed to be deeper below D1.
I still run my system with those patches to hook up PCI and USB wakeup mechanisms to the ACPI tables. ISTR that they got pulled at some point because they caused some system to wake up immediately instead of suspending ... sound familiar?
If that immediate-wake problem is now otherwise resolved, maybe it's time to revisit the merge of those patches. (From *LAST* January I think, in at least one otherwise-mergeable incarnation ...)
In the absense of those patches, nothing is hooking up USB to the relevant ACPI tables.
Want I should repost my latest version of those patches? They apply cleanly against RC7.
- Dave
Quoted 7 lines · On Tuesday 08 January 2008 20:47:00 Len Brown wrote:
FYI,
I think we may have an issue here where the entire Linux suspend order is being proposed to change, when in fact the underlying issue may really be that USB is in D3 on S3 for this box when it is not supposed to be deeper below D1.
I respectfully disagree. The USB device that exhibits this behaviour (USB2, the device that gets bound to ehci-hcd) is not the offender - the system will suspend and resume just fine even after Linux has put it into D3.
USB0 (the device that gets bound to ohci-hcd), does not have this requirement that it can be only put into D1 when going to S3 - the DSDT here says it's just fine to put this device into D3 when we advertise XP compatibility.
As I pointed out in the bug:
1) The ACPI suspend ordering is still wrong for suspend on ACPI 1.0 systems
2) Based on poking around in Vista, it may also be required to disable autosuspend for OHCI on CK804 (nForce 4), since Vista here apparently does not enable USB autosuspend on the USB hubs on this board (yet enabling autosuspend is supposedly the default Vista behaviour, and I've certainly never touched the USB settings in Vista).
Given we have two different BIOS's from different manufacturers for the same chipset, that both have a similar SMI trap, and are both breaking here, I wonder if this is a known problem with the reference nVidia BIOS; so Windows will not put USB devices into D3 early on this chipset, to ensure that USB0 is not in a low power state before _PTS() is called (unfortunately, on point 2, I don't have enough to back it up either way, besides my own observations here).
-Carlos
Signature · 13 lines
E-Mail: [email protected] Web: strangeworlds.co.uk GPG Key ID: 0x23EE722D ------------------------------------------------------------------------- Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace _______________________________________________ [email protected] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Quoted 6 lines · On Wednesday 09 January 2008 00:09:21 Carlos Corbacho wrote:
2) Based on poking around in Vista, it may also be required to disable autosuspend for OHCI on CK804 (nForce 4), since Vista here apparently does not enable USB autosuspend on the USB hubs on this board (yet enabling autosuspend is supposedly the default Vista behaviour, and I've certainly never touched the USB settings in Vista).
Quoted 7 lines
Given we have two different BIOS's from different manufacturers for the same chipset, that both have a similar SMI trap, and are both breaking here, I wonder if this is a known problem with the reference nVidia BIOS; so Windows will not put USB devices into D3 early on this chipset, to ensure that USB0 is not in a low power state before
_PTS()is called (unfortunately, on point 2, I don't have enough to back it up either way, besides my own observations here).
I've had confirmation from another nForce 4 box that Vista also disables autosuspend/ selective suspend on the root hubs there, so I'm pretty confident in saying now that this will also be needed in Linux (definitely for OHCI. I don't think we need to stop autosuspend on EHCI, even though Windows does appear to disable it for that as well), to avoid inadvertently triggering the suspend-to-RAM hang on these broken BIOSs.
(Testing also shows that putting the OHCI controller into D2 is no good either - having it in any state other than D1 before we call the ACPI _PTS() method will reliably hang the box on suspend).
What's the best way to go about doing this? I've been glancing over the OHCI code and I can't see how to easily do this (unless 'broken_suspend' is the correct option here?)
-Carlos
Signature · 3 lines
E-Mail: [email protected] Web: strangeworlds.co.uk GPG Key ID: 0x23EE722D
Quoted 7 lines · Carlos Corbacho
I've had confirmation from another nForce 4 box that Vista also disables autosuspend/ selective suspend on the root hubs there, so I'm pretty confident in saying now that this will also be needed in Linux (definitely for OHCI. I don't think we need to stop autosuspend on EHCI, even though Windows does appear to disable it for that as well), to avoid inadvertently triggering the suspend-to-RAM hang on these broken BIOSs.
Quoted 7 lines
(Testing also shows that putting the OHCI controller into D2 is no good either - having it in any state other than D1 before we call the ACPI
_PTS()method will reliably hang the box on suspend).What's the best way to go about doing this? I've been glancing over the OHCI code and I can't see how to easily do this (unless '
broken_suspend' is the correct option here?)
Currently there's no need to change anything.
The USB autosuspend code affects only the controller's USB interface -- it doesn't touch the PCI side. An autosuspended controller will remain in D0. Until somebody tries writing autosuspend code for PCI devices...
Alan Stern
Quoted 1 line · On Wednesday 09 January 2008 16:07:04 Alan Stern wrote:
Currently there's no need to change anything.
Ok.
Quoted 4 lines
The USB autosuspend code affects only the controller's USB interface -- it doesn't touch the PCI side. An autosuspended controller will remain in D0. Until somebody tries writing autosuspend code for PCI devices...
Is this likely to happen?
-Carlos
Signature · 3 lines
E-Mail: [email protected] Web: strangeworlds.co.uk GPG Key ID: 0x23EE722D
Quoted 11 lines · Carlos Corbacho
Quoted 1 line · On Wednesday 09 January 2008 16:07:04 Alan Stern wrote:
Currently there's no need to change anything.
Ok.
Quoted 4 lines
The USB autosuspend code affects only the controller's USB interface -- it doesn't touch the PCI side. An autosuspended controller will remain in D0. Until somebody tries writing autosuspend code for PCI devices...
Is this likely to happen?
I don't know of anybody working on it. A minimal prerequisite is that PCI runtime wakeup processing needs to work right -- which it doesn't. See
http://bugzilla.kernel.org/show_bug.cgi?id=6892
Alan Stern
Quoted 6 lines · Alan Stern
Quoted 6 lines
Quoted 5 lines
The USB autosuspend code affects only the controller's USB interface -- it doesn't touch the PCI side. An autosuspended controller will remain in D0. Until somebody tries writing autosuspend code for PCI devices...
Quoted 7 lines
Quoted 1 line
Is this likely to happen?
I don't know of anybody working on it. A minimal prerequisite is that PCI runtime wakeup processing needs to work right -- which it doesn't. See
And while most of the non-PCI USB host platforms to which I have access don't have that type of issue, their hardware isn't actually set up to offer an analogue of runtime PCI_D3 (for example) power states.
In more detail: they generally have some clocks that could be disabled, but for various reasons they need to be left running. Disabling those clocks prevents wakeup from working ... yes, a multi-MHz clock just to detect the D+ (or D-) pullup as it kicks in. Systems using an external PHY will sometimes offer an alternative, when the PHY can issue those wakeup IRQs by itself, but that seems oddly uncommon.
- Dave
-
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html