Re: xHCI immediately wakes up Asus P8Z68-V LX in S5
On Mon, Jan 21, 2013 at 09:33:15AM -0800, Sarah Sharp wrote: On Mon, Jan 21, 2013 at 12:00:14AM +, Ben Hutchings wrote: I finally got enough email out of the way to get back to this: On Wed, 2012-12-19 at 16:23 -0800, Sarah Sharp wrote: On Wed, Dec 19, 2012 at 03:15:09AM +, Ben Hutchings wrote: [...] The symptoms are pretty bizarre, and I honestly don't know what could be the root cause. I would suggest you try the BIOS update and see if it fixes the issue. Now that I've worked out how to do the update (Asus's Windows utilities fail to install, but there turns out to be a flash update program inside the setup program) it does seem to be fixed in the current BIOS version (version 4003 dated 2012-08-22). I can't tell for sure whether that's because of a code change or a configuration change, because *of course* the flash update program has to erase the configuration sector too. :-/ Ok, thanks for letting me know the BIOS update fixed it. Thanks for taking the time to look at this. Ben. -- Ben Hutchings We get into the habit of living before acquiring the habit of thinking. - Albert Camus -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: xHCI immediately wakes up Asus P8Z68-V LX in S5
I finally got enough email out of the way to get back to this: On Wed, 2012-12-19 at 16:23 -0800, Sarah Sharp wrote: On Wed, Dec 19, 2012 at 03:15:09AM +, Ben Hutchings wrote: [...] I set sysctl kernel.printk=8 and recorded the screen during shutdown, from which I transcribe the following: pcieport :00:1c.6: wake-up capability enabled by ACPI xhci_hcd :04:00.0: // Halt the HC xhci_hcd :04:00.0: xhci_shutdown completed - status = 1 Ok, then the xHCI host controller reported that it did halt successfully. It should not be sending any interrupts or PMEs when it's halted. [...] So, as far as I can see this problem is specific to: - Sleep in S5 - Driver loaded - Run-time power management disabled - No devices or super-speed device plugged in Any of these avoid the problem: - Sleep in S3 or S4 - Driver unloaded - Run-time power management enabled - Low-speed device plugged in Is it any low speed device, or just a mouse? Does a connected keyboard or a USB serial device make the system stay shutdown? A keyboard has the same effect. I don't think I have any USB serial devices to test with. The symptoms are pretty bizarre, and I honestly don't know what could be the root cause. I would suggest you try the BIOS update and see if it fixes the issue. Now that I've worked out how to do the update (Asus's Windows utilities fail to install, but there turns out to be a flash update program inside the setup program) it does seem to be fixed in the current BIOS version (version 4003 dated 2012-08-22). I can't tell for sure whether that's because of a code change or a configuration change, because *of course* the flash update program has to erase the configuration sector too. :-/ Ben. -- Ben Hutchings Never attribute to conspiracy what can adequately be explained by stupidity. signature.asc Description: This is a digitally signed message part
Re: xHCI immediately wakes up Asus P8Z68-V LX in S5
δΊ 2012/12/16 8:37, Ben Hutchings ει: 'echo disabled /sys/bus/pci/devices/:04:00.0/power/wakeup' does *not* work around this. This is strange. Normally, If disable the xhci's wakeup, the xhci's gpe would not be opened and so xhci couldn't wakeup the system. Can you attach the output of acpidump? -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: xHCI immediately wakes up Asus P8Z68-V LX in S5
On Wed, Dec 19, 2012 at 03:15:09AM +, Ben Hutchings wrote: On Mon, 2012-12-17 at 13:28 -0800, Sarah Sharp wrote: On Sun, Dec 16, 2012 at 12:37:00AM +, Ben Hutchings wrote: Since Linux 3.2.16, my desktop with an Asus P8Z68-V LX motherboard always wakes up a few seconds after I shutdown. I then have to switch it off a second time. This still occurs in Linux 3.6.9 (haven't tried 3.7 yet). Hmm. So if we enable PCI bus suspend for this xHCI host controller, then it will immediately wakeup the system on shutdown? So it seems. What happens when runtime PM is enabled for the host (and any USB devices attached to it)? Does the host controller stay in D3hot, or does it immediately pop back into D0? It stays in D3hot. Also, this fixes the problem. Can you turn on CONFIG_USB_XHCI_HCD_DEBUGGING and CONFIG_USB_DEBUG for your kernel and send me the dmesg? I'm wondering if the xHCI host controller is either failing to complete the host suspend command, or perhaps failing to be halted. This happens in S5 (soft-off), so there is no way to read dmesg afterwards! I just checked S3 (mem) and S4 (disk), and the system stays properly suspended in those states. I set sysctl kernel.printk=8 and recorded the screen during shutdown, from which I transcribe the following: pcieport :00:1c.6: wake-up capability enabled by ACPI xhci_hcd :04:00.0: // Halt the HC xhci_hcd :04:00.0: xhci_shutdown completed - status = 1 Ok, then the xHCI host controller reported that it did halt successfully. It should not be sending any interrupts or PMEs when it's halted. ACPI: Preparing to enter system sleep state S5 Disabling non-boot CPUs ... Power down. acpi_power_off called The first line is related to wake-on-LAN as the specified device is the downstream port connected to the network controller. [...] No devices are connected to the xHCI. 'echo disabled /sys/bus/pci/devices/:04:00.0/power/wakeup' does *not* work around this. Does unloading the xHCI driver before shutdown fix this? [...] Yes. Also, I tried plugging devices into the USB 3.0-capable ports. Plugging in a mouse fixes this. Plugging in a super-speed SATA enclosure doesn't. So, as far as I can see this problem is specific to: - Sleep in S5 - Driver loaded - Run-time power management disabled - No devices or super-speed device plugged in Any of these avoid the problem: - Sleep in S3 or S4 - Driver unloaded - Run-time power management enabled - Low-speed device plugged in Is it any low speed device, or just a mouse? Does a connected keyboard or a USB serial device make the system stay shutdown? The symptoms are pretty bizarre, and I honestly don't know what could be the root cause. I would suggest you try the BIOS update and see if it fixes the issue. Sarah Sharp -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: xHCI immediately wakes up Asus P8Z68-V LX in S5
On Mon, 2012-12-17 at 13:28 -0800, Sarah Sharp wrote: On Sun, Dec 16, 2012 at 12:37:00AM +, Ben Hutchings wrote: Since Linux 3.2.16, my desktop with an Asus P8Z68-V LX motherboard always wakes up a few seconds after I shutdown. I then have to switch it off a second time. This still occurs in Linux 3.6.9 (haven't tried 3.7 yet). I initially bisected this to: commit 13a307e1a4a10502d688ce058141bc503933214e Author: Lin Ming ming.m@intel.com Date: Mon Nov 28 09:46:02 2011 +0800 ACPICA: Fix to allow region arguments to reference other scopes commit 8931d9ea78848b073bf299594f148b83abde4a5e upstream. However, that seems to be a perfectly good bug fix (the error mentioned in the commit message did previously appear on this system). I therefore tried cherry-picking it onto earlier versions, and bisected to: commit 9777e3ce907d4cb5a513902a87ecd03b52499569 Author: Andiry Xu andiry...@amd.com Date: Thu Oct 14 07:23:03 2010 -0700 USB: xHCI: bus power management implementation Hmm. So if we enable PCI bus suspend for this xHCI host controller, then it will immediately wakeup the system on shutdown? So it seems. What happens when runtime PM is enabled for the host (and any USB devices attached to it)? Does the host controller stay in D3hot, or does it immediately pop back into D0? It stays in D3hot. Also, this fixes the problem. Can you turn on CONFIG_USB_XHCI_HCD_DEBUGGING and CONFIG_USB_DEBUG for your kernel and send me the dmesg? I'm wondering if the xHCI host controller is either failing to complete the host suspend command, or perhaps failing to be halted. This happens in S5 (soft-off), so there is no way to read dmesg afterwards! I just checked S3 (mem) and S4 (disk), and the system stays properly suspended in those states. I set sysctl kernel.printk=8 and recorded the screen during shutdown, from which I transcribe the following: pcieport :00:1c.6: wake-up capability enabled by ACPI xhci_hcd :04:00.0: // Halt the HC xhci_hcd :04:00.0: xhci_shutdown completed - status = 1 ACPI: Preparing to enter system sleep state S5 Disabling non-boot CPUs ... Power down. acpi_power_off called The first line is related to wake-on-LAN as the specified device is the downstream port connected to the network controller. [...] No devices are connected to the xHCI. 'echo disabled /sys/bus/pci/devices/:04:00.0/power/wakeup' does *not* work around this. Does unloading the xHCI driver before shutdown fix this? [...] Yes. Also, I tried plugging devices into the USB 3.0-capable ports. Plugging in a mouse fixes this. Plugging in a super-speed SATA enclosure doesn't. So, as far as I can see this problem is specific to: - Sleep in S5 - Driver loaded - Run-time power management disabled - No devices or super-speed device plugged in Any of these avoid the problem: - Sleep in S3 or S4 - Driver unloaded - Run-time power management enabled - Low-speed device plugged in Ben. -- Ben Hutchings Life is like a sewer: what you get out of it depends on what you put into it. signature.asc Description: This is a digitally signed message part
Re: xHCI immediately wakes up Asus P8Z68-V LX in S5
On Sun, Dec 16, 2012 at 12:37:00AM +, Ben Hutchings wrote: Since Linux 3.2.16, my desktop with an Asus P8Z68-V LX motherboard always wakes up a few seconds after I shutdown. I then have to switch it off a second time. This still occurs in Linux 3.6.9 (haven't tried 3.7 yet). I initially bisected this to: commit 13a307e1a4a10502d688ce058141bc503933214e Author: Lin Ming ming.m@intel.com Date: Mon Nov 28 09:46:02 2011 +0800 ACPICA: Fix to allow region arguments to reference other scopes commit 8931d9ea78848b073bf299594f148b83abde4a5e upstream. However, that seems to be a perfectly good bug fix (the error mentioned in the commit message did previously appear on this system). I therefore tried cherry-picking it onto earlier versions, and bisected to: commit 9777e3ce907d4cb5a513902a87ecd03b52499569 Author: Andiry Xu andiry...@amd.com Date: Thu Oct 14 07:23:03 2010 -0700 USB: xHCI: bus power management implementation Hmm. So if we enable PCI bus suspend for this xHCI host controller, then it will immediately wakeup the system on shutdown? What happens when runtime PM is enabled for the host (and any USB devices attached to it)? Does the host controller stay in D3hot, or does it immediately pop back into D0? Can you turn on CONFIG_USB_XHCI_HCD_DEBUGGING and CONFIG_USB_DEBUG for your kernel and send me the dmesg? I'm wondering if the xHCI host controller is either failing to complete the host suspend command, or perhaps failing to be halted. That is, this is the first commit for which cherry-picking commit 13a307e1a4a1 on top results in the problem. lspci -vvnn says: 04:00.0 USB Controller [0c03]: Device [1b21:1042] (prog-if 30) Subsystem: ASUSTeK Computer Inc. Device [1043:8488] Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast TAbort- TAbort- MAbort- SERR- PERR- INTx- Latency: 0, Cache Line Size: 64 bytes Interrupt: pin A routed to IRQ 17 Region 0: Memory at fe50 (64-bit, non-prefetchable) [size=32K] Capabilities: [50] MSI: Enable- Count=1/8 Maskable- 64bit+ Address: Data: Capabilities: [68] MSI-X: Enable+ Count=8 Masked- Vector table: BAR=0 offset=2000 PBA: BAR=0 offset=2080 Capabilities: [78] Power Management version 3 Flags: PMEClk- DSI- D1- D2- AuxCurrent=55mA PME(D0-,D1-,D2-,D3hot+,D3cold+) Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME- Capabilities: [80] Express (v2) Legacy Endpoint, MSI 00 DevCap: MaxPayload 512 bytes, PhantFunc 0, Latency L0s 64ns, L1 2us ExtTag- AttnBtn- AttnInd- PwrInd- RBE+ FLReset- DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported- RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop+ MaxPayload 128 bytes, MaxReadReq 512 bytes DevSta: CorrErr+ UncorrErr- FatalErr- UnsuppReq- AuxPwr- TransPend- LnkCap: Port #1, Speed 5GT/s, Width x1, ASPM L0s L1, Latency L0 unlimited, L1 unlimited ClockPM- Surprise- LLActRep- BwNot- LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- Retrain- CommClk+ ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt- LnkSta: Speed 5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt- DevCap2: Completion Timeout: Not Supported, TimeoutDis- DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis- LnkCtl2: Target Link Speed: 5GT/s, EnterCompliance- SpeedDis-, Selectable De-emphasis: -6dB Transmit Margin: Normal Operating Range, EnterModifiedCompliance- ComplianceSOS- Compliance De-emphasis: -6dB LnkSta2: Current De-emphasis Level: -6dB Capabilities: [100 v1] Virtual Channel Caps: LPEVC=0 RefClk=100ns PATEntryBits=1 Arb:Fixed- WRR32- WRR64- WRR128- Ctrl: ArbSelect=Fixed Status: InProgress- VC0:Caps: PATOffset=00 MaxTimeSlots=1 RejSnoopTrans- Arb:Fixed- WRR32- WRR64- WRR128- TWRR128- WRR256- Ctrl: Enable+ ID=0 ArbSelect=Fixed TC/VC=01 Status: NegoPending- InProgress- Kernel driver in use: xhci_hcd No devices are connected to the xHCI. 'echo disabled /sys/bus/pci/devices/:04:00.0/power/wakeup' does *not* work around this. Does unloading the xHCI driver before shutdown fix this? I can try updating the BIOS if you think this might help (the description of changes is very vague). Let's see what the dmesg shows before you update the BIOS. But in general, if it's an issue with ACPI wake
xHCI immediately wakes up Asus P8Z68-V LX in S5
Since Linux 3.2.16, my desktop with an Asus P8Z68-V LX motherboard always wakes up a few seconds after I shutdown. I then have to switch it off a second time. This still occurs in Linux 3.6.9 (haven't tried 3.7 yet). I initially bisected this to: commit 13a307e1a4a10502d688ce058141bc503933214e Author: Lin Ming ming.m@intel.com Date: Mon Nov 28 09:46:02 2011 +0800 ACPICA: Fix to allow region arguments to reference other scopes commit 8931d9ea78848b073bf299594f148b83abde4a5e upstream. However, that seems to be a perfectly good bug fix (the error mentioned in the commit message did previously appear on this system). I therefore tried cherry-picking it onto earlier versions, and bisected to: commit 9777e3ce907d4cb5a513902a87ecd03b52499569 Author: Andiry Xu andiry...@amd.com Date: Thu Oct 14 07:23:03 2010 -0700 USB: xHCI: bus power management implementation That is, this is the first commit for which cherry-picking commit 13a307e1a4a1 on top results in the problem. lspci -vvnn says: 04:00.0 USB Controller [0c03]: Device [1b21:1042] (prog-if 30) Subsystem: ASUSTeK Computer Inc. Device [1043:8488] Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast TAbort- TAbort- MAbort- SERR- PERR- INTx- Latency: 0, Cache Line Size: 64 bytes Interrupt: pin A routed to IRQ 17 Region 0: Memory at fe50 (64-bit, non-prefetchable) [size=32K] Capabilities: [50] MSI: Enable- Count=1/8 Maskable- 64bit+ Address: Data: Capabilities: [68] MSI-X: Enable+ Count=8 Masked- Vector table: BAR=0 offset=2000 PBA: BAR=0 offset=2080 Capabilities: [78] Power Management version 3 Flags: PMEClk- DSI- D1- D2- AuxCurrent=55mA PME(D0-,D1-,D2-,D3hot+,D3cold+) Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME- Capabilities: [80] Express (v2) Legacy Endpoint, MSI 00 DevCap: MaxPayload 512 bytes, PhantFunc 0, Latency L0s 64ns, L1 2us ExtTag- AttnBtn- AttnInd- PwrInd- RBE+ FLReset- DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported- RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop+ MaxPayload 128 bytes, MaxReadReq 512 bytes DevSta: CorrErr+ UncorrErr- FatalErr- UnsuppReq- AuxPwr- TransPend- LnkCap: Port #1, Speed 5GT/s, Width x1, ASPM L0s L1, Latency L0 unlimited, L1 unlimited ClockPM- Surprise- LLActRep- BwNot- LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- Retrain- CommClk+ ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt- LnkSta: Speed 5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt- DevCap2: Completion Timeout: Not Supported, TimeoutDis- DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis- LnkCtl2: Target Link Speed: 5GT/s, EnterCompliance- SpeedDis-, Selectable De-emphasis: -6dB Transmit Margin: Normal Operating Range, EnterModifiedCompliance- ComplianceSOS- Compliance De-emphasis: -6dB LnkSta2: Current De-emphasis Level: -6dB Capabilities: [100 v1] Virtual Channel Caps: LPEVC=0 RefClk=100ns PATEntryBits=1 Arb:Fixed- WRR32- WRR64- WRR128- Ctrl: ArbSelect=Fixed Status: InProgress- VC0:Caps: PATOffset=00 MaxTimeSlots=1 RejSnoopTrans- Arb:Fixed- WRR32- WRR64- WRR128- TWRR128- WRR256- Ctrl: Enable+ ID=0 ArbSelect=Fixed TC/VC=01 Status: NegoPending- InProgress- Kernel driver in use: xhci_hcd No devices are connected to the xHCI. 'echo disabled /sys/bus/pci/devices/:04:00.0/power/wakeup' does *not* work around this. I can try updating the BIOS if you think this might help (the description of changes is very vague). Ben. -- Ben Hutchings Theory and practice are closer in theory than in practice. - John Levine, moderator of comp.compilers signature.asc Description: This is a digitally signed message part
