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.
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 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.