We have a problem with Linux e1000e driver on an on-board e1000e controller, (listed as 82579LM). We have pinpointed the problem to a very simple test case.
A task sends an UDP packet every 5ms. Most of the time, this happens in a few microseconds, but from time to time, this can take a few multiples of 50 microseconds.
Instrumenting the driver, we found that the lost time happens in the function e1000e_update_tail_wa, where the function waits for the register at offset 0x05B54 to contain the bit 0x01000000. We understand from the code that using this register is a workaround for the 82579 chip. Looking at various datasheets, we were not able to find a documentation of what this register does and a description of exactly what this workaround is needed? Since this workaround is consuming time, is there any way we could replace it with say, a software spinlock?
Thank you for the post. What is the brand and model of your system? Can you provide me also which Linux driver version you used from https://downloadcenter.intel.com/product/47549/Intel-82579-Gigabit-Ethernet-Controller Intel® Download Center?
Thank you for your reply.
We are using the driver included in the Linux kernel version 3.14.17 but I have also check the code of the Intel e1000e-188.8.131.52 driver version and I have seen the same mechanism in function "__ew32_prepare" called by "e1000e_update_tdt_wa". This arbitration for accessing to the CSR registers seems to be specific to the 82579 chip for which the flag FLAG2_PCIM2PCI_ARBITER_WA is activated.
Good day. I checked with our business unit and we got a response that there is no reported issue on either another customers' systems or Intel customer
reference board with 82579LM. Therefore, we are highly recommending you to report this issue to the board manufacturer if you think it is critical issue. The board manufacturer can debug this issue in first line to check whether this is software issue such as BIOS/ ME firmware/ GbE image which the end-user cannot do.
Hope this clarifies.