On Sun, 24 Jun 2012, Ben Hutchings wrote: > [The full log for this bug is at http://bugs.debian.org/677472] > > On Thu, 2012-06-14 at 09:28 -0700, Octavio Alvarez wrote: > > Under normal circumstances the system simply does not suspend. It appears > > to go all the way to suspension (screen off, disks off, etc.) but when it > > appears that it is going to go off, something prevents it. System doesn't > > hang, it just fails at the very last moment of suspension. > > > > I tried debugging using pm_test. I set it to "core" but suspend_stats > > doesn't catch anything: > > > > # cat /sys/kernel/debug/suspend_stats > > success: 12 > > fail: 0 > > failed_freeze: 0 > > failed_prepare: 0 > > failed_suspend: 0 > > failed_suspend_noirq: 0 > > failed_resume: 0 > > failed_resume_noirq: 0 > > failures: > > last_failed_dev: > > > > last_failed_errno: 0 > > 0 > > last_failed_step: > > > > Even with pm_test set to "none", suspend_stats increases the "success" > > value. > > This indicates that the system is woken up immediately after it > suspends. From the kernel point of view (but not a practical point of > view!) this is different from failing to suspend. > > > As I said earlier, removing ohci_hcd lets suspend work again. > > So the USB controller (OHCI) has for some reason started waking up the > system. As I suspected, this system has an Nvidia chipset: > > 00:0b.0 USB controller [0c03]: NVIDIA Corporation MCP51 USB Controller [10de:026d] (rev a2) (prog-if 10 [OHCI]) > Subsystem: ASUSTeK Computer Inc. A8N-VM CSM Mainboard [1043:81bc] > 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 (750ns min, 250ns max) > Interrupt: pin A routed to IRQ 23 > Region 0: Memory at d5006000 (32-bit, non-prefetchable) [size=4K] > Capabilities: <access denied> > Kernel driver in use: ohci_hcd > > The Nvidia implementation of OHCI is unusual in some ways and has > prompted a number of changes to power management. The last one was: > > commit c61875977458637226ab093a35d200f2d5789787 > Author: Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> > Date: Thu Nov 17 16:41:45 2011 -0500 > > OHCI: final fix for NVIDIA problems (I hope) Actually that wasn't exactly a power management change, although it was vaguely related. It really was more concerned with initialization and shutdown. > But it looks like we have to disappoint Alan again. Well, this sounds like a different problem. What happens if Octavio disables wakeup for that controller before suspending? echo disabled >/sys/bus/pci/devices/0000:00:0b.0/power/wakeup Alan Stern -- 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
