Bug 90157 - PCI: No IRQ known for interrupt... makes yenta_socket.o fail (patch included)
Summary: PCI: No IRQ known for interrupt... makes yenta_socket.o fail (patch included)
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: kernel   
(Show other bugs)
Version: 9
Hardware: athlon
OS: Linux
Target Milestone: ---
Assignee: Arjan van de Ven
QA Contact: Brian Brock
Depends On:
TreeView+ depends on / blocked
Reported: 2003-05-03 19:57 UTC by Allan Beaufour Larsen
Modified: 2007-04-18 16:53 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2003-05-22 09:42:37 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 Allan Beaufour Larsen 2003-05-03 19:57:38 UTC
Description of problem: 
yenta_socket.o fails to load on my machine, because there is no interrupt assigned to it. It 
worked fine in 2.4.18. The reason is a a (as far as I can see) RedHat patch to 
Version-Release number of selected component (if applicable): 
How reproducible: 
Every single time. 
Steps to Reproduce: 
1. modprobe yenta_socket 
Actual results: 
Kernel says: PCI: No IRQ known for interrupt pin A of device 00:08.0. 
and yenta_socket refuses to load. 
Expected results: 
Guess? :) Successful load. 
Additional info: 
Where's the solution field? Well, here it goes: 
drivers/pcmcia/yenta.c:896-897 has the following entry (which is not in the official 2.4.20): 
if (dev->irq==0) 
  return -1; 
If I remove that, the module loads and everything works like a charm. 
... Allan Beaufour

Comment 1 Arjan van de Ven 2003-05-05 12:03:51 UTC
your bios didn't assign an irq to the cardbus card.
We added that check because on some laptops that caused a hard crash on module
load..... but it seems that on some other laptops the other hack for the "no
irq" case was good enough to get it basic working.
For the next build I've removed our sanity check

Comment 2 Arjan van de Ven 2003-05-22 09:42:37 UTC
anyway current erratum reverts to the old behavior

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