I have four systems running drbd (several combinations of two-node DRBD devices) which all get "Digest integrity check FAILED" errors. One of the possible causes is TSO, so obivously I want to test running without it.
ethtool -K eth1 rx off tx off sg off tso off gso off
I ran the above command and saw the following in my logs before the system rebooted:
Jan 4 14:39:10 hetz3 kernel: [3167347.964860] e1000e 0000:02:00.0: eth1: Reset adapter Jan 4 14:39:10 hetz3 kernel: [3167347.978907] xenbr1: port 1(eth1) entering disabled state Jan 4 14:39:14 hetz3 kernel: [3167351.681827] e1000e: eth1 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: Rx/Tx Jan 4 14:39:14 hetz3 kernel: [3167351.682167] xenbr1: port 1(eth1) entering learning state
Is it expected that you can change TSO settings while the system is running?
Yes, definitely. I do it all the time (xen+bridge+offload can be troublesome, especially when I'm the one writing the drivers!). Do you see a panic flash up on the screen before reboot? You can adjust /proc/sys/kernel/panic to give a delay before rebooting. What card is it? What kernel version? Is the card a member of a bridge? Just yesterday I discovered the joys of netconsole and its ability to capture kernel panic output, and if eth1 is actually your second network adapter you might be able to use eth0 to capture the panic output to submit a bug. If nothing else works, you might have more luck taking the interface down, changing the parameters, then setting it up again. Slightly less convenient but maybe it won't cause a reset if the adapter isn't online. Checksum offload failures can be really nasty - and for the situation you describe to arise the card must be calculating a correct checksum but corrupting the data, which is extra nasty. James