Problems with BCE network adapter (Dell PE2950)

[Tom Judge]

Tom Judge wrote:
> Tom Judge wrote:
>> David Christensen wrote:
>>>> Sorry for the top post, please try following patch:
>>>> http://people.freebsd.org/~sephe/if_bce.c.diff
>>>>
>>>> This is probably the cause; I noticed it when bce(4) was ported to 
>>>> DragonFly.
>>>>
>>>
>>> Thanks Sephe, I think you're on to something.  I have some
>>> debug code in the driver to simulate mbuf allocation
>>> failures and when I enable that I start receiving the same
>>> error messages Tom reported (along with various kernel
>>> panics), but when I include your change the system seems
>>> to keep humming along. I'll certainly add your code into an update 
>>> shortly.
>>>
>>> Dave
>>>
>>
>> I'm not going to have a chance to test this patch until next week but 
>> I will let you know what the results are.
>>
>> Tom
> 
> 
> So here goes,  after 2 days testing we have come up with the following 
> data.
> 
> The configuration
> 
> [PE[12]950] ----> [PowerConnect 5324]
> 
> The system is running 8192 byte Jumbo Frames.
> 
> sultan# ifconfig bce0
> bce0: flags=8847<UP,BROADCAST,DEBUG,RUNNING,SIMPLEX,MULTICAST> mtu 8192
>         options=3b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU>
>         inet 172.31.0.28 netmask 0xffffff00 broadcast 172.31.0.255
>         inet 172.31.0.163 netmask 0xffffffff broadcast 172.31.0.163
>         ether 00:19:b9:e4:4d:cc
>         media: Ethernet autoselect (1000baseTX <full-duplex>)
>         status: active
> 
> 
> After applying both David and Sephe's patches I have yet to get a system 
> in a state where it is stable with jumbo frames enabled, the systems 
> crash almost immediately after the switch changes the port state 
> (Spanning tree) from LEARNING to FORWARDING.  The output from this crash 
> can be found attached as crash-1.txt.gz.
> 
> If the frame size is left at 1500 then the interface seems stable, 
> however I can't fully test this as the interface is connected to a GigE 
> only network with an mtu of 8192.
> 
> If BCE_DEBUG is remove from if_bcereg.h then the system just exhibits 
> the original problem and may or may not crash.
> 
> The next test was to try the kernel with BCE_DEBUG and with the 
> following extra patch (so that the driver does not jump to the 
> breakpoint when an unexpected mbuf is found in the rx buffer).
> 
> --- if_bce.c    (revision 62)
> +++ if_bce.c    (revision 66)
> @@ -4050,7 +4050,8 @@
>                         DBRUNIF((!(rxbd->rx_bd_flags & RX_BD_FLAGS_END)),
>                                 BCE_PRINTF("%s(%d): Unexpected mbuf 
> found in rx_bd[0x%04X]!\n",
>                                 __FILE__, __LINE__, sw_chain_cons);
> -                               bce_breakpoint(sc));
> +                               bce_dump_mbuf(sc, m));
> +//                             bce_breakpoint(sc));
> 
>                         /*
>                          * ToDo: If the received packet is small enough
> 
> 
> With this patch the system boots and does not crash straight away, 
> however it is almost completely unusable.  The output with this kernel 
> can be found attached as crash-2.txt.gz.  Also this causes the following 
> new error message:
> 
> fgrep -n leak crash-2.txt
> 3194:bce0: /usr/src/sys/dev/bce/if_bce.c(3842): Memory leak! Lost 114 
> mbufs from rx chain!
> 
> Has no one else come across this problem, or are Jumbo frames not widely 
> used?
> 
> Tom
> 
It would seem that the crash can be simulated just by increasing the MTU 
above 1500 (tested in single user mode).

Tom