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

[Joseph R. Skoler]

I've looked through all the docs I could find, and tried a whole bunch of
options, but none seem to change the irq that the board uses (11).

The problem only occurs after entering monitor mode (iwpriv eth1 monitor 1
1).

I've used all the PCIC options below:

#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"
#PCIC_OPTS="irq_mode=3DO"
#PCIC_OPTS="no_scan pci_irq_list=3,4,5,7,9"
#PCIC_OPTS="cb_pci_irq=7"
#PCIC_OPTS="do_pci_probe=0"
#PCIC_OPTS="pci_csc=0"
#PCIC_OPTS="pc_debug=1"
#PCIC_OPTS="pci_int=0"

Any ideas where to turn now?

FYI, here's dmesg:

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

Thanks,

Joseph R. Skoler
joseph at compuhelp.com <mailto:joseph at compuhelp.com>
CompuHelp Technologies, Inc.
Computer Consulting, Network Solutions, Integration, Support
11 Lispenard Street   New York, NY  10013  212-995-2955
http://www.compuhelp.com



> > > > 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.
> >
> > Physical misconfiguration -- i.e., dip switch/jumper setting?
>
> Possibly, but more likely something in the PCMCIA subsystem that's
> setting up the bridge incorrectly.  I don't know much about this area,
> but I think different bridges act a bit differently with respect to
> this, so there are sometimes problems.
>
> > If not, where is the config stuff for the TI1410?
>
> Like I say, I don't know this area at all well.  You could try
> fiddling with the irq_mode parameter.
>
> --
> 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
>