Re: Possible fix for i217 problem
No issues on systems running
em0 at pci3 dev 0 function 0 Intel I210 rev 0x03: msi, address 0c:..
em1 at pci4 dev 0 function 0 Intel I210 rev 0x03: msi, address 0c:..
Also working on
em0 at pci1 dev 0 function 0 Intel 82576 rev 0x01: msi, address 90:..
em1 at pci1 dev 0 function 1 Intel 82576 rev 0x01: msi, address 90:..
But i still have a small problem with
em0 at pci0 dev 25 function 0 Intel I218-V rev 0x00: msi, address f0:..
If booting up with the LAN cable connected, everything is fine and media
type is set to
media: Ethernet autoselect (1000baseT full-duplex)
When the cable is not attached during boot, i end up with
media: Ethernet autoselect (10baseT full-duplex)
and have to de-/attach to get 1000baseT again.
A PCIe x1 'Intel 82574L' adapter doesn't show these problems.
On Tue, Aug 04, 2015 at 10:40:25PM +0200, Stefan Fritsch wrote:
Hi,
someone mentioned to me the i217-LM problems that were reported on misc
end of May. It is possible that the patch below helps.
For us, it fixed a problem on a laptop with i217-LM (pci id 8086:153a)
where the receiving of packets would stop until the battery of the laptop
was removed (or until linux or freebsd were booted, which also have this
workaround). A normal reboot or power-cycle without removing the battery
did not help. Interestingly, not even the Intel PXE BIOS has the
workaround.
The problem would happen if the LAN cable was plugged in after the card
had already been initialized. If the LAN cable was always plugged in when
the laptop was powered on, the problem would not appear.
The workaround is part of the e1000_lv_jumbo_workaround_ich8lan() function
in e1000_ich8lan.c in freebsd, but only the part that is used if jumbo
packets are *not* configured. Linux has the same fix as
b20a774495671f037e7160ea2ce87 and da1e2046e5f5ab268e55d30d6b74099ade0aeb6f
with some more info in the commit messages.
This probably has quite some potential to cause regressions with other
boards, so i am not sure if it should go in before 5.8 release.
Cheers,
Stefan
--- a/sys/dev/pci/if_em_hw.c
+++ b/sys/dev/pci/if_em_hw.c
@@ -91,6 +91,7 @@ static int32_t em_id_led_init(struct em_hw *);
static int32_t em_init_lcd_from_nvm_config_region(struct em_hw *,
uint32_t,
uint32_t);
static int32_t em_init_lcd_from_nvm(struct em_hw *);
+static int32_t em_phy_no_cable_workaround(struct em_hw *);
static void em_init_rx_addrs(struct em_hw *);
static void em_initialize_hardware_bits(struct em_hw *);
static boolean_t em_is_onboard_nvm_eeprom(struct em_hw *);
@@ -7018,6 +7019,96 @@ em_read_mac_addr(struct em_hw *hw)
}
/**
+ * Explicitly disables jumbo frames and resets some PHY registers back to hw-
+ * defaults. This is necessary in case the ethernet cable was inserted AFTER
+ * the firmware initialized the PHY. Otherwise it is left in a state where
+ * it is possible to transmit but not receive packets. Observed on I217-LM
and
+ * fixed in FreeBSD's sys/dev/e1000/e1000_ich8lan.c.
+ *
+ * hw - Struct containing variables accessed by shared code
+
*/
+STATIC int32_t
+em_phy_no_cable_workaround(struct em_hw *hw) {
+ int32_t ret_val, dft_ret_val;
+ uint32_t mac_reg;
+ uint16_t data, phy_reg;
+
+ /* disable Rx path while enabling workaround */
+ em_read_phy_reg(hw, I2_DFT_CTRL, phy_reg);
+ ret_val = em_write_phy_reg(hw, I2_DFT_CTRL, phy_reg | (1 14));
+ if (ret_val)
+ return ret_val;
+
+ /* Write MAC register values back to h/w defaults */
+ mac_reg = E1000_READ_REG(hw, FFLT_DBG);
+ mac_reg = ~(0xF 14);
+ E1000_WRITE_REG(hw, FFLT_DBG, mac_reg);
+
+ mac_reg = E1000_READ_REG(hw, RCTL);
+ mac_reg = ~E1000_RCTL_SECRC;
+ E1000_WRITE_REG(hw, RCTL, mac_reg);
+
+ ret_val = em_read_kmrn_reg(hw, E1000_KUMCTRLSTA_OFFSET_CTRL, data);
+ if (ret_val)
+ goto out;
+ ret_val = em_write_kmrn_reg(hw, E1000_KUMCTRLSTA_OFFSET_CTRL,
+ data ~(1 0));
+ if (ret_val)
+ goto out;
+
+ ret_val = em_read_kmrn_reg(hw, E1000_KUMCTRLSTA_OFFSET_HD_CTRL, data);
+ if (ret_val)
+ goto out;
+
+ data = ~(0xF 8);
+ data |= (0xB 8);
+ ret_val = em_write_kmrn_reg(hw, E1000_KUMCTRLSTA_OFFSET_HD_CTRL, data);
+ if (ret_val)
+ goto out;
+
+ /* Write PHY register values back to h/w defaults */
+ em_read_phy_reg(hw, I2_SMBUS_CTRL, data);
+ data = ~(0x7F 5);
+ ret_val = em_write_phy_reg(hw, I2_SMBUS_CTRL, data);
+ if (ret_val)
+ goto out;
+
+ em_read_phy_reg(hw, I2_MODE_CTRL, data);
+ data |= (1 13);
+ ret_val = em_write_phy_reg(hw, I2_MODE_CTRL, data);
+ if (ret_val)
+
Re: Possible fix for i217 problem
On 2015 Aug 05 (Wed) at 10:08:05 +0200 (+0200), Mark Patruck wrote:
:No issues on systems running
:
:em0 at pci3 dev 0 function 0 Intel I210 rev 0x03: msi, address 0c:..
:em1 at pci4 dev 0 function 0 Intel I210 rev 0x03: msi, address 0c:..
:
:Also working on
:
:em0 at pci1 dev 0 function 0 Intel 82576 rev 0x01: msi, address 90:..
:em1 at pci1 dev 0 function 1 Intel 82576 rev 0x01: msi, address 90:..
:
:
:But i still have a small problem with
:
:em0 at pci0 dev 25 function 0 Intel I218-V rev 0x00: msi, address f0:..
:
:If booting up with the LAN cable connected, everything is fine and media
:type is set to
:
:media: Ethernet autoselect (1000baseT full-duplex)
:
:When the cable is not attached during boot, i end up with
:
:media: Ethernet autoselect (10baseT full-duplex)
:
:and have to de-/attach to get 1000baseT again.
:
FWIW, I have no such problems with
em0 at pci0 dev 25 function 0 Intel I218-LM rev 0x03: msi, address
68:f7:28:84:1d:37
Net works fine and comes up media: Ethernet autoselect (1000baseT full-duplex)
as expected
:A PCIe x1 'Intel 82574L' adapter doesn't show these problems.
:
:
:On Tue, Aug 04, 2015 at 10:40:25PM +0200, Stefan Fritsch wrote:
: Hi,
:
: someone mentioned to me the i217-LM problems that were reported on misc
: end of May. It is possible that the patch below helps.
:
: For us, it fixed a problem on a laptop with i217-LM (pci id 8086:153a)
: where the receiving of packets would stop until the battery of the laptop
: was removed (or until linux or freebsd were booted, which also have this
: workaround). A normal reboot or power-cycle without removing the battery
: did not help. Interestingly, not even the Intel PXE BIOS has the
: workaround.
:
: The problem would happen if the LAN cable was plugged in after the card
: had already been initialized. If the LAN cable was always plugged in when
: the laptop was powered on, the problem would not appear.
:
: The workaround is part of the e1000_lv_jumbo_workaround_ich8lan() function
: in e1000_ich8lan.c in freebsd, but only the part that is used if jumbo
: packets are *not* configured. Linux has the same fix as
: b20a774495671f037e7160ea2ce87 and da1e2046e5f5ab268e55d30d6b74099ade0aeb6f
: with some more info in the commit messages.
:
: This probably has quite some potential to cause regressions with other
: boards, so i am not sure if it should go in before 5.8 release.
:
: Cheers,
: Stefan
:
:
: --- a/sys/dev/pci/if_em_hw.c
: +++ b/sys/dev/pci/if_em_hw.c
: @@ -91,6 +91,7 @@ static int32_t em_id_led_init(struct em_hw *);
: static int32_t em_init_lcd_from_nvm_config_region(struct em_hw *,
uint32_t,
: uint32_t);
: static int32_t em_init_lcd_from_nvm(struct em_hw *);
: +static int32_t em_phy_no_cable_workaround(struct em_hw *);
: static void em_init_rx_addrs(struct em_hw *);
: static void em_initialize_hardware_bits(struct em_hw *);
: static boolean_t em_is_onboard_nvm_eeprom(struct em_hw *);
: @@ -7018,6 +7019,96 @@ em_read_mac_addr(struct em_hw *hw)
: }
:
:
/**
: + * Explicitly disables jumbo frames and resets some PHY registers back to
hw-
: + * defaults. This is necessary in case the ethernet cable was inserted AFTER
: + * the firmware initialized the PHY. Otherwise it is left in a state where
: + * it is possible to transmit but not receive packets. Observed on I217-LM
and
: + * fixed in FreeBSD's sys/dev/e1000/e1000_ich8lan.c.
: + *
: + * hw - Struct containing variables accessed by shared code
: +
*/
: +STATIC int32_t
: +em_phy_no_cable_workaround(struct em_hw *hw) {
: +int32_t ret_val, dft_ret_val;
: +uint32_t mac_reg;
: +uint16_t data, phy_reg;
: +
: +/* disable Rx path while enabling workaround */
: +em_read_phy_reg(hw, I2_DFT_CTRL, phy_reg);
: +ret_val = em_write_phy_reg(hw, I2_DFT_CTRL, phy_reg | (1 14));
: +if (ret_val)
: +return ret_val;
: +
: +/* Write MAC register values back to h/w defaults */
: +mac_reg = E1000_READ_REG(hw, FFLT_DBG);
: +mac_reg = ~(0xF 14);
: +E1000_WRITE_REG(hw, FFLT_DBG, mac_reg);
: +
: +mac_reg = E1000_READ_REG(hw, RCTL);
: +mac_reg = ~E1000_RCTL_SECRC;
: +E1000_WRITE_REG(hw, RCTL, mac_reg);
: +
: +ret_val = em_read_kmrn_reg(hw, E1000_KUMCTRLSTA_OFFSET_CTRL, data);
: +if (ret_val)
: +goto out;
: +ret_val = em_write_kmrn_reg(hw, E1000_KUMCTRLSTA_OFFSET_CTRL,
: +data ~(1 0));
: +if (ret_val)
: +goto out;
: +
: +ret_val = em_read_kmrn_reg(hw, E1000_KUMCTRLSTA_OFFSET_HD_CTRL, data);
: +if (ret_val)
: +goto out;
: +
: +data = ~(0xF 8);
: +data |= (0xB 8);
: +ret_val = em_write_kmrn_reg(hw, E1000_KUMCTRLSTA_OFFSET_HD_CTRL, data);
: +if (ret_val)
: +goto out;
: +
: +/* Write PHY register values back to
Re: Possible fix for i217 problem
Hmm..weird. Is the I218-LM the only nic in your system? Because if
i add an additional PCIe Intel 85247L, my onboard I218-V comes up
with 1000baseT as well.
em0 at pci1 dev 0 function 0 Intel 82574L rev 0x00: msi, address 00:..
em1 at pci0 dev 25 function 0 Intel I218-V rev 0x00: msi, address f0:..
On Wed, Aug 05, 2015 at 12:24:42PM +0200, Peter Hessler wrote:
On 2015 Aug 05 (Wed) at 10:08:05 +0200 (+0200), Mark Patruck wrote:
:No issues on systems running
:
:em0 at pci3 dev 0 function 0 Intel I210 rev 0x03: msi, address 0c:..
:em1 at pci4 dev 0 function 0 Intel I210 rev 0x03: msi, address 0c:..
:
:Also working on
:
:em0 at pci1 dev 0 function 0 Intel 82576 rev 0x01: msi, address 90:..
:em1 at pci1 dev 0 function 1 Intel 82576 rev 0x01: msi, address 90:..
:
:
:But i still have a small problem with
:
:em0 at pci0 dev 25 function 0 Intel I218-V rev 0x00: msi, address f0:..
:
:If booting up with the LAN cable connected, everything is fine and media
:type is set to
:
:media: Ethernet autoselect (1000baseT full-duplex)
:
:When the cable is not attached during boot, i end up with
:
:media: Ethernet autoselect (10baseT full-duplex)
:
:and have to de-/attach to get 1000baseT again.
:
FWIW, I have no such problems with
em0 at pci0 dev 25 function 0 Intel I218-LM rev 0x03: msi, address
68:f7:28:84:1d:37
Net works fine and comes up media: Ethernet autoselect (1000baseT
full-duplex)
as expected
:A PCIe x1 'Intel 82574L' adapter doesn't show these problems.
:
:
:On Tue, Aug 04, 2015 at 10:40:25PM +0200, Stefan Fritsch wrote:
: Hi,
:
: someone mentioned to me the i217-LM problems that were reported on misc
: end of May. It is possible that the patch below helps.
:
: For us, it fixed a problem on a laptop with i217-LM (pci id 8086:153a)
: where the receiving of packets would stop until the battery of the laptop
: was removed (or until linux or freebsd were booted, which also have this
: workaround). A normal reboot or power-cycle without removing the battery
: did not help. Interestingly, not even the Intel PXE BIOS has the
: workaround.
:
: The problem would happen if the LAN cable was plugged in after the card
: had already been initialized. If the LAN cable was always plugged in when
: the laptop was powered on, the problem would not appear.
:
: The workaround is part of the e1000_lv_jumbo_workaround_ich8lan() function
: in e1000_ich8lan.c in freebsd, but only the part that is used if jumbo
: packets are *not* configured. Linux has the same fix as
: b20a774495671f037e7160ea2ce87 and da1e2046e5f5ab268e55d30d6b74099ade0aeb6f
: with some more info in the commit messages.
:
: This probably has quite some potential to cause regressions with other
: boards, so i am not sure if it should go in before 5.8 release.
:
: Cheers,
: Stefan
:
:
: --- a/sys/dev/pci/if_em_hw.c
: +++ b/sys/dev/pci/if_em_hw.c
: @@ -91,6 +91,7 @@ static int32_t em_id_led_init(struct em_hw *);
: static int32_tem_init_lcd_from_nvm_config_region(struct em_hw *,
uint32_t,
:uint32_t);
: static int32_tem_init_lcd_from_nvm(struct em_hw *);
: +static int32_tem_phy_no_cable_workaround(struct em_hw *);
: static void em_init_rx_addrs(struct em_hw *);
: static void em_initialize_hardware_bits(struct em_hw *);
: static boolean_t em_is_onboard_nvm_eeprom(struct em_hw *);
: @@ -7018,6 +7019,96 @@ em_read_mac_addr(struct em_hw *hw)
: }
:
:
/**
: + * Explicitly disables jumbo frames and resets some PHY registers back to
hw-
: + * defaults. This is necessary in case the ethernet cable was inserted
AFTER
: + * the firmware initialized the PHY. Otherwise it is left in a state where
: + * it is possible to transmit but not receive packets. Observed on
I217-LM and
: + * fixed in FreeBSD's sys/dev/e1000/e1000_ich8lan.c.
: + *
: + * hw - Struct containing variables accessed by shared code
: +
*/
: +STATIC int32_t
: +em_phy_no_cable_workaround(struct em_hw *hw) {
: + int32_t ret_val, dft_ret_val;
: + uint32_t mac_reg;
: + uint16_t data, phy_reg;
: +
: + /* disable Rx path while enabling workaround */
: + em_read_phy_reg(hw, I2_DFT_CTRL, phy_reg);
: + ret_val = em_write_phy_reg(hw, I2_DFT_CTRL, phy_reg | (1 14));
: + if (ret_val)
: + return ret_val;
: +
: + /* Write MAC register values back to h/w defaults */
: + mac_reg = E1000_READ_REG(hw, FFLT_DBG);
: + mac_reg = ~(0xF 14);
: + E1000_WRITE_REG(hw, FFLT_DBG, mac_reg);
: +
: + mac_reg = E1000_READ_REG(hw, RCTL);
: + mac_reg = ~E1000_RCTL_SECRC;
: + E1000_WRITE_REG(hw, RCTL, mac_reg);
: +
: + ret_val = em_read_kmrn_reg(hw, E1000_KUMCTRLSTA_OFFSET_CTRL, data);
: + if (ret_val)
: + goto out;
: + ret_val =
Re: Possible fix for i217 problem
The em0 is the only ethernet nic on the laptop, this is on a Thinkpad
x250 laptop.
On 2015 Aug 05 (Wed) at 13:23:13 +0200 (+0200), Mark Patruck wrote:
:Hmm..weird. Is the I218-LM the only nic in your system? Because if
:i add an additional PCIe Intel 85247L, my onboard I218-V comes up
:with 1000baseT as well.
:
:em0 at pci1 dev 0 function 0 Intel 82574L rev 0x00: msi, address 00:..
:em1 at pci0 dev 25 function 0 Intel I218-V rev 0x00: msi, address f0:..
:
:
:On Wed, Aug 05, 2015 at 12:24:42PM +0200, Peter Hessler wrote:
: On 2015 Aug 05 (Wed) at 10:08:05 +0200 (+0200), Mark Patruck wrote:
: :No issues on systems running
: :
: :em0 at pci3 dev 0 function 0 Intel I210 rev 0x03: msi, address 0c:..
: :em1 at pci4 dev 0 function 0 Intel I210 rev 0x03: msi, address 0c:..
: :
: :Also working on
: :
: :em0 at pci1 dev 0 function 0 Intel 82576 rev 0x01: msi, address 90:..
: :em1 at pci1 dev 0 function 1 Intel 82576 rev 0x01: msi, address 90:..
: :
: :
: :But i still have a small problem with
: :
: :em0 at pci0 dev 25 function 0 Intel I218-V rev 0x00: msi, address f0:..
: :
: :If booting up with the LAN cable connected, everything is fine and media
: :type is set to
: :
: :media: Ethernet autoselect (1000baseT full-duplex)
: :
: :When the cable is not attached during boot, i end up with
: :
: :media: Ethernet autoselect (10baseT full-duplex)
: :
: :and have to de-/attach to get 1000baseT again.
: :
:
: FWIW, I have no such problems with
:
: em0 at pci0 dev 25 function 0 Intel I218-LM rev 0x03: msi, address
68:f7:28:84:1d:37
:
: Net works fine and comes up media: Ethernet autoselect (1000baseT
full-duplex)
: as expected
:
:
:
: :A PCIe x1 'Intel 82574L' adapter doesn't show these problems.
: :
: :
: :On Tue, Aug 04, 2015 at 10:40:25PM +0200, Stefan Fritsch wrote:
: : Hi,
: :
: : someone mentioned to me the i217-LM problems that were reported on misc
: : end of May. It is possible that the patch below helps.
: :
: : For us, it fixed a problem on a laptop with i217-LM (pci id 8086:153a)
: : where the receiving of packets would stop until the battery of the laptop
: : was removed (or until linux or freebsd were booted, which also have this
: : workaround). A normal reboot or power-cycle without removing the battery
: : did not help. Interestingly, not even the Intel PXE BIOS has the
: : workaround.
: :
: : The problem would happen if the LAN cable was plugged in after the card
: : had already been initialized. If the LAN cable was always plugged in when
: : the laptop was powered on, the problem would not appear.
: :
: : The workaround is part of the e1000_lv_jumbo_workaround_ich8lan()
function
: : in e1000_ich8lan.c in freebsd, but only the part that is used if jumbo
: : packets are *not* configured. Linux has the same fix as
: : b20a774495671f037e7160ea2ce87 and
da1e2046e5f5ab268e55d30d6b74099ade0aeb6f
: : with some more info in the commit messages.
: :
: : This probably has quite some potential to cause regressions with other
: : boards, so i am not sure if it should go in before 5.8 release.
: :
: : Cheers,
: : Stefan
: :
: :
: : --- a/sys/dev/pci/if_em_hw.c
: : +++ b/sys/dev/pci/if_em_hw.c
: : @@ -91,6 +91,7 @@ static int32_t em_id_led_init(struct em_hw *);
: : static int32_t em_init_lcd_from_nvm_config_region(struct em_hw *,
uint32_t,
: : uint32_t);
: : static int32_t em_init_lcd_from_nvm(struct em_hw *);
: : +static int32_t em_phy_no_cable_workaround(struct em_hw *);
: : static void em_init_rx_addrs(struct em_hw *);
: : static void em_initialize_hardware_bits(struct em_hw *);
: : static boolean_t em_is_onboard_nvm_eeprom(struct em_hw *);
: : @@ -7018,6 +7019,96 @@ em_read_mac_addr(struct em_hw *hw)
: : }
: :
: :
/**
: : + * Explicitly disables jumbo frames and resets some PHY registers back
to hw-
: : + * defaults. This is necessary in case the ethernet cable was inserted
AFTER
: : + * the firmware initialized the PHY. Otherwise it is left in a state
where
: : + * it is possible to transmit but not receive packets. Observed on
I217-LM and
: : + * fixed in FreeBSD's sys/dev/e1000/e1000_ich8lan.c.
: : + *
: : + * hw - Struct containing variables accessed by shared code
: : +
*/
: : +STATIC int32_t
: : +em_phy_no_cable_workaround(struct em_hw *hw) {
: : + int32_t ret_val, dft_ret_val;
: : + uint32_t mac_reg;
: : + uint16_t data, phy_reg;
: : +
: : + /* disable Rx path while enabling workaround */
: : + em_read_phy_reg(hw, I2_DFT_CTRL, phy_reg);
: : + ret_val = em_write_phy_reg(hw, I2_DFT_CTRL, phy_reg | (1 14));
: : + if (ret_val)
: : + return ret_val;
: : +
: : + /* Write MAC register values back to h/w defaults */
: : + mac_reg = E1000_READ_REG(hw, FFLT_DBG);
: : + mac_reg = ~(0xF 14);
: : + E1000_WRITE_REG(hw, FFLT_DBG, mac_reg);
: : +
: : + mac_reg =
Re: Possible fix for i217 problem
On 2015/08/05 10:08, Mark Patruck wrote: But i still have a small problem with em0 at pci0 dev 25 function 0 Intel I218-V rev 0x00: msi, address f0:.. Thanks for testing. Still - just to check I understand correctly, this diff doesn't help with your nic, but doesn't make things worse?
Re: Possible fix for i217 problem
Correct. On Wed, Aug 05, 2015 at 01:08:19PM +0100, Stuart Henderson wrote: On 2015/08/05 10:08, Mark Patruck wrote: But i still have a small problem with em0 at pci0 dev 25 function 0 Intel I218-V rev 0x00: msi, address f0:.. Thanks for testing. Still - just to check I understand correctly, this diff doesn't help with your nic, but doesn't make things worse? -- Mark Patruck ( mark at wrapped.cx ) GPG key 0xF2865E51 / 187F F6D3 EE04 1DCE 1C74 F644 0D3C F66F F286 5E51 http://www.wrapped.cx
Re: Possible fix for i217 problem
Thanks to everyone for the testing. The patch is now committed.
Re: Possible fix for i217 problem
On Wed, Aug 05, 2015 at 02:04:28AM +0200, Hrvoje Popovski wrote: On 4.8.2015. 23:47, Stuart Henderson wrote: On 2015/08/04 22:40, Stefan Fritsch wrote: someone mentioned to me the i217-LM problems that were reported on misc end of May. It is possible that the patch below helps. This fixes my Dell poweredge T20: em0 at pci0 dev 25 function 0 Intel I217-LM rev 0x04: msi, address f8:b1:56:... And doesn't break my X220: em0 at pci0 dev 25 function 0 Intel 82579LM rev 0x04: msi, address f0:de:f1:... I have the same revionsl 82579LM on this new-to-me X220, and I just ran some tcpbench(1) tests through a vlan(4) with the patch. Seems to be fine though I was only testing end-to-end with an Alix using vr(4), so only 100BaseT. the diff is unlikely to affect performance, specifically. it will affect cable plugins, removals, other link layer decisions, etc.
Re: Possible fix for i217 problem
On 2015/08/04 22:40, Stefan Fritsch wrote:
someone mentioned to me the i217-LM problems that were reported on misc
end of May. It is possible that the patch below helps.
This fixes my Dell poweredge T20:
em0 at pci0 dev 25 function 0 Intel I217-LM rev 0x04: msi, address
f8:b1:56:...
And doesn't break my X220:
em0 at pci0 dev 25 function 0 Intel 82579LM rev 0x04: msi, address
f0:de:f1:...
Readers with I217 / I218 / 82579 devices, please test, especially if network
is currently WORKING for you. We know it fixes various issues but the important
thing is that this isn't at the expense of other systems.
For us, it fixed a problem on a laptop with i217-LM (pci id 8086:153a)
where the receiving of packets would stop until the battery of the laptop
was removed (or until linux or freebsd were booted, which also have this
workaround). A normal reboot or power-cycle without removing the battery
did not help. Interestingly, not even the Intel PXE BIOS has the
workaround.
The problem would happen if the LAN cable was plugged in after the card
had already been initialized. If the LAN cable was always plugged in when
the laptop was powered on, the problem would not appear.
The workaround is part of the e1000_lv_jumbo_workaround_ich8lan() function
in e1000_ich8lan.c in freebsd, but only the part that is used if jumbo
packets are *not* configured. Linux has the same fix as
b20a774495671f037e7160ea2ce87 and da1e2046e5f5ab268e55d30d6b74099ade0aeb6f
with some more info in the commit messages.
This probably has quite some potential to cause regressions with other
boards, so i am not sure if it should go in before 5.8 release.
Cheers,
Stefan
--- a/sys/dev/pci/if_em_hw.c
+++ b/sys/dev/pci/if_em_hw.c
@@ -91,6 +91,7 @@ static int32_t em_id_led_init(struct em_hw *);
static int32_t em_init_lcd_from_nvm_config_region(struct em_hw *,
uint32_t,
uint32_t);
static int32_t em_init_lcd_from_nvm(struct em_hw *);
+static int32_t em_phy_no_cable_workaround(struct em_hw *);
static void em_init_rx_addrs(struct em_hw *);
static void em_initialize_hardware_bits(struct em_hw *);
static boolean_t em_is_onboard_nvm_eeprom(struct em_hw *);
@@ -7018,6 +7019,96 @@ em_read_mac_addr(struct em_hw *hw)
}
/**
+ * Explicitly disables jumbo frames and resets some PHY registers back to hw-
+ * defaults. This is necessary in case the ethernet cable was inserted AFTER
+ * the firmware initialized the PHY. Otherwise it is left in a state where
+ * it is possible to transmit but not receive packets. Observed on I217-LM
and
+ * fixed in FreeBSD's sys/dev/e1000/e1000_ich8lan.c.
+ *
+ * hw - Struct containing variables accessed by shared code
+
*/
+STATIC int32_t
+em_phy_no_cable_workaround(struct em_hw *hw) {
+ int32_t ret_val, dft_ret_val;
+ uint32_t mac_reg;
+ uint16_t data, phy_reg;
+
+ /* disable Rx path while enabling workaround */
+ em_read_phy_reg(hw, I2_DFT_CTRL, phy_reg);
+ ret_val = em_write_phy_reg(hw, I2_DFT_CTRL, phy_reg | (1 14));
+ if (ret_val)
+ return ret_val;
+
+ /* Write MAC register values back to h/w defaults */
+ mac_reg = E1000_READ_REG(hw, FFLT_DBG);
+ mac_reg = ~(0xF 14);
+ E1000_WRITE_REG(hw, FFLT_DBG, mac_reg);
+
+ mac_reg = E1000_READ_REG(hw, RCTL);
+ mac_reg = ~E1000_RCTL_SECRC;
+ E1000_WRITE_REG(hw, RCTL, mac_reg);
+
+ ret_val = em_read_kmrn_reg(hw, E1000_KUMCTRLSTA_OFFSET_CTRL, data);
+ if (ret_val)
+ goto out;
+ ret_val = em_write_kmrn_reg(hw, E1000_KUMCTRLSTA_OFFSET_CTRL,
+ data ~(1 0));
+ if (ret_val)
+ goto out;
+
+ ret_val = em_read_kmrn_reg(hw, E1000_KUMCTRLSTA_OFFSET_HD_CTRL, data);
+ if (ret_val)
+ goto out;
+
+ data = ~(0xF 8);
+ data |= (0xB 8);
+ ret_val = em_write_kmrn_reg(hw, E1000_KUMCTRLSTA_OFFSET_HD_CTRL, data);
+ if (ret_val)
+ goto out;
+
+ /* Write PHY register values back to h/w defaults */
+ em_read_phy_reg(hw, I2_SMBUS_CTRL, data);
+ data = ~(0x7F 5);
+ ret_val = em_write_phy_reg(hw, I2_SMBUS_CTRL, data);
+ if (ret_val)
+ goto out;
+
+ em_read_phy_reg(hw, I2_MODE_CTRL, data);
+ data |= (1 13);
+ ret_val = em_write_phy_reg(hw, I2_MODE_CTRL, data);
+ if (ret_val)
+ goto out;
+
+ /*
+ * 776.20 and 776.23 are not documented in
+ * i217-ethernet-controller-datasheet.pdf...
+ */
+ em_read_phy_reg(hw, PHY_REG(776, 20), data);
+ data = ~(0x3FF 2);
+ data |= (0x8 2);
+ ret_val = em_write_phy_reg(hw, PHY_REG(776, 20), data);
+ if (ret_val)
+ goto out;
+
+ ret_val = em_write_phy_reg(hw,
Re: Possible fix for i217 problem
On 2015/08/04 22:40, Stefan Fritsch wrote: someone mentioned to me the i217-LM problems that were reported on misc end of May. It is possible that the patch below helps. This fixes my Dell poweredge T20: em0 at pci0 dev 25 function 0 Intel I217-LM rev 0x04: msi, address f8:b1:56:... And doesn't break my X220: em0 at pci0 dev 25 function 0 Intel 82579LM rev 0x04: msi, address f0:de:f1:... Readers with I217 / I218 / 82579 devices, please test, especially if network is currently WORKING for you. We know it fixes various issues but the important thing is that this isn't at the expense of other systems. This diff will be in the next snapshots, for rapid testing before release. The most important goal ensuring this does not cause a regression for other chips. Don't test the ones this hopes to fix. Test the ones it shouldn't affect!!!
Re: Possible fix for i217 problem
On 4.8.2015. 23:47, Stuart Henderson wrote: On 2015/08/04 22:40, Stefan Fritsch wrote: someone mentioned to me the i217-LM problems that were reported on misc end of May. It is possible that the patch below helps. This fixes my Dell poweredge T20: em0 at pci0 dev 25 function 0 Intel I217-LM rev 0x04: msi, address f8:b1:56:... And doesn't break my X220: em0 at pci0 dev 25 function 0 Intel 82579LM rev 0x04: msi, address f0:de:f1:... Readers with I217 / I218 / 82579 devices, please test, especially if network is currently WORKING for you. We know it fixes various issues but the important thing is that this isn't at the expense of other systems. don't know if this is relevant but intel i350 seems to work normal after this patches.
Possible fix for i217 problem
Hi,
someone mentioned to me the i217-LM problems that were reported on misc
end of May. It is possible that the patch below helps.
For us, it fixed a problem on a laptop with i217-LM (pci id 8086:153a)
where the receiving of packets would stop until the battery of the laptop
was removed (or until linux or freebsd were booted, which also have this
workaround). A normal reboot or power-cycle without removing the battery
did not help. Interestingly, not even the Intel PXE BIOS has the
workaround.
The problem would happen if the LAN cable was plugged in after the card
had already been initialized. If the LAN cable was always plugged in when
the laptop was powered on, the problem would not appear.
The workaround is part of the e1000_lv_jumbo_workaround_ich8lan() function
in e1000_ich8lan.c in freebsd, but only the part that is used if jumbo
packets are *not* configured. Linux has the same fix as
b20a774495671f037e7160ea2ce87 and da1e2046e5f5ab268e55d30d6b74099ade0aeb6f
with some more info in the commit messages.
This probably has quite some potential to cause regressions with other
boards, so i am not sure if it should go in before 5.8 release.
Cheers,
Stefan
--- a/sys/dev/pci/if_em_hw.c
+++ b/sys/dev/pci/if_em_hw.c
@@ -91,6 +91,7 @@ static int32_tem_id_led_init(struct em_hw *);
static int32_t em_init_lcd_from_nvm_config_region(struct em_hw *, uint32_t,
uint32_t);
static int32_t em_init_lcd_from_nvm(struct em_hw *);
+static int32_t em_phy_no_cable_workaround(struct em_hw *);
static voidem_init_rx_addrs(struct em_hw *);
static voidem_initialize_hardware_bits(struct em_hw *);
static boolean_t em_is_onboard_nvm_eeprom(struct em_hw *);
@@ -7018,6 +7019,96 @@ em_read_mac_addr(struct em_hw *hw)
}
/**
+ * Explicitly disables jumbo frames and resets some PHY registers back to hw-
+ * defaults. This is necessary in case the ethernet cable was inserted AFTER
+ * the firmware initialized the PHY. Otherwise it is left in a state where
+ * it is possible to transmit but not receive packets. Observed on I217-LM and
+ * fixed in FreeBSD's sys/dev/e1000/e1000_ich8lan.c.
+ *
+ * hw - Struct containing variables accessed by shared code
+ */
+STATIC int32_t
+em_phy_no_cable_workaround(struct em_hw *hw) {
+ int32_t ret_val, dft_ret_val;
+ uint32_t mac_reg;
+ uint16_t data, phy_reg;
+
+ /* disable Rx path while enabling workaround */
+ em_read_phy_reg(hw, I2_DFT_CTRL, phy_reg);
+ ret_val = em_write_phy_reg(hw, I2_DFT_CTRL, phy_reg | (1 14));
+ if (ret_val)
+ return ret_val;
+
+ /* Write MAC register values back to h/w defaults */
+ mac_reg = E1000_READ_REG(hw, FFLT_DBG);
+ mac_reg = ~(0xF 14);
+ E1000_WRITE_REG(hw, FFLT_DBG, mac_reg);
+
+ mac_reg = E1000_READ_REG(hw, RCTL);
+ mac_reg = ~E1000_RCTL_SECRC;
+ E1000_WRITE_REG(hw, RCTL, mac_reg);
+
+ ret_val = em_read_kmrn_reg(hw, E1000_KUMCTRLSTA_OFFSET_CTRL, data);
+ if (ret_val)
+ goto out;
+ ret_val = em_write_kmrn_reg(hw, E1000_KUMCTRLSTA_OFFSET_CTRL,
+ data ~(1 0));
+ if (ret_val)
+ goto out;
+
+ ret_val = em_read_kmrn_reg(hw, E1000_KUMCTRLSTA_OFFSET_HD_CTRL, data);
+ if (ret_val)
+ goto out;
+
+ data = ~(0xF 8);
+ data |= (0xB 8);
+ ret_val = em_write_kmrn_reg(hw, E1000_KUMCTRLSTA_OFFSET_HD_CTRL, data);
+ if (ret_val)
+ goto out;
+
+ /* Write PHY register values back to h/w defaults */
+ em_read_phy_reg(hw, I2_SMBUS_CTRL, data);
+ data = ~(0x7F 5);
+ ret_val = em_write_phy_reg(hw, I2_SMBUS_CTRL, data);
+ if (ret_val)
+ goto out;
+
+ em_read_phy_reg(hw, I2_MODE_CTRL, data);
+ data |= (1 13);
+ ret_val = em_write_phy_reg(hw, I2_MODE_CTRL, data);
+ if (ret_val)
+ goto out;
+
+ /*
+* 776.20 and 776.23 are not documented in
+* i217-ethernet-controller-datasheet.pdf...
+*/
+ em_read_phy_reg(hw, PHY_REG(776, 20), data);
+ data = ~(0x3FF 2);
+ data |= (0x8 2);
+ ret_val = em_write_phy_reg(hw, PHY_REG(776, 20), data);
+ if (ret_val)
+ goto out;
+
+ ret_val = em_write_phy_reg(hw, PHY_REG(776, 23), 0x7E00);
+ if (ret_val)
+ goto out;
+
+ em_read_phy_reg(hw, I2_PCIE_POWER_CTRL, data);
+ ret_val = em_write_phy_reg(hw, I2_PCIE_POWER_CTRL, data ~(1 10));
+ if (ret_val)
+ goto out;
+
+out:
+ /* re-enable Rx path after enabling workaround */
+ dft_ret_val = em_write_phy_reg(hw, I2_DFT_CTRL, phy_reg ~(1 14));
+ if (ret_val)
+ return ret_val;
+ else
+ return dft_ret_val;
+}
+
Re: Possible fix for i217 problem
On Tue, Aug 04, 2015 at 07:16:48PM -0600, Theo de Raadt wrote: On Wed, Aug 05, 2015 at 02:04:28AM +0200, Hrvoje Popovski wrote: On 4.8.2015. 23:47, Stuart Henderson wrote: On 2015/08/04 22:40, Stefan Fritsch wrote: someone mentioned to me the i217-LM problems that were reported on misc end of May. It is possible that the patch below helps. This fixes my Dell poweredge T20: em0 at pci0 dev 25 function 0 Intel I217-LM rev 0x04: msi, address f8:b1:56:... And doesn't break my X220: em0 at pci0 dev 25 function 0 Intel 82579LM rev 0x04: msi, address f0:de:f1:... I have the same revionsl 82579LM on this new-to-me X220, and I just ran some tcpbench(1) tests through a vlan(4) with the patch. Seems to be fine though I was only testing end-to-end with an Alix using vr(4), so only 100BaseT. the diff is unlikely to affect performance, specifically. it will affect cable plugins, removals, other link layer decisions, etc. OK, well, plug in/out ran through my ifstated(8) states properly, switching to the rtwn(4) for egress, and switched back. Suspend/resume seemed to behave as before, also.
Re: Possible fix for i217 problem
On Wed, Aug 05, 2015 at 02:04:28AM +0200, Hrvoje Popovski wrote: On 4.8.2015. 23:47, Stuart Henderson wrote: On 2015/08/04 22:40, Stefan Fritsch wrote: someone mentioned to me the i217-LM problems that were reported on misc end of May. It is possible that the patch below helps. This fixes my Dell poweredge T20: em0 at pci0 dev 25 function 0 Intel I217-LM rev 0x04: msi, address f8:b1:56:... And doesn't break my X220: em0 at pci0 dev 25 function 0 Intel 82579LM rev 0x04: msi, address f0:de:f1:... I have the same revionsl 82579LM on this new-to-me X220, and I just ran some tcpbench(1) tests through a vlan(4) with the patch. Seems to be fine though I was only testing end-to-end with an Alix using vr(4), so only 100BaseT.
