The following information was provided by Joseph Garcia (jpgarcia@execpc.com), but not posted by him. :)
Kernel version: any (2.2.x - 2.4.x)
Symptoms: high speed transfers from a macintosh with a BMAC network device are limited to less than 100kB/s and often corrupted. Systems known to have this are some Wallstreets and beige Desktops. 10/100 chips in Lombard are BMAC+ which do not seem to have the bug. This is a hardware bug that exists in some releases of the chip, and only effects Tx packets.
Reproduction instructions: Open an FTP client to any system you have a potential 10Mbit transfer speed. Transfering from the other computer will yeild high speeds, however transfering to the other system will reveal this problem. This works with most all protocols i've seen. This is also seen when on occation, SSH connections using scp or X-forwarding will close with a comment on connection quality/reliability. something like that.
Explanation of problem: When there is a collision on the network, the BMAC chip will corrupt its Tx DMA buffer. Proposed solution is to have only one Tx packet in DMA at a time, which the current driver seems to almost do. Potential for more than one in transit seems to exist. I beleive that there might be something else relevant to what causes the collisions.
Fixes: No known implementations in Linux. MacOS and Darwin appear to have workarounds.
ADDENDUM FROM POSTER:
A kludge to get around this problem is to continuously ping a machine; this seems to allow *some* connectivity, and I've heard of other people doing this as well as a kludge. I'm not a programmer, so I couldn't tell you how or why this works. :)
Logged In: YES
user_id=46404
Our driver may not feed the chip fast enough to trigger this
bug. Takashi fixed a different (dbdma related) issue that
appear to fix all known bmac issues so far...