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 <st...@rowland.harvard.edu>
> 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, email to debian-kernel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/pine.lnx.4.44l0.1206251025280.1770-100...@iolanthe.rowland.org
