Hello,
When I enable the ps/2 mouse, I get some kind of conflict between it and
the keyboard (usually only after using them both for a while) resulting
in both going ... "dead". The serial mouse still works though. Disabling
the ps/2 mouse and unloading the module does sort it out again. (This I
do over the network ;)
Any ideas how I can debug this problem?
Thanks,
Hugo van der Merwe
> > Any ideas how I can debug this problem?
>
> well, sanity-checking should happen first. for instance,
> bios settings, whether you have the mouse plugged into the
> mouse PS/2 port (they're often different), and what kinds
> of messages the kernel prints regarding these items...
OK, some lies ... it seems I have ps/2 support compiled in, not as a
module. If I start gpm with parameters that makes it read ps2 mouse, the
keyboard and the mouse stops working immediately. However, a while back,
when using ps/2 in X only, I could start X and use it for a while, only
after a few minutes does it all "lock up". Then killing X with the
serial mouse gave me my keyboard back.
I don't recall having changed anything in the BIOS since my 2.2 days,
when the mouse worked fine. (I cannot say for certain that it broke
during my 2.2->2.4 upgrade. Should I install a 2.2. kernel again and see
if it happens there?) What setting in the BIOS should I be playing with?
I don't find anything special in syslog or any other log file.
/var/log/dmesg has the one related line:
Detected PS/2 Mouse Port.
When gpm is "using" the mouse, I see the following line
in /proc/interrupts:
12: 0 XT-PIC PS/2 Mouse
That 0 probably means something? When gpm is not using the mouse, there
is no line for interrupt 12. (I do notice my sound card and one of my
two network cards is sharing interrupt 10. Is this something that might
have negative consequences?)
I sometimes notice the following in user.log:
Oct 17 21:54:45 baboon /usr/sbin/gpm[14687]: oops() invoked from gpn.c(204)
Oct 17 21:54:45 baboon /usr/sbin/gpm[14687]: /var/run/gpm.pid: No such file or directory
It doesn't happen very often though, and might be tied to the staring
and stopping of gpm, rather than with the functioning of the ps/2 port.
I cannot reproduce this reliably.
What else might be involved? /proc/{iomem,ioports,dma} are the same with
gpm with ps/2 running and not running.
Thanks,
Hugo van der Merwe
ps, please CC me, thanks. How high is this list's traffic, and where is
its archive?
Hi,
the mouse needs to be reinitialized after being replugged. First it needs to
be enabled and then set to the protocol it uses (if different from plain
PS/2). This should be handled by mouse driver, i.e. gpm and X11.
However, it isn't.
There once was a kernel patch to do the first part (it can't do the second,
asw the kernel has not the slightest clue about the specifics of the mouse),
but
* it was bad design (should be done in userspace, where knowledge baout the
specific mouse id present)
* broke some mouses (synps2 most notably)
so it got disbaled. You can try reenabling by using the parammeter
psaux-reconnect and check whether this makes a difference.
I don't have the slightest clue why it affects yoiur keyboard.
Regards,
--
Kurt Garloff <[email protected]> Eindhoven, NL
GPG key: See mail header, key servers Linux kernel development
SuSE GmbH, Nuernberg, DE SCSI, Security
> the mouse needs to be reinitialized after being replugged. First it needs to
It was plugged in at boot time, is this then still necessary?
> so it got disbaled. You can try reenabling by using the parammeter
> psaux-reconnect and check whether this makes a difference.
>
> I don't have the slightest clue why it affects yoiur keyboard.
Is there good reason to believe that this is my problem then? How can I
find evidence that supports this theory? Especially interesting was the
days when I could start X and use the ps/2 mouse and keyboard for a
while, before they locked up...
Hugo van der Merwe