Re: keyboard under X with 2.6.31

[Boyan <btanastasov@yahoo.co.uk>]

On Wed, 7 Oct 2009 17:19:25 -0300, Frédéric L. W. Meunier wrote:
> My keyboard (ABNT2 PS/2) seems to be broken under X with 2.6.31.2.
> After less than an hour, it starts acting crazy. The first time, all
> leds turned off and I couldn't type anything. The second time, all
> leds > also turned off, but since it happened while I was pressing the
> Backspace key to delete text, it continued deleting, like if the key
> was pressed.
>
> In both cases, the mouse (USB) still works and I can exit X, where the
> keyboard works. There's nothing in the logs.
>
> No problem with 2.6.30.9. Is it supposed to be a kernel or X bug ?

Something similar is happening with my keyboard too. With 2.6.31 after
some time the keyboard stops under X on my Fedora 11. I can switch to
text console only after SysRq+R. When go back to X the keyboard is
working, but after some time it stops again. 


I can trigger it easily with gthumb quickly changing pictures, but it is
possible with other cpu intensive operations too. To be sure I've tested
with previous X 1.6.3-4 which was from August and I've used it without
problems with 2.6.30 and 2.6.30.3. It was replaced on 18 Sep 2009 by
1.6.4 RC (installed update after 2.6.31). The problem is reproducible on
both of X versions with 2.6.31, 2.6.31.3 and 2.6.32-rc3.

I've bisected this and the result is:

e043e42bdb66885b3ac10d27a01ccb9972e2b0a3 is first bad commit
commit e043e42bdb66885b3ac10d27a01ccb9972e2b0a3
Author: OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>
Date:   Wed Jul 29 12:15:56 2009 -0700

     pty: avoid forcing 'low_latency' tty flag

     We really don't want to mark the pty as a low-latency device, 
because as
     Alan points out, the ->write method can be called from an IRQ (ppp?),
     and that means we can't use ->low_latency=1 as we take mutexes in the
     low_latency case.

     So rather than using low_latency to force the written data to be pushed
     to the ldisc handling at 'write()' time, just make the reader side (or
     the poll function) do the flush when it checks whether there is data to
     be had.

     This also fixes the problem with lost data in an emacs compile buffer
     (bugzilla 13815), and we can thus revert the low_latency pty hack
     (commit 3a54297478e6578f96fd54bf4daa1751130aca86: "pty: quickfix 
for the
     pty ENXIO timing problems").

     Signed-off-by: OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>
     Tested-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
     [ Modified to do the tty_flush_to_ldisc() inside input_available_p() so
       that it triggers for both read and poll()  - Linus]
     Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

:040000 040000 52e7420b2aa2360632dd965e56b96510619d34e2 
5156b59352d1350cb9b4d452581dd84d24d5a541 M      drivers
:040000 040000 f0a333b7faa0ce80a57e2ee8536e79a6fe33ac35 
b3968b239ac3f64c57f17bb10034b98559f1ffa2 M      include


Reverting this patch on top of 2.6.31.3 fixes it for me.