linux-kernel - Re: [PATCH] e1000e: Link flap workaround option for false IRP events

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <9f460418-99c6-49f9-ac2c-7a957f781e17@app.fastmail.com>
Date: Fri, 28 Feb 2025 09:59:05 -0500
From: "Mark Pearson" <mpearson-lenovo@...ebb.ca>
To: "Andrew Lunn" <andrew@...n.ch>
Cc: anthony.l.nguyen@...el.com, przemyslaw.kitszel@...el.com,
 andrew+netdev@...n.ch, davem@...emloft.net, edumazet@...gle.com,
 kuba@...nel.org, pabeni@...hat.com, intel-wired-lan@...ts.osuosl.org,
 netdev@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] e1000e: Link flap workaround option for false IRP events

Hi Andrew

On Thu, Feb 27, 2025, at 11:07 AM, Andrew Lunn wrote:
>> >> +			e1e_rphy(hw, PHY_REG(772, 26), &phy_data);
>> >
>> > Please add some #define for these magic numbers, so we have some idea
>> > what PHY register you are actually reading. That in itself might help
>> > explain how the workaround actually works.
>> >
>> 
>> I don't know what this register does I'm afraid - that's Intel knowledge and has not been shared.
>
> What PHY is it? Often it is just a COTS PHY, and the datasheet might
> be available.
>
> Given your setup description, pause seems like the obvious thing to
> check. When trying to debug this, did you look at pause settings?
> Knowing what this register is might also point towards pause, or
> something totally different.
>
> 	Andrew

For the PHY - do you know a way of determining this easily? I can reach out to the platform team but that will take some time. I'm not seeing anything in the kernel logs, but if there's a recommended way of confirming that would be appreciated.

We did look at at the pause pieces - which I agree seems like an obvious candidate given the speed mismatch on the network.
Experts on the Intel networking team did reproduce the issue in their lab and looked at this for many weeks without determining root cause. I wish it was as obvious as pause control configuration :)

Thanks
Mark