Hi,
I'm having the following problem: after I start X11 (or gpm with no X)
my keyboard and PS/2 mouse sometimes locks up. What could that be?
440BX UP celeron mobo here (Abit - BH6?), '94 AT keyboard, '2000 A4tech
2-wheel mouse, various Linux 2.4 versions (usually -ac, currently 2.4.10ac3).
I'm using NVidia Xserver module, but it doesn't seem related (the lookup
occured with no X while starting gpm once or twice).
If I kill Xserver (haven't tried with gpm), the keyboard (and mouse) start
working again (the next Xserver spawn works fine).
For me, it looks like some race condition between open_aux and mouse
(kbd?) interrupt, causing interrupts or kbd controller to stay disabled
after the mouse device is opened. The interrupt counters for both kbd
and psaux stay constant when I move the mouse and/or press buttons/keyboard
keys:
intrepid:~$ cat /proc/interrupts
CPU0
0: 1528212 XT-PIC timer
1: 6 XT-PIC keyboard
2: 0 XT-PIC cascade
3: 189554 XT-PIC serial
9: 1587447 XT-PIC acpi, nvidia
11: 15215 XT-PIC usb-uhci, eth0, eth1
12: 2 XT-PIC PS/2 Mouse
14: 49181 XT-PIC ide0
15: 1 XT-PIC ide1
NMI: 0
ERR: 3
I'm currently keeping this machine in locked state, so I can provide more
info.
What I also found is that open_aux routine isn't protected by lock_kernel(),
while release_aux is. Is that correct? Would a mouse interrupt received
before open_aux() is completed cause such a lookup?
--
Krzysztof Halasa
Network Administrator
On Tue, Oct 09, 2001 at 12:21:48PM +0200, Krzysztof Halasa wrote:
> I'm having the following problem: after I start X11 (or gpm with no X)
> my keyboard and PS/2 mouse sometimes locks up. What could that be?
I have the same problem. However the lockup most often occurs after
switching with Ctrl+Alt+Fx from plain text console to X. PS/2 mouse +
keyboard, gpm running.
> 440BX UP celeron mobo here (Abit - BH6?), '94 AT keyboard, '2000 A4tech
> 2-wheel mouse, various Linux 2.4 versions (usually -ac, currently 2.4.10ac3).
> I'm using NVidia Xserver module, but it doesn't seem related (the lookup
> occured with no X while starting gpm once or twice).
I had this problem for quite some time with 2.2.x and 2.4.x kernels,
XFree86 3.3.x -- 4.1.0 and S3 Trio3D / NVidia TNT2 M64 / NVidia
GeForce2. Lockups with S3 convice me that NVidia module is probably
irrelevant here.
> If I kill Xserver (haven't tried with gpm), the keyboard (and mouse) start
> working again (the next Xserver spawn works fine).
I've found out that ssh'ing to the host and running chvt 1 (as root)
helps. Switching back to X usually works fine.
I haven't tried monitoring /proc/interrupts, but even the magic SysRq
doesn't work during the lock-up.
P.S. I'm not subscribed to linux-kernel.
Marius Gedminas
--
"I'll be Bach." -- Johann Sebastian Schwarzenegger
On Thu, Oct 11, 2001 at 10:04:06PM +0200, Koos Vriezen wrote:
> I had the same symptoms, console input froze for several minutes. I tried
> several things and after disabling CONFIG_X86_UP_APIC in the kernel, it
> didn't occur anymore (but I'm not sure it's the cause).
CONFIG_X86_UP_APIC is disabled on my system.
Today I tried some experimenting: after repeatedly switching between vt1
and vt7 for some time I got the lockup. Syslog didn't contain any
interesting messages. The counters for keyboard and PS/2 mouse in
/proc/interrupts became stuck. One interesting thing I noticed is that
PS/2 mouse line disappeared for a short time during console switch.
While gpm was running, fuser and lsof indicate that it didn't have
/dev/mouse open -- only XFree86 did.
I've waited for about 30 minutes for any keyboard timeouts to appear,
but didn't see any. Then I tried chvt 7 with no effect (vt7 was already
the active console). Then chvt 1 fixed the lockup. Interrupt counters
went alive again. This time fuser and lsof showed that /dev/mouse is
opened by gpm only. It looks like both XFree and gpm close /dev/mouse
when they're not active, and reopen it then they become active.
I'm now compiling 2.4.9 with some printk()s added in open_aux and
release_aux. If I get any interesting results, I'll post them here.
Marius Gedminas
--
When all else fails, read the instructions.
Hi,
The original problem description:
> I'm having the following problem: after I start X11 (or gpm with no X)
> my keyboard and PS/2 mouse sometimes locks up. What could that be?
>
> 440BX UP celeron mobo here (Abit - BH6?), '94 AT keyboard, '2000 A4tech
> 2-wheel mouse, various Linux 2.4 versions (usually -ac, currently 2.4.10ac3).
> I'm using NVidia Xserver module, but it doesn't seem related (the lookup
> occured with no X while starting gpm once or twice).
>
> If I kill Xserver (haven't tried with gpm), the keyboard (and mouse) start
> working again (the next Xserver spawn works fine).
>
> For me, it looks like some race condition between open_aux and mouse
> (kbd?) interrupt, causing interrupts or kbd controller to stay disabled
> after the mouse device is opened. The interrupt counters for both kbd
> and psaux stay constant when I move the mouse and/or press buttons/keyboard
> keys:
I finally found some free time for investigation. It seems the problem is
the mouse + the keyboard controller - it's A4Tech WWW-something mouse
with 3 buttons and 2 wheels (PS/2 Intellimouse-compatible). The mother-
board is Abit BH6 (slot-1, Intel 440BX + Winbond W83977 - I'm not sure
which IC works as the keyboard controller).
The following script hangs on dd (keyboard hangs as well) on my system
after few seconds:
q=0;
while :; do
(echo -en '\xe8\x03'; dd bs=1 count=2 >/dev/null)<>/dev/psaux 1>&0;
q=$[$q+1];
echo $q;
done
(If you want to check this script on your system, remember it may lock
your PS/2 mouse and keyboard and you may need to use remote shell to kill
the script - closing /dev/psaux makes keyboard alive again). Of course,
it's pointless to run it if you don't have PS/2 mouse. Before running
the script, make sure no processes have /dev/psaux open (kill gpm, Xserver
etc).
The script basically opens /dev/psaux (the kernel initializes mouse),
writes E8 03 (two bytes) there, tries to read 2 bytes back, then closes
the psaux. It looks like under some circumstances, the mouse does something
really bad to the keyboard controller and then it stops requesting
interrupts.
After swapping the mouse with old MS 2-key one, the script no longer
hangs the keyboard. I'm not sure if the (A4Tech) mouse can cause malfunction
to other machines (with other motherboards), but it doesn't do any harm
to my notebook (internal mouse off).
Last accesses to the keyboard controller before a hang (gpm start):
Dec 15 20:46:46 kernel: CMD D4 KBD_CCMD_WRITE_MOUSE
Dec 15 20:46:46 kernel: STA 3F
Dec 15 20:46:46 kernel: INP FA
Dec 15 20:46:46 kernel: STA 3C
Dec 15 20:46:46 kernel: OUT F3 AUX_SET_SAMPLE
Dec 15 20:46:46 kernel: STA 34
Dec 15 20:46:46 kernel: CMD D4 KBD_CCMD_WRITE_MOUSE
Dec 15 20:46:46 kernel: STA 3D
Dec 15 20:46:46 kernel: INP FA
Dec 15 20:46:46 kernel: STA 3C
Dec 15 20:46:46 kernel: OUT 64 (100)
Dec 15 20:46:46 kernel: STA 34
Dec 15 20:46:46 kernel: CMD D4 KBD_CCMD_WRITE_MOUSE
Dec 15 20:46:46 kernel: STA 3D
Dec 15 20:46:46 kernel: INP FA
Dec 15 20:46:46 kernel: STA 3C
Dec 15 20:46:46 kernel: OUT E8 AUX_SET_RES
Dec 15 20:46:46 kernel: STA 34
Dec 15 20:46:46 kernel: CMD D4 KBD_CCMD_WRITE_MOUSE
Dec 15 20:46:46 kernel: STA 3F
Dec 15 20:46:46 kernel: INP FA
Dec 15 20:46:46 kernel: STA 3C
Dec 15 20:46:46 kernel: OUT 03 (3)
Dec 15 20:46:46 kernel: STA 34 <<<<<<<<<<< status = 34 here
Dec 15 20:46:55 root: kbd and mouse dead
CMD - command write, STA - status read, INP - data read, OUT - data write.
The last mouse command is E8 03 (AUX_SET_RES 3).
gpm started without a hang:
...
Dec 15 20:44:44 kernel: INP FA
Dec 15 20:44:44 kernel: STA 3C
Dec 15 20:44:44 kernel: OUT 03 (3)
Dec 15 20:44:44 kernel: STA 35 <<<<<<<<<<< status is different here
Dec 15 20:44:44 kernel: INP FA
Dec 15 20:44:46 kernel: STA 15
Dec 15 20:44:46 kernel: INP 1C
Dec 15 20:44:46 kernel: STA 15
Dec 15 20:44:46 kernel: INP 9C
Dec 15 20:44:46 kernel: STA 14
Dec 15 20:44:47 root: kbd ok
I've noted that the status after the AUX_SET_RES(3) command is always
0x35 when there is no hang, and 0x34 or 0x36 otherwise.
The question is - is the hardware (kbd controller or mouse) faulty,
or should we do something to it in the kernel?
--
Krzysztof Halasa
Network Administrator
I just got a Tyan Tiger K7 and experienced a similar problem. The
keyboard locked up when gpm started, but it came back after I
stopped gpm (by logging in remotely). I discovered in my BIOS that
the mouse was configured to "Automatic". Changing it to "Enabled"
fixed my problem.
I suggest checking your BIOS for anything related to the mouse. It
could be occurring because the interrupt is not getting assigned
for the mouse by the BIOS, or something to that effect. That is
what my thoughts are on this problem. After seeing reports of the
interrupt counts in /proc/interrupts not being updated while the
mouse (/dev/psaux) is opened, it made me think that it could be an
IRQ problem.