Re: [Intel-wired-lan] [REGRESSION] e1000e heavy packet loss on Meteor Lake - 6.14.2

["Lifshits, Vitaly" <vitaly.lifshits@intel.com>]

On 6/18/2025 4:41 PM, Christian Heusel wrote:
> On 25/06/18 03:28PM, Marek Marczykowski-Górecki wrote:
>> On Fri, May 09, 2025 at 02:17:32AM +0200, Marek Marczykowski-Górecki wrote:
>>> On Fri, May 09, 2025 at 01:28:36AM +0200, Marek Marczykowski-Górecki wrote:
>>>> On Fri, May 09, 2025 at 01:13:28AM +0200, Paul Menzel wrote:
>>>>> Dear Marek, dear Vitaly,
>>>>>
>>>>>
>>>>> Am 09.05.25 um 00:41 schrieb Marek Marczykowski-Górecki:
>>>>>> On Thu, May 08, 2025 at 09:26:18AM +0300, Lifshits, Vitaly
>>>>>>> On 4/21/2025 4:28 PM, Marek Marczykowski-Górecki wrote:
>>>>>>>> On Mon, Apr 21, 2025 at 03:19:12PM +0200, Marek Marczykowski-Górecki wrote:
>>>>>>>>> On Mon, Apr 21, 2025 at 03:44:02PM +0300, Lifshits, Vitaly wrote:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On 4/16/2025 3:43 PM, Marek Marczykowski-Górecki wrote:
>>>>>>>>>>> On Wed, Apr 16, 2025 at 03:09:39PM +0300, Lifshits, Vitaly wrote:
>>>>>>>>>>>> Can you please also share the output of ethtool -i? I would like to know the
>>>>>>>>>>>> NVM version that you have on your device.
>>>>>>>>>>>
>>>>>>>>>>> driver: e1000e
>>>>>>>>>>> version: 6.14.1+
>>>>>>>>>>> firmware-version: 1.1-4
>>>>>>>>>>> expansion-rom-version:
>>>>>>>>>>> bus-info: 0000:00:1f.6
>>>>>>>>>>> supports-statistics: yes
>>>>>>>>>>> supports-test: yes
>>>>>>>>>>> supports-eeprom-access: yes
>>>>>>>>>>> supports-register-dump: yes
>>>>>>>>>>> supports-priv-flags: yes
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Your firmware version is not the latest, can you check with the board
>>>>>>>>>> manufacturer if there is a BIOS update to your system?
>>>>>>>>>
>>>>>>>>> I can check, but still, it's a regression in the Linux driver - old
>>>>>>>>> kernel did work perfectly well on this hw. Maybe new driver tries to use
>>>>>>>>> some feature that is missing (or broken) in the old firmware?
>>>>>>>>
>>>>>>>> A little bit of context: I'm maintaining the kernel package for a Qubes
>>>>>>>> OS distribution. While I can try to update firmware on my test system, I
>>>>>>>> have no influence on what hardware users will use this kernel, and
>>>>>>>> which firmware version they will use (and whether all the vendors
>>>>>>>> provide newer firmware at all). I cannot ship a kernel that is known
>>>>>>>> to break network on some devices.
>>>>>>>>
>>>>>>>>>> Also, you mentioned that on another system this issue doesn't reproduce, do
>>>>>>>>>> they have the same firmware version?
>>>>>>>>>
>>>>>>>>> The other one has also 1.1-4 firmware. And I re-checked, e1000e from
>>>>>>>>> 6.14.2 works fine there.
>>>>>
>>>>>>> Thank you for your detailed feedback and for providing the requested
>>>>>>> information.
>>>>>>>
>>>>>>> We have conducted extensive testing of this patch across multiple systems
>>>>>>> and have not observed any packet loss issues. Upon comparing the mentioned
>>>>>>> setups, we noted that while the LAN controller is similar, the CPU differs.
>>>>>>> We believe that the issue may be related to transitions in the CPU's low
>>>>>>> power states.
>>>>>>>
>>>>>>> Consequently, we kindly request that you disable the CPU low power state
>>>>>>> transitions in the S0 system state and verify if the issue persists. You can
>>>>>>> disable this in the kernel parameters on the command line with idle=poll.
>>>>>>> Please note that this command is intended for debugging purposes only, as it
>>>>>>> may result in higher power consumption.
>>>>>>
>>>>>> I tried with idle=poll, and it didn't help, I still see a lot of packet
>>>>>> losses. But I can also confirm that idle=poll makes the system use
>>>>>> significantly more power (previously at 25-30W, with this option stays
>>>>>> at about 42W).
>>>>>>
>>>>>> Is there any other info I can provide, enable some debug features or
>>>>>> something?
>>>>>>
>>>>>> I see the problem is with receiving packets - in my simple ping test,
>>>>>> the ping target sees all the echo requests (and respond to them), but
>>>>>> the responses aren't reaching ping back (and are not visible on tcpdump
>>>>>> on the problematic system either).
>>>>>
>>>>> As the cause is still unclear, can the commit please be reverted in the
>>>>> master branch due adhere to Linux’ no-regression policy, so that it can be
>>>>> reverted from the stable series?
>>>>>
>>>>> Marek, did you also test 6.15 release candidates?
>>>>
>>>> The last test I did was on 6.15-rc3. I can re-test on -rc5.
>>>
>>> Same with 6.15-rc5.
>>
>> And the same issue still applies to 6.16-rc2. FWIW Qubes OS kernel has
>> this buggy patch revered and nobody complained (contrary to the version
>> with the patch included). Should I submit the revert patch?

It is not a good idea to revert this patch as most of the systems will 
encounter the original issues (PHY access and packet loss). The reason I 
first introduced this patch was because big vendors reported the packet 
loss issue. You can refer to the following sightings:
https://answers.launchpad.net/ubuntu/+question/816003
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2066064
https://bugzilla.kernel.org/show_bug.cgi?id=218869

As an intermediate solution we can either use a privileged flag to make 
it configurable. I will share with you a patch that might fix the issue
on your system that I would like you to try.

FYI, we are currently investigating a similar issue that seems to be due 
to a misconfiguration of the system firmware.

> 
> Just submit a revert then 👍 I have no authority here, but had good
> experience with just sending a revert patch in the past 🤗
> 
> Cheers,
> Chris