Andy Sporner wrote:
[ ... ]
At this point, lack of information about the device makes
it hard to offer advice. I can only offer the following
observartions, and the rest is up to you:
o You indicated that the Realtek interface has
ovrlapping memory, if probed and attached. Maybe
it has it anyway.
o You indicate that there is a register that is
available through the I/O space. There has to
be a reason why the vendor did this.
o The following are the differences between the
NetBSD and FreeBSD versions; I believe them to
be significant:
o The NetBSD driver does not lock up,
while the FreeBSD driver does
o The NetBSD "pattern write and read" is
slow, but the FreeBSD version is fast
My suggestion is to:
1) Print out the configuration bits on both FreeBSD and
NetBSD to see if there is a difference.
2) Find out why the register is exposed in I/O space.
3) Find out why the NetBSD is slower. It may be the
configuration bits. It may be the programming of
the bridge chipset; it may be writeback caching;
it may be something else entirely.
4) Intentionally add a delay into the FreeBSD code;
for all I know about the hardware, it has DRAM on
it, and accessing it at full throttle without the
waits that the NetBSD version of the code has may
mean that it misses too many refresh cycles and
craps out.
5) Add a timeout reset to the receive interrupt; if
this fixes it, the problem is in the receive
interrupt getting lost.
6) "" for the transmit interrupt.
7) Consider going to NETISR based polling, where you
call the ISR for the card, as if there had been an
interrupt. Worst case, if everything else is equal,
this will effectively poll the card, instead of
waiting for interrupts, and lost interrupts will be
apparent.
Other than that, it's Bill Paul time...
-- Terry
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
