On 2007/11/30 09:57, Girish Venkatachalam wrote: > On 20:47:57 Nov 29, Stuart Henderson wrote: > > > Been there, done that. If you use plaintext protocols (ftp or so) > > over the interface, you'll see random corruption visible in the > > data (e.g. directory listings). > > > > At 133MHz there's some corruption between motherboard and card. > > Disappears at 66MHz. > > > > Normally this would be masked by TCP checksums (you'd get packet > > loss, but it would mostly be corrected rather than pass corrupt > > packets up the stack), but the em(4) does offload TCP checksum > > processing to the card, so the checksum no longer covers the > > transfer over the PCI bus, hence the wierd protocol errors. > > TCP checksums or for that matter any checksum cannot catch *all* errors.
Agreed, hence the "mostly". > Since there is a MAC computation for every packet, this will easily help > you identify the problem. With this happening, you're lucky to get an ftp banner through without corruption, I don't think I ever had an SSH session setup. I already have two workarounds, one is to use the old quad em(4) with the IBM(Tundra) bridge (which work ok at 64x133 but the RJ45 sockets are the wrong way up to latch correctly in some of Supermicro's 1U cases), the other is to use the newer cards (Pericom bridge) at 66MHz. I haven't heard of this happen on other systems (and other 64x133 cards work), I suspect it's a hardware problem between H8SSL and the Pericom bridge chip.
