Help: eth1: IRQ handler is looping too much! Shutting down

[David Gibson]

On Sun, Jun 16, 2002 at 06:33:05PM -0400, Joseph R. Skoler wrote:
> 
> Making progress, but sure could use some more help -- I'm stuck:
> 
> Redhat 7.2/2.4.18, pcmcia-cs-3.1.34, Orinoco Gold 7.28, Orinoco 11b.
> 
> Upon bootup, dmesg shows:
> 
> Linux PCMCIA Card Services 3.1.34
>   kernel build: 2.4.18 #10 SMP Fri Jun 14 18:45:20 EDT 2002
>   options:  [pci] [cardbus] [apm]
> Intel ISA/PCI/CardBus PCIC probe:
> PCI: Found IRQ 11 for device 01:0c.0
> PCI: Sharing IRQ 11 with 00:01.0
> PCI: Sharing IRQ 11 with 01:08.0
>   TI 1410 rev 01 PCI-to-CardBus at slot 01:0c, mem 0xe4801000
>     host opts [0]: [pci only] [pci irq 11] [lat 64/176] [bus 2/5]
>     PCI card interrupts, PCI status changes
> cs: memory probe 0xa0000000-0xa0ffffff: clean.
> hermes.c: 5 Apr 2002 David Gibson <hermes at gibson.dropbear.id.au>
> orinoco.c 0.11b (David Gibson <hermes at gibson.dropbear.id.au> and others)
> orinoco_cs.c 0.11b (David Gibson <hermes at gibson.dropbear.id.au> and others)
> cs: IO port probe 0x0100-0x04ff: excluding 0x200-0x207 0x378-0x37f
> 0x3c0-0x3df 0x4d0-0x4d7
> cs: IO port probe 0x0208-0x0377: clean.
> cs: IO port probe 0x0380-0x03bf: clean.
> cs: IO port probe 0x03e0-0x04cf: clean.
> cs: IO port probe 0x04d8-0x04ff: clean.
> cs: IO port probe 0x0a00-0x0aff: clean.
> cs: IO port probe 0x0c00-0x0cff: clean.
> eth1: Station identity 001f:0001:0007:001c
> eth1: Looks like a Lucent/Agere firmware version 7.28
> eth1: Ad-hoc demo mode supported
> eth1: IEEE standard IBSS ad-hoc mode supported
> eth1: WEP supported, 104-bit key
> eth1: MAC address 00:02:2D:52:CE:7D
> eth1: Station name "HERMES I"
> eth1: ready
> eth1: index 0x01: Vcc 5.0, irq 11, io 0x0100-0x013f
> 
> When I issue "iwpriv eth1 monitor 1 1" dmesg appends:
> 
> eth1: IRQ handler is looping too much! Shutting down.

This means the driver is receiving way more interrupts than it could
reasonably expect.  It's basically a sanity test so that if something
goes wrong and the interrupt line is never deasserted, the whole
machine doesn't lock up inside the interrupt routine.

> Thinking it's an IRQ problem, I've tried each line (uncommented) in the
> following /etc/sysconfig/pcmcia:
> 
> #PCIC_OPTS=irq_list=3
> #CORE_OPTS=
> #CARDMGR_OPTS=
> #PCIC=yenta_socket
> PCIC=i82365
> #PCIC_OPTS=irq_list=11
> #PCIC_OPTS=irq_mode=0
> #PCI_IRQ_LIST=3
> #PCIC_OPTS="irq_mode=0 pci_csc=0 poll_interval=100"
> #PCIC_OPTS="irq_mode=1 irq_list=3,4"
> PCIC_OPTS="irq_mode=0 pci_irq_list=3,4,5,7,9"
> 
> Interestingly, the ti1410 always gets irq 11 -- nothing I do can seems to
> change that.
> 
> Although, when I choose irq_mode=1, I get the following:
> 
>   TI 1410 rev 01 PCI-to-CardBus at slot 01:0c, mem 0xe4801000
>     host opts [0]: [isa irq] [pci irq 11] [lat 64/176] [bus 2/5]
>     ISA irqs (scanned) = none!<6>    PCI card interrupts, PCI status changes
> 
> Does the group think this looks like an IRQ conflict?  If not, what then?

It's possible - but the driver can share interrupts so to cause this
problem it would mean the other device is generating heaps of
interrupts.  Probably more likely is some misconfiguration of the
PCI<->PCMCIA bridge so that it always asserting the interrupt line.

-- 
David Gibson			| For every complex problem there is a
david at gibson.dropbear.id.au	| solution which is simple, neat and
				| wrong.  -- H.L. Mencken
http://www.ozlabs.org/people/dgibson