On Sun, Dec 16, 2012 at 12:37:00AM +0000, 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.lin@xxxxxxxxx> > 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.xu@xxxxxxx> > 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 fe500000 (64-bit, non-prefetchable) [size=32K] > Capabilities: [50] MSI: Enable- Count=1/8 Maskable- 64bit+ > Address: 0000000000000000 Data: 0000 > Capabilities: [68] MSI-X: Enable+ Count=8 Masked- > Vector table: BAR=0 offset=00002000 > PBA: BAR=0 offset=00002080 > 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/0000: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 events, updating the BIOS might help. Sarah Sharp -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
