Chris Cappuccio ??????:
i've got a pair of h8ssl-i boards that work fine at 133mhz. i have
another set that i run at 66mhz, but only because that's the max the raid
controller supports (some kind of LSI card. i like the areca better though)
bge shows up as:
bge0 at pci2 dev 3 function 0 "Broadcom BCM5704C" rev 0x10, BCM5704 B0
(0x2100): irq 5, address 00:30:48:56:68:d4
brgphy0 at bge0 phy 1: BCM5704 10/100/1000baseT PHY, rev. 0
bge1 at pci2 dev 3 function 1 "Broadcom BCM5704C" rev 0x10, BCM5704 B0
(0x2100): irq 9, address 00:30:48:56:68:d5
brgphy1 at bge1 phy 1: BCM5704 10/100/1000baseT PHY, rev. 0
In fact, the H8-SSL-I2 docs say the jumper is for the PCI-X slot, not
for the PCI-X bus, so I guess the onboard BCM704C is unaffected of its
settings. Anyways, if it is, or is not, it surely IS working fine,
except for the input errors Stuart pointed he had, which i could
confirm. I've not seen any problems with traffic flowing through them,
though, but Stuart have had.
Also, nobody claims the PCI-X is not workable on 133 MHz bus, what it
seems like is there's a compatibility issues between recent Intel em(4)s
and the ServerWorks HT-1000 (or this Supermicro board). In my opinion,
it's too bad that hardware of exactly this two brands, which are
none-the-less big names in the server market, are unable to play
together nicely at 133 MHz. It's a shame!
Regards,
Doichin
Stuart Henderson [EMAIL PROTECTED] wrote:
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.
