Linux-kernel mailing list archive 1998-49,: Re: 2.1.131-ac3 3c509 no irq_save in the sender code

# Re: 2.1.131-ac3 3c509 no irq_save in the sender code

Andrea Arcangeli (andrea@e-mind.com)
Wed, 9 Dec 1998 16:11:00 +0100 (CET)

- Messages sorted by: [ date ][ thread ][ subject ][ author ]
- Next message: Paul Barton-Davis: "Re: Linux threads -- as seen in NT Magazine"
- Previous message: Andrea Arcangeli: "Re: IEEE 1284 development"

On Wed, 9 Dec 1998, Alan Cox wrote:

>SMP
>
>CPU0 CPU1
>
>EL3_WINDOW(1)
>out to fifo
>out to fifo IRQ
>out to fifo stats change
>out to fifo EL3_WINDOW(6)
>out to stats read stats
>out to stats EL3_WINDOW(1)
>out to fifo IRQ return

You could' t really explain the thing better. I taken some minutes but now
I understood the EL3WINDOW meaning and the reason for the disable_irq()
thing fine.

The point is to avoid update_stats() (that goes in windows 6 for awhile)
to run while the TX is on the fly. But to do that we don' t need the
spin_lock in el3_interrupt, update_stats will just spin on the lock itself
if needed. And disable_irq() just synchronize_irqs itself btw (I was wrong
in my last email).

Index: linux/drivers/net/3c509.c
diff -u linux/drivers/net/3c509.c:1.1.3.1 linux/drivers/net/3c509.c:1.1.1.1.2.4
--- linux/drivers/net/3c509.c:1.1.3.1 Sat Dec 5 11:13:41 1998
+++ linux/drivers/net/3c509.c Wed Dec 9 16:08:04 1998
@@ -597,7 +597,6 @@
}
lp = (struct el3_private *)dev->priv;
- spin_lock(&lp->lock);
if (dev->interrupt)
printk("%s: Re-entering the interrupt handler.\n", dev->name);
@@ -660,7 +659,6 @@
printk("%s: exiting interrupt, status %4.4x.\n", dev->name,
inw(ioaddr + EL3_STATUS));
}
- spin_unlock(&lp->lock);
dev->interrupt = 0;
return;
}

Comments?

Andrea Arcangeli

PS. Many thanks Alan for the very useful explanation.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

- Next message: Paul Barton-Davis: "Re: Linux threads -- as seen in NT Magazine"
- Previous message: Andrea Arcangeli: "Re: IEEE 1284 development"