2.2.11 and tulip.c issues
Robert G. Brown
Fri Aug 20 11:19:05 1999
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...
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:email@example.com