Debug info for RequestIRQ: Resource in use

Adam D Bradley artdodge at cs.bu.edu
Wed Oct 8 02:05:56 BST 2003 

Hi Pavel,

Thanks for your quick reply.  Here's what I've gathered so far.

On Mon, 2003-10-06 at 16:31, Pavel Roskin wrote: 
> On Mon, 6 Oct 2003, Adam D Bradley wrote:

> > I get the "RequestIRQ: Resource in use" error using an orinoco wireless
> > PCMCIA card (Lucent WaveLAN/IEEE) under ISA-enabled Linux 2.6.0-test6
> > kernels.  I applied the debugging patch from
> > http://pcmcia.arm.linux.org.uk/ (for which this list is the only stated
> > contact address) and here's what I got:
> >
> > Oct  6 15:46:21 puddleglum kernel: cs: memory probe
> > 0xa0000000-0xa0ffffff: clean.
> 
> I don't see the messages from the socket initialization.  Since you
> compiled PCMCIA support into the kernel, it should be in the early
> messages during the boot.  If you compile PCMCIA as modules, you'll see
> the messages when you load the modules.  Those messages can show what
> interrupts are used.

PCI: Enabling device 0000:02:01.0 (0000 -> 0002)
Yenta: CardBus bridge found at 0000:02:01.0 [1028:014e]
Yenta: ISA IRQ list 00d8, PCI irq9
Socket status: 30000006
Yenta: CardBus bridge found at 0000:02:01.1 [1028:014e]
Yenta: ISA IRQ list 00d8, PCI irq9
Socket status: 30000047

> I don't see any information about your hardware.  It appears you have two
> separate PCMCIA bridges on the same interrupt.  Can you send the output of
> lspci?  On the other hand, I see that "cardctl info" only reports data for
> one socket.

puddleglum:~# lspci
00:00.0 Host bridge: Intel Corp.: Unknown device 3340 (rev 03)
00:01.0 PCI bridge: Intel Corp.: Unknown device 3341 (rev 03)
00:1d.0 USB Controller: Intel Corp. 82801DB USB (Hub #1) (rev 01)
00:1d.1 USB Controller: Intel Corp. 82801DB USB (Hub #2) (rev 01)
00:1d.2 USB Controller: Intel Corp. 82801DB USB (Hub #3) (rev 01)
00:1d.7 USB Controller: Intel Corp. 82801DB USB EHCI Controller (rev 01)
00:1e.0 PCI bridge: Intel Corp. 82801BAM/CAM PCI Bridge (rev 81)
00:1f.0 ISA bridge: Intel Corp.: Unknown device 24cc (rev 01)
00:1f.1 IDE interface: Intel Corp.: Unknown device 24ca (rev 01)
00:1f.5 Multimedia audio controller: Intel Corp. 82801DB AC'97 Audio
(rev 01)
00:1f.6 Modem: Intel Corp. 82801DB AC'97 Modem (rev 01)
01:00.0 VGA compatible controller: nVidia Corporation: Unknown device
0286 (rev a1)
02:00.0 Ethernet controller: Broadcom Corporation NetXtreme BCM5705M
Gigabit Ethernet (rev 01)
02:01.0 CardBus bridge: Texas Instruments: Unknown device ac47 (rev 01)
02:01.1 CardBus bridge: Texas Instruments: Unknown device ac4a (rev 01)
02:01.2 FireWire (IEEE 1394): Texas Instruments: Unknown device 802b
02:01.3 System peripheral: Texas Instruments: Unknown device 8204
02:03.0 Network controller: Intel Corp.: Unknown device 1043 (rev 04)

puddleglum:~# cardctl status
Socket 0:
  5V 16-bit PC Card
  function 0: [ready]
Socket 1:
  no card

puddleglum:~# cardctl info
PRODID_1="Lucent Technologies"
PRODID_2="WaveLAN/IEEE"
PRODID_3="Version 01.01"
PRODID_4=""
MANFID=0156,0002
FUNCID=6
PRODID_1=""
PRODID_2=""
PRODID_3=""
PRODID_4=""
MANFID=0000,0000
FUNCID=255

The system physically only has one socket.  It also has a smartcard
reader... might that be the second (an uniformed wild-ass guess)?

> My guess is that RequestIRQ fails because the PCMCIA subsystem request the
> IRQ for exclusive use.  See function pcmcia_request_irq() in
> drivers/pcmcia/cs.c.  You may want to add debugging printk calls before
> the call to request_irq() to see if SA_SHIRQ is used, and if it's not, the
> reason for that.

It looks like SA_SHIRQ is not being set, because orinoco_cs wants an
IRQ_TYPE_EXCLUSIVE interrupt.  The specific point at which it fails is
this block within pcmcia_request_irq()  (with my debugging printk()'s
added):

1944         for (irq = 0; irq < 32; irq++)
1945             if ((mask >> irq) & 1) {
1946                 printk("cs: probing irq %d, try %d\n", irq, try);
1947                 ret = try_irq(req->Attributes, irq, try);
1948                 if (ret == 0) break;
1949                 printk("cs: failed, got %d\n", ret);
1950             }

On my system, this block tries to grab interrupts 3, 4, and 7.

IRQ3 already has the serial driver hanging off of it, so that fails
(check_irq in rsrc_mgr.c fails, thus try_irq returns CS_IN_USE).

For IRQs 4 and 7 it's less clear to me what happens; according to
/proc/interrupts, neither has anything attached to it, but since
"irq_table[4].Attributes" and "irq_table[7].Attributes" are both set to
0x60 (RES_ALLOCATED | RES_REMOVED), try_irq() fails because it sees both
that RES_ALLOCATED in irq_table[...].Attributes and IRQ_TYPE_EXCLUSIVE
in the Attributes argument.

Other trivia that may or may not be important:

1) dmesg includes "Dell Latitude with broken BIOS detected. Refusing to
enable the local APIC."; this is a Dell Latitude D800.

2) There's a "spurious 8259A interrupt: IRQ7" in the debug log.  Once I
observed this to happen about 3 seconds after a failed insertion of the
card, although other times this happens without the card having been
inserted.

3) Here's my debugging output from an insert...

Note that "30" = 0x2e = CS_IN_USE
and "0x60" = RES_ALLOCATED (0x20) | RES_REMOVED (0x40)

Oct  8 00:38:38 puddleglum kernel: cs: memory probe
0xa0000000-0xa0ffffff: clean.
Oct  8 00:38:38 puddleglum kernel: orinoco.c 0.13e (David Gibson
<hermes at gibson.dropbear.id.au> and others)
Oct  8 00:38:38 puddleglum kernel: orinoco_cs.c 0.13e (David Gibson
<hermes at gibson.dropbear.id.au> and others)
Oct  8 00:38:38 puddleglum kernel: cs: request irq: pci irq 9 mask 00d8
Oct  8 00:38:38 puddleglum kernel: cs: probing irq 3, try 0
Oct  8 00:38:38 puddleglum kernel: rsrc_mgr: info->Attrributes=0x0
Oct  8 00:38:38 puddleglum kernel: rsrc_mgr: check_irq(3) failed
Oct  8 00:38:38 puddleglum kernel: cs: failed, got 30
Oct  8 00:38:38 puddleglum kernel: cs: probing irq 4, try 0
Oct  8 00:38:38 puddleglum kernel: rsrc_mgr: info->Attrributes=0x60
Oct  8 00:38:38 puddleglum kernel: cs: failed, got 30
Oct  8 00:38:38 puddleglum kernel: cs: probing irq 7, try 0
Oct  8 00:38:38 puddleglum kernel: rsrc_mgr: info->Attrributes=0x60
Oct  8 00:38:38 puddleglum kernel: cs: failed, got 30
Oct  8 00:38:38 puddleglum kernel: cs: probing irq 3, try 1
Oct  8 00:38:38 puddleglum kernel: rsrc_mgr: info->Attrributes=0x0
Oct  8 00:38:38 puddleglum kernel: rsrc_mgr: check_irq(3) failed
Oct  8 00:38:38 puddleglum kernel: cs: failed, got 30
Oct  8 00:38:38 puddleglum kernel: cs: probing irq 4, try 1
Oct  8 00:38:38 puddleglum kernel: rsrc_mgr: info->Attrributes=0x60
Oct  8 00:38:38 puddleglum kernel: cs: failed, got 30
Oct  8 00:38:38 puddleglum kernel: cs: probing irq 7, try 1
Oct  8 00:38:38 puddleglum kernel: rsrc_mgr: info->Attrributes=0x60
Oct  8 00:38:38 puddleglum kernel: cs: failed, got 30
Oct  8 00:38:38 puddleglum kernel: cs: done probing, ret=30
Oct  8 00:38:38 puddleglum kernel: cs: bailing out, ret=30
Oct  8 00:38:38 puddleglum kernel: orinoco_cs: RequestIRQ: Resource in
use


Adam
---- Adam D. Bradley, Ph.D. -- Research Associate -- <>< ----
----- Department of Computer Science, Boston University -----
-- MCS183 -- 358-1143 -- http://cs-people.bu.edu/artdodge/ --

More information about the linux-pcmcia mailing list