lkml.org 
[lkml]   [2000]   [Feb]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 2.3.47 tulip lockup
Andre Hedrick wrote:
>
> On Fri, 25 Feb 2000, Andrea Arcangeli wrote:
>
> > here the fix for the tulip deadlock at against 2.3.48pre1:
>
> > @@ -1009,6 +1003,9 @@
> > printk(KERN_INFO "%s: %s rev %d at %#3lx,",
> > dev->name, tulip_tbl[chip_idx].chip_name, chip_rev, ioaddr);
> >
> > + /* initalize before accessing the chipsets */
> > + spin_lock_init(&tp->tx_lock);
> > +
>
> Little overkill, prettier than my kludge, and looks like a decenct
> standard to setup "spin_lock_init(....);"

See my patch posted under subject "Tulip driver overhaul" which was also
sent to Linus [separately]

Short term, what should really be done is something like

outl_csr6() {
if (chip != xircom)
outl(data)
return
...ugly xircom-specific locking and such...
}

The lock should not even be held for most adapters. (Linus pointed out
that even my version, as posted to lkml and sent to him, is still ugly
because of said locking)

However, the REAL solution is to completely audit this driver for SMP.
eepro100 should be a good model, and 8139too after 2.3.48-pre2 (or
whatever) is released.

--
Jeff Garzik |
Building 1024 | Viva la open source!
MandrakeSoft, Inc. |

-
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/

\
 
 \ /
  Last update: 2005-03-22 13:56    [W:0.051 / U:0.532 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site