2.2.11 and tulip.c issues

[Robert G. Brown]

On Fri, 20 Aug 1999, Donald Becker wrote:

> On Thu, 19 Aug 1999, Aron Griffis wrote:
> 
> > On Thu, 19 Aug 1999, Robert G. Brown wrote:
> > > Unfortunately, if the ioport doesn't shift I'm going to guess that the
> > > patch doesn't help.  Its beginning to sound more like some kernel
> > > resource is overlapping -- perhaps a memory-mapped region?  -- with the
> ...
> > Thanks for the attention to the problem, Robert.  I consulted with the
> > guy here that wrote the tulip driver for Tru64, and he made some
> > recommendations, none of which changed the behavior I'd been seeing.
> 
> The current Tulip driver uses I/O space accesses to registers.  I've known
> for a while that using memory space would produce better code on machines
> like the Alpha and PPC that don't have native I/O space instructions.
> 
> It turns out that using memory space results in dramatically better performance
> on certain x86 SMP machines as well.  The trivial single processor performance
> improvement is multiplied because the tiny number of I/O writes occur in
> locked critical regions.  Using memory space allows the writes to "complete"
> into the write buffer immediately, instead of waiting until the PCI bus
> transaction has finished.
> 
> I have a test version of the Tulip driver that uses memory operations.
> This might fix the problem above, and will likely avoid the need for
> udelay(2) on the PNIC to work around the write-buffer-delay bug.

This sounds good.  If you give me a URL I'd be happy to give it a spin
here.  I'm probably just going to be "playing" compared to the rigorous
testing sequence you describe below, but maybe I can break something
with it, you never know;-).  I'll probably be playing anyway...

   rgb

Robert G. Brown	                       http://www.phy.duke.edu/~rgb/
Duke University Dept. of Physics, Box 90305
Durham, N.C. 27708-0305
Phone: 1-919-660-2567  Fax: 919-660-2525     email:rgb@phy.duke.edu