Linux MIPS Architecture development
 help / color / mirror / Atom feed
From: Grant Grundler <grundler@parisc-linux.org>
To: Jim Gifford <maillist@jg555.com>
Cc: Martin Michlmayr <tbm@cyrius.com>,
	Linux MIPS List <linux-mips@linux-mips.org>
Subject: Re: Tulip RaQ2 64 Bit Fix
Date: Mon, 16 Jan 2006 13:35:46 -0700	[thread overview]
Message-ID: <20060116203546.GA22635@colo.lackof.org> (raw)
In-Reply-To: <43CBC97E.3090800@jg555.com>

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.

and ia64-linux.

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

>  He 
> 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.
http://lists.parisc-linux.org/pipermail/parisc-linux-cvs/2002-October/031613.html

That was a first mostly correct version.
Here's the "final" patch (at the time):
http://lists.parisc-linux.org/pipermail/parisc-linux-cvs/2002-December/032081.html


> 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:
	http://www.spinics.net/lists/linux-net/msg11267.html

And a second, similar patch that I had outstanding
at the same time:
	http://www.spinics.net/lists/linux-net/msg11268.html

>  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. :)

cheers,
grant

      parent reply	other threads:[~2006-01-16 20:23 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-12-05  5:18 Tulip RaQ2 64 Bit Fix Jim Gifford
2005-12-05 11:44 ` Ralf Baechle
2006-01-16 16:03   ` Martin Michlmayr
2006-01-16 16:27     ` Jim Gifford
2006-01-16 16:58       ` Martin Michlmayr
2006-01-17  1:23         ` Andrew Morton
2006-01-17  1:36           ` Jeff Garzik
2006-01-17  2:35             ` Grant Grundler
2006-01-17  2:29               ` Andrew Morton
2006-01-17  2:29                 ` Andrew Morton
2006-01-16 20:35       ` Grant Grundler [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20060116203546.GA22635@colo.lackof.org \
    --to=grundler@parisc-linux.org \
    --cc=linux-mips@linux-mips.org \
    --cc=maillist@jg555.com \
    --cc=tbm@cyrius.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox