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
On Sun, 11 May 2003, Daniel Ritz wrote:
> 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
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,
*/
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 */
> 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.
--
function.linuxpower.ca
Zwane Mwaikambo wrote:
> @@ -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 */
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
On Sun, 11 May 2003, Jeff Garzik wrote:
> 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.
--
function.linuxpower.ca
On Sul, 2003-05-11 at 18:24, Jeff Garzik wrote:
> 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.
> 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
On Sun, 2003-05-11 at 18:20, Alan Cox wrote:
> On Sul, 2003-05-11 at 18:24, Jeff Garzik wrote:
> > 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.
> Its quite safe to do so.
Not on all platforms.
--
dwmw2
On Sul, 2003-05-11 at 23:08, David Woodhouse wrote:
> 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)
> After that period of time has elapsed and the card is actually gone, you
> _really_ don't want to be bitbanging its ports.
>
> > Its quite safe to do so.
>
> Not on all platforms.
On all that matters it is safe, the others are unfixable anyway
On Sun, 2003-05-11 at 22:40, Alan Cox wrote:
> On Sul, 2003-05-11 at 23:08, David Woodhouse wrote:
> > 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.
> > After that period of time has elapsed and the card is actually gone, you
> > _really_ don't want to be bitbanging its ports.
> >
> > > 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.
--
dwmw2
On Sunday 11 May 2003 18:13, Zwane Mwaikambo wrote:
> On Sun, 11 May 2003, Daniel Ritz wrote:
> > 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...
> 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,
> */
>
> 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 */
>
> > 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.
On Mon, 12 May 2003, Daniel Ritz wrote:
> 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
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 13 May 2003 06:50:22 -0000
@@ -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);
--
function.linuxpower.ca