Bug 37812

Verified same problem on Winbook XL (irq=12, mouse dead and hangs system if used)
I have also excluded all "normal irq's", 2,4,5,7,10,11,12,13,14 ... still grabs 12.

This is entirely a BIOS issue. For cardbus controllers (yenta_socket driver),
which are PCI devices, the BIOS assigns the IRQ and there is nothing Linux can
do about that, just as Linux cannot change the IRQ of your PCI networkcard.

The only case where this _is_ possible, is on SMP systems with an IO apic chip.
Several modern single-processor machines also have this chip nowadays.
A quick hack to see if this works is to install the SMP kernel on your laptop
and boot that.

Tried SMP kernel, no change.

Loaded Normal kernel sources, added support for the IO_APIC & PCMCIA, no change.

Yenta still grabs IRQ 12 regardless of the EXCLUDES.

I can "unhang" the system by installing/removing a PCMCIA card several times.

EXCLUDES is irrelevant for this. The __BIOS__ assigns IRQ 12 to the cardbus
controller, there is nothing Linux can do to change that.

I've also encountered this problem on a Winbook XL with RH 7.1.  If the hardware
is insisting
on using irq 12 for both the Texas Instruments PCI1131 controller and the PS/2
mouse,
and Linux can't do anything abou it, how do you explain the fact that every
version of
RedHat from 5.1 through 7.0 has run without problem on this computer?  Also,
Windows 98
runs without incident and the system device manager reports the pcmcia
controller is
using irq 15.   What does that mean?

I've been in communication with David Hinds who thinks this may be a problem in
the
kernel and may have been fixed in 2.4.4.  I will have to try it.   But it can't
be fixed on
the pcmcia side of the installation.

When I get a chance, I may reinstall RH7.0 and try to see what it is doing.

Some additional comments.  What actually freezes is the mouse/keyboard
controller on
the mother board.   And this can happen even if pcmcia is not started.   For
example,
del pcmcia from startup and after booting in level 3, login and start gpm (if it
is not
already running).  There is no mouse cursor--as there should be with gpm
running---but
you can type and execute commands until you touch the touch pad, and then the
keyboard freezes.   If you start a script which sleeps a while and then
terminates gpm, before
starting gpm, things come back to normal after  it terminates.   If you start
pcmcia
and then try to start X, the mouse and keyboard will be frozen after it comes
up.
I suspect that if you arranged to kill it after a pause with a program running
in the
bakcground, you wouldn't have to shut off the machine to recover.  You can also
test the combination just by running Xconfigurator.  During the test phase when
you
are asked if you like what you see , the mouse will be frozen, but it will time
out.

There is nothing in the BIOS setup which allows you to change the PCI1131
controller
interrupt.

Ok. If windows is finding irq 15, that is interesting. Could you try 
passing "pci=biosirq" to the lilo prompt commandline (eg 
lilo: linux pci=biosirq

I had already tried passing pci=biosirq to the kernel since we had found that
suggestion
elsewhere.  But I just tried it again and examined the boot messages in detail
to see if
there was any difference.  As best I can tell there wasn't any difference.  And
of course
it didn't do any good.   According to the messages, the kernel is setting irq 12
for the
PCI1131 controller quite late in the process, but it doesn't provide
enlightenment about
why it is selecting that interrupt.

Apparently this all worked fine when pcmcia was not done by the kernel as
recently as
RH7.0, and I gather the code for yenta_socket in the kernel has been rewritten
from scratch.

Important Correction!  If pcmcia is deleted from the startup script, then gpm
works properly.
Also, /proc/pci shows the Texas Instruments PCI1131 controller without any
interrupts
set.   It is a bit difficult being sure one has tested all combinations.  I
thought I had checked
this particular one before, but apparently I only checked what happened if
pcmcia was
started during boot and stopped afterwards.  In that case the interrupt is
removed from
/proc/interrupts, but it still shows up in /proc/pci.

So it seems clear that the kernel module which starts pcmcia is assigning the
interrupt
to the controller, and once assigned it can't be removed by stopping the
service.

I don't know what this says about why the kernel is choosing that interrupt.  
Any thoughts
would be appreciated.

Can you attach or past the output of lspci -vv ? Just to see what exact hardware
this machine has.

Here is the requested information.  I did it with X and more, and it is possible
some things got
garbled.
------------------------------------------------------------------
Here is the result of lspci -vv when yenta_socket has never been run.  Note
the controller is set to irq 0.

00:00.0 Host bridge: Intel Corporation 430TX - 82439TX MTXC (rev 01)
	Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping-
SERR- FastB2B-
	Status: Cap- 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort-
<MAbort+ >SERR- <PERR-
	Latency: 32

00:01.0 ISA bridge: Intel Corporation 82371AB PIIX4 ISA (rev 02)
	Control: I/O+ Mem+ BusMaster+ SpecCycle+ MemWINV- VGASnoop- ParErr- Stepping-
SERR- FastB2B-
	Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort-
<MAbort- >SERR- <PERR-
	Latency: 0

00:01.1 IDE interface: Intel Corporation 82371AB PIIX4 IDE (rev 01) (prog-if 80
[Master])
	Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping-
SERR- FastB2B-
	Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort
- <MAbort- >SERR- <PERR-
	Latency: 32
	Region 4: I/O ports at ffa0 [size=16]

00:01.2 USB Controller: Intel Corporation 82371AB PIIX4 USB (rev 01) (prog-if 00
[UHCI])
	Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping-
SERR- FastB2B-
	Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort-
<MAbort- >SERR- <PERR-
	Latency: 64
	Interrupt: pin D routed to IRQ 11
	Region 4: I/O ports at ef80 [size=32]

00:01.3 Bridge: Intel Corporation 82371AB PIIX4 ACPI (rev 02)
	Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping-
SERR- FastB2B-
	Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort-
<MAbort- >SERR- <PERR-
	Interrupt: pin ? routed to IRQ 9

00:02.0 VGA compatible controller: Chips and Technologies F65554 (rev c2) (prog-
if 00 [VGA])
	Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping+
SERR+ FastB2B-
	Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort-
<MAbort- >SERR- <PERR-
	Region 0: Memory at fd000000 (32-bit, non-prefetchable) [size=16M]
	Expansion ROM at febc0000 [disabled] [size=256K]

00:03.0 CardBus bridge: Texas Instruments PCI1131 (rev 01)
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping-
SERR- FastB2B-
	Status: Cap- 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort-
<MAbort- >SERR- <PERR-
	Latency: 0
	Interrupt: pin A routed to IRQ 0
	Region 0: Memory at 10000000 (32-bit, non-prefetchable) [size=4K]
	Bus: primary=00, secondary=01, subordinate=04, sec-latency=0
	BridgeCtl: Parity- SERR- ISA- VGA- MAbort- >Reset+ 16bInt+ PostWrite+
	16-bit legacy interface ports at 03e1
ping- SERR- FastB2B-
	Status: Cap- 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort-
<MAbort- >SERR- <PERR-
	Latency: 0
	Interrupt: pin B routed to IRQ 0
	Region 0: Memory at 10001000 (32-bit, non-prefetchable) [size=4K]
	Bus: primary=00, secondary=05, subordinate=08, sec-latency=0
	BridgeCtl: Parity- SERR- ISA- VGA- MAbort- >Reset+ 16bInt+ PostWrite+
	16-bit legacy interface ports at 03e1
----------------------------------------------------------------------
Here is the result of lspci -vv AFTER yenta_socket was run.  Note that
the controller is now using irq 12. 

00:00.0 Host bridge: Intel Corporation 430TX - 82439TX MTXC (rev 01)
	Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping-
SERR- FastB2B-
	Status: Cap- 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort-
<MAbort+ >SERR- <PERR-
	Latency: 32

00:01.0 ISA bridge: Intel Corporation 82371AB PIIX4 ISA (rev 02)
	Control: I/O+ Mem+ Buping- SERR- FastB2B-
	Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort-
<MAbort- >SERR- <PERR-
	Latency: 0

00:01.1 IDE interface: Intel Corporation 82371AB PIIX4 IDE (rev 01) (prog-if 80
[Master])
	Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping-
SERR- FastB2B-
	Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort-
<MAbort- >SERR- <PERR-
	Latency: 32
	Region 4: I/O ports at ffa0 [size=16]

00:01.2 USB Controller: Intel Corporation 82371AB PIIX4 USB (rev 01) (prog-if 00
[UHCI])
	Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping-
SERR- FastB2B-
	Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort-
<MAbort- >SERR- <PERR-
	Latency: 64
	Interrupt: pin D routed to IRQ 11
sMaster+ SpecCycle+ MemWINV- VGASnoop- ParErr- Step

00:03.1 CardBus bridge: Texas Instruments PCI1131 (rev 01)
	Control: I/O+ 	Region 4: I/O ports at ef80 [size=32]

00:01.3 Bridge: Intel Corporation 82371AB PIIX4 ACPI (rev 02)
	Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping-
SERR- FastB2B-
	Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort-
<MAbort- >SERR- <PERR-
	Interrupt: pin ? routed to IRQ 9

00:02.0 VGA compatible controller: Chips and Technologies F65554 (rev c2)
(prog-if 00 [VGA])
	Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping+
SERR+ FastB2B-
	Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort-
<MAbort- >SERR- <PERR-
	Region 0: Memory at fd000000 (32-bit, non-prefetchable) [size=16M]
	Expansion ROM at febc0000 [disabled] [size=256K]

00:03.0 CardBus bridge: Texas Instruments PCI1131 (rev 01)
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping-
SERR- FastB2B-
	Status: Cap- 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbortMem+
BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Step

- <MAbort- >SERR- <PERR-
	Latency: 168, cache line size 08
	Interrupt: pin A routed to IRQ 12
	Region 0: Memory at 10000000 (32-bit, non-prefetchable) [size=4K]
	Bus: primary=00, secondary=01, subordinate=01, sec-latency=176
	Memory window 0: 10c00000-10fff000 (prefetchable)
	Memory window 1: 11000000-113ff000
	I/O window 0: 00001800-000018ff
	I/O window 1: 00001c00-00001cff
	BridgeCtl: Parity- SERR- ISA- VGA- MAbort- >Reset+ 16bInt+ PostWrite+
	16-bit legacy interface ports at 0001

00:03.1 CardBus bridge: Texas Instruments PCI1131 (rev 01)
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping-
SERR- FastB2B-
	Status: Cap- 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort-
<MAbort- >SERR- <PERR-
	Latency: 168, cache line size 08
	Interrupt: pin B routed to IRQ 12
	Region 0: Memory at 10001000 (32-bit, non-prefetchable) [size=4K]
	Bus: primary=00, secondary=05, subordinate=05, sec-latency=176
	Memory window 0: 10400000-107ff000 (prefetchable)
	Memory window 1: 11000000-113ff000
	I/O window 0: 00001800-000018ff
	I/O window 1: 00001c00-00001cff
	BridgeCtl: Parity- SERR- ISA- VGA- MAbort- >Reset+ 16bInt+ PostWrite+
	16-bit legacy interface ports at 0001

00:03.1 CardBus bridge: Texas Instruments PCI1131 (rev 01)
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping-
SERR- FastB2B-
	Status: Cap- 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort-
<MAbort- >SERR- <PERR-
	Latency: 168, cache line size 08
	Interrupt: pin B routed to IRQ 12
	Region 0: Memory at 10001000 (32-bit, non-prefetchable) [size=4K]
	Bus: primary=00, secondary=05, subordinate=05, sec-latency=176
	Memory window 0: 10400000-107ff000 (prefetchable)
	Memory window 1: 10800000-10bff000
	I/O window 0: 00001000-000010ff
	I/O window 1: 00001400-000014ff
	BridgeCtl: Parity- SERR- ISA- VGA- MAbort- >Reset+ 16bInt+ PostWrite+
	16-bit legacy interface ports at 0001

I got further information from Dave Hinds.    He suggested passing
pci=irqmask=0xefff
to the kernel.  That masks out irq12.   When I did that and started pcmcia after
booting,
yenta_socket assigned irq 15 rather than irq12, but then things fell apart.  
The system
more or less hung, and I kept getting the message
ide_dmaproc: chipset supported ide_dma_lostirq func only: 13
hda: lost interrupt
Recall that Windows 98 manages to do it with the TI controller using irq 15. 
Ordinarily
this would be for the second IDE port, but perhaps they don't expect that to be
used.
Maybe we are getting a little closer to a solution.   There has to be some way
to force
the TI controller to use irq 15 without messing up anything else.
I am going to reinstall RH 7.0 to see how it is done there, but perhaps one of
the redhat
people can find out first.

Ok. So this rules out the mouse part being evil and restricts it to the yenta
code. Right now (23:43 at night) I don't have any more ideas other than
trying a newer kernel (you can get one from the rawhide section of the
redhat ftp site or it's mirrors). My cardbus card is at the office so I cannot
check if that shares an IRQ right now. I'll do that asap.

Passing the following irq mask to the kernel appears to work, at least for my
Winbook XL.
pci=irqmask=0x8fff
This excludes irqs  12,13, and 14.
I hope this conclusion is not premature.  Probably this should be fixed in the
kernel module
and maybe it already is.  I will try to find out.

I was premature.  If pcmcia is running and my modem card is plugged in, gmc and
other
gnome components keep crashing.  But
pci=irqmask=0xafff
seems to do a lot better.  That allows both irq 13 and irq 15.

I've tried checking the kernel mailing list archives.   There seems to be some
discussion
of problem conerning yenta_socket, but I can't tell if anything has been done to
deal with
this specific problem.

I was premature.  If pcmcia is running and my modem card is plugged in, gmc and
other
gnome components keep crashing.  But
pci=irqmask=0xafff
seems to do a lot better.  That allows both irq 13 and irq 15.

I've tried checking the kernel mailing list archives.   There seems to be some
discussion
of problem conerning yenta_socket, but I can't tell if anything has been done to
deal with
this specific problem.

Ah Ha!

The problem is that the IRQ 15 is being "penalized" by the new

/usr/src/linux/arch/i386/kernel/pci-irq.c

that was added to 2.4 kernel.

Change the penalty for IRQ 12 to something high, like 10000 and IRQ 15 to 0.

That way when the system boots, the first PCI IRQ that is available will be 15.

That FIXED it for me.

B

The use of irq 15 on a laptop which is not likely to be using ide1 (the second
IDE port)
seems okay, but what happens if the pcmcia card and an ide device try to share
the
interrupt?   Probably the ultimate solution will have to be more complicated.

There should be a more elegant solution, like assigning the PENALTY based on if the HARDWARE EVEN EXISTS.

In a laptop IRQ 12, 13, 14 (486+) are pretty much a given.  Some may have a 2nd IDE at 15 (why, I don't  know).

But customizing it by hand is probably NOT the way to go for simple user installs.

Why IRQ 12 got a ZERO is beyond me.

It's as "elegant" as a "kernel parameter", and more elegant than having it NOT WORK because the IRQ has been "penaltied out".

Another point, even picking a LAPTOP install did not fix this, and it COULD HAVE.  The binary for a laptop install (and kernel source could have had a "define" yuck) could have opened up IRQ 15.

I suppose USB mice and keyboards will "mess up a lot of stuff", but even MY laptop with the USB ports has a PS/2 mapped mouse pad.

We can discuss this until the cows come home, but the pci-irq.c not only fixes it but explains why it happened and opens up "fixes" for a lot of other potential problems.

B

"fixes" in this case most likely means "work around strange bios".
This laptop seems to be the rare exception...... so I doubt it is 
_only_ a linux problem.

Its quite possible the cardbus distributed with that laptop knows about specific
IRQ allocation rules. I'd agree that IRQ12 probably should be penalised too. Its
asking for trouble.

If it is a BIOS problem it only occurs with 7.1.

I agree, it is probably not a good idea to use IRQ15, but, I don't
have the ability to pick the PCMCIA IRQ ... regardless, if the BIOS
picks IRQ 10 & 11 for IDE, the machine should detect it and WORK.

We should have PCI beyond the old "jumper & play" days when everything
was "predetermined", both port address and IRQ.

What about the SCSI machines, no IRQ 14 & 15 used there ?  Do we just
throw the PRE-ASSIGNED IRQ's away because our machine doesn't have the
right hardware ?  That is what the pci-irq.c is going to do.

To review,

Win98, OK (IRQ15=pcmcia)
RH 6.1, OK
RH 7.0, OK
RH 7.1, OK with pci_irq.c changed to irq12=10000 and irq15=0

The machine runs fine this way, even with only 24M, X & KDE are fine.
The BIOS is assigning the first unused IRQ (15) to the PCMCIA.
Now RH 7.1 is setting things just like WIN98 and previous RH versions.

Am I misunderstanding something?  I presume you changed pci-irq.c to reflect the
new penalties
and then you recomplied the kernel.  Or maybe it was just necessary to remake
the modules.
If so, that seems more complicated that putting
append="pci=irqmask=0xafff"
in /etc/lilo.conf and running lilo.  That leads to irqs 12 and 14 being excluded
for pci devices,
which one certainly wants to be the case, and yenta_socket assigns irq 15 to the
TI pcmcia
controller, which is just what the other solution does. 
I believe in the original pci_irq.c, the penalty for irq 12 was not zero.   It
was lower than
for irq 15, but I can't look now since I don't have access to a machine with the
kernel source.
By the way,  my Winbook XL ran fine with Windows 95, Windows 98,  and Redhat
5.1, 5.2, 6.1,
6.2, and 7.0.  It is only under 7.1 that I've had this problem.