Bug 54989

Keyboard freezes whenever i move the mouse although there's no mouse cursor 
movement

Hi.  I've seen what appears to be the same problem.  Here is a report of my
observations...

I have a machine with RH 6.2 and 7.1 partitions, where the mouse (Logitech
3-button PS/2) and keyboard (standard US 104 or 105 key) work fine.  I installed
RH 7.2 on a third partition and the installation goes smoothly.  I could use my
mouse and keyboard during installation just fine.  When I boot into RH 7.2, bad
things happen when I try to run X.  The mouse never moves, the keyboard doesn't
do anything. (eg. Ctrl-Alt-Backspace, GNOME keybindings, Crt-Alt-F2 and other
virtual terminals don't work)  This behavior is seen with both Xconfigurator and
startx.  It also happens with and without gpm running.  A typical scenario is to
run Xconfigurator, try to use the mouse and keyboard, and then after 10 seconds
it times out and brings me back to Xconfigurator's screen after the 10 second X
test.  Often, my keyboard will be thoroughly screwed up, with keys being
exchanged or acting as if I have Ctrl pressed all the time.  Randomly pressing
keys will often eventually lead to a keyboard reset which fixes it, or else the
machine reboots.  Sometimes logging in remotely and killing gpm helps reset the
lockup, but doesn't help me run X successfully. mouseconfig repeatedly fails to
recognize the mouse.  I've tried copying my /etc/sysconfig/mouse,
/etc/sysconfig/keyboard, XF86Config, and XF86Config-4 files from my RH 7.1
partition but it does not improve the situation.  I spent quite a while
troubleshooting involving rebooting, running Xconfigurator and mouseconfig, and
twiddling the config files listed above and the problem is chronic.

I noted that IRQ assignments for the mouse and keyboard were the same in my 7.1
and 7.2 partitions.

In trying to identify whether this was a kernel-level failure or higher level, I
booted into my RH 7.2 root partition (which includes /usr and everything else in
the / partition) but with my RH 7.1 kernel.  (I think I upgraded and rebuilt the
kernel for my RH 7.1 partition months ago.  At a glance, it looks like it is
2.4.2.)  This completely solved the problem, with mouseconfig finding the mouse
and startx running just fine.

So, I'm guessing something happened to PS/2 support in the Linux kernel roughly
between versions 2.4.2 and 2.4.8.  I know others are using PS/2 mice with RH 7.2
without problems, so it must be some more obscure case where it fails.  There
isn't much special about my PC's hardware AFAIK though.  I have USB on my
system, but no attached devices.

I could just run with the older kernel, but this seems like a nasty bug that may
persist without some real effort, so I'd be happy to help troubleshoot the
problem. 

andrewl - How well do these details fit with your observations?  You mention in
your report that you did not have problems with 7.0, but you had problems with
7.1.  You didn't mention 7.2 in your description though.  So X and your mouse
work for you with 7.0, but fails with 7.1 and 7.2?

Dan
d-mueth

After a discussion between Greg Leblanc and msw about this bug, Greg moved this
over to the kernel component.

Andrew Lee answered the question I posed to him above in an email.  It isn't
really private, so I expect he won't mind me posting his reply:

---
Yes I found both 7.1 and 7.2 has problem with PS/2 mouse and Keyboard. The
problem with 7.2 is a little different.
7.2 loaded up fine but with no mouse cursor. I can input things from keyboard
but as soon as i try moving the mouse
it froze up the keyboard.
I didn't really fix the problem but what i did was switch my mouse to serial. So
I think the problem is there's a
conflict with the keyboard and PS/2 adapter. ( my guess )
---

I did some more testing to try to narrow down where the problem is:

1) I upgraded to 2.4.9-13 from Red Hat's 7.2 errata.  I built a custom kernel. 
This did not seem to improve things at all.  Mouseconfig segfaults and can lock
up the virtual terminal.  Xconfigurator breaks as before.

2) I removed all my PCI cards and ISA cards.  I kept in my AGP video card.  This
actually fixed it!  mouseconfig ran and could find my mouse, Xconfigurator
worked, and startx worked.

3) I replaced only my sound card.  This was sufficient to break mouseconfig,
etc.  Note that adding my sound card did not change the system very much, as the
sound card is not set up properly and doesn't even get an IRQ.  Looking in /proc
for the two cases: (a) /proc/interrupts has tiny differences which don't look
important, (b) /proc/iomem are the same, (c) /proc/ioports are the same except
when the sound card is in it has two lines for isapnp read and write but they
don't appear to conflict with anything, (d) /proc/pci are the same, (e)
/proc/devices are the same.  /sbin/lsmod is the same for both cases.  There
doesn't seem to be any IRQ or memory conflicts, especially considering the sound
card isn't being configured and assigned any resources.

My sound card is made by Genius and is a Crystal Codec. It uses the cs4232
driver.  The chip on the card says "Crystal CX4235-XQ3 ZTALOE9927".  It works
fine on my RH6.2 partition, but isn't configured properly on my 7.1 or 7.2
partitions.

I'm out of ideas on what sort of conflict this may be, since I'm mostly familiar
with IRQ/dma/memory conflicts of configured devices which this doesn't seem to
be.  Suggestions?

Andrew - Do you have the same sound card on your system?

Problem solved! - sort of ...

Well, I got things working and learned about some weird behavior in the
process.  To summarize:

1) /proc/interrupts doesn't show all the IRQ's assigned.  You have to look in
/proc/pci and /proc/isapnp to discover other assigned IRQ's.  (This seems like a
bug to me.) In my case, isapnp from the kernel was assigning IRQ 12 to my sound
card but not listing it in /proc/interrupts so I didn't realize there was a
resource conflict.

2) The isapnp stuff in the Linux kernel seems to completely ignore
/etc/isapnp.conf and /etc/modules.conf.  Instead, it just probes the card and
gives it some resources.  Giving it IRQ 12 seems particularly dumb, and it is
annoying that the isapnp in the kernel ignores the files in /etc.  Hopefully
somebody will change this to be more natural and sensible.

3) Turning off isapnp in the kernel and just assigning the resources in
/etc/modules.conf fixed the problem.  I now have sound and mouse working and I
don't think the user-level isapnp stuff is being used at all.

4) It looks like mouseconfig could be improved in a few ways here.  Right now
mouseconfig segfaults if IRQ 12 is already taken and the user has a PS/2 mouse. 
Sometimes it even hangs the console so a hard reboot is necessary.  At minimum,
it should not segfault.  What would be better is if mouseconfig identified IRQ
12 was being used and put up a comment saying that IRQ 12 may need to be free'd
up for the mouse.

-Dan

I have Crystal sound card by Aopen using cs423x driver.

This should be resolved in newer kernels. Any problems still ?