-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
thus JohnS spake:
On Fri, 2010-08-20 at 09:36 +0200, Timo Schoeler wrote:
I tried with Intel's most recent driver, it shows the same behaviour:
[root@bla ~]# ip link set dev eth0 mtu 1576 SIOCSIFMTU: Invalid argument [root@bla ~]# ip link set dev eth1 mtu 1576 [root@bla ~]# ip link show dev eth1 6: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1576 qdisc pfifo_fast qlen 1000 link/ether 00:30:48:xx:xx:xy brd ff:ff:ff:ff:ff:ff
Try with "ethtool"
Doesn't work either.
While the first device (seen as eth0) does *not* allow to set a different MTU (tried with 1576 and 1546, both values I could use; I am forced to use values >1500 here due to protocol stuff), the second works without a problem.
Some e1000 cards do not even have support for jumbo frames. Just maybe if yours is that case you may not be able to raise the mtu value no higher than 1500.
I saw this:
82573(V/L/E) TX Unit Hang Messages ---------------------------------- Several adapters with the 82573 chipset display "TX unit hang" messages during normal operation with the e1000e driver. The issue appears both with TSO enabled and disabled, and is caused by a power management function that is enabled in the EEPROM. Early releases of the chipsets to vendors had the EEPROM bit that enabled the feature. After the issue was discovered newer adapters were released with the feature disabled in the EEPROM.
If you encounter the problem in an adapter, and the chipset is an 82573-based one, you can verify that your adapter needs the fix by using ethtool:
# ethtool -e eth0 Offset Values ------ ------ 0x0000 00 12 34 56 fe dc 30 0d 46 f7 f4 00 ff ff ff ff 0x0010 ff ff ff ff 6b 02 8c 10 d9 15 8c 10 86 80 de 83 ^^ The value at offset 0x001e (de) has bit 0 unset. This enables the problematic power saving feature. In this case, the EEPROM needs to read "df" at offset 0x001e.
A one-time EEPROM fix is available as a shell script. This script will verify that the adapter is applicable to the fix and if the fix is needed or not. If the fix is required, it applies the change to the EEPROM and updates the checksum. The user must reboot the system after applying the fix if changes were made to the EEPROM.
(from http://downloadmirror.intel.com/15817/eng/README.txt)
However, the card is okay, I didn't need to fix it.
I also had a look at the driver's source code, what still puzzles me after reading this is that the other card on board *works*:
(...)
case e1000_82573: case e1000_82574: case e1000_82583: /* Disable ASPM L0s due to hardware errata */ e1000e_disable_aspm(adapter->pdev, PCIE_LINK_STATE_L0S);
if (pdev->device == E1000_DEV_ID_82573L) { adapter->flags |= FLAG_HAS_JUMBO_FRAMES; adapter->max_hw_frame_size = DEFAULT_JUMBO; } break; default: break; }
return 0; }
(...)
static struct e1000_info e1000_82573_info = { .mac = e1000_82573, .flags = FLAG_HAS_HW_VLAN_FILTER | FLAG_HAS_WOL | FLAG_APME_IN_CTRL3 | FLAG_RX_CSUM_ENABLED | FLAG_HAS_SMART_POWER_DOWN | FLAG_HAS_AMT | FLAG_HAS_SWSM_ON_LOAD, .pba = 20, .max_hw_frame_size = ETH_FRAME_LEN + ETH_FCS_LEN, .init_ops = e1000_init_function_pointers_82571, .get_variants = e1000_get_variants_82571, };
(...)
/* 82573 Errata 17 */ if (((adapter->hw.mac.type == e1000_82573) || (adapter->hw.mac.type == e1000_82574)) && (max_frame > ETH_FRAME_LEN + ETH_FCS_LEN)) { adapter->flags2 |= FLAG2_DISABLE_ASPM_L1; e1000e_disable_aspm(adapter->pdev, PCIE_LINK_STATE_L1); }
(...)
John
Timo