![]() | ||||||||||
Messages in this thread |
On Fri, 28 Mar 2008, Linus Torvalds wrote: > > I tend to think it's actually a regression, I've done exactly what I > > described there dozens of times before on older kernels and it doesn't > > seem to be a race condition, X always locks the input device and I > > never had trouble with that before. > Ahh. So it's easily repeatable for you.. Do you think you could bisect it? > At least a few runs? Even a partial bisection will give a nice (== much > smaller) range of commits to be blamed, and might tell us why it started > happening.. ... and if bisecting the whole tree isn't the way for you to go right now, maybe restricting to drivers/input/ and drivers/base/ (as I think this might be some broken driver core refcounting) and possibly drivers/hid/ (if you are using any HID input device) might also be sufficient. -- Jiri Kosina SUSE Labs -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ | |||||||||
| Last update: 2008-03-28 22:19 [W:0.262 / U:0.030 seconds] ©2003-2008 Jasper Spaans | ||||||||||