SPONSORED LINKS
Well, thanks to a suggestion provoked by my question, i have a workaround for the keyboard-freeze problem i've been having with the 2.0.0 kernel. The workaround is to start X - i now use Redhat's runlevel 5, instead of the tty-console runlevel 3, and the problem simply doesn't show. Here's the response from Andries Brouwer which inspired this workaround (thanks, Andries!): On Sat, 22 Jun 1996, Andries.Brouwer@cwi.nl wrote: Ken Manheimer: > : What's odd is that, once the keyboard is locked out, *no* keystrokes > : are recognized - not only are regular keystrokes ignored, as is > : ctrl-alt-delete, but the special Thinkpad BIOS keystrokes - > : configuration (Fn-F1), screen toggle Fn-F3, volume Fn-PgUp Fn-PgDn - > : also have no effect! > > Yes. What seems to be happening is that the keyboard receives > the first byte of a two-byte command (like set leds or set repeat rate > or choose scancode set) and then sits waiting for the second byte. > Sending another byte by writing directly to the ioport revives the > keyboard. You can have this as a menu item. > > Different people have this problem for different kernel versions; > it may be timing related. What's interesting is that i don't have to do anything but start X - i didn't even have to figure out how to send a byte directly to the keyboard ioport. Both X and the virtual consoles all work fine, with no further finagling. And i have an X session on VC 7 all the time, which is not a bad way to operate... Thanks, everyone. Ken Manheimer klm@cnri.reston.va.us 703 620-8990 x268 (orporation for National Research |nitiatives 1895 Preston White Drive, Suite 100 Reston, VA 22091