em driver Update r235527 (May 2012) broke hw csum (at least)
ob at e-Gitt.NET
Fri Apr 12 11:05:14 UTC 2013
just for a short note: I have several servers running FreeBSD 9-STABLE.
However, the test of the latest STABLE revisions (machines received no
OS updates for over a year, no relevant security updates for my case)
brought up stability issues.
After giving traffic (over 2 VLANs) to the machine it stalled. I could
switch between screens, could not start any command, top/vmstat/...
stopped updating. ping was fine. After some time the machine was
sometimes back for a few seconds, if I stopped the service (dovecot2,
about 800-1500 sessions) I could keep it running sometimes. If I was not
able to stop the service in time, the machine kept in "stalled" state
em0 at pci0:3:0:0: class=0x020000 card=0x040d15d9 chip=0x10d38086 rev=0x00
vendor = 'Intel Corporation'
device = '82574L Gigabit Network Connection'
class = network
subclass = ethernet
FreeBSD [...] 9.1-STABLE FreeBSD 9.1-STABLE #18
r249361: Thu Apr 11 16:38:17 CEST 2013
Switching off most of the hardware offloading works around the problem:
up vlanmtu -tso -lro -rxcsum -txcsum -vlanhwtag -vlanhwcsum -vlantso
em0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu
inet6 fe80::225:90ff:fe32:e3a8%em0 prefixlen 64 scopeid 0x2
media: Ethernet autoselect (1000baseT <full-duplex>)
Though I wondoer, it still says: VLAN_HWCSUM VLAN_HWTSO in the Options?
Interestingly -txcsum -rxcsum was my first test, this alone didn't do
the trick (or the interface was already in a state where it wouldn't
OK, I know: using hw csum is a bad idea anyway, even thogh it seemed to
be working for my case up to that point. Does it make sense to dig any
deeper or ist it just the way it is and I stumbled over not using best
practice up to then? :-)
| Oliver Brandmueller http://sysadm.in/ ob at sysadm.in |
| Ich bin das Internet. Sowahr ich Gott helfe. |
More information about the freebsd-stable