On Fri, 28 Mar 2008, Linus Torvalds wrote:

quoted text
> > 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

--
unsubscribe notice
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/