From owner-freebsd-hackers Thu Oct 17 10:05:22 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id KAA12390 for hackers-outgoing; Thu, 17 Oct 1996 10:05:22 -0700 (PDT) Received: from rocky.mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id KAA12371 for ; Thu, 17 Oct 1996 10:05:16 -0700 (PDT) Received: (from nate@localhost) by rocky.mt.sri.com (8.7.5/8.7.3) id LAA18599; Thu, 17 Oct 1996 11:04:29 -0600 (MDT) Date: Thu, 17 Oct 1996 11:04:29 -0600 (MDT) Message-Id: <199610171704.LAA18599@rocky.mt.sri.com> From: Nate Williams To: "Jordan K. Hubbard" Cc: "Brian N. Handy" , freebsd-hackers@freebsd.org Subject: Re: 2.2-961006-SNAP keyboard lockup In-Reply-To: <3664.845570375@time.cdrom.com> References: <3664.845570375@time.cdrom.com> Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > I do occasionally have keyboard lockups too, but only under X. > > When it locks up, is it possible to run this from a mouse menu button > or something and see if it fixes it? > > echo "set ipending=2" | gdb -k -w /kernel /dev/mem >/dev/null 2>&1 Make sure this process is run as 'root' or it won't work. (I know only too well about that problem, and I know have a suid program which does the above I can call from a menu.) > I have the same problem, but it only happens when I xmodmap the > keyboard to swap my capslock and DEL keys. Before I did this (the > result of switching keyboards to one which didn't do it in hardware), > I never had a problem at all. I don't use xmodmap at all on my box and I see it *all* the time, at least once/week. (I switched the CL and DEL keys with a new keymap in syscons). However, if Jordan is still using his M$ Natural keyboard then we have something in common. It's also not X-related, as I've locked things up outside of X although X seems to 'perturb' the system as it happens much more often in X. I can also lockup vty switching by attempting to switch out of X before it's completely initialized, which confuses the heck out of syscons. If it's any consolation, the *exact* same behavior occurs under SCO, so syscons is doing a pretty good job of emulating both the good and bad features of the SCO console driver. :) Nate