Fixed bug in intel 10M/100M/1G NIC driver.

[olivernie]

Bit CTRL_ASDE is reserved and must be set to 0b according to intel 82576EB datasheet.

[robinsmidsrod]

Does this fix an actual problem, or is it just for datasheet compliance? From what I can remember, we try to avoid flags on new drivers unless absolutely required (usually for strange hardware issues/bugs).

[olivernie]

Yes. In my board, intel 82576EB is connected to BCM8359(copper on board). The builtin PXE in NIC can DHCP and load the IPXE binary from server. But IPXE can't even the ifstat shows link is up. This patch fix this bug. IPXE could DHCP again and chainload the other image.

[robinsmidsrod]

It would be beneficial if you provide the results from the tests located at ipxe.org/dev/driver both with and without the provided patch, so that it is clear what this patch fixes.

[ipxe-devel]

On 27/04/16 16:17, Oliver Nie wrote:

Yes. In my board, intel 82576EB is connected to BCM8359(copper on
board). The builtin PXE in NIC can DHCP and load the IPXE binary from
server. But IPXE can't even the ifstat shows link is up. This patch fix
this bug. IPXE could DHCP again and chainload the other image.

Thanks for confirming that.

If we're applying this change to one NIC, then we should probably apply
it to all NICs with the same requirement stated in the datasheet.

Michael

[olivernie]

Ok. I will take a look at ipxe.org/dev/driver to see how to run those tests. Update the result later.

[olivernie]

OK. Here are results of ipxe.org/dev/driver

• Link detection --- Pass
• Basic DHCP --- Pass
• Close and reopen --- Pass
• Large file transfer correctness --- Pass
• Large file transfer speed --- 4.6s on 512MB
• Link interruption --- Transfer finished with no error
• Loopback --- Not Applicable since I have only one port on intel 82576
• High-MTU loopback --- Not Applicable
• VLAN loopback --- Not Applicable

[robinsmidsrod]

@olivernie Thanks for the test feedback. The loopback tests are most of the time tested with two NICs in the same system, with one being the one under test and the other one a known working NIC. This ensures that there is no packet drop in the receive and transmit data paths and that VLAN features work as intended. If it's a laptop and it's impossible to attach another NIC then it's quite hard to test that, but doable if you have one of the supported USB3 NICs.

[olivernie]

@robinsmidsrod I got another board which has two NICs. Net0 is using intel 82567lm, net1 is using intel 82576eb. My patch is on 82576eb. Following are the results on loopback tests. Enabled debugging level 3 for intel and netdevice. The failed case shows 1 packet transmitted but nothing received, even packet with error. Since I am not sure 82567lm is a known working NIC or not, regarding to intel driver in IPXE, I can't tell the problem is on which side. I have no supported USB3 NICs in my hand to do further test.

• Loopback --- lotest net0 net1 --- Pass; lotest net1 net0 --- Pass
• High-MTU loopback --- lotest -m 1504 net0 net1 --- Fail; loest -m 1504 net1 net0 --- Pass
• VLAN loopback --- lotest net0-123 net1-123 --- Pass; loest net1-123 net0-123 --- Pass

[NiKiZe]

Is this still an issue in current master?

[mcb30]

This was cleaned up into commit 2d79b20f2