Re: [linux-usb-devel] 2.6.18-rc6-mm1 (-mm2): ohci resume problem

Re: [linux-usb-devel] 2.6.18-rc6-mm1 (-mm2): ohci resume problem

[Robert Hancock]

Alan Stern wrote:
> On Thu, 14 Sep 2006, Alan Stern wrote:
> 
>> Now of course, the autosuspend stuff has to work properly no matter what 
>> the kernel configuration is.  I'll go back and rebuild the drivers with 
>> USB_SUSPEND turned off and see what happens.  With any luck I'll have a 
>> fix ready in the near future.
> 
> This should start fixing things, but I'm not certain it will solve the 
> entire problem.  If it doesn't work, send another dmesg log.

This patch seems to fix the problem for me..

-- 
Robert Hancock      Saskatoon, SK, Canada
To email, remove "nospam" from hancockr@nospamshaw.ca
Home Page: http://www.roberthancock.com/

Re: [linux-usb-devel] 2.6.18-rc6-mm1 (-mm2): ohci resume problem

[Robert Hancock]

Rafael J. Wysocki wrote:
> BTW, all of the systems on which the problem shows up seem to be 64-bit.
> 
> If you can't reproduce it on a 32-bit system, some type casting may be wrong
> somewhere.
> 
> Greetings,
> Rafael

I'm getting this problem on a 32-bit system (see my report in reply to 
Andrew's 2.6.18-rc6-mm2 announcement). The EHCI driver won't suspend on 
the second attempt after bootup.

-- 
Robert Hancock      Saskatoon, SK, Canada
To email, remove "nospam" from hancockr@nospamshaw.ca
Home Page: http://www.roberthancock.com/

Re: [linux-usb-devel] 2.6.18-rc6-mm1 (-mm2): ohci resume problem

[Rafael J. Wysocki]

On Thursday, 14 September 2006 16:28, Robert Hancock wrote:
> Rafael J. Wysocki wrote:
> > BTW, all of the systems on which the problem shows up seem to be 64-bit.
> > 
> > If you can't reproduce it on a 32-bit system, some type casting may be wrong
> > somewhere.
> > 
> > Greetings,
> > Rafael
> 
> I'm getting this problem on a 32-bit system (see my report in reply to 
> Andrew's 2.6.18-rc6-mm2 announcement). The EHCI driver won't suspend on 
> the second attempt after bootup.

Ah, so I was wrong.

I've seen your report, but I thought it was a 64-bit system for some reason.
Sorry for the confusion.

Rafael


-- 
You never change things by fighting the existing reality.
		R. Buckminster Fuller

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

[Alan Stern]

On Fri, 8 Sep 2006, Andrew Morton wrote:

> Alan, is this likely to be due to your USB PM changes?

It's possible.  Most of those changes are innocuous.  They add routines
that don't get used until a later patch.  However one of them might be
responsible.


On Fri, 8 Sep 2006, Rafael J. Wysocki wrote:

> On Friday, 8 September 2006 10:13, Andrew Morton wrote:
> > 
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18-rc6/2.6.18-rc6-mm1/
> 
> ohci_hcd doesn't work after a resume from disk on HPC nx6325, worked on
> 2.6.18-rc5-mm1.
> 
> It helps if I rmmod and modprobe it after the resume.

This patch affects OHCI.  You can try reverting it, to see if that makes 
any difference.  It probably should have been left out of -mm, since it 
interacts pretty strongly with some later USB PM patches that did get left 
out.

	gregkh-usb-usbcore-remove-usb_suspend_root_hub.patch

> Here's the relevant part of the dmesg output:
> 
> usb usb1: resuming
>  usbdev1.1_ep00: PM: resume from 0, parent usb1 still 1
> hub 1-0:1.0: PM: resume from 0, parent usb1 still 1
> hub 1-0:1.0: resuming
>  usbdev1.1: PM: resume from 0, parent usb1 still 1

If reverting that patch doesn't help, please post the relevant dmesg log 
after setting CONFIG_USB_DEBUG.

Alan Stern

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

[Rafael J. Wysocki]

On Friday, 8 September 2006 22:44, Alan Stern wrote:
> On Fri, 8 Sep 2006, Andrew Morton wrote:
> 
> > Alan, is this likely to be due to your USB PM changes?
> 
> It's possible.  Most of those changes are innocuous.  They add routines
> that don't get used until a later patch.  However one of them might be
> responsible.

Well, after recompiling the kernel for several times (because of a different
problem) I'm no longer able to reproduce the problem.

Sorry for the noise.

Greetings,
Rafael


-- 
You never change things by fighting the existing reality.
		R. Buckminster Fuller

Re: [linux-usb-devel] 2.6.18-rc6-mm1 (-mm2): ohci resume problem

[Rafael J. Wysocki]

On Saturday, 9 September 2006 00:57, Rafael J. Wysocki wrote:
> On Friday, 8 September 2006 22:44, Alan Stern wrote:
> > On Fri, 8 Sep 2006, Andrew Morton wrote:
> > 
> > > Alan, is this likely to be due to your USB PM changes?
> > 
> > It's possible.  Most of those changes are innocuous.  They add routines
> > that don't get used until a later patch.  However one of them might be
> > responsible.
> 
> Well, after recompiling the kernel for several times (because of a different
> problem) I'm no longer able to reproduce the problem.

I have retested it on 2.6.18-rc6-mm1 and the problem sometimes happens.
It's not readily reproducible, as I said before, and it apparently doesn't
happen with gregkh-usb-usbcore-remove-usb_suspend_root_hub.patch
reverted.

Greetings,
Rafael


-- 
You never change things by fighting the existing reality.
		R. Buckminster Fuller

Re: [linux-usb-devel] 2.6.18-rc6-mm1 (-mm2): ohci resume problem

[Rafael J. Wysocki]

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

On Wednesday, 13 September 2006 14:07, Rafael J. Wysocki wrote:
> On Saturday, 9 September 2006 00:57, Rafael J. Wysocki wrote:
> > On Friday, 8 September 2006 22:44, Alan Stern wrote:
> > > On Fri, 8 Sep 2006, Andrew Morton wrote:
> > > 
> > > > Alan, is this likely to be due to your USB PM changes?
> > > 
> > > It's possible.  Most of those changes are innocuous.  They add routines
> > > that don't get used until a later patch.  However one of them might be
> > > responsible.
> > 
> > Well, after recompiling the kernel for several times (because of a different
> > problem) I'm no longer able to reproduce the problem.
> 
> I have retested it on 2.6.18-rc6-mm1 and the problem sometimes happens.
> It's not readily reproducible, as I said before, and it apparently doesn't
> happen with gregkh-usb-usbcore-remove-usb_suspend_root_hub.patch
> reverted.

Well, I have reproduced it with gregkh-usb-usbcore-remove-usb_suspend_root_hub.patch
reverted too.

Attached is the output of dmesg from the failing case with USB_DEBUG set.
It covers two attempts to suspend to disk, the second one being unsuccessful,
with reloading the ohci_hcd module in between.  [This kernel also has your
other patch to prevent the second suspend from failing applied, but it doesn't
help.]

Greetings,
Rafael


-- 
You never change things by fighting the existing reality.
		R. Buckminster Fuller

[-- Attachment #2: dmesg.log.gz --]
[-- Type: application/x-gzip, Size: 17040 bytes --]

Re: [linux-usb-devel] 2.6.18-rc6-mm1 (-mm2): ohci resume problem

[Alan Stern]

On Wed, 13 Sep 2006, Rafael J. Wysocki wrote:

> Well, I have reproduced it with gregkh-usb-usbcore-remove-usb_suspend_root_hub.patch
> reverted too.
> 
> Attached is the output of dmesg from the failing case with USB_DEBUG set.
> It covers two attempts to suspend to disk, the second one being unsuccessful,
> with reloading the ohci_hcd module in between.  [This kernel also has your
> other patch to prevent the second suspend from failing applied, but it doesn't
> help.]

Okay.  Your problem, and probably Mattia's too, is something other than
what that recent patch addressed.  I can't tell from the dmesg log exactly
what went wrong, but I can tell you where to look.

In drivers/usb/core/driver.c, resume_device() is not succeeding.  That is, 
the lines near the end which do

	if (status == 0)
		udev->dev.power.power_state.event = PM_EVENT_ON;

aren't running during the first resume.  You can see this in the dmesg 
log; lines 1173-1175 say

	usb usb1: resuming
	 usbdev1.1_ep00: PM: resume from 0, parent usb1 still 1
	hub 1-0:1.0: PM: resume from 0, parent usb1 still 1

If power_state.event had gotten set to PM_EVENT_ON then the parent state 
would be 0, not 1.  This is the source of your problem.  During your 
second suspend attempt, usb1 didn't get handled correctly because its 
state was set wrong.  (I suspect the mishandling took place in usbcore 
rather than the PM core, but it doesn't matter.  The state should not have 
been wrong to begin with.)  Consequently its parent device 0000:00:13.2 
refused to freeze, which aborted the suspend attempt.

For the usb1 device, udriver->resume should point to the generic_resume() 
routine in drivers/usb/core/generic.c.  In fact, this should be true for 
every device that driver.c:resume_device() sees.  But generic_resume() 
simply calls usb_port_resume() in hub.c, and the log doesn't contain any 
of the USB debugging messages that usb_port_resume() would produce.  So I 
can't tell what happened.

The patch below will add some extra debugging information.  We need to
find out why the resume didn't succeed.  Oh -- and of course, you should
reinstate all those autosuspend patches.  Otherwise this patch won't 
apply!

Alan Stern



Index: mm/drivers/usb/core/driver.c
===================================================================
--- mm.orig/drivers/usb/core/driver.c
+++ mm/drivers/usb/core/driver.c
@@ -825,6 +825,7 @@ static int resume_device(struct usb_devi
 	struct usb_device_driver	*udriver;
 	int				status = 0;
 
+	dev_dbg(&udev->dev, "%s: state %d\n", __FUNCTION__, udev->state);
 	if (udev->state == USB_STATE_NOTATTACHED ||
 			udev->state != USB_STATE_SUSPENDED)
 		goto done;
@@ -839,7 +840,7 @@ static int resume_device(struct usb_devi
 	status = udriver->resume(udev);
 
 done:
-	// dev_dbg(&udev->dev, "%s: status %d\n", __FUNCTION__, status);
+	dev_dbg(&udev->dev, "%s: status %d\n", __FUNCTION__, status);
 	if (status == 0)
 		udev->dev.power.power_state.event = PM_EVENT_ON;
 	return status;

Re: [linux-usb-devel] 2.6.18-rc6-mm1 (-mm2): ohci resume problem

[Rafael J. Wysocki]

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

On Wednesday, 13 September 2006 20:38, Alan Stern wrote:
> On Wed, 13 Sep 2006, Rafael J. Wysocki wrote:
> 
> > Well, I have reproduced it with gregkh-usb-usbcore-remove-usb_suspend_root_hub.patch
> > reverted too.
> > 
> > Attached is the output of dmesg from the failing case with USB_DEBUG set.
> > It covers two attempts to suspend to disk, the second one being unsuccessful,
> > with reloading the ohci_hcd module in between.  [This kernel also has your
> > other patch to prevent the second suspend from failing applied, but it doesn't
> > help.]
> 
> Okay.  Your problem, and probably Mattia's too, is something other than
> what that recent patch addressed.  I can't tell from the dmesg log exactly
> what went wrong, but I can tell you where to look.
> 
> In drivers/usb/core/driver.c, resume_device() is not succeeding.  That is, 
> the lines near the end which do
> 
> 	if (status == 0)
> 		udev->dev.power.power_state.event = PM_EVENT_ON;
> 
> aren't running during the first resume.  You can see this in the dmesg 
> log; lines 1173-1175 say
> 
> 	usb usb1: resuming
> 	 usbdev1.1_ep00: PM: resume from 0, parent usb1 still 1
> 	hub 1-0:1.0: PM: resume from 0, parent usb1 still 1
> 
> If power_state.event had gotten set to PM_EVENT_ON then the parent state 
> would be 0, not 1.  This is the source of your problem.  During your 
> second suspend attempt, usb1 didn't get handled correctly because its 
> state was set wrong.  (I suspect the mishandling took place in usbcore 
> rather than the PM core, but it doesn't matter.  The state should not have 
> been wrong to begin with.)  Consequently its parent device 0000:00:13.2 
> refused to freeze, which aborted the suspend attempt.
> 
> For the usb1 device, udriver->resume should point to the generic_resume() 
> routine in drivers/usb/core/generic.c.  In fact, this should be true for 
> every device that driver.c:resume_device() sees.  But generic_resume() 
> simply calls usb_port_resume() in hub.c, and the log doesn't contain any 
> of the USB debugging messages that usb_port_resume() would produce.  So I 
> can't tell what happened.
> 
> The patch below will add some extra debugging information.  We need to
> find out why the resume didn't succeed.  Oh -- and of course, you should
> reinstate all those autosuspend patches.  Otherwise this patch won't 
> apply!

OK

Attached is a dmesg output from 2.6.18-rc6-mm2 with the patch applied.
It covers two consecutive attempts to suspend (the second one obviously
failed).

Greetings,
Rafael


-- 
You never change things by fighting the existing reality.
		R. Buckminster Fuller

[-- Attachment #2: dmesg-debug.log.gz --]
[-- Type: application/x-gzip, Size: 14809 bytes --]

Re: [linux-usb-devel] 2.6.18-rc6-mm1 (-mm2): ohci resume problem

[Alan Stern]

On Wed, 13 Sep 2006, Rafael J. Wysocki wrote:

> > The patch below will add some extra debugging information.  We need to
> > find out why the resume didn't succeed.  Oh -- and of course, you should
> > reinstate all those autosuspend patches.  Otherwise this patch won't 
> > apply!
> 
> OK
> 
> Attached is a dmesg output from 2.6.18-rc6-mm2 with the patch applied.
> It covers two consecutive attempts to suspend (the second one obviously
> failed).

Hmm... The patch didn't yield any output.  Unlike Mattia's log, yours
doesn't include any lines saying "usb usb1: wakeup_rh" so I can't be sure
whether the patch code should have run or not.

Try this patch instead.  It looks for problems occurring a little earlier 
in the call chain.

Alan Stern


Index: mm/drivers/usb/core/hcd-pci.c
===================================================================
--- mm.orig/drivers/usb/core/hcd-pci.c
+++ mm/drivers/usb/core/hcd-pci.c
@@ -406,6 +406,8 @@ int usb_hcd_pci_resume (struct pci_dev *
 			usb_hc_died (hcd);
 		}
 	}
+	dev_dbg(&dev->dev, "Controller %p state after resume %d\n",
+			&dev->dev, dev->dev.power.power_state.event);
 
 	return retval;
 }
Index: mm/drivers/usb/core/driver.c
===================================================================
--- mm.orig/drivers/usb/core/driver.c
+++ mm/drivers/usb/core/driver.c
@@ -1060,6 +1060,8 @@ int usb_resume_both(struct usb_device *u
 	struct usb_interface	*intf;
 	struct usb_device	*parent = udev->parent;
 
+	dev_dbg(&udev->dev, "Device state before resume %d\n", udev->state);
+
 	cancel_delayed_work(&udev->autosuspend);
 	if (udev->state == USB_STATE_NOTATTACHED)
 		return -ENODEV;
@@ -1072,6 +1074,9 @@ int usb_resume_both(struct usb_device *u
 			status = usb_resume_both(parent);
 		} else {
 
+	dev_dbg(&udev->dev, "Parent %p PM state %d\n",
+	udev->dev.parent, udev->dev.parent->power.power_state.event);
+
 			/* We can't progagate beyond the USB subsystem,
 			 * so if a root hub's controller is suspended
 			 * then we're stuck. */
@@ -1094,7 +1099,7 @@ int usb_resume_both(struct usb_device *u
 		}
 	}
 
-	// dev_dbg(&udev->dev, "%s: status %d\n", __FUNCTION__, status);
+	dev_dbg(&udev->dev, "%s: status %d\n", __FUNCTION__, status);
 	return status;
 }
 

Re: [linux-usb-devel] 2.6.18-rc6-mm1 (-mm2): ohci resume problem

[Rafael J. Wysocki]

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

On Wednesday, 13 September 2006 23:01, Alan Stern wrote:
> On Wed, 13 Sep 2006, Rafael J. Wysocki wrote:
> 
> > > The patch below will add some extra debugging information.  We need to
> > > find out why the resume didn't succeed.  Oh -- and of course, you should
> > > reinstate all those autosuspend patches.  Otherwise this patch won't 
> > > apply!
> > 
> > OK
> > 
> > Attached is a dmesg output from 2.6.18-rc6-mm2 with the patch applied.
> > It covers two consecutive attempts to suspend (the second one obviously
> > failed).
> 
> Hmm... The patch didn't yield any output.  Unlike Mattia's log, yours
> doesn't include any lines saying "usb usb1: wakeup_rh" so I can't be sure
> whether the patch code should have run or not.
> 
> Try this patch instead.  It looks for problems occurring a little earlier 
> in the call chain.

I've applied both patches at a time (I hope they don't conflict).

The dmesg output is attached.

Greetings,
Rafael


-- 
You never change things by fighting the existing reality.
		R. Buckminster Fuller

[-- Attachment #2: dmesg-debug-2.log.gz --]
[-- Type: application/x-gzip, Size: 14973 bytes --]

Re: [linux-usb-devel] 2.6.18-rc6-mm1 (-mm2): ohci resume problem

[Alan Stern]

On Wed, 13 Sep 2006, Rafael J. Wysocki wrote:

> > Try this patch instead.  It looks for problems occurring a little earlier 
> > in the call chain.
> 
> I've applied both patches at a time (I hope they don't conflict).
> 
> The dmesg output is attached.

The dmesg output shows the root-hub device state is set wrong.

I have to leave now, so I can't give you another patch to try.  You can 
experiment as follows...

Look in drivers/usb/host/ehci-pci.c, at ehci_pci_resume().  The part of 
interest is everything following the "restart:" statement label.

Try adding some ehci_dbg() lines in there (copy the form of the line just
after restart:).  We want to follow the value of
hcd->self.root_hub->state.  Initially it should be equal to
USB_STATE_SUSPENDED (= 8), and it shouldn't change.  But somewhere it is
getting set to USB_STATE_CONFIGURED (= 7).  I don't know where, but almost 
certainly somewhere in this routine.  If you can find out where that 
happens, I'd appreciate it.

Alan Stern

Re: [linux-usb-devel] 2.6.18-rc6-mm1 (-mm2): ohci resume problem

[Rafael J. Wysocki]

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

On Wednesday, 13 September 2006 23:55, Alan Stern wrote:
> On Wed, 13 Sep 2006, Rafael J. Wysocki wrote:
> 
> > > Try this patch instead.  It looks for problems occurring a little earlier 
> > > in the call chain.
> > 
> > I've applied both patches at a time (I hope they don't conflict).
> > 
> > The dmesg output is attached.
> 
> The dmesg output shows the root-hub device state is set wrong.
> 
> I have to leave now, so I can't give you another patch to try.  You can 
> experiment as follows...
> 
> Look in drivers/usb/host/ehci-pci.c, at ehci_pci_resume().  The part of 
> interest is everything following the "restart:" statement label.
> 
> Try adding some ehci_dbg() lines in there (copy the form of the line just
> after restart:).  We want to follow the value of
> hcd->self.root_hub->state.  Initially it should be equal to
> USB_STATE_SUSPENDED (= 8), and it shouldn't change.  But somewhere it is
> getting set to USB_STATE_CONFIGURED (= 7).  I don't know where, but almost 
> certainly somewhere in this routine.  If you can find out where that 
> happens, I'd appreciate it.

Done, but it shows hcd->self.root_hub->state is already 7 right after restart.

I've used the following patch to verify this:

---
 drivers/usb/host/ehci-pci.c |    8 ++++++++
 1 file changed, 8 insertions(+)

Index: linux-2.6.18-rc6-mm2/drivers/usb/host/ehci-pci.c
===================================================================
--- linux-2.6.18-rc6-mm2.orig/drivers/usb/host/ehci-pci.c
+++ linux-2.6.18-rc6-mm2/drivers/usb/host/ehci-pci.c
@@ -291,14 +291,19 @@ static int ehci_pci_resume(struct usb_hc
 
 restart:
 	ehci_dbg(ehci, "lost power, restarting\n");
+	ehci_dbg(ehci, "root hub state: %d\n", hcd->self.root_hub->state);
 	usb_root_hub_lost_power(hcd->self.root_hub);
+	ehci_dbg(ehci, "root hub state: %d\n", hcd->self.root_hub->state);
 
 	/* Else reset, to cope with power loss or flush-to-storage
 	 * style "resume" having let BIOS kick in during reboot.
 	 */
 	(void) ehci_halt(ehci);
+	ehci_dbg(ehci, "root hub state: %d\n", hcd->self.root_hub->state);
 	(void) ehci_reset(ehci);
+	ehci_dbg(ehci, "root hub state: %d\n", hcd->self.root_hub->state);
 	(void) ehci_pci_reinit(ehci, pdev);
+	ehci_dbg(ehci, "root hub state: %d\n", hcd->self.root_hub->state);
 
 	/* emptying the schedule aborts any urbs */
 	spin_lock_irq(&ehci->lock);
@@ -306,12 +311,15 @@ restart:
 		ehci->reclaim_ready = 1;
 	ehci_work(ehci, NULL);
 	spin_unlock_irq(&ehci->lock);
+	ehci_dbg(ehci, "root hub state: %d\n", hcd->self.root_hub->state);
 
 	/* restart; khubd will disconnect devices */
 	retval = ehci_run(hcd);
+	ehci_dbg(ehci, "root hub state: %d\n", hcd->self.root_hub->state);
 
 	/* here we "know" root ports should always stay powered */
 	ehci_port_power(ehci, 1);
+	ehci_dbg(ehci, "root hub state: %d\n", hcd->self.root_hub->state);
 
 	return retval;
 }

The output of dmesg is attached.

Greetings,
Rafael


-- 
You never change things by fighting the existing reality.
		R. Buckminster Fuller

[-- Attachment #2: dmesg-debug-3.log.gz --]
[-- Type: application/x-gzip, Size: 15082 bytes --]

Re: [linux-usb-devel] 2.6.18-rc6-mm1 (-mm2): ohci resume problem

[Rafael J. Wysocki]

On Thursday, 14 September 2006 15:14, Rafael J. Wysocki wrote:
> On Wednesday, 13 September 2006 23:55, Alan Stern wrote:
> > On Wed, 13 Sep 2006, Rafael J. Wysocki wrote:
> > 
> > > > Try this patch instead.  It looks for problems occurring a little earlier 
> > > > in the call chain.
> > > 
> > > I've applied both patches at a time (I hope they don't conflict).
> > > 
> > > The dmesg output is attached.
> > 
> > The dmesg output shows the root-hub device state is set wrong.
> > 
> > I have to leave now, so I can't give you another patch to try.  You can 
> > experiment as follows...
> > 
> > Look in drivers/usb/host/ehci-pci.c, at ehci_pci_resume().  The part of 
> > interest is everything following the "restart:" statement label.
> > 
> > Try adding some ehci_dbg() lines in there (copy the form of the line just
> > after restart:).  We want to follow the value of
> > hcd->self.root_hub->state.  Initially it should be equal to
> > USB_STATE_SUSPENDED (= 8), and it shouldn't change.  But somewhere it is
> > getting set to USB_STATE_CONFIGURED (= 7).  I don't know where, but almost 
> > certainly somewhere in this routine.  If you can find out where that 
> > happens, I'd appreciate it.
> 
> Done, but it shows hcd->self.root_hub->state is already 7 right after restart.

BTW, all of the systems on which the problem shows up seem to be 64-bit.

If you can't reproduce it on a 32-bit system, some type casting may be wrong
somewhere.

Greetings,
Rafael


-- 
You never change things by fighting the existing reality.
		R. Buckminster Fuller

Re: [linux-usb-devel] 2.6.18-rc6-mm1 (-mm2): ohci resume problem

[Alan Stern]

On Thu, 14 Sep 2006, Rafael J. Wysocki wrote:

> > > Try adding some ehci_dbg() lines in there (copy the form of the line just
> > > after restart:).  We want to follow the value of
> > > hcd->self.root_hub->state.  Initially it should be equal to
> > > USB_STATE_SUSPENDED (= 8), and it shouldn't change.  But somewhere it is
> > > getting set to USB_STATE_CONFIGURED (= 7).  I don't know where, but almost 
> > > certainly somewhere in this routine.  If you can find out where that 
> > > happens, I'd appreciate it.
> > 
> > Done, but it shows hcd->self.root_hub->state is already 7 right after restart.
> 
> BTW, all of the systems on which the problem shows up seem to be 64-bit.
> 
> If you can't reproduce it on a 32-bit system, some type casting may be wrong
> somewhere.

I realized last night what the problem must be.  It's extremely obvious in 
retrospect, but I happen to have a blind spot in this particular area.

All you guys must have CONFIG_USB_SUSPEND turned off.  Mattis certainly 
does; I checked his .config.  Now I hardly ever do any testing without 
CONFIG_USB_SUSPEND, since there's not much point working on power 
management code if your kernel isn't set up to actually suspend devices.
As a result I missed seeing the problems caused by the autosuspend 
changes.

Now of course, the autosuspend stuff has to work properly no matter what 
the kernel configuration is.  I'll go back and rebuild the drivers with 
USB_SUSPEND turned off and see what happens.  With any luck I'll have a 
fix ready in the near future.

Alan Stern

Re: [linux-usb-devel] 2.6.18-rc6-mm1 (-mm2): ohci resume problem

[Alan Stern]

On Thu, 14 Sep 2006, Alan Stern wrote:

> Now of course, the autosuspend stuff has to work properly no matter what 
> the kernel configuration is.  I'll go back and rebuild the drivers with 
> USB_SUSPEND turned off and see what happens.  With any luck I'll have a 
> fix ready in the near future.

This should start fixing things, but I'm not certain it will solve the 
entire problem.  If it doesn't work, send another dmesg log.

Alan Stern



Index: mm/drivers/usb/core/driver.c
===================================================================
--- mm.orig/drivers/usb/core/driver.c
+++ mm/drivers/usb/core/driver.c
@@ -813,7 +813,7 @@ static int suspend_device(struct usb_dev
 	status = udriver->suspend(udev, msg);
 
 done:
-	// dev_dbg(&udev->dev, "%s: status %d\n", __FUNCTION__, status);
+	dev_dbg(&udev->dev, "%s: status %d\n", __FUNCTION__, status);
 	if (status == 0)
 		udev->dev.power.power_state.event = msg.event;
 	return status;
@@ -839,7 +839,7 @@ static int resume_device(struct usb_devi
 	status = udriver->resume(udev);
 
 done:
-	// dev_dbg(&udev->dev, "%s: status %d\n", __FUNCTION__, status);
+	dev_dbg(&udev->dev, "%s: status %d\n", __FUNCTION__, status);
 	if (status == 0)
 		udev->dev.power.power_state.event = PM_EVENT_ON;
 	return status;
@@ -876,7 +876,7 @@ static int suspend_interface(struct usb_
 	}
 
 done:
-	// dev_dbg(&intf->dev, "%s: status %d\n", __FUNCTION__, status);
+	dev_dbg(&intf->dev, "%s: status %d\n", __FUNCTION__, status);
 	if (status == 0)
 		intf->dev.power.power_state.event = msg.event;
 	return status;
@@ -917,7 +917,7 @@ static int resume_interface(struct usb_i
 	}
 
 done:
-	// dev_dbg(&intf->dev, "%s: status %d\n", __FUNCTION__, status);
+	dev_dbg(&intf->dev, "%s: status %d\n", __FUNCTION__, status);
 	if (status == 0)
 		intf->dev.power.power_state.event = PM_EVENT_ON;
 	return status;
@@ -1021,7 +1021,7 @@ int usb_suspend_both(struct usb_device *
 	} else if (parent)
 		usb_autosuspend_device(parent, 0);
 
-	// dev_dbg(&udev->dev, "%s: status %d\n", __FUNCTION__, status);
+	dev_dbg(&udev->dev, "%s: status %d\n", __FUNCTION__, status);
 	return status;
 }
 
@@ -1079,11 +1079,12 @@ int usb_resume_both(struct usb_device *u
 					PM_EVENT_ON)
 				status = -EHOSTUNREACH;
 		}
-		if (status == 0 && udev->state == USB_STATE_SUSPENDED)
+		if (status == 0)
 			status = resume_device(udev);
 		if (parent)
 			mutex_unlock(&parent->pm_mutex);
-	}
+	} else
+		status = resume_device(udev);
 
 	/* Now the parent won't suspend until we are finished */
 
@@ -1094,7 +1095,7 @@ int usb_resume_both(struct usb_device *u
 		}
 	}
 
-	// dev_dbg(&udev->dev, "%s: status %d\n", __FUNCTION__, status);
+	dev_dbg(&udev->dev, "%s: status %d\n", __FUNCTION__, status);
 	return status;
 }
 
Index: mm/drivers/usb/core/hub.c
===================================================================
--- mm.orig/drivers/usb/core/hub.c
+++ mm/drivers/usb/core/hub.c
@@ -1898,6 +1898,8 @@ static int hub_suspend(struct usb_interf
 		if (bus) {
 			int	status = hcd_bus_suspend (bus);
 
+	dev_dbg(&hdev->dev, "bus_suspend %d\n", status);
+
 			if (status != 0) {
 				dev_dbg(&hdev->dev, "'global' suspend %d\n",
 					status);
@@ -1923,6 +1925,9 @@ static int hub_resume(struct usb_interfa
 		struct usb_bus	*bus = hdev->bus;
 		if (bus) {
 			status = hcd_bus_resume (bus);
+
+	dev_dbg(&hdev->dev, "bus_resume %d\n", status);
+
 			if (status) {
 				dev_dbg(&intf->dev, "'global' resume %d\n",
 					status);

Re: [linux-usb-devel] 2.6.18-rc6-mm1 (-mm2): ohci resume problem

[Rafael J. Wysocki]

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

On Thursday, 14 September 2006 18:17, Alan Stern wrote:
> On Thu, 14 Sep 2006, Alan Stern wrote:
> 
> > Now of course, the autosuspend stuff has to work properly no matter what 
> > the kernel configuration is.  I'll go back and rebuild the drivers with 
> > USB_SUSPEND turned off and see what happens.  With any luck I'll have a 
> > fix ready in the near future.
> 
> This should start fixing things, but I'm not certain it will solve the 
> entire problem.  If it doesn't work, send another dmesg log.

Now USB didn't work after the first resume (kernel configured with USB_SUSPEND
unset).

The dmesg output is attached.

Rafael


-- 
You never change things by fighting the existing reality.
		R. Buckminster Fuller

[-- Attachment #2: dmesg-with-fix.log.gz --]
[-- Type: application/x-gzip, Size: 14301 bytes --]

Re: [linux-usb-devel] 2.6.18-rc6-mm1 (-mm2): ohci resume problem

[Rafael J. Wysocki]

On Thursday, 14 September 2006 19:08, Rafael J. Wysocki wrote:
> On Thursday, 14 September 2006 18:17, Alan Stern wrote:
> > On Thu, 14 Sep 2006, Alan Stern wrote:
> > 
> > > Now of course, the autosuspend stuff has to work properly no matter what 
> > > the kernel configuration is.  I'll go back and rebuild the drivers with 
> > > USB_SUSPEND turned off and see what happens.  With any luck I'll have a 
> > > fix ready in the near future.
> > 
> > This should start fixing things, but I'm not certain it will solve the 
> > entire problem.  If it doesn't work, send another dmesg log.
> 
> Now USB didn't work after the first resume (kernel configured with USB_SUSPEND
> unset).

Okay, this is not reproducible, so I gather it was due to my other problem
with the USB resume (sigh).

Anyway, the second suspend/resume worked just fine, so the patch apparently
helps.

Thanks,
Rafael


-- 
You never change things by fighting the existing reality.
		R. Buckminster Fuller

Re: [linux-usb-devel] 2.6.18-rc6-mm1 (-mm2): ohci resume problem

[Alan Stern]

On Thu, 14 Sep 2006, Rafael J. Wysocki wrote:

> Okay, this is not reproducible, so I gather it was due to my other problem
> with the USB resume (sigh).
> 
> Anyway, the second suspend/resume worked just fine, so the patch apparently
> helps.

Doing the simpler tests, with only one USB host driver at a time, is still 
the best way to go.  Once they both work with USB_SUSPEND turned off, 
we'll try them with USB_SUSPEND turned on.

Alan Stern

Re: [linux-usb-devel] 2.6.18-rc6-mm1 (-mm2): ohci resume problem

[Alan Stern]

On Thu, 14 Sep 2006, Rafael J. Wysocki wrote:

> Now USB didn't work after the first resume (kernel configured with USB_SUSPEND
> unset).
> 
> The dmesg output is attached.

This is getting too confusing.  :-(

Let's try a simpler test.  Leave USB_SUSPEND unset.

First rmmod ohci-hcd.  None of your full-speed USB devices will work, but 
that's okay.  Try the suspend-twice test and see what happens.

Second, rmmod ehci-hcd and modprobe ohci-hcd.  Again try the suspend-twice 
test.

Having only one USB host driver loaded at any time should simplify things.

Alan Stern

Re: [linux-usb-devel] 2.6.18-rc6-mm1 (-mm2): ohci resume problem

[Rafael J. Wysocki]

On Thursday, 14 September 2006 19:22, Alan Stern wrote:
> On Thu, 14 Sep 2006, Rafael J. Wysocki wrote:
> 
> > Now USB didn't work after the first resume (kernel configured with USB_SUSPEND
> > unset).
> > 
> > The dmesg output is attached.
> 
> This is getting too confusing.  :-(

Sorry for the confusion.

> Let's try a simpler test.  Leave USB_SUSPEND unset.
> 
> First rmmod ohci-hcd.  None of your full-speed USB devices will work, but 
> that's okay.  Try the suspend-twice test and see what happens.
> 
> Second, rmmod ehci-hcd and modprobe ohci-hcd.  Again try the suspend-twice 
> test.

Done, works (with USB_SUSPEND unset).

Greetings,
Rafael


-- 
You never change things by fighting the existing reality.
		R. Buckminster Fuller

Re: [linux-usb-devel] 2.6.18-rc6-mm1 (-mm2): ohci resume problem

[Alan Stern]

On Thu, 14 Sep 2006, Rafael J. Wysocki wrote:

> > Let's try a simpler test.  Leave USB_SUSPEND unset.
> > 
> > First rmmod ohci-hcd.  None of your full-speed USB devices will work, but 
> > that's okay.  Try the suspend-twice test and see what happens.
> > 
> > Second, rmmod ehci-hcd and modprobe ohci-hcd.  Again try the suspend-twice 
> > test.
> 
> Done, works (with USB_SUSPEND unset).

Okay, good.  Then for the next stage, repeat the same tests but with 
USB_SUSPEND set.

Alan Stern

Re: [linux-usb-devel] 2.6.18-rc6-mm1 (-mm2): ohci resume problem

[Rafael J. Wysocki]

On Thursday, 14 September 2006 21:37, Rafael J. Wysocki wrote:
> On Thursday, 14 September 2006 20:28, Alan Stern wrote:
> > On Thu, 14 Sep 2006, Rafael J. Wysocki wrote:
> > 
> > > > Let's try a simpler test.  Leave USB_SUSPEND unset.
> > > > 
> > > > First rmmod ohci-hcd.  None of your full-speed USB devices will work, but 
> > > > that's okay.  Try the suspend-twice test and see what happens.
> > > > 
> > > > Second, rmmod ehci-hcd and modprobe ohci-hcd.  Again try the suspend-twice 
> > > > test.
> > > 
> > > Done, works (with USB_SUSPEND unset).
> > 
> > Okay, good.
> 
> Well, sorry.  This test has been passed, but after a reboot it refused to
> suspend just once giving the same messages that I've got from the kernel
> with USB_SUSPEND set (the relevant dmesg output is attached).

This only happens if _both_ ohci_hcd and ehci_hcd are loaded before the
suspend.
 
> > Then for the next stage, repeat the same tests but with  
> > USB_SUSPEND set.
> 
> Compiling.

The results are now the same with and without USB_SUSPEND set.  Namely,
if one hcd is loaded before a suspend (either ehci or ohci), it succeeds
(repeatable arbitrary number of times in a row).  However, if both hcds are
loaded before a suspend, it fails (100% of the time) and the messages are
like in the dmesg output attached to the previous message.

I've reproduced this behavior on another x86_64 box.

Greetings,
Rafael


-- 
You never change things by fighting the existing reality.
		R. Buckminster Fuller

Re: [linux-usb-devel] 2.6.18-rc6-mm1 (-mm2): ohci resume problem

[Alan Stern]

On Thu, 14 Sep 2006, Rafael J. Wysocki wrote:

> Well, sorry.  This test has been passed, but after a reboot it refused to
> suspend just once giving the same messages that I've got from the kernel
> with USB_SUSPEND set (the relevant dmesg output is attached).
> 
> > Then for the next stage, repeat the same tests but with  
> > USB_SUSPEND set.

Okay, hang on, let's try to solve this first.

This actually is a completely different problem from what I've been
attacking up to now, and we definitely should resolve it.  It's purely a
question of the ohci-hcd driver, nothing (or very little) to do with
usbcore or ehci-hcd or uhci-hcd.

I'm asking David to chime in, because this is his code and his driver.

Here's an explanation of the problem.  Basically it boils down to the way 
ohci-hcd rolls its own root-hub autosuspend.  I'm referring to the call to 
ohci_bus_suspend() near the end of ohci-hub.c:ohci_hub_status_data().
Things go wrong because that call totally bypasses usbcore.  It's a 
layering violation.

The corresponding root-hub autoresume code, i.e., the call to
usb_hcd_resume_root_hub() in ohci-hcd.c:ohci_irq(), _does_ go through
usbcore.  It fails for two reasons.  First, resume_root_hub does its job
by queuing a call to usb_autoresume_device(), and when CONFIG_USB_SUSPEND
isn't set that routine is a no-op.  Second, since usbcore was never
notified when the root hub was suspended, the root hub's device state
isn't USB_STATE_SUSPENED and the interface is still marked as active -- so
even if usb_autoresume_device() did get called it wouldn't do anything.

As I see it, there are two ways to resolve the problem.  The easiest is to
rip out the autosuspend stuff from ohci-hcd entirely.  When my generic
autosuspend patches are accepted, the HCD-specific stuff won't be needed
so much.  This has the disadvantage that the root hub will never get
suspended if CONFIG_USB_SUSPEND isn't set.  On the other hand, this is how 
ehci_hcd works already.

The second way is to copy what I did in uhci-hcd.  There is a special
"root hub is stopped" mode which kicks in only when no ports are
connected.  It isn't a full-fledged suspend, in the sense that usbcore
isn't notified -- just like what happens in ohci-hcd.  The difference is,
since we know no devices are attached, the driver can go back to normal
operation while in interrupt context.  It doesn't have to sleep because no
attached devices means no TRSMRCY delay is needed and the controller's
hardware can be reset directly.  As a result, the corresponding
"auto-restart" code doesn't need to go through usbcore either and so
usb_autoresume_device() never enters the picture.

I don't know if this is feasible with OHCI.  For now, I'll include a patch 
that takes the first approach and disables the ohci-hcd autosuspend 
entirely.  I think it will solve your problem above.

Alan Stern


Index: mm/drivers/usb/host/ohci-hub.c
===================================================================
--- mm.orig/drivers/usb/host/ohci-hub.c
+++ mm/drivers/usb/host/ohci-hub.c
@@ -391,17 +391,6 @@ ohci_hub_status_data (struct usb_hcd *hc
 done:
 	spin_unlock_irqrestore (&ohci->lock, flags);
 
-#ifdef	CONFIG_PM
-	/* save power by autosuspending idle root hubs;
-	 * INTR_RD wakes us when there's work
-	 */
-	if (can_suspend && usb_trylock_device (hcd->self.root_hub) == 0) {
-		ohci_vdbg (ohci, "autosuspend\n");
-		(void) ohci_bus_suspend (hcd);
-		usb_unlock_device (hcd->self.root_hub);
-	}
-#endif
-
 	return changed ? length : 0;
 }
 

Re: [linux-usb-devel] 2.6.18-rc6-mm1 (-mm2): ohci resume problem

[Rafael J. Wysocki]

On Thursday, 14 September 2006 22:55, Alan Stern wrote:
> On Thu, 14 Sep 2006, Rafael J. Wysocki wrote:
> 
> > Well, sorry.  This test has been passed, but after a reboot it refused to
> > suspend just once giving the same messages that I've got from the kernel
> > with USB_SUSPEND set (the relevant dmesg output is attached).
> > 
> > > Then for the next stage, repeat the same tests but with  
> > > USB_SUSPEND set.
> 
> Okay, hang on, let's try to solve this first.
> 
> This actually is a completely different problem from what I've been
> attacking up to now, and we definitely should resolve it.  It's purely a
> question of the ohci-hcd driver, nothing (or very little) to do with
> usbcore or ehci-hcd or uhci-hcd.
> 
> I'm asking David to chime in, because this is his code and his driver.
> 
> Here's an explanation of the problem.  Basically it boils down to the way 
> ohci-hcd rolls its own root-hub autosuspend.  I'm referring to the call to 
> ohci_bus_suspend() near the end of ohci-hub.c:ohci_hub_status_data().
> Things go wrong because that call totally bypasses usbcore.  It's a 
> layering violation.
> 
> The corresponding root-hub autoresume code, i.e., the call to
> usb_hcd_resume_root_hub() in ohci-hcd.c:ohci_irq(), _does_ go through
> usbcore.  It fails for two reasons.  First, resume_root_hub does its job
> by queuing a call to usb_autoresume_device(), and when CONFIG_USB_SUSPEND
> isn't set that routine is a no-op.  Second, since usbcore was never
> notified when the root hub was suspended, the root hub's device state
> isn't USB_STATE_SUSPENED and the interface is still marked as active -- so
> even if usb_autoresume_device() did get called it wouldn't do anything.
> 
> As I see it, there are two ways to resolve the problem.  The easiest is to
> rip out the autosuspend stuff from ohci-hcd entirely.  When my generic
> autosuspend patches are accepted, the HCD-specific stuff won't be needed
> so much.  This has the disadvantage that the root hub will never get
> suspended if CONFIG_USB_SUSPEND isn't set.  On the other hand, this is how 
> ehci_hcd works already.

This isn't a big deal as far as I'm concerned, but I think that dependancy
will have to be reflected by some Kconfig rules (eg. if CONFIG_USB_SUSPEND
gets selected automatically if CONFIG_PM is set).

> The second way is to copy what I did in uhci-hcd.  There is a special
> "root hub is stopped" mode which kicks in only when no ports are
> connected.  It isn't a full-fledged suspend, in the sense that usbcore
> isn't notified -- just like what happens in ohci-hcd.  The difference is,
> since we know no devices are attached, the driver can go back to normal
> operation while in interrupt context.  It doesn't have to sleep because no
> attached devices means no TRSMRCY delay is needed and the controller's
> hardware can be reset directly.  As a result, the corresponding
> "auto-restart" code doesn't need to go through usbcore either and so
> usb_autoresume_device() never enters the picture.
> 
> I don't know if this is feasible with OHCI.  For now, I'll include a patch 
> that takes the first approach and disables the ohci-hcd autosuspend 
> entirely.  I think it will solve your problem above.

Yes it does.

Now I'm able to suspend/resume several times in a row with both
ohci and ehci hcds loaded all the time.  Thanks a lot!

Greetings,
Rafael


-- 
You never change things by fighting the existing reality.
		R. Buckminster Fuller

Re: [linux-usb-devel] 2.6.18-rc6-mm1 (-mm2): ohci resume problem

[Alan Stern]

On Thu, 14 Sep 2006, Rafael J. Wysocki wrote:

> > As I see it, there are two ways to resolve the problem.  The easiest is to
> > rip out the autosuspend stuff from ohci-hcd entirely.  When my generic
> > autosuspend patches are accepted, the HCD-specific stuff won't be needed
> > so much.  This has the disadvantage that the root hub will never get
> > suspended if CONFIG_USB_SUSPEND isn't set.  On the other hand, this is how 
> > ehci_hcd works already.
> 
> This isn't a big deal as far as I'm concerned, but I think that dependancy
> will have to be reflected by some Kconfig rules (eg. if CONFIG_USB_SUSPEND
> gets selected automatically if CONFIG_PM is set).

Ultimately the best thing will be for CONFIG_USB_SUSPEND simply to 
disappear.  That's the long-term goal.  It was never intended to be much 
more than a stop-gap setting, for use while the USB suspend/resume 
routines were under development and not entirely reliable.

> > I don't know if this is feasible with OHCI.  For now, I'll include a patch 
> > that takes the first approach and disables the ohci-hcd autosuspend 
> > entirely.  I think it will solve your problem above.
> 
> Yes it does.
> 
> Now I'm able to suspend/resume several times in a row with both
> ohci and ehci hcds loaded all the time.  Thanks a lot!

You're welcome.

I'll wait to hear Dave's comments before submitting this.

Alan Stern

Re: [linux-usb-devel] 2.6.18-rc6-mm1 (-mm2): ohci resume problem

[Rafael J. Wysocki]

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

On Thursday, 14 September 2006 17:04, Alan Stern wrote:
> On Thu, 14 Sep 2006, Rafael J. Wysocki wrote:
> 
> > > > Try adding some ehci_dbg() lines in there (copy the form of the line just
> > > > after restart:).  We want to follow the value of
> > > > hcd->self.root_hub->state.  Initially it should be equal to
> > > > USB_STATE_SUSPENDED (= 8), and it shouldn't change.  But somewhere it is
> > > > getting set to USB_STATE_CONFIGURED (= 7).  I don't know where, but almost 
> > > > certainly somewhere in this routine.  If you can find out where that 
> > > > happens, I'd appreciate it.
> > > 
> > > Done, but it shows hcd->self.root_hub->state is already 7 right after restart.
> > 
> > BTW, all of the systems on which the problem shows up seem to be 64-bit.
> > 
> > If you can't reproduce it on a 32-bit system, some type casting may be wrong
> > somewhere.
> 
> I realized last night what the problem must be.  It's extremely obvious in 
> retrospect, but I happen to have a blind spot in this particular area.
> 
> All you guys must have CONFIG_USB_SUSPEND turned off.  Mattis certainly 
> does; I checked his .config.  Now I hardly ever do any testing without 
> CONFIG_USB_SUSPEND, since there's not much point working on power 
> management code if your kernel isn't set up to actually suspend devices.
> As a result I missed seeing the problems caused by the autosuspend 
> changes.

Well, on my box the USB suspend also doesn't work with USB_SUSPEND set,
but the reason is different:

sb usb2: 'global' suspend -16
hub 2-0:1.0: suspend error -16
suspend_device(): usb_suspend+0x0/0x5b [usbcore]() returns -16
Could not suspend device usb2: error -16

The .config and full dmesg output (with the three debug patches applied) are
attached.

Greetings,
Rafael


-- 
You never change things by fighting the existing reality.
		R. Buckminster Fuller

[-- Attachment #2: dmesg-usb-suspend.log.gz --]
[-- Type: application/x-gzip, Size: 15471 bytes --]

[-- Attachment #3: kernel-config.gz --]
[-- Type: application/x-gzip, Size: 12931 bytes --]

Re: [linux-usb-devel] 2.6.18-rc6-mm1 (-mm2): ohci resume problem

[Mattia Dongili]

On Wed, Sep 13, 2006 at 02:38:35PM -0400, Alan Stern wrote:
> On Wed, 13 Sep 2006, Rafael J. Wysocki wrote:
> 
> > Well, I have reproduced it with gregkh-usb-usbcore-remove-usb_suspend_root_hub.patch
> > reverted too.
> > 
> > Attached is the output of dmesg from the failing case with USB_DEBUG set.
> > It covers two attempts to suspend to disk, the second one being unsuccessful,
> > with reloading the ohci_hcd module in between.  [This kernel also has your
> > other patch to prevent the second suspend from failing applied, but it doesn't
> > help.]
> 
> Okay.  Your problem, and probably Mattia's too, is something other than
> what that recent patch addressed.  I can't tell from the dmesg log exactly
> what went wrong, but I can tell you where to look.
> 
> In drivers/usb/core/driver.c, resume_device() is not succeeding.  That is, 
> the lines near the end which do
> 
> 	if (status == 0)
> 		udev->dev.power.power_state.event = PM_EVENT_ON;
> 
> aren't running during the first resume.  You can see this in the dmesg 
> log; lines 1173-1175 say
> 
> 	usb usb1: resuming
> 	 usbdev1.1_ep00: PM: resume from 0, parent usb1 still 1
> 	hub 1-0:1.0: PM: resume from 0, parent usb1 still 1
> 
> If power_state.event had gotten set to PM_EVENT_ON then the parent state 
> would be 0, not 1.  This is the source of your problem.  During your 
> second suspend attempt, usb1 didn't get handled correctly because its 
> state was set wrong.  (I suspect the mishandling took place in usbcore 
> rather than the PM core, but it doesn't matter.  The state should not have 
> been wrong to begin with.)  Consequently its parent device 0000:00:13.2 
> refused to freeze, which aborted the suspend attempt.
> 
> For the usb1 device, udriver->resume should point to the generic_resume() 
> routine in drivers/usb/core/generic.c.  In fact, this should be true for 
> every device that driver.c:resume_device() sees.  But generic_resume() 
> simply calls usb_port_resume() in hub.c, and the log doesn't contain any 
> of the USB debugging messages that usb_port_resume() would produce.  So I 
> can't tell what happened.
> 
> The patch below will add some extra debugging information.  We need to
> find out why the resume didn't succeed.  Oh -- and of course, you should
> reinstate all those autosuspend patches.  Otherwise this patch won't 
> apply!

ok, with USB_DEBUG=y and this is with your first patch still applied
http://oioio.altervista.org/linux/dmesg-2.6.18-rc6-mm1-verbose-usb-try2

this is without it:
http://oioio.altervista.org/linux/dmesg-2.6.18-rc6-mm1-verbose-usb-try3

I hope I'm not mixing thing too much with Rafael :)

Thanks
-- 
mattia
:wq!

Re: [linux-usb-devel] 2.6.18-rc6-mm1 (-mm2): ohci resume problem

[Alan Stern]

On Wed, 13 Sep 2006, Mattia Dongili wrote:

> > The patch below will add some extra debugging information.  We need to
> > find out why the resume didn't succeed.  Oh -- and of course, you should
> > reinstate all those autosuspend patches.  Otherwise this patch won't 
> > apply!
> 
> ok, with USB_DEBUG=y and this is with your first patch still applied
> http://oioio.altervista.org/linux/dmesg-2.6.18-rc6-mm1-verbose-usb-try2
> 
> this is without it:
> http://oioio.altervista.org/linux/dmesg-2.6.18-rc6-mm1-verbose-usb-try3
> 
> I hope I'm not mixing thing too much with Rafael :)

No.  But this log doesn't include the debugging output in the patch from 
my previous message.

Alan Stern

Re: [linux-usb-devel] 2.6.18-rc6-mm1 (-mm2): ohci resume problem

[Mattia Dongili]

On Wed, Sep 13, 2006 at 04:54:13PM -0400, Alan Stern wrote:
> On Wed, 13 Sep 2006, Mattia Dongili wrote:
> 
> > > The patch below will add some extra debugging information.  We need to
> > > find out why the resume didn't succeed.  Oh -- and of course, you should
> > > reinstate all those autosuspend patches.  Otherwise this patch won't 
> > > apply!
> > 
> > ok, with USB_DEBUG=y and this is with your first patch still applied
> > http://oioio.altervista.org/linux/dmesg-2.6.18-rc6-mm1-verbose-usb-try2
> > 
> > this is without it:
> > http://oioio.altervista.org/linux/dmesg-2.6.18-rc6-mm1-verbose-usb-try3
> > 
> > I hope I'm not mixing thing too much with Rafael :)
> 
> No.  But this log doesn't include the debugging output in the patch from 
> my previous message.

doh! I'm pretty sure the patch is applied...
$ patch -p1 --dry-run < ../add_usb_debug.patch
patching file drivers/usb/core/driver.c
Reversed (or previously applied) patch detected!  Assume -R? [n]

Will try again with USB_SUSPEND=y, tomorrow I'll try to find some time
to test all the other things you suggested  (if still necessary) :)
-- 
mattia
:wq!

Re: [linux-usb-devel] 2.6.18-rc6-mm1 (-mm2): ohci resume problem

[Alan Stern]

On Thu, 14 Sep 2006, Mattia Dongili wrote:

> > No.  But this log doesn't include the debugging output in the patch from 
> > my previous message.
> 
> doh! I'm pretty sure the patch is applied...
> $ patch -p1 --dry-run < ../add_usb_debug.patch
> patching file drivers/usb/core/driver.c
> Reversed (or previously applied) patch detected!  Assume -R? [n]

Actually I was wrong to think the patch wasn't in there just because it
didn't produce any output.

> Will try again with USB_SUSPEND=y, tomorrow I'll try to find some time
> to test all the other things you suggested  (if still necessary) :)

No, don't do that.  Keep USB_SUSPEND=n, and try only the most recent patch
I sent to Rafael:

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

I know for certain that some of Rafael's problems are different from 
yours, because his involve ehci-hcd and ohci-hcd whereas you have only 
UHCI controllers.

Alan Stern

Re: [linux-usb-devel] 2.6.18-rc6-mm1 (-mm2): ohci resume problem

[Mattia Dongili]

On Thu, Sep 14, 2006 at 04:25:26PM -0400, Alan Stern wrote:
> On Thu, 14 Sep 2006, Mattia Dongili wrote:
[...]
> > Will try again with USB_SUSPEND=y, tomorrow I'll try to find some time
> > to test all the other things you suggested  (if still necessary) :)
> 
> No, don't do that.  Keep USB_SUSPEND=n, and try only the most recent patch

damn! (hitting ctrl-c) :)

> I sent to Rafael:
> 
> http://marc.theaimsgroup.com/?l=linux-kernel&m=115825076000987&w=2
> 
> I know for certain that some of Rafael's problems are different from 
> yours, because his involve ehci-hcd and ohci-hcd whereas you have only 
> UHCI controllers.

ok, will do. But please allow some time (can go back to you tomorrow) as
I'm in low-spare-time-mode...

-- 
mattia
:wq!

Re: [linux-usb-devel] 2.6.18-rc6-mm1 (-mm2): ohci resume problem

[Mattia Dongili]

On Thu, Sep 14, 2006 at 04:25:26PM -0400, Alan Stern wrote:
> On Thu, 14 Sep 2006, Mattia Dongili wrote:
[...]
> > Will try again with USB_SUSPEND=y, tomorrow I'll try to find some time
> > to test all the other things you suggested  (if still necessary) :)
> 
> No, don't do that.  Keep USB_SUSPEND=n, and try only the most recent patch
> I sent to Rafael:
> 
> http://marc.theaimsgroup.com/?l=linux-kernel&m=115825076000987&w=2
> 
> I know for certain that some of Rafael's problems are different from 
> yours, because his involve ehci-hcd and ohci-hcd whereas you have only 
> UHCI controllers.

Yay! this patch fixes the issue. It already survived 3 susp/resume
cycles.
Log is here:
http://oioio.altervista.org/linux/dmesg-2.6.18-rc6-mm1-usb-susp

Do you want to see a test run with USB_SUSPEND=y? (well I'll try it out
anyway)

Thanks again
PS: sadly spamcop has my provider in its blacklists, linux-usb-devel
didn't receive any of my mails...
-- 
mattia
:wq!

Re: [linux-usb-devel] 2.6.18-rc6-mm1 (-mm2): ohci resume problem

[Alan Stern]

On Sat, 16 Sep 2006, Mattia Dongili wrote:

> Yay! this patch fixes the issue. It already survived 3 susp/resume
> cycles.
> Log is here:
> http://oioio.altervista.org/linux/dmesg-2.6.18-rc6-mm1-usb-susp
> 
> Do you want to see a test run with USB_SUSPEND=y? (well I'll try it out
> anyway)

Then so far it looks good...  I'll submit this patch early next week.

Alan Stern