bge mac address initialization is wrong
The way that
bge does its mac addresses initailization and management isn't quite correct. When updates for the 5719/5720 was done it disabled the use of the MAC features for using rings and groups and restored the old unicast mac address setting. The way that it did this was that it set all for receive address registers and set the tracking state to indicate that they were used during initialization.
However, when the unicast entry point was called, it used the rings mac address related functions. However, it thought all of the unicast addresses were available, but they weren't actually because that was tracked in a different way. These basically ended up leading us to walk over the array of mac addresses and actually end up dereferencing beyond the end of an array of mac addresses. While there were ASSERTS there, they weren't found until testing on a debug build for 12450.
Updated by Robert Mustacchi over 1 year ago
We tested this on three different devices, which covers three different chipset families in bge(7D):
In all cases we exercised parts of the following bits of functionality:
- IPv4, IPv6
- Link Aggregation (LACP)
- Basic gigabit TCP saturation (over NFS, SCP, etc.) and data validation
Updated by Electric Monk over 1 year ago
- Status changed from New to Closed
- % Done changed from 90 to 100
commit 9e717e77bf4b9b5ad279c38a2311c076468e85f5 Author: Robert Mustacchi <email@example.com> Date: 2020-04-22T06:18:18.000Z 12496 bge mac address initialization is wrong 12497 bge ape locking left always disabled after 7513 12498 bge ring interrupt masking logic is broken Reviewed by: Paul Winder <firstname.lastname@example.org> Approved by: Dan McDonald <email@example.com>