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 -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
