Re: be ethernet - IPv6 / mcast broken ?

[Erik Fair <fair%netbsd.org@localhost>]

What testing support do we (NetBSD) have for verifying the operation of the various ethernet chip hardware checksum offload implementations under combinatorial conditions, e.g. VLAN vs. not VLAN?

I have used be(4) devices in sun4c gear (IPX, SS2) with NetBSD (I think 5 - it’s been some years) and it seemed to work within the limited load I put on them, whereas hme(4) didn’t work (i.e. not seen by OFW, not ergo netbootable). Our own be(4) man page says that the device is not capable of Nway auto-negotiation of media speed and that must be specified explicitly in ifconfig(8).

	Erik



> On Feb 17, 2017, at 12:37, Michael <macallan%netbsd.org@localhost> wrote:
> 
> Hello,
> 
> On Fri, 17 Feb 2017 13:37:32 -0500
> Brandon Applegate <brandon%burn.net@localhost> wrote:
> 
>>> (2) You might find that the BigMac interface is defaulting to
>>> half-duplex operation, which modern switches/hubs tend not to like
>>> at 100MBit/sec. I'm not sure if BigMac even supports full-duplex at
>>> 100Mbit/sec, but if it does, you may need to force it using
>>> OpenBOOT commands.  
>> 
>> It is.  It seems to work (my switches are fine with it).  Obviously
>> not optimal though...
> 
> According to the man page it's half duplex only. Seems to work with my
> switch though.
> 
>>> (3) The BigMac hardware 1.x and 2.x were notoriously buggy at the
>>> hardware/firmware level. Sun released a longish sequence of patches
>>> for SunOS 4 and Solaris 2, and even for OpenBOOT system firmware
>>> (SFE 2.x requires OBP 2.26) to try and address the BigMac hardware
>>> issues, but there was always a certain amount of crossed fingers in
>>> getting them to work reliably. It is possible that NetBSD may
>>> contain better workarounds for the hardware bugs, and might even
>>> contain code to address the above system-level "hardware reasons"
>>> on sun4c, although that does sound a bit optimistic. 
>> 
>> That makes a ton of sense with regard to how this guy is behaving.
>> Sounds like this card had a couple of strikes against it from the
>> get-go...
> 
> I'm not so sure that's what we're seeing here. I can reproduce the IPv6
> issue on an SS20 for starters, but IPv4 operation seems to work fine.
> According to the driver mine's a rev. 1
> 
>>> (4) The SunSwift (hme) 100Mbit/sec Ethernet cards were also not
>>> supported by Sun in sun4c, but in that particular case, appears to
>>> be simply because Sun never went to the effort of formally
>>> qualifying them in such systems, rather than due to any known
>>> imcompatibilities? And they certainly did not have the crippling
>>> hardware bugs that the BigMac cards did. If you have a SunSwift
>>> card to hand, there might be some mileage in giving that a try
>>> instead, although of course no guarantees on an IPX. 
>> 
>> I see.  I read the sparc port hardware page - and saw lots of "not
>> supported on sun4c”.  Sounds like what you are saying is that the hme
>> is much better than the brain-damaged be, but the caveat is that it
>> too isn’t “officially” blessed in a sun4c box.
> 
> It is, and the cards are fairly common. They also support hardware
> checksum offloading which should help with slow CPUs.
> 
> have fun
> Michael
>