Re: [linux-usb-devel] 2.6.18-rc6-mm1

[Mattia Dongili <malattia@linux.it>]

On Tue, Sep 12, 2006 at 10:28:27AM -0400, Alan Stern wrote:
> On Tue, 12 Sep 2006, Rafael J. Wysocki wrote:
> 
> > Now I have another symtom: during the _second_ suspend the suspending of
> > USB controllers fails with messages like this:
> > 
> > usb_hcd_pci_suspend(): ehci_pci_suspend+0x0/0xab [ehci_hcd]() returns -22
> > pci_device_suspend(): usb_hcd_pci_suspend+0x0/0x16d [usbcore]() returns -22
> > suspend_device(): pci_device_suspend+0x0/0x4b() returns -22
> > Could not suspend device 0000:00:13.2: error -22
> > 
> > Could you please tell me which patches might have caused this, in your opinion?

oh great, I was going to report (almost) the same for S3:

[  224.436000] uhci_hcd 0000:00:1d.2: Root hub isn't suspended!
[  224.436000] usb_hcd_pci_suspend(): uhci_suspend+0x0/0xe0 [uhci_hcd]() returns -16
[  224.436000] pci_device_suspend(): usb_hcd_pci_suspend+0x0/0x1a0 [usbcore]() returns -16
[  224.436000] suspend_device(): pci_device_suspend+0x0/0x70() returns -16
[  224.436000] Could not suspend device 0000:00:1d.2: error -16

I'd also add that the 3rd attempt at suspending will simply hang with
powered down monitor but sysrq is still available.

> It's a little difficult to pin down the blame.  In one form or another
> this problem probably existed all along, although it may not have been 
> very obvious.
> 
> For those interested in the explanation:
> 
> The EHCI USB controller is represented in sysfs by two device structures.  
> The higher one represents the controller's PCI interface (let's call it
> the "PCI-controller") and the lower one represents the USB interface
> (let's call it the "root hub").  Inside the resume() routine for the
> PCI-controller, if the driver finds that power was lost during the suspend
> -- as it would be for suspend-to-disk -- the driver reinitializes the root
> hub but without telling usbcore it has done so.  If the root hub had
> already been suspended at the time of the suspend-to-disk, then
> resume-from-disk would skip calling its resume() method.  So as far as 
> usbcore knows the root hub should still be suspended, but in fact it is 
> awake.
> 
> Consequently during the second suspend-to-disk, usbcore does not pass the
> suspend() call on to the root hub's driver.  Then the suspend() method for
> the PCI-controller fails, because it sees that the child root hub is still
> unsuspended.

I assume this is still true for suspend-to-ram :)
Maybe this is related, I'd like to add also that with previous kernels
(all the 2.6.17*-mm serie until 2.6.18-rc5-mm1) after the first resume I
get those annoying "resets":

[73060.848000] usb 1-2: reset low speed USB device using uhci_hcd and address 3
[73128.332000] usb 1-2: reset low speed USB device using uhci_hcd and address 3
[73586.392000] usb 1-2: reset low speed USB device using uhci_hcd and address 3
[73944.592000] usb 1-2: reset low speed USB device using uhci_hcd and address 3

when the device is reset while typing the char being typed is repeated 4
times. Suspending and resuming again seems to fix that.
Oh, here it is:
Bus 002 Device 001: ID 0000:0000  
Bus 003 Device 003: ID 054c:0056 Sony Corp. 
Bus 003 Device 001: ID 0000:0000  
Bus 001 Device 003: ID 046d:c001 Logitech, Inc. N48/M-BB48 [FirstMouse Plus]
Bus 001 Device 001: ID 0000:0000  

> I was just going to send in a patch to fix the problem.  I haven't had
> much of a chance to try it out yet.  The patch is included below, so you
> can test it right away and let me know if it works for you before I submit 
> it.

going to reboot to test it, hold on.

-- 
mattia
:wq!
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/