Bug 37812
Summary: | PCMCIA -- Yenta claims IRQ 12 preventing PS/2 mouse from being used | ||
---|---|---|---|
Product: | [Retired] Red Hat Linux | Reporter: | Clark Tompsett <clarkt> |
Component: | kernel-pcmcia-cs | Assignee: | Dave Jones <davej> |
Status: | CLOSED WONTFIX | QA Contact: | Brock Organ <borgan> |
Severity: | high | Docs Contact: | |
Priority: | medium | ||
Version: | 7.1 | CC: | brentrbrian, kingbt, len, minus71, pfrields |
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: | 2004-11-25 07:18:58 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Clark Tompsett
2001-04-26 13:35:27 UTC
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. |