Messages in this thread | | | Date | Fri, 20 Aug 1999 03:11:57 -0400 (EDT) | From | Donald Becker <> | Subject | Re: 2.2.11 and tulip.c issues |
| |
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 is a major change, and I'll have to test a lot of boards. I expect the biggest issue to be timing changes for the serial bit streams used to read the EEPROM and MII registers. I initially validated the original code by probing the traces on the circuit board and checking that actual bit rate was in-spec. Since then I've used a software approach (reading a real-time counter) to verify that the bit rate hasn't changed. The software method may no longer be accurate with the write buffers in the memory subsystem that arbitrarily changes the timing of writes.
A second issue is checking that all of the chips are reliable with memory operations. Some chips, notably the VIA Rhine, were only design-tested with I/O operations.
[[ Please hold any follow-up discussions about Tulip or general driver issues on linux-tulip@beowulf.gsfc.nasa.gov instead of on the linux-kernel list. ]]
Donald Becker becker@cesdis.gsfc.nasa.gov USRA-CESDIS, Center of Excellence in Space Data and Information Sciences. Code 930.5, Goddard Space Flight Center, Greenbelt, MD. 20771 301-286-0882 http://cesdis.gsfc.nasa.gov/people/becker/whoiam.html
- 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/
| |