2.6.14-rc1-mm1: usb breaks suspend

2.6.14-rc1-mm1: usb breaks suspend

[Pavel Machek]

[-- Attachment #1: Type: text/plain, Size: 269 bytes --]

Hi!

In -mm, usb breaks suspend to disk. Compiled without
CONFIG_USB_SUSPEND, it just plainly fails; iwth USB_SUSPEND, it
actually tries to suspend USB, but it fails and machine refuses to
suspend. Is it known or is it worth debugging?
								Pavel
-- 
Thanks, Sharp!

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: [linux-pm] 2.6.14-rc1-mm1: usb breaks suspend

[Alan Stern]

On Mon, 17 Oct 2005, Pavel Machek wrote:

> Hi!
> 
> In -mm, usb breaks suspend to disk. Compiled without
> CONFIG_USB_SUSPEND, it just plainly fails; iwth USB_SUSPEND, it
> actually tries to suspend USB, but it fails and machine refuses to
> suspend. Is it known or is it worth debugging?

More details please.

2.6.14-rc1 is a little old by now.  With 2.6.14-rc4 I don't know
about -mm, but there's a problem with the uhci-hcd driver in Greg K-H's
tree.  I submitted a patch earlier today:

http://marc.theaimsgroup.com/?l=linux-usb-devel&m=112956023807659&w=2

Alan Stern

Re: [linux-pm] 2.6.14-rc1-mm1: usb breaks suspend

[Rafael J. Wysocki]

Hi,

On Monday, 17 of October 2005 20:54, Alan Stern wrote:
> On Mon, 17 Oct 2005, Pavel Machek wrote:
> 
> > Hi!
> > 
> > In -mm, usb breaks suspend to disk. Compiled without
> > CONFIG_USB_SUSPEND, it just plainly fails; iwth USB_SUSPEND, it
> > actually tries to suspend USB, but it fails and machine refuses to
> > suspend. Is it known or is it worth debugging?
> 
> More details please.

Fails for me too on x86-64, with the following messages:

Stopping tasks: ========================|
Freeing memory... done (14642 pages freed)
Suspending device card0-0
Suspending device 2-2:1.0
Suspending device 2-2
Suspending device 3-0:1.0
hub 3-0:1.0: no suspend?
Suspending device usb3
Could not suspend device usb3: error -16
Some devices failed to suspend
Restarting tasks... done

where the USB-related info returned by the kernel is this:

ohci_hcd: 2005 April 22 USB 1.1 'Open' Host Controller (OHCI) Driver (PCI)
ACPI: PCI Interrupt Link [LUS0] enabled at IRQ 11
ACPI: PCI Interrupt 0000:00:02.0[A] -> Link [LUS0] -> GSI 11 (level, low) -> IRQ 11
PCI: Setting latency timer of device 0000:00:02.0 to 64
ohci_hcd 0000:00:02.0: OHCI Host Controller
ohci_hcd 0000:00:02.0: new USB bus registered, assigned bus number 1
ohci_hcd 0000:00:02.0: irq 11, io mem 0xfebfb000
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 3 ports detected
ACPI: PCI Interrupt Link [LUS1] enabled at IRQ 11
ACPI: PCI Interrupt 0000:00:02.1[B] -> Link [LUS1] -> GSI 11 (level, low) -> IRQ 11
PCI: Setting latency timer of device 0000:00:02.1 to 64
ohci_hcd 0000:00:02.1: OHCI Host Controller
ohci_hcd 0000:00:02.1: new USB bus registered, assigned bus number 2
ohci_hcd 0000:00:02.1: irq 11, io mem 0xfebfc000
hub 2-0:1.0: USB hub found
hub 2-0:1.0: 3 ports detected
ACPI: PCI Interrupt Link [LUS2] enabled at IRQ 5
usb 2-2: new low speed USB device using ohci_hcd and address 2
PCI: setting IRQ 5 as level-triggered
ACPI: PCI Interrupt 0000:00:02.2[C] -> Link [LUS2] -> GSI 5 (level, low) -> IRQ 5
PCI: Setting latency timer of device 0000:00:02.2 to 64
ehci_hcd 0000:00:02.2: EHCI Host Controller
ehci_hcd 0000:00:02.2: debug port 1
ehci_hcd 0000:00:02.2: new USB bus registered, assigned bus number 3
ehci_hcd 0000:00:02.2: irq 5, io mem 0xfebfdc00
PCI: cache line size of 64 is not supported by device 0000:00:02.2
ehci_hcd 0000:00:02.2: park 0
ehci_hcd 0000:00:02.2: USB 2.0 initialized, EHCI 1.00, driver 10 Dec 2004
usb 2-2: device descriptor read/all, error -110
hub 3-0:1.0: USB hub found
hub 3-0:1.0: 6 ports detected
ohci_hcd 0000:00:02.1: wakeup
usb 2-2: new low speed USB device using ohci_hcd and address 4
usbcore: registered new driver hiddev
input: Logitech USB Receiver//class/input_dev as input3
input: USB HID v1.10 Mouse [Logitech USB Receiver] on usb-0000:00:02.1-2
usbcore: registered new driver usbhid
drivers/usb/input/hid-core.c: v2.6:USB HID core driver

Greetings,
Rafael

Re: 2.6.14-rc1-mm1: usb breaks suspend

[Alan Stern]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 4102 bytes --]

On Mon, 17 Oct 2005, Rafael J. Wysocki wrote:

> Hi,
> 
> On Monday, 17 of October 2005 20:54, Alan Stern wrote:
> > On Mon, 17 Oct 2005, Pavel Machek wrote:
> > 
> > > Hi!
> > > 
> > > In -mm, usb breaks suspend to disk. Compiled without
> > > CONFIG_USB_SUSPEND, it just plainly fails; iwth USB_SUSPEND, it
> > > actually tries to suspend USB, but it fails and machine refuses to
> > > suspend. Is it known or is it worth debugging?
> > 
> > More details please.
> 
> Fails for me too on x86-64, with the following messages:
> 
> Stopping tasks: ========================|
> Freeing memory... done (14642 pages freed)
> Suspending device card0-0
> Suspending device 2-2:1.0
> Suspending device 2-2
> Suspending device 3-0:1.0
> hub 3-0:1.0: no suspend?
> Suspending device usb3
> Could not suspend device usb3: error -16
> Some devices failed to suspend
> Restarting tasks... done
> 
> where the USB-related info returned by the kernel is this:
> 
> ohci_hcd: 2005 April 22 USB 1.1 'Open' Host Controller (OHCI) Driver (PCI)
> ACPI: PCI Interrupt Link [LUS0] enabled at IRQ 11
> ACPI: PCI Interrupt 0000:00:02.0[A] -> Link [LUS0] -> GSI 11 (level, low) -> IRQ 11
> PCI: Setting latency timer of device 0000:00:02.0 to 64
> ohci_hcd 0000:00:02.0: OHCI Host Controller
> ohci_hcd 0000:00:02.0: new USB bus registered, assigned bus number 1
> ohci_hcd 0000:00:02.0: irq 11, io mem 0xfebfb000
> hub 1-0:1.0: USB hub found
> hub 1-0:1.0: 3 ports detected
> ACPI: PCI Interrupt Link [LUS1] enabled at IRQ 11
> ACPI: PCI Interrupt 0000:00:02.1[B] -> Link [LUS1] -> GSI 11 (level, low) -> IRQ 11
> PCI: Setting latency timer of device 0000:00:02.1 to 64
> ohci_hcd 0000:00:02.1: OHCI Host Controller
> ohci_hcd 0000:00:02.1: new USB bus registered, assigned bus number 2
> ohci_hcd 0000:00:02.1: irq 11, io mem 0xfebfc000
> hub 2-0:1.0: USB hub found
> hub 2-0:1.0: 3 ports detected
> ACPI: PCI Interrupt Link [LUS2] enabled at IRQ 5
> usb 2-2: new low speed USB device using ohci_hcd and address 2
> PCI: setting IRQ 5 as level-triggered
> ACPI: PCI Interrupt 0000:00:02.2[C] -> Link [LUS2] -> GSI 5 (level, low) -> IRQ 5
> PCI: Setting latency timer of device 0000:00:02.2 to 64
> ehci_hcd 0000:00:02.2: EHCI Host Controller
> ehci_hcd 0000:00:02.2: debug port 1
> ehci_hcd 0000:00:02.2: new USB bus registered, assigned bus number 3
> ehci_hcd 0000:00:02.2: irq 5, io mem 0xfebfdc00
> PCI: cache line size of 64 is not supported by device 0000:00:02.2
> ehci_hcd 0000:00:02.2: park 0
> ehci_hcd 0000:00:02.2: USB 2.0 initialized, EHCI 1.00, driver 10 Dec 2004
> usb 2-2: device descriptor read/all, error -110
> hub 3-0:1.0: USB hub found
> hub 3-0:1.0: 6 ports detected
> ohci_hcd 0000:00:02.1: wakeup
> usb 2-2: new low speed USB device using ohci_hcd and address 4
> usbcore: registered new driver hiddev
> input: Logitech USB Receiver//class/input_dev as input3
> input: USB HID v1.10 Mouse [Logitech USB Receiver] on usb-0000:00:02.1-2
> usbcore: registered new driver usbhid
> drivers/usb/input/hid-core.c: v2.6:USB HID core driver
> 
> Greetings,
> Rafael

Weird.

I can't tell what happened.  But I can tell you that USB development
goes on in Greg K-H's tree.  The current version is available as a patch
based on 2.6.14-rc4:

http://www.kernel.org/pub/linux/kernel/people/gregkh/gregkh-2.6/gregkh-all-2.6.14-rc4.patch

On top of that you should apply the patch for uhci-hcd that I mentioned 
before.  With this combination I have had no problem suspending three 
different machines.  Sometimes they even wake up, too!  :-)

Be warned: That particular kernel has a bug which sometimes causes 
"modprobe ehci-hcd" to hang.  In case this happens to you, I've included a 
patch below with a temporary workaround.  Untested, but it should work.

Alan Stern



--- a/drivers/usb/host/ehci-pci.c	Thu Oct 13 17:04:13 2005
+++ b/drivers/usb/host/ehci-pci.c	Mon Oct 17 20:57:21 2005
@@ -66,6 +66,7 @@
 	u32			temp;
 	unsigned		count = 256/4;
 
+	spin_lock_init (&ehci->lock);
 	ehci->caps = hcd->regs;
 	ehci->regs = hcd->regs + HC_LENGTH(readl(&ehci->caps->hc_capbase));
 	dbg_hcs_params(ehci, "reset");


[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

2.6.14-rc4-mm1: USB suspend regression (was: Re: 2.6.14-rc1-mm1: usb breaks suspend)

[Rafael J. Wysocki]

Hi,

On Tuesday, 18 of October 2005 03:01, Alan Stern wrote:
> On Mon, 17 Oct 2005, Rafael J. Wysocki wrote:
> > On Monday, 17 of October 2005 20:54, Alan Stern wrote:
> > > On Mon, 17 Oct 2005, Pavel Machek wrote:
> > > 
> > > > Hi!
> > > > 
> > > > In -mm, usb breaks suspend to disk. Compiled without
> > > > CONFIG_USB_SUSPEND, it just plainly fails; iwth USB_SUSPEND, it
> > > > actually tries to suspend USB, but it fails and machine refuses to
> > > > suspend. Is it known or is it worth debugging?
> > > 
> > > More details please.
> > 
> > Fails for me too on x86-64, with the following messages:
> > 
> > Stopping tasks: ========================|
> > Freeing memory... done (14642 pages freed)
> > Suspending device card0-0
> > Suspending device 2-2:1.0
> > Suspending device 2-2
> > Suspending device 3-0:1.0
> > hub 3-0:1.0: no suspend?
> > Suspending device usb3
> > Could not suspend device usb3: error -16
> > Some devices failed to suspend
> > Restarting tasks... done
> > 
> > where the USB-related info returned by the kernel is this:
> > 
> > ohci_hcd: 2005 April 22 USB 1.1 'Open' Host Controller (OHCI) Driver (PCI)
> > ACPI: PCI Interrupt Link [LUS0] enabled at IRQ 11
> > ACPI: PCI Interrupt 0000:00:02.0[A] -> Link [LUS0] -> GSI 11 (level, low) -> IRQ 11
> > PCI: Setting latency timer of device 0000:00:02.0 to 64
> > ohci_hcd 0000:00:02.0: OHCI Host Controller
> > ohci_hcd 0000:00:02.0: new USB bus registered, assigned bus number 1
> > ohci_hcd 0000:00:02.0: irq 11, io mem 0xfebfb000
> > hub 1-0:1.0: USB hub found
> > hub 1-0:1.0: 3 ports detected
> > ACPI: PCI Interrupt Link [LUS1] enabled at IRQ 11
> > ACPI: PCI Interrupt 0000:00:02.1[B] -> Link [LUS1] -> GSI 11 (level, low) -> IRQ 11
> > PCI: Setting latency timer of device 0000:00:02.1 to 64
> > ohci_hcd 0000:00:02.1: OHCI Host Controller
> > ohci_hcd 0000:00:02.1: new USB bus registered, assigned bus number 2
> > ohci_hcd 0000:00:02.1: irq 11, io mem 0xfebfc000
> > hub 2-0:1.0: USB hub found
> > hub 2-0:1.0: 3 ports detected
> > ACPI: PCI Interrupt Link [LUS2] enabled at IRQ 5
> > usb 2-2: new low speed USB device using ohci_hcd and address 2
> > PCI: setting IRQ 5 as level-triggered
> > ACPI: PCI Interrupt 0000:00:02.2[C] -> Link [LUS2] -> GSI 5 (level, low) -> IRQ 5
> > PCI: Setting latency timer of device 0000:00:02.2 to 64
> > ehci_hcd 0000:00:02.2: EHCI Host Controller
> > ehci_hcd 0000:00:02.2: debug port 1
> > ehci_hcd 0000:00:02.2: new USB bus registered, assigned bus number 3
> > ehci_hcd 0000:00:02.2: irq 5, io mem 0xfebfdc00
> > PCI: cache line size of 64 is not supported by device 0000:00:02.2
> > ehci_hcd 0000:00:02.2: park 0
> > ehci_hcd 0000:00:02.2: USB 2.0 initialized, EHCI 1.00, driver 10 Dec 2004
> > usb 2-2: device descriptor read/all, error -110
> > hub 3-0:1.0: USB hub found
> > hub 3-0:1.0: 6 ports detected
> > ohci_hcd 0000:00:02.1: wakeup
> > usb 2-2: new low speed USB device using ohci_hcd and address 4
> > usbcore: registered new driver hiddev
> > input: Logitech USB Receiver//class/input_dev as input3
> > input: USB HID v1.10 Mouse [Logitech USB Receiver] on usb-0000:00:02.1-2
> > usbcore: registered new driver usbhid
> > drivers/usb/input/hid-core.c: v2.6:USB HID core driver
> > 
> > Greetings,
> > Rafael
> 
> Weird.
> 
> I can't tell what happened.  But I can tell you that USB development
> goes on in Greg K-H's tree.  The current version is available as a patch
> based on 2.6.14-rc4:
> 
> http://www.kernel.org/pub/linux/kernel/people/gregkh/gregkh-2.6/gregkh-all-2.6.14-rc4.patch
> 
> On top of that you should apply the patch for uhci-hcd that I mentioned 
> before.  With this combination I have had no problem suspending three 
> different machines.  Sometimes they even wake up, too!  :-)

Thanks a lot for all the information.

Still I'd rather like to figure out what causes the problem to appear
in -rc4-mm1.  So far I have identified the offending patch which is:

gregkh-usb-usb-power-state-03.patch

(ie. with the patch the problem occurs 100% of the time and without
the patch it doesn't).  I don't know which change in the patch is at
fault (yet).  [Note: the patch didn't revert cleanly so I changed the
7th chunk in drivers/usb/core/hub.c a bit.]

The devices that refuse to suspend (with the above patch) are:

usb usb3: Product: EHCI Host Controller
usb usb3: Manufacturer: Linux 2.6.14-rc4-mm1 ehci_hcd
usb usb3: SerialNumber: 0000:00:02.2

usb usb2: Product: OHCI Host Controller
usb usb2: Manufacturer: Linux 2.6.14-rc4-mm1 ohci_hcd
usb usb2: SerialNumber: 0000:00:02.1

Greetings,
Rafael

Re: 2.6.14-rc4-mm1: USB suspend regression

[Mark Lord]

None of the recent kernels can resume-from-ram reliably for me
if I use CONFIG_USB_SUSPEND (set).   But with that option UNset,
suspend/resume to/from RAM works very well.

BUT.. new in 2.6.14-rc*, is that the ehci_hcd USB hispeed driver
no longer survives resume from ram.  I have to unload/reload the
module to get hispeed USB after resume.

-ml

Re: 2.6.14-rc4-mm1: USB suspend regression

[Alan Stern]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1000 bytes --]

[Trimmed the CC: list]

On Wed, 19 Oct 2005, Mark Lord wrote:

> None of the recent kernels can resume-from-ram reliably for me
> if I use CONFIG_USB_SUSPEND (set).   But with that option UNset,
> suspend/resume to/from RAM works very well.

Try applying this patch:

http://marc.theaimsgroup.com/?l=linux-kernel&m=112966405019175&w=2

It may very well help the CONFIG_USB_SUSPEND problem.  If it doesn't, 
please turn on CONFIG_USB_DEBUG and post the dmesg log for the suspend and 
resume.

> BUT.. new in 2.6.14-rc*, is that the ehci_hcd USB hispeed driver
> no longer survives resume from ram.  I have to unload/reload the
> module to get hispeed USB after resume.

Well, on my machine it works with resume from Standby.  (Resume from RAM 
doesn't work at all -- pushing the power button to start the resume causes 
a clean shutdown instead!)

Your dmesg log might provide some useful information here as well.  But if
it's a serious problem you'll have to get Dave Brownell to help.

Alan Stern


[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: 2.6.14-rc4-mm1: USB suspend regression

[Mark Lord]

[-- Attachment #1: Type: text/plain, Size: 684 bytes --]

Alan Stern wrote:
>
>>None of the recent kernels can resume-from-ram reliably for me
>>if I use CONFIG_USB_SUSPEND (set).   But with that option UNset,
>>suspend/resume to/from RAM works very well.
>
> Try applying this patch:
> http://marc.theaimsgroup.com/?l=linux-kernel&m=112966405019175&w=2

I have already adopted that patch independently,
and it has done wonders for stability with 2.6.14-rc4
coming back from suspend-to-ram.  Or is that just my imagination?

But I have not yet tried reenabling CONFIG_USB_SUSPEND in conjunction
with that patch -- just too much grief and wasted time every round
I try with CONFIG_USB_SUSPEND.  I'll get to it again eventually though.

Cheers

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: 2.6.14-rc4-mm1: USB suspend regression (was: Re: 2.6.14-rc1-mm1: usb breaks suspend)

[Alan Stern]

[Trimmed the CC: list]

On Wed, 19 Oct 2005, Rafael J. Wysocki wrote:

> Hi,
> 
> On Tuesday, 18 of October 2005 03:01, Alan Stern wrote:
> > On Mon, 17 Oct 2005, Rafael J. Wysocki wrote:
> > > On Monday, 17 of October 2005 20:54, Alan Stern wrote:
> > > > On Mon, 17 Oct 2005, Pavel Machek wrote:
> > > > 
> > > > > Hi!
> > > > > 
> > > > > In -mm, usb breaks suspend to disk. Compiled without
> > > > > CONFIG_USB_SUSPEND, it just plainly fails; iwth USB_SUSPEND, it
> > > > > actually tries to suspend USB, but it fails and machine refuses to
> > > > > suspend. Is it known or is it worth debugging?
> > > > 
> > > > More details please.
> > > 
> > > Fails for me too on x86-64, with the following messages:
> > > 
> > > Stopping tasks: ========================|
> > > Freeing memory... done (14642 pages freed)
> > > Suspending device card0-0
> > > Suspending device 2-2:1.0
> > > Suspending device 2-2
> > > Suspending device 3-0:1.0
> > > hub 3-0:1.0: no suspend?

This line is the puzzle.  It indicates that the driver bound to the
3-0:1.0 device (which is a root hub interface for one of your USB
controllers) doesn't have a suspend or resume method.  But the hub driver
_does_ have these methods!

Unless you somehow screwed up the build.  Take a look inside
drivers/usb/core/hub.c and make sure that the hub_suspend() and
hub_resume() routines are listed in the hub_driver table, and that they
haven't been preprocessed away into NULLs.  You might end up needing to do
a clean rebuild.

> > > Suspending device usb3
> > > Could not suspend device usb3: error -16
> > > Some devices failed to suspend

These errors occurred, naturally enough, because the driver for usb3 
refused to suspend since one of the children -- namely 3-0:1.0 -- wasn't 
suspended.

> Thanks a lot for all the information.
> 
> Still I'd rather like to figure out what causes the problem to appear
> in -rc4-mm1.  So far I have identified the offending patch which is:
> 
> gregkh-usb-usb-power-state-03.patch
> 
> (ie. with the patch the problem occurs 100% of the time and without
> the patch it doesn't).  I don't know which change in the patch is at
> fault (yet).  [Note: the patch didn't revert cleanly so I changed the
> 7th chunk in drivers/usb/core/hub.c a bit.]

I don't think this is as simple as finding an offending line in a 
particular patch.  As you can see from the numbering, that patch was part 
of a large series; it wasn't meant to be applied or removed in isolation.

> The devices that refuse to suspend (with the above patch) are:
> 
> usb usb3: Product: EHCI Host Controller
> usb usb3: Manufacturer: Linux 2.6.14-rc4-mm1 ehci_hcd
> usb usb3: SerialNumber: 0000:00:02.2
> 
> usb usb2: Product: OHCI Host Controller
> usb usb2: Manufacturer: Linux 2.6.14-rc4-mm1 ohci_hcd
> usb usb2: SerialNumber: 0000:00:02.1

Maybe if you solve the riddle above (suspend method not present in the hub 
driver) it will clear up these issues as well.

Alan Stern



-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
_______________________________________________
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel

Re: 2.6.14-rc4-mm1: USB suspend regression (was: Re: 2.6.14-rc1-mm1: usb breaks suspend)

[Rafael J. Wysocki]

Hi,

On Wednesday, 19 of October 2005 18:18, Alan Stern wrote:
> [Trimmed the CC: list]
}-- snip --{
> > > > Stopping tasks: ========================|
> > > > Freeing memory... done (14642 pages freed)
> > > > Suspending device card0-0
> > > > Suspending device 2-2:1.0
> > > > Suspending device 2-2
> > > > Suspending device 3-0:1.0
> > > > hub 3-0:1.0: no suspend?
> 
> This line is the puzzle.  It indicates that the driver bound to the
> 3-0:1.0 device (which is a root hub interface for one of your USB
> controllers) doesn't have a suspend or resume method.  But the hub driver
> _does_ have these methods!

Unless someone, like me, has CONFIG_USB_SUSPEND unset,
in which case they are #defined as NULLs (of course if I'm not missing
anything).  Is now CONFIG_USB_SUSPEND mandatory for being able to suspend?

> Unless you somehow screwed up the build.  Take a look inside
> drivers/usb/core/hub.c and make sure that the hub_suspend() and
> hub_resume() routines are listed in the hub_driver table, and that they
> haven't been preprocessed away into NULLs.  You might end up needing to do
> a clean rebuild.

This already is a clean build, on top of 2.6.13 unpacked from scratch (well,
I have some patches applied, but they don't touch USB).

> > > > Suspending device usb3
> > > > Could not suspend device usb3: error -16
> > > > Some devices failed to suspend
> 
> These errors occurred, naturally enough, because the driver for usb3 
> refused to suspend since one of the children -- namely 3-0:1.0 -- wasn't 
> suspended.

I've figured out that too.  However, if something has no _suspend() routine,
verify_suspended() could return 0 for it, I think, instead of -EBUSY.

Greetings,
Rafael

Re: 2.6.14-rc4-mm1: USB suspend regression (was: Re: 2.6.14-rc1-mm1: usb breaks suspend)

[Alan Stern]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 2046 bytes --]

On Wed, 19 Oct 2005, Rafael J. Wysocki wrote:

> > This line is the puzzle.  It indicates that the driver bound to the
> > 3-0:1.0 device (which is a root hub interface for one of your USB
> > controllers) doesn't have a suspend or resume method.  But the hub driver
> > _does_ have these methods!
> 
> Unless someone, like me, has CONFIG_USB_SUSPEND unset,
> in which case they are #defined as NULLs (of course if I'm not missing
> anything).  Is now CONFIG_USB_SUSPEND mandatory for being able to suspend?

No.  It's mandatory only for runtime PM; system PM will work as long as 
CONFIG_PM is set.

> > Unless you somehow screwed up the build.  Take a look inside
> > drivers/usb/core/hub.c and make sure that the hub_suspend() and
> > hub_resume() routines are listed in the hub_driver table, and that they
> > haven't been preprocessed away into NULLs.  You might end up needing to do
> > a clean rebuild.
> 
> This already is a clean build, on top of 2.6.13 unpacked from scratch (well,
> I have some patches applied, but they don't touch USB).

Then that's your problem.  There has been a lot of development on USB 
suspend/resume in 2.6.14, and you don't have all the patches applied.  In 
particular, you are missing usb-pm-05.patch (probably a bunch of others as 
well).

Take my advice: Start from 2.6.14-rc4, apply gregkh-all-2.6.14-rc4.patch 
(it gets updated fairly often, so retrieve a fresh copy), and also apply 
the PF_NOFREEZE patch (as585) I posted on lkml and linux-pm.

> > These errors occurred, naturally enough, because the driver for usb3 
> > refused to suspend since one of the children -- namely 3-0:1.0 -- wasn't 
> > suspended.
> 
> I've figured out that too.  However, if something has no _suspend() routine,
> verify_suspended() could return 0 for it, I think, instead of -EBUSY.

Dave Brownell would probably give you an argument, but I tend to agree.  
Alternatively, if something has no ->suspend then we could just set its 
->power.power_state value directly so it would _appear_ to be suspended.

Alan Stern


[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: 2.6.14-rc4-mm1: USB suspend regression (was: Re: 2.6.14-rc1-mm1: usb breaks suspend)

[Rafael J. Wysocki]

Hi,

On Wednesday, 19 of October 2005 22:46, Alan Stern wrote:
> On Wed, 19 Oct 2005, Rafael J. Wysocki wrote:
}-- snip --{
> There has been a lot of development on USB  
> suspend/resume in 2.6.14, and you don't have all the patches applied.  In 
> particular, you are missing usb-pm-05.patch (probably a bunch of others as 
> well).

If I'm missing any patches that's becasue they are not in 2.6.14-rc4-mm1
for some reason (I assume an important one).

> Take my advice: Start from 2.6.14-rc4, apply gregkh-all-2.6.14-rc4.patch 
> (it gets updated fairly often, so retrieve a fresh copy), and also apply 
> the PF_NOFREEZE patch (as585) I posted on lkml and linux-pm.

>From my POV this means there's no point in testing USB suspend/resume
on 2.6.14-rc4-mm1, because it's potentially broken.  Which is fair enough,
BTW.

> > > These errors occurred, naturally enough, because the driver for usb3 
> > > refused to suspend since one of the children -- namely 3-0:1.0 -- wasn't 
> > > suspended.
> > 
> > I've figured out that too.  However, if something has no _suspend() routine,
> > verify_suspended() could return 0 for it, I think, instead of -EBUSY.
> 
> Dave Brownell would probably give you an argument, but I tend to agree.  
> Alternatively, if something has no ->suspend then we could just set its 
> ->power.power_state value directly so it would _appear_ to be suspended.

Well, that depends.  If the driver has a _resume() routine, it's ->power.power_state
should be set on suspend.  However, if it has neither _resume() nor _suspend(),
it's ->power.power_state is not really well defined, so it's just easier to ignore it.

Greetings,
Rafael

Re: 2.6.14-rc4-mm1: USB suspend regression (was: Re: 2.6.14-rc1-mm1: usb breaks suspend)

[Alan Stern]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 2346 bytes --]

On Thu, 20 Oct 2005, Rafael J. Wysocki wrote:

> Hi,
> 
> On Wednesday, 19 of October 2005 22:46, Alan Stern wrote:
> > On Wed, 19 Oct 2005, Rafael J. Wysocki wrote:
> }-- snip --{
> > There has been a lot of development on USB  
> > suspend/resume in 2.6.14, and you don't have all the patches applied.  In 
> > particular, you are missing usb-pm-05.patch (probably a bunch of others as 
> > well).
> 
> If I'm missing any patches that's becasue they are not in 2.6.14-rc4-mm1
> for some reason (I assume an important one).

You'll have to get the details from Greg.  The stuff in his tree generally 
does end up in -mm after only a short delay, but maybe some patches get 
lost somehow.  Or maybe some of them didn't make it in time for -mm1.

> > Take my advice: Start from 2.6.14-rc4, apply gregkh-all-2.6.14-rc4.patch 
> > (it gets updated fairly often, so retrieve a fresh copy), and also apply 
> > the PF_NOFREEZE patch (as585) I posted on lkml and linux-pm.
> 
> From my POV this means there's no point in testing USB suspend/resume
> on 2.6.14-rc4-mm1, because it's potentially broken.  Which is fair enough,
> BTW.

If 2.6.14-rc4-mm1 still has hub_suspend and hub_resume preprocessed away,
then you're right -- it's too old to be worth testing.

> > > I've figured out that too.  However, if something has no _suspend() routine,
> > > verify_suspended() could return 0 for it, I think, instead of -EBUSY.
> > 
> > Dave Brownell would probably give you an argument, but I tend to agree.  
> > Alternatively, if something has no ->suspend then we could just set its 
> > ->power.power_state value directly so it would _appear_ to be suspended.
> 
> Well, that depends.  If the driver has a _resume() routine, it's ->power.power_state
> should be set on suspend.  However, if it has neither _resume() nor _suspend(),
> it's ->power.power_state is not really well defined, so it's just easier to ignore it.

I don't want to change this without talking to Dave first, and
unfortunately he's incommunicado at the moment.  Wasn't it Groucho Marx
who said that "communicado" was a small country in Latin America?  In
Dave's case the country isn't so small (Brazil) and all the emails
I've sent him in the last few days have bounced.  So we'll have to wait 
until he gets back and straightens things out with his service provider.

Alan Stern


[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: [linux-pm] 2.6.14-rc1-mm1: usb breaks suspend

[Pavel Machek]

Hi!

> > In -mm, usb breaks suspend to disk. Compiled without
> > CONFIG_USB_SUSPEND, it just plainly fails; iwth USB_SUSPEND, it
> > actually tries to suspend USB, but it fails and machine refuses to
> > suspend. Is it known or is it worth debugging?
> 
> More details please.
> 
> 2.6.14-rc1 is a little old by now.  With 2.6.14-rc4 I don't know

2.6.14-rc4-mm1, sorry.

> about -mm, but there's a problem with the uhci-hcd driver in Greg K-H's
> tree.  I submitted a patch earlier today:
> 
> http://marc.theaimsgroup.com/?l=linux-usb-devel&m=112956023807659&w=2

Yes, this patch helps. [I still get quite a lot of debug messages, but
that's another story].
								Pavel
-- 
Boycott Kodak -- for their patent abuse against Java.