Skip to contentSkip to conversation

xirc2ps_cs, irq 3: nobody cared, shutdown hangs

bug 2.5.69 Daniel Ritz 5 participants 10 messages May 11, 2003 – May 13, 2003 Network drivers

lore
Share & tools
lore

Daniel Ritz

author
#0 lore raw

hi

i see that one on shutdown with a xircom ce3 10/100 16bit pcmcia network card, driver xirc2ps_cs. the netdevice also never gets free, so the shutdown never finishs. 2.5.68 also doesn't work, 2.5.67 does work.

rgds
-daniel

irq 3: nobody cared!

Call Trace:
 [<c010d5ff>] handle_IRQ_event+0x93/0x104
 [<c010d607>] handle_IRQ_event+0x9b/0x104
 [<c010dac1>] do_IRQ+0x181/0x2cc
 [<d0839b80>] +0x0/0xa80 [yenta_socket]
 [<c010bfe0>] common_interrupt+0x18/0x20
 [<d0839b80>] +0x0/0xa80 [yenta_socket]
 [<d0836938>] yenta_set_socket+0x144/0x250 [yenta_socket]
 [<d083847e>] +0x55e/0x87e [yenta_socket]
 [<d0836144>] pci_set_socket+0x28/0x34 [yenta_socket]
 [<d0839b80>] +0x0/0xa80 [yenta_socket]
 [<d0888192>] set_socket+0x16/0x1c [pcmcia_core]
 [<d0889d0b>] pcmcia_release_configuration+0xa7/0x110 [pcmcia_core]
 [<d088b018>] CardServices+0x1b8/0x340 [pcmcia_core]
 [<d084bec0>] xirc2ps_cs_driver+0x0/0xa0 [xirc2ps_cs]
 [<d0849268>] xirc2ps_release+0x68/0x94 [xirc2ps_cs]
 [<d084bf60>] +0x0/0xe0 [xirc2ps_cs]
 [<d084a621>] +0x21/0x60 [xirc2ps_cs]
 [<c013cdd5>] sys_delete_module+0x1b5/0x1d8
 [<c0154e5c>] sys_munmap+0x44/0x64
 [<c010b673>] syscall_call+0x7/0xb

handlers:
[<d0849438>] (xirc2ps_interrupt+0x0/0x59c [xirc2ps_cs])
unregister_netdevice: waiting for eth0 to become free. Usage count = 2
unregister_netdevice: waiting for eth0 to become free. Usage count = 2
unregister_netdevice: waiting for eth0 to become free. Usage count = 2
unregister_netdevice: waiting for eth0 to become free. Usage count = 2

#1 lore raw
Quoted 5 lines · Daniel Ritz

hi

i see that one on shutdown with a xircom ce3 10/100 16bit pcmcia network card, driver xirc2ps_cs. the netdevice also never gets free, so the shutdown never finishs. 2.5.68 also doesn't work, 2.5.67 does work.

Interesting, eject with one of my PCMCIA (smc91c92) network cards also triggers an unhandled interrupt. I think the IRQ_NONE is incorrect here as the device really may have an interrupt to service.

Index: linux-2.5-cvs/drivers/net/pcmcia/xirc2ps_cs.c
===================================================================
RCS file: /home/cvs/linux-2.5/drivers/net/pcmcia/xirc2ps_cs.c,v retrieving revision 1.19

drivers/net/pcmcia/xirc2ps_cs.c +2 -1
diff -u -p -B -r1.19 xirc2ps_cs.c
@@ -1312,7 +1312,7 @@ xirc2ps_interrupt(int irq, void *dev_id,
 				  */
 
     if (!netif_device_present(dev))
-	return IRQ_NONE;
+	goto out;
 
     ioaddr = dev->base_addr;
     if (lp->mohawk) { /* must disable the interrupt */

@@ -1515,6 +1515,7 @@ xirc2ps_interrupt(int irq, void *dev_id,
      * force an interrupt with this command:
      *	  PutByte(XIRCREG_CR, EnableIntr|ForceIntr);
      */
+  out:
     return IRQ_RETVAL(handled);
 } /* xirc2ps_interrupt */
Quoted 4 lines

unregister_netdevice: waiting for eth0 to become free. Usage count = 2
unregister_netdevice: waiting for eth0 to become free. Usage count = 2
unregister_netdevice: waiting for eth0 to become free. Usage count = 2
unregister_netdevice: waiting for eth0 to become free. Usage count = 2

I can reproduce this, i'll have a look.

Signature · 1 line
function.linuxpower.ca
#2 lore raw
Quoted 10 lines · Zwane Mwaikambo
drivers/net/pcmcia/xirc2ps_cs.c +1 -1
@@ -1312,7 +1312,7 @@ xirc2ps_interrupt(int irq, void *dev_id,
 				  */
 
     if (!netif_device_present(dev))
-	return IRQ_NONE;
+	goto out;
 
     ioaddr = dev->base_addr;
     if (lp->mohawk) { /* must disable the interrupt */

drivers/net/pcmcia/xirc2ps_cs.c xirc2ps_interrupt(int irq, void *dev_id, · line 1520

Quoted 6 lines
drivers/net/pcmcia/xirc2ps_cs.c +1 -0
@@ -1515,6 +1515,7 @@ xirc2ps_interrupt(int irq, void *dev_id,
      * force an interrupt with this command:
      *	  PutByte(XIRCREG_CR, EnableIntr|ForceIntr);
      */
+  out:
     return IRQ_RETVAL(handled);
 } /* xirc2ps_interrupt */

If this patch works, it's mainly a signal to dig deeper.

If netif_device_present() returns false, we think the hardware has disappeared. So that implies a bug in calling netif_device_detach() no a bug in the irq handler return value.

This is _especially_ true for pcmcia, even more than pci. PCI ejects (including cardbus) are electrically safe, whereas pcmcia is different.
If pcmcia hardware disappears on you, you _really_ don't want to be
bitbanging its ports.

Jeff

#3 lore raw
Quoted 10 lines · Jeff Garzik

If this patch works, it's mainly a signal to dig deeper.

If netif_device_present() returns false, we think the hardware has disappeared. So that implies a bug in calling netif_device_detach() no a bug in the irq handler return value.

This is _especially_ true for pcmcia, even more than pci. PCI ejects (including cardbus) are electrically safe, whereas pcmcia is different.
If pcmcia hardware disappears on you, you _really_ don't want to be
bitbanging its ports.

Could possibly be a problem in CardServices, it appears to defer free'ing interrupts.

Signature · 1 line
function.linuxpower.ca
#4 lore raw
In reply to Jeff Garzik
Quoted 3 lines · Jeff Garzik

If netif_device_present() returns false, we think the hardware has disappeared. So that implies a bug in calling netif_device_detach() no a bug in the irq handler return value.

Not really. The IRQ can be outstanding from the hardware unplug, especially on PCMCIA. Its an edge triggered IRQ so the unplug is very likely to latch an IRQ for delivery as the connector unplugs.

Quoted 2 lines

If pcmcia hardware disappears on you, you _really_ don't want to be
bitbanging its ports.

Its quite safe to do so. What we must do is ensure we don't reallocate the ports until they are truely freed. The current PCMCIA seems to get that right, (the current PCI locking for cardbus and hotplug is still terminally broken of course)

Alan

#5 lore raw
Quoted 3 lines · Alan Cox
Quoted 2 lines · Jeff Garzik

If pcmcia hardware disappears on you, you _really_ don't want to be
bitbanging its ports.

PCMCIA has varying pin length for the CD pins and hence gives you a few milliseconds of warning before the card is _actually_ disconnected.

After that period of time has elapsed and the card is actually gone, you _really_ don't want to be bitbanging its ports.

Quoted 1 line

Its quite safe to do so.

Not on all platforms.

Signature · 1 line
dwmw2
#6 lore raw
Quoted 2 lines · David Woodhouse

PCMCIA has varying pin length for the CD pins and hence gives you a few milliseconds of warning before the card is _actually_ disconnected.

Which is less than the worst case IRQ response time (or indeed on some PCs the worst case CPU hold off time for the PCI bus)

Quoted 6 lines

After that period of time has elapsed and the card is actually gone, you _really_ don't want to be bitbanging its ports.

Quoted 1 line

Its quite safe to do so.

Not on all platforms.

On all that matters it is safe, the others are unfixable anyway

#7 lore raw
Quoted 6 lines · Alan Cox
Quoted 2 lines · David Woodhouse

PCMCIA has varying pin length for the CD pins and hence gives you a few milliseconds of warning before the card is _actually_ disconnected.

Which is less than the worst case IRQ response time (or indeed on some PCs the worst case CPU hold off time for the PCI bus)

On some hardware.

Quoted 8 lines
Quoted 6 lines

After that period of time has elapsed and the card is actually gone, you _really_ don't want to be bitbanging its ports.

Quoted 1 line

Its quite safe to do so.

Not on all platforms.

On all that matters it is safe, the others are unfixable anyway

Said 'others' will tend to give you better worst-case IRQ latency than a PeeCee with broken PCI host bridge and IDE controllers :)

And even if that weren't the case, you appear to be asserting that because a problem may still be triggerable in a worst-case scenario with certain hardware configurations, we shouldn't attempt to fix it at all. With that I disagree.

Signature · 1 line
dwmw2
author
#8 lore raw
In reply to Zwane Mwaikambo
Quoted 11 lines · Zwane Mwaikambo
Quoted 5 lines · Daniel Ritz

hi

i see that one on shutdown with a xircom ce3 10/100 16bit pcmcia network card, driver xirc2ps_cs. the netdevice also never gets free, so the shutdown never finishs. 2.5.68 also doesn't work, 2.5.67 does work.

Interesting, eject with one of my PCMCIA (smc91c92) network cards also triggers an unhandled interrupt. I think the IRQ_NONE is incorrect here as the device really may have an interrupt to service.

ok, i tried that one, but no luck. still nobody cares. so it's that one:
if (int_status == 0xff) { /* card may be ejected */

        DEBUG(3, "%s: interrupt %d for dead card\n", dev->name, irq);
        handled = 0;
        goto leave;
    }

but it's not ejected, only a modpobe -r...

Quoted 31 lines

Index: linux-2.5-cvs/drivers/net/pcmcia/xirc2ps_cs.c
===================================================================
RCS file: /home/cvs/linux-2.5/drivers/net/pcmcia/xirc2ps_cs.c,v retrieving revision 1.19
diff -u -p -B -r1.19 xirc2ps_cs.c
--- linux-2.5-cvs/drivers/net/pcmcia/xirc2ps_cs.c 8 May 2003 05:16:27
-0000 1.19 +++ linux-2.5-cvs/drivers/net/pcmcia/xirc2ps_cs.c 11 May 2003
15:20:03 -0000 @@ -1312,7 +1312,7 @@ xirc2ps_interrupt(int irq, void *dev_id,

drivers/net/pcmcia/xirc2ps_cs.c +2 -1
 				  */
 
     if (!netif_device_present(dev))
-	return IRQ_NONE;
+	goto out;
 
     ioaddr = dev->base_addr;
     if (lp->mohawk) { /* must disable the interrupt */

@@ -1515,6 +1515,7 @@ xirc2ps_interrupt(int irq, void *dev_id,
      * force an interrupt with this command:
      *	  PutByte(XIRCREG_CR, EnableIntr|ForceIntr);
      */
+  out:
     return IRQ_RETVAL(handled);
 } /* xirc2ps_interrupt */
Quoted 4 lines

unregister_netdevice: waiting for eth0 to become free. Usage count = 2
unregister_netdevice: waiting for eth0 to become free. Usage count = 2
unregister_netdevice: waiting for eth0 to become free. Usage count = 2
unregister_netdevice: waiting for eth0 to become free. Usage count = 2

I can reproduce this, i'll have a look.

#9 lore raw
Quoted 8 lines · Daniel Ritz

ok, i tried that one, but no luck. still nobody cares. so it's that one:
if (int_status == 0xff) { /* card may be ejected */

        DEBUG(3, "%s: interrupt %d for dead card\n", dev->name, irq);
        handled = 0;
        goto leave;
    }

but it's not ejected, only a modpobe -r...

We shutdown the device so a lot of things aren't defined at this stage. Lets make that handled = 1, we're bound to have 1 or 2 of these interrupts creeping in.

Index: linux-2.5-cvs/drivers/net/pcmcia/xirc2ps_cs.c
===================================================================
RCS file: /home/cvs/linux-2.5/drivers/net/pcmcia/xirc2ps_cs.c,v retrieving revision 1.19

drivers/net/pcmcia/xirc2ps_cs.c +1 -2
diff -u -p -B -r1.19 xirc2ps_cs.c
@@ -1312,7 +1312,7 @@ xirc2ps_interrupt(int irq, void *dev_id,
 				  */
 
     if (!netif_device_present(dev))
-	return IRQ_NONE;
+	return IRQ_HANDLED;
 
     ioaddr = dev->base_addr;
     if (lp->mohawk) { /* must disable the interrupt */

@@ -1330,7 +1330,6 @@ xirc2ps_interrupt(int irq, void *dev_id,
   loop_entry:
     if (int_status == 0xff) { /* card may be ejected */
 	DEBUG(3, "%s: interrupt %d for dead card\n", dev->name, irq);
-	handled = 0;
 	goto leave;
     }
     eth_status = GetByte(XIRCREG_ESR);
Signature · 1 line
function.linuxpower.ca