Bug 43504 - (ISAPNP IRQ_ROUTING)ps/2 mouse not detected
Summary: (ISAPNP IRQ_ROUTING)ps/2 mouse not detected
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: kernel (Show other bugs)
(Show other bugs)
Version: 7.1
Hardware: i586 Linux
Target Milestone: ---
Assignee: Arjan van de Ven
QA Contact: Brock Organ
Depends On:
TreeView+ depends on / blocked
Reported: 2001-06-05 13:58 UTC by Marco Ostini
Modified: 2007-04-18 16:33 UTC (History)
8 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2003-06-08 20:44:29 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description Marco Ostini 2001-06-05 13:58:33 UTC
From Bugzilla Helper:
User-Agent: Mozilla/4.73C-CCK-MCD {C-UDP; EBM-APPLE} (Macintosh; U; PPC)

Description of problem:
During the fresh installation, the mouse and X worked just fine.

Now, when using the 2.4.2-2 kernel supplied, any attempt to go to run level 
5 fails because the ps/2 mouse is not detected.

on startup gpm reports:
gpm[819]: oops() invoked from gpm.c(978)
gpm[819]: /dev/mouse: Device or resource busy

a 'cat /proc/interrupts' reveals that IRQ 12 is being used by the sound 
card. The mouse is not detected.

greping dmesg also shows that the PS/2 mouse has not been detected.

Without that mouse, x fails with a:
Cannot open mouse (Device or resource busy)

How reproducible:

Steps to Reproduce:
1. boot Redhat Linux 7.1

Actual Results:  the ps/2 mouse was not detected

Expected Results:  the ps/2 mouse should have been detected, and gpm & X run 

Additional info:

lspci shows;

00:00:0 Host bridge: Intel Corp 430TX - 82439TX MTXC (rev 01)

Onboard VGA, Ethernet controller, ISA Bridge, IDE nterface, USB Controller 
and Bridge are detected.

Comment 1 Arjan van de Ven 2001-06-05 14:03:46 UTC
If you disable the loading of the sound-module (eg edit /etc/modules.conf and
comment the sound module otu), does it work then ?

Comment 2 Marco Ostini 2001-06-06 09:42:49 UTC
I found a /etc/modules.conf~ which only loaded the parport and ethernet, so after 
reciprocating the name of this and the active modules.conf file I restarted and 
found that the ps/2 mouse had been detected.

after editing the other modules.conf file so that the sound card used IRQ 5 & 11 
instead of 5 & 12 both the ps/2 mouse and sound worked normally:

options cs4232 io=0x534 irq=5 dma=1 dma2=0 mpuio=0x330 mpuirq=11

cat /proc/interrupts now shows:

  0:     330407          XT-PIC  timer
  1:          7          XT-PIC  keyboard
  2:          0          XT-PIC  cascade
  5:          1          XT-PIC  Crystal audio controller
  8:          1          XT-PIC  rtc
 10:       5360          XT-PIC  usb-uhci, PCnet/FAST 79C971
 11:          0          XT-PIC  MPU-401 UART
 12:         24          XT-PIC  PS/2 Mouse
 14:       5767          XT-PIC  ide0
 15:          0          XT-PIC  ide1

Why is it that and interrupt of 12 was given to the sound card when an active PS/
2 mouse was part of the system?

Will the USB controller and the ethernet controller interfere with each other 
sharing IRQ 10?

Thanks for the prompt assistance.

Comment 3 Arjan van de Ven 2001-06-06 09:48:33 UTC
IRQ's _should_ be able to be shared.
Unfortionatly, some hardware seems to cheat and object to that... it seems
to happen with soundcards more than with other hardware. 
I've changed the kernel (for future versions) to make it use IRQ 12 less for
other hardware, although sometimes the BIOS makes the choice and Linux just
trusts the bios.

Comment 4 Need Real Name 2001-07-03 03:29:30 UTC
I have a similar problem, but it's more insidious:  Even if I change
modules.conf the way marco did, when I reboot IT GETS CHANGED BACK.
In fact, these files, which all reference the sound card, get changed
at EVERY boot:  /etc/modules.conf /etc/sysconfig/hwconfig

So no matter what I do, I still can't run X.  BTW, the biggest common
factor I have with marco is that I also have a Crystal audio
controller that worked fine under RedHat 6.2.

Comment 5 Harman Nagra 2001-08-06 21:51:41 UTC
This problem continues on with the roswell beta release also, as said 
criglerj@acm.org , even if I change the /etc/modules.conf to not load the sound 
module, or specify the sound card options, it gets changed on reboot.

Again the common factors are that I have a cs4232 and a ps2 mouse.

Can we pls pls pls find a workaround on this one.


Comment 6 Need Real Name 2001-08-12 14:04:45 UTC
I, too, have the same problem as criglerj@acm.org. On reboot the /etc/modules.conf is changed back so the cs4232 is set to use IRQ's 5 and 12.

Comment 7 Arun Kumar 2001-08-16 07:57:04 UTC
I had the same problem on my machine.
Setup: Dell Dimension XPS R450, BIOS: 4S4EBOX1.10A.0019.P09 version A09, MS 
IntelliMouse on PS/2, Crystal Audio controller.
I have been trying to install 7.1 with the same problem with mouse detection 
for the past week. As a last resort I tried a BIOS upgrade and it worked! I'm 
on BIOS version A13. I dont know if this is relevant to the problems you all 
are having, but I had exactly the same symptoms.

Comment 8 Need Real Name 2001-08-18 14:29:29 UTC
My solution was also in the BIOS. I have an Award BIOS and was able to find a section for setting up PCI/PNP settings. In my case I had 
to set IRQ 5 and IRQ 9 to the setting of "Legacy ISA" the other available setting was "PCI/PNP" and this setting caused the problems. Of 
course now I have new problems and while I get a GUI screen, I cannot log so have to begin at the console, log in, and then startx.

Comment 9 Bill Ferguson 2001-10-03 21:53:32 UTC
I too had the same problem.  I have an E-machines etower 333 with a crystal 
audio 423x chipset.  This system worked fine with 6.0, 6.1, 6.2 and 7.0.  When 
I upgraded to 7.1, no mouse.  The uart on the audio ended up with interrupt 
12, which disabled the mouse.  I tried overriding the /etc/modules.conf 
settings with my own, only to discover that they get written at boot time.  I 
disabled sound which enabled the mouse, but that wasn't a satisfactory setup.  
So, I started troubleshooting and here is what I found...

/etc/modules.conf is written at boot time under the control of the 
/etc/rc.d/rc.sysinit script.  rc.sysinit calls /sbin/sndconfig with the 
(undocumented) --mungepnp option to generate the /etc/modules.conf.  
/sbin/sndconfig gets its PnP information from /sbin/pnpdump, which shows IRQ 
12 as a valid choice for the sound card MPU.

I tried installing the isapnptools to override the sound card configuration.  
I marked IRQ 12 as used in the /etc/isapnp.gone file, but this had no effect.  

I next went to the kernel source to figure out how the kernel does hardware 
detection.  While looking through the documentation I came across a 
description of how the PCI card slot interrupts are allocated and how to 
override them in /usr/src/linux-2.4/Documentation/i386/IO-APIC.txt.  I checked 
my /proc/interrupts and figured out which IRQs the cards in the PCI slots were 
using and specified them with 'append="pirq=10,8"' in the /etc/lilo.conf.  I 
ran /sbin/lilo, then rebooted and the MPU had moved to IRQ 11 and the mouse 
was on 12.  

It would seem that when the kernel (2.4.x) does hardware detection, it 
reserves certain IRQs for the PCI slots.  When it runs short of IRQs, it 
attempts to share(?) and thus IRQ 12 ends up assigned to a sound card.  It 
also appears that sound cards don't play well with others, therefore the mouse 
doesn't get detected.

I did find one more interesting item.  I removed the append from the 
/etc/lilo.conf and rebooted and everything is still fine.  It appears that 
once the system boots in the reconfigured mode it retains those settings and 
the hardware detection rediscovers them.

Comment 10 Greg Bailey 2001-10-09 06:00:04 UTC
I also have a CS4232 and PS/2 mouse (HP Pavilion 6355), and made the following
two changes to get things to work:

1.  Edit the "options cs4232" line in /etc/modules.conf to include "mpuirq=11"
2.  Pass "nopnp" on the kernel command line.  This prevents "sndconfig
--mungepnp" from being executed in /etc/rc.d/rc.sysinit; yet the sound
configuration has already been generated in /etc/modules.conf

What's interesting is that "cat /proc/isapnp" showed the MPU as "active" before
I added the "mpuirq=11" option; maybe since I didn't specify "mpuio", it got set
as "not active"...


Comment 11 Alan Cox 2003-06-08 20:44:29 UTC
Resolved by making ISAPnP favour keeping away from IRQ 12 (PS/2)

Note You need to log in before you can comment on or make changes to this bug.