[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <1206742499.22530.90.camel@johannes.berg>
Date: Fri, 28 Mar 2008 23:14:59 +0100
From: Johannes Berg <johannes@...solutions.net>
To: Linus Torvalds <torvalds@...ux-foundation.org>
Cc: Arjan van de Ven <arjan@...ux.intel.com>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
NetDev <netdev@...r.kernel.org>, Dmitry Torokhov <dtor@...l.ru>
Subject: Re: Oops/Warning report for the week of March 28th 2008
> 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..
Unfortunately, it takes forever on this machine to compile a kernel
after any bigger changes. I can do it early next week when I have access
to my bigger box again.
On the other hand, it should be easily reproducible by anyone else with
the same trick, here's what I do:
* configure X to use /dev/input/event* devices
* in an xterm, do something like
rmmod usbhid ; modprobe usbhid
* switch to a VT
* watch kernel crash as X releases the grab on the event device
Mind you, I actually did this with the appletouch driver, but I don't
think it makes a difference since the problematic thing is the code that
X grabs the device. A trivial program that executes the grab ioctl would
probably suffice if you leave it running over a rmmod/modprobe cycle.
johannes
Download attachment "signature.asc" of type "application/pgp-signature" (829 bytes)
Powered by blists - more mailing lists