Bug 13624

Reassigning to USB.

(switched to email.  Please respond via emailed reply-to-all, not via the
bugzilla web interface).

On Thu, 25 Jun 2009 18:18:45 GMT
bugzilla-daemon@bugzilla.kernel.org wrote:

> http://bugzilla.kernel.org/show_bug.cgi?id=13624
> 
>            Summary: usb: wrong autosuspend initialization
>            Product: Power Management
>            Version: 2.5
>     Kernel Version: 2.6.30
>           Platform: All
>         OS/Version: Linux
>               Tree: Mainline
>             Status: NEW
>           Severity: normal
>           Priority: P1
>          Component: Other
>         AssignedTo: power-management_other@kernel-bugs.osdl.org
>         ReportedBy: list@phuk.ath.cx
>         Regression: Yes
> 
> 
> My optical usb mouse (Logitech MX500, 046d:c025) turns its LED off after 2
> seconds of idling. That means I have to press a button to wake it up again.
> 
> This happens only if it's connected at bootup:
> # cat /sys/bus/usb/devices/2-1/power/level
> auto
> 
> then after I replug it:
> # cat /sys/bus/usb/devices/2-1/power/level
> on
> 
> which then results in the desired behaviour (LED stays on). This is new since
> 2.6.30. I'm using the gentoo patchset, but I'll assume they didn't tamper
> with
> usb autosuspend there.
> 

Seems to be a 2.6.29->2.6.30 regression.

On Thu, 25 Jun 2009, Andrew Morton wrote:

> > http://bugzilla.kernel.org/show_bug.cgi?id=13624
> > 
> >            Summary: usb: wrong autosuspend initialization

> > My optical usb mouse (Logitech MX500, 046d:c025) turns its LED off after 2
> > seconds of idling. That means I have to press a button to wake it up again.
> > 
> > This happens only if it's connected at bootup:
> > # cat /sys/bus/usb/devices/2-1/power/level
> > auto
> > 
> > then after I replug it:
> > # cat /sys/bus/usb/devices/2-1/power/level
> > on
> > 
> > which then results in the desired behaviour (LED stays on). This is new
> since
> > 2.6.30. I'm using the gentoo patchset, but I'll assume they didn't tamper
> with
> > usb autosuspend there.
> > 
> 
> Seems to be a 2.6.29->2.6.30 regression.

This should be rejected as a duplicate of Bug #13505.

Alan Stern

On Thu, 25 Jun 2009, Andrew Morton wrote:

> > http://bugzilla.kernel.org/show_bug.cgi?id=13624
> > 
> >            Summary: usb: wrong autosuspend initialization

> > My optical usb mouse (Logitech MX500, 046d:c025) turns its LED off after 2
> > seconds of idling. That means I have to press a button to wake it up again.
> > 
> > This happens only if it's connected at bootup:
> > # cat /sys/bus/usb/devices/2-1/power/level
> > auto
> > 
> > then after I replug it:
> > # cat /sys/bus/usb/devices/2-1/power/level
> > on
> > 
> > which then results in the desired behaviour (LED stays on). This is new
> since
> > 2.6.30. I'm using the gentoo patchset, but I'll assume they didn't tamper
> with
> > usb autosuspend there.
> > 
> 
> Seems to be a 2.6.29->2.6.30 regression.

This should be rejected as a duplicate of Bug #13505.

Alan Stern

On Thu, 25 Jun 2009 15:15:14 -0400 (EDT)
Alan Stern <stern@rowland.harvard.edu> wrote:

> On Thu, 25 Jun 2009, Andrew Morton wrote:
> 
> > > http://bugzilla.kernel.org/show_bug.cgi?id=13624
> > > 
> > >            Summary: usb: wrong autosuspend initialization
> 
> > > My optical usb mouse (Logitech MX500, 046d:c025) turns its LED off after
> 2
> > > seconds of idling. That means I have to press a button to wake it up
> again.
> > > 
> > > This happens only if it's connected at bootup:
> > > # cat /sys/bus/usb/devices/2-1/power/level
> > > auto
> > > 
> > > then after I replug it:
> > > # cat /sys/bus/usb/devices/2-1/power/level
> > > on
> > > 
> > > which then results in the desired behaviour (LED stays on). This is new
> since
> > > 2.6.30. I'm using the gentoo patchset, but I'll assume they didn't tamper
> with
> > > usb autosuspend there.
> > > 
> > 
> > Seems to be a 2.6.29->2.6.30 regression.
> 
> This should be rejected as a duplicate of Bug #13505.
> 

But #13505 was closed as "invalid".

That's two people now whose systems have falied when they switched from
a 2.6.29 kernel to a 2.6.30 kernel.  That is a kernel-caused regression.

What is the justification for not fixing this kernel-caused regression
within the kernel?

On Thu, 25 Jun 2009, Andrew Morton wrote:

> > > Seems to be a 2.6.29->2.6.30 regression.
> > 
> > This should be rejected as a duplicate of Bug #13505.
> > 
> 
> But #13505 was closed as "invalid".
> 
> That's two people now whose systems have falied when they switched from
> a 2.6.29 kernel to a 2.6.30 kernel.  That is a kernel-caused regression.

"Causality" can be a peculiar notion.  This particular bad effect is a
result of a combination of features in userspace and in the kernel.  
(Bug #13505 was determined to be "caused" by a bogus udev rule.)  Why
should we therefore conclude that the effect is a kernel regression?

> What is the justification for not fixing this kernel-caused regression
> within the kernel?

Suppose the kernel contained a bug whereby the kill(2) system call
always failed when targeted at the current process's session leader.  
Suppose furthermore that a user had in his .bash_profile script a line
that attempted to kill the current login shell.

Fixing the kernel bug would suddenly cause that user's login sessions
to die immediately.  Does this mean that fixing the bug introduced a
regression?  What would be the justification for not fixing this
kernel-caused regression within the kernel?

This may sound silly or facetious, but it is very analogous to the 
situation in Bug #13505 and presumably in this Bug.

I suggest that the bug reporter search for a udev rule under either 
/lib/udev or /etc/udev which writes "auto" to the mouse's power/level 
attribute.  Perhaps Marcus can tell us exactly where he found the bogus 
rule on his system.

Alan Stern

On Thu, 25 Jun 2009 16:21:51 -0400 (EDT)
Alan Stern <stern@rowland.harvard.edu> wrote:

> On Thu, 25 Jun 2009, Andrew Morton wrote:
> 
> > > > Seems to be a 2.6.29->2.6.30 regression.
> > > 
> > > This should be rejected as a duplicate of Bug #13505.
> > > 
> > 
> > But #13505 was closed as "invalid".
> > 
> > That's two people now whose systems have falied when they switched from
> > a 2.6.29 kernel to a 2.6.30 kernel.  That is a kernel-caused regression.
> 
> "Causality" can be a peculiar notion.  This particular bad effect is a
> result of a combination of features in userspace and in the kernel.  
> (Bug #13505 was determined to be "caused" by a bogus udev rule.)  Why
> should we therefore conclude that the effect is a kernel regression?

A "kernel-caused regression" is different from a "kernel regression".

We need to be practical here.  Look at the effects of each change and
work out what we should do so as to produce the best result for real
people using Linux in the real world.

I have in the past rejected outright bugfixes because fixing the bug
could break existing userspace.  Such is life.

> I suggest that the bug reporter search for a udev rule under either 
> /lib/udev or /etc/udev which writes "auto" to the mouse's power/level 
> attribute.  Perhaps Marcus can tell us exactly where he found the bogus 
> rule on his system.

Well that would help, and hopefully the number of people who are
hitting this is small.

But if the problem turns out to be significantly widespread then sure,
we may end up deciding to provide a workaround in the kernel.

For practical reasons.

ah well, I don't have any UDEV rules related to this, but I *do* have laptop-mode enabling usb-autosuspend. It'd still be a regression, but maybe there needs to be some discussion about whose responsibility it is to decide which devices should generally *not* be autosuspended. I'd say it's userspace who needs to care about that, but let's see...

On Thu, 25 Jun 2009, Andrew Morton wrote:

> We need to be practical here.  Look at the effects of each change and
> work out what we should do so as to produce the best result for real
> people using Linux in the real world.
> 
> I have in the past rejected outright bugfixes because fixing the bug
> could break existing userspace.  Such is life.
> 
> > I suggest that the bug reporter search for a udev rule under either 
> > /lib/udev or /etc/udev which writes "auto" to the mouse's power/level 
> > attribute.  Perhaps Marcus can tell us exactly where he found the bogus 
> > rule on his system.
> 
> Well that would help, and hopefully the number of people who are
> hitting this is small.
> 
> But if the problem turns out to be significantly widespread then sure,
> we may end up deciding to provide a workaround in the kernel.
> 
> For practical reasons.

All right, here is a practical patch disabling autosuspend support in 
usbhid.  I hope we don't have to apply it.

Alan Stern

-----------------------------------------------------------------------


THis patch disables autosuspend in the usbhid driver.  Apparently too
many people have bogus udev scripts that activate autosuspend for
mice which can't support it properly.

Signed-off-by: Alan Stern <stern@rowland.harvard.edu>

---

Index: 2.6.30/drivers/hid/usbhid/hid-core.c
===================================================================
--- 2.6.30.orig/drivers/hid/usbhid/hid-core.c
+++ 2.6.30/drivers/hid/usbhid/hid-core.c
@@ -1377,7 +1377,8 @@ static struct usb_driver hid_driver = {
 	.pre_reset =	hid_pre_reset,
 	.post_reset =	hid_post_reset,
 	.id_table =	hid_usb_ids,
-	.supports_autosuspend = 1,
+/* Disable this until bogus udev scripts aren't so widespread */
+/*	.supports_autosuspend = 1,	*/
 };
 
 static const struct hid_device_id hid_usb_table[] = {

Reply-To: ich@phuk.ath.cx

Andrew Morton wrote:
> On Thu, 25 Jun 2009 16:21:51 -0400 (EDT)
> Alan Stern <stern@rowland.harvard.edu> wrote:
> 
>> On Thu, 25 Jun 2009, Andrew Morton wrote:
>>
>>>>> Seems to be a 2.6.29->2.6.30 regression.
>>>> This should be rejected as a duplicate of Bug #13505.
>>>>
>>> But #13505 was closed as "invalid".
>>>
>>> That's two people now whose systems have falied when they switched from
>>> a 2.6.29 kernel to a 2.6.30 kernel.  That is a kernel-caused regression.
>> "Causality" can be a peculiar notion.  This particular bad effect is a
>> result of a combination of features in userspace and in the kernel.  
>> (Bug #13505 was determined to be "caused" by a bogus udev rule.)  Why
>> should we therefore conclude that the effect is a kernel regression?
> 
> A "kernel-caused regression" is different from a "kernel regression".
> 
> We need to be practical here.  Look at the effects of each change and
> work out what we should do so as to produce the best result for real
> people using Linux in the real world.
> 
> I have in the past rejected outright bugfixes because fixing the bug
> could break existing userspace.  Such is life.
> 
>> I suggest that the bug reporter search for a udev rule under either 
>> /lib/udev or /etc/udev which writes "auto" to the mouse's power/level 
>> attribute.  Perhaps Marcus can tell us exactly where he found the bogus 
>> rule on his system.
> 
> Well that would help, and hopefully the number of people who are
> hitting this is small.
> 
> But if the problem turns out to be significantly widespread then sure,
> we may end up deciding to provide a workaround in the kernel.
> 
> For practical reasons.

Alright, it was laptop-mode setting everything to auto-suspend. Dunno 
what else might fiddle with this, but maybe if we can get laptop-mode to 
deal with it quickly enough, the impact might be limited.
But why did it work before? How did the kernel know it shouldn't 
auto-suspend my mouse, even if userspace tells it to?

On Thu, 25 Jun 2009 16:50:51 -0400 (EDT)
Alan Stern <stern@rowland.harvard.edu> wrote:

> THis patch disables autosuspend in the usbhid driver.  Apparently too
> many people have bogus udev scripts that activate autosuspend for
> mice which can't support it properly.
> 
> Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
> 
> ---
> 
> Index: 2.6.30/drivers/hid/usbhid/hid-core.c
> ===================================================================
> --- 2.6.30.orig/drivers/hid/usbhid/hid-core.c
> +++ 2.6.30/drivers/hid/usbhid/hid-core.c
> @@ -1377,7 +1377,8 @@ static struct usb_driver hid_driver = {
>       .pre_reset =    hid_pre_reset,
>       .post_reset =   hid_post_reset,
>       .id_table =     hid_usb_ids,
> -     .supports_autosuspend = 1,
> +/* Disable this until bogus udev scripts aren't so widespread */
> +/*   .supports_autosuspend = 1,      */
>  };

mmmm..

a) we don't yet have enough data to know whether this is necessary

b) the patch doesn't provide us a way of ever fixing things up.  Is
there any way in which the kernel can detect the problem and then emit
a "hey, fix your junk" printk?

Reply-To: ich@phuk.ath.cx

Andrew Morton wrote:
> On Thu, 25 Jun 2009 16:50:51 -0400 (EDT)
> Alan Stern <stern@rowland.harvard.edu> wrote:
> 
>> THis patch disables autosuspend in the usbhid driver.  Apparently too
>> many people have bogus udev scripts that activate autosuspend for
>> mice which can't support it properly.
>>
>> Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
>>
>> ---
>>
>> Index: 2.6.30/drivers/hid/usbhid/hid-core.c
>> ===================================================================
>> --- 2.6.30.orig/drivers/hid/usbhid/hid-core.c
>> +++ 2.6.30/drivers/hid/usbhid/hid-core.c
>> @@ -1377,7 +1377,8 @@ static struct usb_driver hid_driver = {
>>      .pre_reset =    hid_pre_reset,
>>      .post_reset =   hid_post_reset,
>>      .id_table =     hid_usb_ids,
>> -    .supports_autosuspend = 1,
>> +/* Disable this until bogus udev scripts aren't so widespread */
>> +/*  .supports_autosuspend = 1,      */
>>  };
> 
> mmmm..
> 
> a) we don't yet have enough data to know whether this is necessary
> 
> b) the patch doesn't provide us a way of ever fixing things up.  Is
> there any way in which the kernel can detect the problem and then emit
> a "hey, fix your junk" printk?
> 

Right. Well then I guess I'll go tell laptop-mode to refrain from 
autosuspending my input devices...

Reply-To: oliver@neukum.org

Am Donnerstag, 25. Juni 2009 22:55:56 schrieb ich:
> But why did it work before? How did the kernel know it shouldn't
> auto-suspend my mouse, even if userspace tells it to?

It didn't. The kernel just got better at suspending HID devices.
If you kill X under 2.6.29, it will also suspend your mouse
and resume it when open the mouse again. It just couldn't use
remote wakeup with HID devices.

	Regards
		Oliver

Reply-To: oliver@neukum.org

Am Donnerstag, 25. Juni 2009 23:01:18 schrieb Andrew Morton:
> b) the patch doesn't provide us a way of ever fixing things up.  Is
> there any way in which the kernel can detect the problem and then emit
> a "hey, fix your junk" printk?

No, we cannot detect this and the devices operate within spec.
A device tells us whether it supports remote wakeup or not with a single
bit. If it is not supported, we don't autosuspend. Otherwise we are at
the mercy of the device. We cannot tell what it takes to make a HID device
request a remote wakeup.

	Regards
		Oliver

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Alan Stern wrote:
> I suggest that the bug reporter search for a udev rule under either 
> /lib/udev or /etc/udev which writes "auto" to the mouse's power/level 
> attribute.  Perhaps Marcus can tell us exactly where he found the bogus 
> rule on his system.

I had a local udev rule that ran the script
/lib/udev/usb-enable-autosuspend that I created, probably after a tip on
the linux-thinkpad mailing list:

http://www.nabble.com/Re:-100--activity-from-fingerprint-reader-even-with-usbcore.autosuspend=1--p20222912.html

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkpIhK4ACgkQXjXn6TzcAQn7bQCg1jGmgvTJVb/NLYngR68dCy/T
lkAAoIjgM5VQu1FefFaDqRRr17MLehP+
=KrKk
-----END PGP SIGNATURE-----

In this case, the problem has been determined to be caused by the 
"laptop-mode" package.  Reconfiguring it should solve the problem.  
If it does, this bug report can be rejected as invalid.

Alan Stern

Alan Stern wrote:
> In this case, the problem has been determined to be caused by the 
> "laptop-mode" package.  Reconfiguring it should solve the problem.  
> If it does, this bug report can be rejected as invalid.
> 
> Alan Stern
> 

Disabling usb autosuspend altogether does solve the problem. However 
laptop_mode currently supports no further differentiation. There's only 
all-on or all-off. I've reported this to their mailing list, and Bart 
seems to agree that laptop_mode can be fixed to allow some 
differentiation. But it doesn't look like there's anyone working on it 
yet. So... don't know how to proceed. Maybe I'll cough something up, but 
not right now.

On Monday 27 July 2009, Alan Stern wrote:
> On Sun, 26 Jul 2009, Rafael J. Wysocki wrote:
> 
> > This message has been generated automatically as a part of a report
> > of regressions introduced between 2.6.29 and 2.6.30.
> > 
> > The following bug entry is on the current list of known regressions
> > introduced between 2.6.29 and 2.6.30.  Please verify if it still should
> > be listed and let me know (either way).
> > 
> > 
> > Bug-Entry   : http://bugzilla.kernel.org/show_bug.cgi?id=13624
> > Subject             : usb: wrong autosuspend initialization
> > Submitter   :  <list@phuk.ath.cx>
> > Date                : 2009-06-25 18:18 (32 days old)
> 
> There's some question as to whether this should be considered a kernel 
> bug.  The kernel isn't doing anything wrong; the problem is that 
> various userspace programs enable autosuspend for devices that can't 
> support it properly.

Dropping from the list of regressions 2.6.29 -> 2.6.30.