First, thanks for the prompt reply!
Stuart Henderson ??????:
On 2007/11/29 22:23, NetOne - Doichin Dokov wrote:
Two weeks ago i bought an Intel Pro/1000MT dual Gbit NIC because i was gonna
soon be in need for more ports in one of our 1U systems,
Change the PCI jumper, which is currently probably on auto,
to 64 bit 66MHz. You probably need to remove the PCIX card to
reach it (unless they changed much of the design between the
H8SSL and -I2, which I doubt).
Yes, it's there. Right after the first PCI slot. Will do that in several
hours, when most of the users go to sleep :)
which has 2 onboard bge(4)s which are working quite nice.
the 5704C bge(4) on my H8SSL are all disabled because of Ierrs
in netstat -ni, maybe you are luckier :-)
Nopes, I'm not:
# netstat -in
Name Mtu Network Address Ipkts Ierrs Opkts Oerrs Colls
{snip}
bge0 1500 <Link> 00:30:48:57:c3:80 44867924 39723 42574046 1 0
bge0 1500 213.137.48. 213.137.48.1 44867924 39723 42574046 1 0
bge0 1500 fe80::%bge0 fe80::230:48ff:fe 44867924 39723 42574046 1 0
bge1 1500 <Link> 00:30:48:57:c3:81 45170081 33204 42551236 1 0
bge1 1500 fe80::%bge1 fe80::230:48ff:fe 45170081 33204 42551236 1 0
Despite seeing Ierrs, I do not see any performance and connectivity
issues. What exactly does lead to having input errors on the bge(4)s?
I mean, would they be usable for what I will need the two more ports
for. This machine is gonna soon have a twin to be backed up with CARP,
and i need the two additional interfaces on each of them for:
1) One interface for cross-connecting the machines to do pfsync
2) One interface to connect to a private networks and run bacula backups
through (i want to use this couple of routers to do some backups at 4-5
a.m. when they are not busy at all)
Using em(4)s for the real traffic, would the bge(4)s be suitable for
pfsync and bacula backups with these errors they are experiencing? Or I
should go get a quad port Intel (i wish i don't have to spend that much
money, though)
everything from it quite nice, fetch remote sites, etc. Suddenly the SSH
connection was dropped with a message I've never seen before - Corrupted MAC
header.
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.
Affirmative. Exactly what I'm experiencing.
dmesg errors during the problems with em(4)s devices:
=======================================
em1: watchdog timeout -- resetting
em1: watchdog timeout -- resetting
pckbcintr: no dev for slot 1
pckbcintr: no dev for slot 1
dmesg bge(4) timeouts which happen from time to time:
=====================================
bge0: watchdog timeout -- resetting
bge1: watchdog timeout -- resetting
mickey posted some diffs on tech@ relating to watchdog
problems with bge and em, they might be worth a look.
Are these what you're talking about, or there were any subsequent
patches I could not find:
http://article.gmane.org/gmane.os.openbsd.tech/14133
http://article.gmane.org/gmane.os.openbsd.tech/14134
If so, I will apply them and recompile.
Again, thank you very much for the help. I highly appreciate it. $30
will be donated to the OpenBSD foundation, plus another copy of the 4.2
CD set bought (we'll need one for the new machine, no? :D).
Regards,
Doichin
