vr(4) issue on Ultra 10

[Pyun YongHyeon]

On Sun, Feb 05, 2006 at 01:45:30PM +0100, Marius Strobl wrote:
 > On Sat, Feb 04, 2006 at 11:14:47AM -0500, Yasholomew Yashinski wrote:
 > > 
 > > I'm intending to use a U10 as a firewall/gateway, so I'm trying to add 
 > > one of my spare PCI NICs, to use along with the hme0. Trying dc(4) brought 
 > > my OS down (writing another email), so I'm trying vr(4) which is flooding 
 > > dmesg/syslog with errors.
 > > 
 > 
 > Vr(4) has to be converted to use bus_dma(9) and probably also made
 > endian-clean in order to also work on sparc64. Currently it has no
 > chance to work on sparc64 and that's why it is commented out in the
 > sparc64 GENERIC.

Quick reading vr(4) shows that the Rhine chip has a serious
limitation in its Tx DMA mechanism. You wouldn't get reasonable
performance on NICs based on the Rhine chip. As most sparc64
supported by FreeBSD has slow CPUs it's hard to put the NIC to the
limit. Coverting vr(4) to use bus_dma(9) is not simple task but it's
possible. 
Instead of using old fast ethernet, I'd like to recommend a new GigE
which is cheap and well supported by FreeBSD. For instance I modified
sk(4) to use bus_dma(9) it worked very well on sparc64. In fact I
could push the 32bit PCI NIC to the bus limit. You can try modified
sk(4) at the following URL.

http://people.freebsd.org/~yongari/sk/if_sk.c
http://people.freebsd.org/~yongari/sk/if_skreg.c

re(4) should work on sparc64 too. However due to the limitation of
Rx DMA engine it needs a fixup code which means it's not ideal NIC
on sparc64.

 > As for your dc(4) problem; dc(4) generally is know to work on
 > sparc64 but looks like there's a problem with the dcphy(4) pseudo
 > PHY driver used for some variants. I can't spot any problem in
 > its code and frame 6 of your dump appears to be corrupted. Could
 > you maybe get the backtrace from a DDB-enabled kernel instead of
 > a dump?
 > 
 > Marius
 > 
-- 
Regards,
Pyun YongHyeon