Linux amd 2.6.32-rc6-00498-g05b553a-dirty #89 SMP Fri Nov 13 10:43:31
CET 2009 i686 GNU/Linux
...and yes, it is a regression. Hw is thinkpad x60.
Tried to suspend, machine came right back, used radio kill switch, and
it suspended ok. Relevant messages seem to be:
Pavel
PM: Preparing system for mem sleep
Freezing user space processes ... (elapsed 0.02 seconds) done.
Freezing remaining freezable tasks ... (elapsed 0.00 seconds) done.
PM: Entering mem sleep
usb 5-2: usb suspend
btusb_intr_complete: hci0 urb f3b57420 failed to resubmit (1)
uhci_hcd 0000:00:1d.3: release dev 2 ep81-INT, period 1, phase 0, 23
us
btusb_bulk_complete: hci0 urb f3b57680 failed to resubmit (1)
btusb_bulk_complete: hci0 urb f3b57718 failed to resubmit (1)
usb 5-1: usb suspend
usb 5-1: usb auto-resume
uhci_hcd 0000:00:1d.3: port 1 portsc 0095,01
usb 5-1: finish resume
uhci_hcd 0000:00:1d.3: reserve dev 2 ep81-INT, period 1, phase 0, 23
us
hub 5-0:1.0: port 1 nyet suspended
hub 5-0:1.0: suspend error -16
pm_op(): usb_dev_suspend+0x0/0x10 returns -16
PM: Device usb5 failed to suspend: error -16
PM: Some devices failed to suspend
thinkpad_acpi: ACPI backlight control delay disabled
usb 5-2: usb resume
uhci_hcd 0000:00:1d.3: port 2 portsc 00a5,01
usb 5-2: finish resume
usb usb4: usb resume
usb usb4: wakeup_rh
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
On Mon 2009-11-16 12:48:29, Oliver Neukum wrote:
> Am Montag, 16. November 2009 12:22:54 schrieb Pavel Machek:
>
> Hi Pavle,
:-)
> first the obvious question. Does it work if you down the interface?
> (not by killswitch)
Well, I'm not sure how repeatable it is. It happens once in two tries
today.
> > usb 5-1: usb suspend
> > usb 5-1: usb auto-resume
> > uhci_hcd 0000:00:1d.3: port 1 portsc 0095,01
> > usb 5-1: finish resume
> > uhci_hcd 0000:00:1d.3: reserve dev 2 ep81-INT, period 1, phase 0, 23
> > us
>
> Why is the device autoresumed here? Are you using autosuspend?
> This is odd, as the freezer should block the send path and remote
> wakeups should be deferred.
I believe I have it enabled in kconfig but not during runtime.
(Another problem is that I need to turn the kill switch on/off to get
my bt usb after resume. That used not be the case long time ago.)
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Am Montag, 16. November 2009 12:22:54 schrieb Pavel Machek:
Hi Pavle,
first the obvious question. Does it work if you down the interface?
(not by killswitch)
> usb 5-1: usb suspend
> usb 5-1: usb auto-resume
> uhci_hcd 0000:00:1d.3: port 1 portsc 0095,01
> usb 5-1: finish resume
> uhci_hcd 0000:00:1d.3: reserve dev 2 ep81-INT, period 1, phase 0, 23
> us
Why is the device autoresumed here? Are you using autosuspend?
This is odd, as the freezer should block the send path and remote
wakeups should be deferred.
Regards
Oliver
Am Montag, 16. November 2009 12:22:54 schrieb Pavel Machek:
> Linux amd 2.6.32-rc6-00498-g05b553a-dirty #89 SMP Fri Nov 13 10:43:31
> CET 2009 i686 GNU/Linux
>
> ...and yes, it is a regression. Hw is thinkpad x60.
>
> Tried to suspend, machine came right back, used radio kill switch, and
> it suspended ok. Relevant messages seem to be:
I forgot to ask. Is this repeatable? The code is build on the assumption
that workqueues are frozen as the system calls suspend for system
sleep. If that assumption is wrong, a race can lead to this failure.
Is it wrong?
Regards
Oliver
Am Samstag, 14. November 2009 12:10:21 schrieb Pavel Machek:
> On Mon 2009-11-16 12:48:29, Oliver Neukum wrote:
> > Am Montag, 16. November 2009 12:22:54 schrieb Pavel Machek:
> >
> > Hi Pavle,
> >
> :-)
> :
> > first the obvious question. Does it work if you down the interface?
> > (not by killswitch)
>
> Well, I'm not sure how repeatable it is. It happens once in two tries
> today.
Ok, so it looks like a race.
> > > usb 5-1: usb suspend
> > > usb 5-1: usb auto-resume
> > > uhci_hcd 0000:00:1d.3: port 1 portsc 0095,01
> > > usb 5-1: finish resume
> > > uhci_hcd 0000:00:1d.3: reserve dev 2 ep81-INT, period 1, phase 0, 23
> > > us
> >
> > Why is the device autoresumed here? Are you using autosuspend?
> > This is odd, as the freezer should block the send path and remote
> > wakeups should be deferred.
>
> I believe I have it enabled in kconfig but not during runtime.
Please check.
> (Another problem is that I need to turn the kill switch on/off to get
> my bt usb after resume. That used not be the case long time ago.)
That is possibly another problem.
Regards
Oliver
On Mon 2009-11-16 14:43:20, Oliver Neukum wrote:
> Am Montag, 16. November 2009 12:22:54 schrieb Pavel Machek:
> > Linux amd 2.6.32-rc6-00498-g05b553a-dirty #89 SMP Fri Nov 13 10:43:31
> > CET 2009 i686 GNU/Linux
> >
> > ...and yes, it is a regression. Hw is thinkpad x60.
> >
> > Tried to suspend, machine came right back, used radio kill switch, and
> > it suspended ok. Relevant messages seem to be:
>
> I forgot to ask. Is this repeatable? The code is build on the
It happened once...
> assumption
> that workqueues are frozen as the system calls suspend for system
> sleep. If that assumption is wrong, a race can lead to this failure.
> Is it wrong?
There are two kinds of workqueues -- AFAICT -- kind one is frozen,
kind two is not.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
On Mon, 16 Nov 2009, Oliver Neukum wrote:
> Am Samstag, 14. November 2009 12:10:21 schrieb Pavel Machek:
> > On Mon 2009-11-16 12:48:29, Oliver Neukum wrote:
> > > Am Montag, 16. November 2009 12:22:54 schrieb Pavel Machek:
> > >
> > > Hi Pavle,
> > >
> > :-)
> > :
> > > first the obvious question. Does it work if you down the interface?
> > > (not by killswitch)
> >
> > Well, I'm not sure how repeatable it is. It happens once in two tries
> > today.
>
> Ok, so it looks like a race.
>
> > > > usb 5-1: usb suspend
> > > > usb 5-1: usb auto-resume
> > > > uhci_hcd 0000:00:1d.3: port 1 portsc 0095,01
> > > > usb 5-1: finish resume
> > > > uhci_hcd 0000:00:1d.3: reserve dev 2 ep81-INT, period 1, phase 0, 23
> > > > us
> > >
> > > Why is the device autoresumed here? Are you using autosuspend?
> > > This is odd, as the freezer should block the send path and remote
> > > wakeups should be deferred.
> >
> > I believe I have it enabled in kconfig but not during runtime.
>
> Please check.
If you want to learn the source of the autoresume, do something like
this:
Index: usb-2.6/drivers/usb/core/hub.c
===================================================================
--- usb-2.6.orig/drivers/usb/core/hub.c
+++ usb-2.6/drivers/usb/core/hub.c
@@ -2334,6 +2334,8 @@ int usb_port_resume(struct usb_device *u
/* drive resume for at least 20 msec */
dev_dbg(&udev->dev, "usb %sresume\n",
(msg.event & PM_EVENT_AUTO ? "auto-" : ""));
+ if ((msg.event & PM_EVENT_AUTO) && udev->maxchild == 0)
+ dump_stack();
msleep(25);
/* Virtual root hubs can trigger on GET_PORT_STATUS to
This will show you what is responsible for all autoresumes of non-hub
USB devices.
Alan Stern
On Mon 2009-11-16 14:43:20, Oliver Neukum wrote:
> Am Montag, 16. November 2009 12:22:54 schrieb Pavel Machek:
> > Linux amd 2.6.32-rc6-00498-g05b553a-dirty #89 SMP Fri Nov 13 10:43:31
> > CET 2009 i686 GNU/Linux
> >
> > ...and yes, it is a regression. Hw is thinkpad x60.
> >
> > Tried to suspend, machine came right back, used radio kill switch, and
> > it suspended ok. Relevant messages seem to be:
>
> I forgot to ask. Is this repeatable? The code is build on the assumption
> that workqueues are frozen as the system calls suspend for system
> sleep. If that assumption is wrong, a race can lead to this failure.
> Is it wrong?
I (shortly) tried to repeat it but could not.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Hi!
> > > Why is the device autoresumed here? Are you using autosuspend?
> > > This is odd, as the freezer should block the send path and remote
> > > wakeups should be deferred.
> >
> > I believe I have it enabled in kconfig but not during runtime.
>
> Please check.
CONFIG_USB_SUSPEND=y
I'm not aware of boot scripts enabling anything.
> > (Another problem is that I need to turn the kill switch on/off to get
> > my bt usb after resume. That used not be the case long time ago.)
>
> That is possibly another problem.
Yes, I guess so. With those many USB experts around, I thought I'd
mention it :-).
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html