Donald Becker wrote:
>
> > > However, natsemi.c's spinlock needs to be retained, and
> > > extended into start_tx(), because this driver has
> > > a race which has cropped up in a few others:
> > > ...
> > > if (np->cur_tx - np->dirty_tx >= TX_QUEUE_LEN - 1) {
> > > /*
Donald Becker wrote:
However, natsemi.c's spinlock needs to be retained, and
extended into start_tx(), because this driver has
a race which has cropped up in a few others:
...
if (np-cur_tx - np-dirty_tx = TX_QUEUE_LEN - 1) {
/* WINDOW HERE */
On Sun, 21 Jan 2001, Jeff Garzik wrote:
> Andrew Morton wrote:
> > Manfred wrote:
> > > Hi Jeff, Tjeerd,
> > > I spotted the spin_lock in natsemi.c, and I think it's bogus.
> > >
> > > The "simultaneous interrupt entry" is a bug in some 2.0 and 2.1 kernel
> > > (even Alan didn't remember it
Andrew Morton wrote:
>
> Manfred wrote:
> >
> > Hi Jeff, Tjeerd,
> >
> > I spotted the spin_lock in natsemi.c, and I think it's bogus.
> >
> > The "simultaneous interrupt entry" is a bug in some 2.0 and 2.1 kernel
> > (even Alan didn't remember it exactly when I asked him), thus a sane
> >
Manfred wrote:
>
> Andrew Morton wrote:
> >
> > start_tx()
> > {
>
> Yes, I overlooked start_tx.
>
> Hmm. start_tx also assumes that the cpu commits writes in order, I'm
> sure the driver is unreliable on RISC cpus.
>
> Perhaps the driver should use pci_alloc_consistent and pci_map_single?
Manfred wrote:
Andrew Morton wrote:
start_tx()
{
Yes, I overlooked start_tx.
Hmm. start_tx also assumes that the cpu commits writes in order, I'm
sure the driver is unreliable on RISC cpus.
Perhaps the driver should use pci_alloc_consistent and pci_map_single?
Eventually, all
Andrew Morton wrote:
Manfred wrote:
Hi Jeff, Tjeerd,
I spotted the spin_lock in natsemi.c, and I think it's bogus.
The "simultaneous interrupt entry" is a bug in some 2.0 and 2.1 kernel
(even Alan didn't remember it exactly when I asked him), thus a sane
driver can assume that
On Sun, 21 Jan 2001, Jeff Garzik wrote:
Andrew Morton wrote:
Manfred wrote:
Hi Jeff, Tjeerd,
I spotted the spin_lock in natsemi.c, and I think it's bogus.
The "simultaneous interrupt entry" is a bug in some 2.0 and 2.1 kernel
(even Alan didn't remember it exactly when I asked
Andrew Morton wrote:
>
> start_tx()
> {
Yes, I overlooked start_tx.
Hmm. start_tx also assumes that the cpu commits writes in order, I'm
sure the driver is unreliable on RISC cpus.
Perhaps the driver should use pci_alloc_consistent and pci_map_single?
--
Manfred
-
To unsubscribe from this
Andrew Morton wrote:
start_tx()
{
Yes, I overlooked start_tx.
Hmm. start_tx also assumes that the cpu commits writes in order, I'm
sure the driver is unreliable on RISC cpus.
Perhaps the driver should use pci_alloc_consistent and pci_map_single?
--
Manfred
-
To unsubscribe from this
Manfred wrote:
>
> Hi Jeff, Tjeerd,
>
> I spotted the spin_lock in natsemi.c, and I think it's bogus.
>
> The "simultaneous interrupt entry" is a bug in some 2.0 and 2.1 kernel
> (even Alan didn't remember it exactly when I asked him), thus a sane
> driver can assume that an interrupt handler
Hi Jeff, Tjeerd,
I spotted the spin_lock in natsemi.c, and I think it's bogus.
The "simultaneous interrupt entry" is a bug in some 2.0 and 2.1 kernel
(even Alan didn't remember it exactly when I asked him), thus a sane
driver can assume that an interrupt handler is never reentered.
Donald
Hi Jeff, Tjeerd,
I spotted the spin_lock in natsemi.c, and I think it's bogus.
The "simultaneous interrupt entry" is a bug in some 2.0 and 2.1 kernel
(even Alan didn't remember it exactly when I asked him), thus a sane
driver can assume that an interrupt handler is never reentered.
Donald
Manfred wrote:
Hi Jeff, Tjeerd,
I spotted the spin_lock in natsemi.c, and I think it's bogus.
The "simultaneous interrupt entry" is a bug in some 2.0 and 2.1 kernel
(even Alan didn't remember it exactly when I asked him), thus a sane
driver can assume that an interrupt handler is never
14 matches
Mail list logo
