Bug 41049

Summary: Genius sound card MPU-401 is assigned IRQ 12
Product: [Retired] Red Hat Linux Reporter: Stephen Walton <stephen.walton>
Component: kernelAssignee: Arjan van de Ven <arjanv>
Status: CLOSED ERRATA QA Contact: Brock Organ <borgan>
Severity: medium Docs Contact:
Priority: medium    
Version: 7.1CC: notting
Target Milestone: ---   
Target Release: ---   
Hardware: i386   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2002-02-11 17:52:59 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
Attachments:
Description Flags
Output of 'cat /proc/isapnp' after bootup
none
Output of '/sbin/lspci -v' immediately after bootup none

Description Stephen Walton 2001-05-17 02:56:55 UTC
From Bugzilla Helper:
User-Agent: Mozilla/4.76 [en] (X11; U; Linux 2.4.2-2 i586)

Description of problem:
I hope I have this sent to the right place.  I have an AMD K6-2 350 MHz
system with Genius ISAPNP sound card.  After upgrading to RedHat 7.1, the
system consistently assigns IRQ 12 to the MPU-401 on the Genius.  I booted
the system using kernel 2.2.19-6.2.1, and was able to run sndconfig 0.43
and determine that an IRQ of 9 for the main sound and 7 for the MPU 401
worked.  I edited /etc/modules.conf accordingly.  Lo and behold, when I
reboot, modules.conf is rewritten to assign IRQ 12 to the MPU 401.  Of
course, since IRQ 12 is supposed to be reserved for the PS/2 mouse, this
means the mouse doesn't work either.  I can get the mouse to work using
'rmmod cs4232' followed by 'insmod  io=0x534 irq=9 dma=1 dma2=0 mpuio=0x330
mpuirq=7'.  This last I just clipped out of my modules.conf file, but I
know it will get changed on the next boot.

What gremlin has gotten into my system?


How reproducible:
Always

Steps to Reproduce:
1.Install Genius sound card and PS/2 mouse in a system
2.Install RedHat 7.1
3.
	

Additional info:

Comment 1 Arjan van de Ven 2001-05-17 08:26:24 UTC
Could you paste or attach the output of "cat /proc/isapnp" ?

Comment 2 Stephen Walton 2001-05-18 02:05:32 UTC
Created attachment 18851 [details]
Output of 'cat /proc/isapnp' after bootup

Comment 3 Bill Nottingham 2001-05-18 02:26:19 UTC
What's the content of /proc/interrupts when the sound card is like this?

Comment 4 Stephen Walton 2001-05-18 03:59:15 UTC
Here is the output of cat /proc/interrupts right after bootup:

           CPU0       
  0:      10043          XT-PIC  timer
  1:        111          XT-PIC  keyboard
  2:          0          XT-PIC  cascade
  4:          1          XT-PIC  serial
  5:         18          XT-PIC  eth0
  8:          1          XT-PIC  rtc
  9:          1          XT-PIC  Crystal audio controller
 10:          0          XT-PIC  usb-uhci
 12:          0          XT-PIC  MPU-401 UART
 14:       6217          XT-PIC  ide0
 15:          2          XT-PIC  ide1
NMI:          0 
ERR:          0

Since my last writing, I even tried lying to sndconfig:  I told it I couldn't
hear the sound and manually set the mpuirq to 7.  It still put mpuirq=12 in
/etc/modules.conf!


Comment 5 Bill Nottingham 2001-05-18 04:15:52 UTC
sndconfig uses what the card is set to via the kernel's isapnp.

However, the kernel really shouldn't have used IRQ 12 here, especially

since 7 & 11 were still (apparently) available. If you do 'lspci -v', are

any PCI devices on IRQ 7 or IRQ 11?

Comment 6 Stephen Walton 2001-05-19 02:49:51 UTC
Created attachment 18990 [details]
Output of '/sbin/lspci -v' immediately after bootup

Comment 7 Bill Nottingham 2001-05-24 22:03:16 UTC
OK, IRQ 7 appears free, so in theory the kernel should be using that
before IRQ 12.

Comment 8 Stephen Walton 2001-05-31 18:45:44 UTC
"Should" is different from "is", of course.  And, why is it that if I 
edit /etc/modules.conf to force IRQ 7, I find it has been overwritten with a 
version which uses IRQ 12 again at the next boot?


Comment 9 Bill Nottingham 2002-01-24 03:41:30 UTC
It gets overwritten because sndconfig tells the kernel's isapnp code to activate
the card at each boot, and then reads the settings the kernel chose. The kernel
chose IRQ 12 in this case.

Comment 10 Arjan van de Ven 2002-02-11 17:31:22 UTC
Well but if the user hard forces another irq, then sndconfig should obey there

Comment 11 Bill Nottingham 2002-02-11 17:47:42 UTC
This is isapnp; since the card needs activated at each boot, there are no user
settings involved.

Comment 12 Stephen Walton 2002-02-11 17:52:54 UTC
Then perhaps the real problem is isapnp:  the difficulty has always been that it
assigned an IRQ to the card which is already in use.

Having said all that, the problem seems to have disappeared now that I'm running
kernel 2.4.9-21.

Comment 13 Arjan van de Ven 2002-02-11 17:56:03 UTC
ok "fixed in errata" it is... ;)