Bug#677472: [3.1->3.2 regression] Immediate wake on suspend, associated with OHCI on MCP51

[Alan Stern <stern@rowland.harvard.edu>]

On Sat, 7 Jul 2012, Octavio Alvarez wrote:

> > If you build a kernel with CONFIG_USB_DEBUG enabled, what
> > shows up in /sys/kernel/debug/usb/ohci/*/registers?
> 
> [Sat Jul 07 12:49:27 -0700 -- alvarezp@octavio:/sys/kernel/debug/usb]
> $ grep . ohci/*/registers
> bus pci, device 0000:00:0b.0
> OHCI Host Controller
> ohci_hcd
> OHCI 1.0, NO legacy support registers, rh state running
> control 0x68f RWE RWC HCFS=operational IE PLE CBSR=3
> cmdstatus 0x00000 SOC=0
> intrstatus 0x00000024 FNO SF
> intrenable 0x8000004a MIE RHSC RD WDH
> ed_controlhead 2edac040
> hcca frame 0x5fce
> fmintvl 0xa7782edf FIT FSMPS=0xa778 FI=0x2edf
> fmremaining 0x80002e53 FRT FR=0x2e53
> periodicstart 0x2a2f
> lsthresh 0x0628
> hub poll timer off
> roothub.a 01000208 POTPGT=1 NPS NDP=8(8)
> roothub.b 00000000 PPCM=0000 DR=0000
> roothub.status 00008000 DRWE
> roothub.portstatus [0] 0x00000100 PPS
> roothub.portstatus [1] 0x00000100 PPS
> roothub.portstatus [2] 0x00000100 PPS
> roothub.portstatus [3] 0x00000100 PPS
> roothub.portstatus [4] 0x00000303 LSDA PPS PES CCS
> roothub.portstatus [5] 0x00000303 LSDA PPS PES CCS
> roothub.portstatus [6] 0x00000101 PPS CCS
> roothub.portstatus [7] 0x00000100 PPS

That's normal, except for the status of port 6 (which actually is port
7, since we normally count ports starting from 1).  The port shows
Current Connect Status, so something is connected to it -- but what?

Can you post a complete dmesg log showing bootup with CONFIG_USB_DEBUG 
enabled?

> > And what shows up in /sys/kernel/debug/usb/devices?
> 
> [Sat Jul 07 12:49:54 -0700 -- alvarezp@octavio:/sys/kernel/debug/usb]
> $ cat devices
...

Pretty much normal.

> > Also, what does the "lspci -vv" output show for the controller if you
> > run it with superuser permissions?
> 
> [Sat Jul 07 12:50:10 -0700 -- alvarezp@octavio:/sys/kernel/debug/usb]
> $ sudo lspci -vv -s 0000:00:0b.1

0b.1 is the EHCI controller.  We want to see the OHCI controller, 0b.0.

> I also bisected the "3.2 doesn't sleep due to ohci" problem and found this:
> 
> commit a6eeeb9f45b5a417f574f3bc799b7122270bf59b
> Author: Alan Stern <stern@rowland.harvard.edu>
> Date:   Mon Sep 26 11:23:38 2011 -0400
> 
>      USB: Update USB default wakeup settings

Yes, that commit enables wakeup for USB host controllers by default.  
Before that, you had to enable wakeup by hand.  The question is: Why
does the controller think it needs to wake up the system?

Can you also post a dmesg log showing a full suspend/immediate-resume 
cycle with CONFIG_USB_DEBUG enabled?

> > And yet the PC doesn't lock up if you unbind ohci-hcd before
> > suspending?
> 
> It suspends but it locks-up while waking up.
> 
> > Maybe you can do a git bisection to find what changed between 3.2 and
> > 3.4 to cause this behavior.
> 
> commit 2feec47d4c5f80b05f1650f5a24865718978eea4
> Author: Bob Moore <robert.moore@intel.com>
> Date:   Tue Feb 14 15:00:53 2012 +0800
> 
>      ACPICA: ACPI 5: Support for new FADT SleepStatus, SleepControl  
> registers
> 
>      Adds sleep and wake support for systems with these registers.
>      One new file, hwxfsleep.c
> 
>      Signed-off-by: Bob Moore <robert.moore@intel.com>
>      Signed-off-by: Len Brown <len.brown@intel.com>

Yes, okay, that is indeed totally separate.  You should bring that 
issue up with Bob Moore and Len Brown on the linux-acpi mailing list.

Alan Stern