On Mon, Jan 16, 2006 at 08:27:42AM -0800, Jim Gifford wrote:
> Jeff Garzick refuses to apply it do to spinlocks.
Jeff refuses to apply the tulip phy init patch because it could
hold off interrupts for up to 2.5ms. I agree this is not a good
"side effect" of this patch. However, rewriting tulip initialization
sequence to avoid this "side effect" is non-trivial.
And in practice, the interrupts are held off only for 600us or so.
> Andrew Morton is
> including in his tree because it fixes issue with Parisc and with MIPS
> based builds.
> So it's kinda of what is the right thing to do. I also use
> this driver on my x86 builds, and it actually performs better. Here is a
> little history of how Grant made the driver.
> Grant Grundler is the network maintainer for Parisc Linux.
> He discovered that the tulip driver didn't perform that well.
No, with faster CPUs, tulip just didn't work on parisc-linux or ia64-linux.
Exact same symptom you had on the mips platform.
> researched the manufactures documentation and found out how to fix the
> driver to work to its optimum performance. He did this back in 2003, has
Oct 2002 actually.
That was a first mostly correct version.
Here's the "final" patch (at the time):
> submitted it to Jeff Garzick several times with no response.
That's not fair to Jeff - as much as I think he's being juvenile
in this case. Jeff and I did exchange email. He's just trying "encourage"
me to rewrite the driver initialization sequence. Not interested.
I prefer to maintain this patch in parisc-linux source tree myself.
> Around late
> 2004, I started to do test builds on 64 bit on my RaQ2 and discovered
> that the driver would not auto-negotiate transfer speeds. Talked to
> numerous people, then someone put me in touch with Grant. I tested the
> driver for about 2 weeks, ask Grant why it wasn't sent upstream, he told
> me about the spinlock issue. I then contacted Andrew Morton, explained
> everything as I am here, and he agreed it was needed and tried to get
> Jeff to add it.
I happened to talk to Andrew about this at OLS2004 - just before you
showed up with the nice failure case on Mips:
And a second, similar patch that I had outstanding
at the same time:
> Jeff sends back a one liner say doing to it's use of
> spinlocks it's not accepted.
I didn't need a longer explanation - I understood his concern.
> That's the gory history.
Sorry - it's more gory than you thought. :)