On Mon, 12 Oct 2009, Nix wrote: > On 12 Oct 2009, Justin P. Mattock uttered the following: > > > Not sure where this stands. Right now all three machines I have seem to be having no issues with the kayboard > > (xserver 1.6.*) I can go and build the latest xserver(1.7) to see if I hit something. > [...] > >> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14388 > >> Subject : keyboard under X with 2.6.31 > >> Submitter : Frédéric L. W. Meunier <fredlwm@xxxxxxxxx> > >> Date : 2009-10-07 20:19 (5 days old) > >> First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=e043e42bdb66885b3ac10d27a01ccb9972e2b0a3 > >> References : http://marc.info/?l=linux-kernel&m=125494753228217&w=4 > > I have been seeing problems precisely like those described (sometimes > the keyboard dies, sometimes it gets 'stuck' with a key held down, until > I switch TTYs, which generally means killing X as I'm not aware of an > easy way to switch VTs using only the mouse), since I moved to 2.6.31 The particular commit that was bisected to should really not matter for X, except perhaps from a timing standpoint. The problem it fixed was in pty's, and X doesn't use them much if at all (various X _programs_ may, of course, but the symptoms don't sound like it's just a particular X app that has issues, but more of a generic X keyboard handling thing) But for non-pty's, there should be no semantic changes from that commit outside of some general tty timing differences by doing that tty_flush_to_ldisc() at new points. I could fairly easily imagine that some timing difference does expose another longer-standing problem in either the kernel or X itself. So the bisection isn't necessarily wrong, it's just not likely telling us what the real problem is. Of course, maybe there is some race condition in the tty_buffer.c code. We _used_ to not call flush_to_ldisc() except through the workqueue code, so races would not be seen in normal circumstances. Now that flush_to_ldisc() could easily get called both synchronously from tty_read()/tty_poll(), while also being hit from the workqueues. Alan, Ogawa-san, do either of you see some problem in tty_buffer.c, perhaps? Linus -- To unsubscribe from this list: send the line "unsubscribe kernel-testers" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
