RE: [Intel-wired-lan] [PATCH 1/2] igc: Wait for MAC passthrough after reset

[Loktionov, Aleksandr]

> -----Original Message-----
> From: Chia-Lin Kao (AceLan) <acelan.kao@xxxxxxxxxxxxx>
> Sent: Monday, June 22, 2026 3:58 AM
> To: Ruinskiy, Dima <dima.ruinskiy@xxxxxxxxx>
> Cc: Loktionov, Aleksandr <aleksandr.loktionov@xxxxxxxxx>; Nguyen,
> Anthony L <anthony.l.nguyen@xxxxxxxxx>; Kitszel, Przemyslaw
> <przemyslaw.kitszel@xxxxxxxxx>; Andrew Lunn <andrew+netdev@xxxxxxx>;
> David S. Miller <davem@xxxxxxxxxxxxx>; Eric Dumazet
> <edumazet@xxxxxxxxxx>; Jakub Kicinski <kuba@xxxxxxxxxx>; Paolo Abeni
> <pabeni@xxxxxxxxxx>; intel-wired-lan@xxxxxxxxxxxxxxxx;
> netdev@xxxxxxxxxxxxxxx; linux-kernel@xxxxxxxxxxxxxxx
> Subject: Re: [Intel-wired-lan] [PATCH 1/2] igc: Wait for MAC
> passthrough after reset
> 
> On Thu, Jun 18, 2026 at 11:51:35AM +0300, Ruinskiy, Dima wrote:
> > On 18/06/2026 10:55, Loktionov, Aleksandr wrote:
> > >
> > >
> > > > -----Original Message-----
> > > > From: Intel-wired-lan <intel-wired-lan-bounces@xxxxxxxxxx> On
> > > > Behalf Of Chia-Lin Kao (AceLan) via Intel-wired-lan
> > > > Sent: Thursday, June 18, 2026 9:33 AM
> > > > To: Nguyen, Anthony L <anthony.l.nguyen@xxxxxxxxx>; Kitszel,
> > > > Przemyslaw <przemyslaw.kitszel@xxxxxxxxx>
> > > > Cc: Andrew Lunn <andrew+netdev@xxxxxxx>; David S. Miller
> > > > <davem@xxxxxxxxxxxxx>; Eric Dumazet <edumazet@xxxxxxxxxx>; Jakub
> > > > Kicinski <kuba@xxxxxxxxxx>; Paolo Abeni <pabeni@xxxxxxxxxx>;
> > > > intel- wired-lan@xxxxxxxxxxxxxxxx; netdev@xxxxxxxxxxxxxxx;
> linux-
> > > > kernel@xxxxxxxxxxxxxxx
> > > > Subject: [Intel-wired-lan] [PATCH 1/2] igc: Wait for MAC
> > > > passthrough after reset
> > > >
> > > > Some systems support MAC passthrough for dock Ethernet
> controllers
> > > > by having firmware rewrite the receive address registers after
> the
> > > > controller reset completes.
> > > >
> > > > igc resets the controller before reading RAL0/RAH0, so that
> reset
> > > > can restore the controller native MAC address temporarily. If
> the
> > > > driver reads the registers immediately, it can race the firmware
> > > > rewrite and keep the native dock MAC instead of the host
> passthrough MAC.
> > > >
> > > > For LMVP devices, poll RAL0/RAH0 after reset and before reading
> > > > the MAC address. Stop once the address registers change to
> another
> > > > valid Ethernet address, allowing firmware a bounded window to
> > > > complete the passthrough update.
> > > >
> Hi Aleksandr and Dima,
> 
> Let me answer your questions below.
> 
> > > Good day, Chia-Lin
> > >
> > > It'd be great if you could share more details on how to reproduce
> the issue.
> > >
> > > What exact hardware setup is affected (dock model, NIC, system)?
> We've observed this issue for a long time, and encountered the issue
> on Lenovo's P15 Gen 2 (type 20YQ, 20YR) Laptops (ThinkPad) the first
> time at 2021 and added 600ms delay.
> Recently, we encountered the same issue on Dell, too, and then
> increased the delay to 1000ms.
> And now, the issue occurs again.
> 
> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1942999
> https://lore.kernel.org/lkml/20210702045120.22855-2-
> aaron.ma@xxxxxxxxxxxxx/
> https://bugs.launchpad.net/ubuntu/+source/linux-oem-6.17/+bug/2143197
> 
> > > Which firmware/BIOS version?
> It doesn't happen on a single firmware or BIOS, and not a single
> hardware or a single brand.
> 
> > > How often does the race trigger?
> It may happen when re-plug the dock cable.
> With the mainline kernel, it's easy to reproduce the issue by re-
> plugging the dock cable.
> 
> > > Do you have a way to reliably reproduce it?
> Yes, I can find some machines to reproduce the issue reliably.
> 
> > >
> > > Also, what is the observed behavior vs. expected behavior? For
> > > example, which MAC address is seen and which one should be used?
> Here is the debugging logs, fc:4c:ea:ae:a1:e3 is the MAC address of
> the machine, and c4:d6:d3:83:75:d1 is the MAC of the dock.
> 
> It gets the correct passthrough MAC address after bootup and the first
> re-plug at 40s, and fails to update the MAC address in time after
> couple of re-plugs.
> 
> [    0.689873] igc 0000:70:00.0: MAC debug before reset_hw:
> RAL0=0xaeea4cfc RAH0=0x8000e3a1 RAR0=fc:4c:ea:ae:a1:e3 valid=1
> [    0.755187] igc 0000:70:00.0: MAC debug after reset_hw:
> RAL0=0x83d3d6c4 RAH0=0x8000d175 RAR0=c4:d6:d3:83:75:d1 valid=1
> [    0.755576] igc 0000:70:00.0: MAC debug:
> eth_platform_get_mac_address ret=-19, reading RAR0/NVM fallback
> [    0.755582] igc 0000:70:00.0: MAC debug: read_mac_addr ret=0
> addr=fc:4c:ea:ae:a1:e3 perm_addr=fc:4c:ea:ae:a1:e3
> [    4.687730] igc 0000:70:00.0: MAC debug firmware: fwnode=<none>
> props(mac=0 local=0 address=0) fwnode_ret=-19
> fwnode_mac=00:00:00:00:00:00 device_ret=-2
> device_mac=00:00:00:00:00:00 is_tbt=0 external=0 hotplug_bridge=0
> [    4.687739] igc 0000:70:00.0: MAC debug before reset_hw:
> RAL0=0xaeea4cfc RAH0=0x8000e3a1 RAR0=fc:4c:ea:ae:a1:e3 valid=1
> [    4.748545] igc 0000:70:00.0: MAC debug after reset_hw:
> RAL0=0x83d3d6c4 RAH0=0x8000d175 RAR0=c4:d6:d3:83:75:d1 valid=1
> [    4.748937] igc 0000:70:00.0: MAC debug:
> eth_platform_get_mac_address ret=-19, reading RAR0/NVM fallback
> [    4.748944] igc 0000:70:00.0: MAC debug: read_mac_addr ret=0
> addr=fc:4c:ea:ae:a1:e3 perm_addr=fc:4c:ea:ae:a1:e3
> [   40.892715] igc 0000:70:00.0: MAC debug firmware: fwnode=<none>
> props(mac=0 local=0 address=0) fwnode_ret=-19
> fwnode_mac=00:00:00:00:00:00 device_ret=-2
> device_mac=00:00:00:00:00:00 is_tbt=0 external=0 hotplug_bridge=0
> [   40.892724] igc 0000:70:00.0: MAC debug before reset_hw:
> RAL0=0x83d3d6c4 RAH0=0x8000d175 RAR0=c4:d6:d3:83:75:d1 valid=1
> [   40.953524] igc 0000:70:00.0: MAC debug after reset_hw:
> RAL0=0x83d3d6c4 RAH0=0x8000d175 RAR0=c4:d6:d3:83:75:d1 valid=1
> [   40.953933] igc 0000:70:00.0: MAC debug:
> eth_platform_get_mac_address ret=-19, reading RAR0/NVM fallback
> [   40.953941] igc 0000:70:00.0: MAC debug: read_mac_addr ret=0
> addr=c4:d6:d3:83:75:d1 perm_addr=c4:d6:d3:83:75:d1
> ...
> [  307.387282] igc 0000:70:00.0: MAC poll change at 700ms:
> RAL0=0xaeea4cfc RAH0=0x8000e3a1 RAR0=fc:4c:ea:ae:a1:e3 valid=1
> prev=c4:d6:d3:83:75:d1 [  328.826084] igc 0000:38:00.0: MAC poll
> change at 1000ms: RAL0=0xaeea4cfc RAH0=0x8000e3a1
> RAR0=fc:4c:ea:ae:a1:e3 valid=1 prev=c4:d6:d3:83:75:d1 [  429.070519]
> igc 0000:38:00.0: MAC poll change at 1100ms: RAL0=0xaeea4cfc
> RAH0=0x8000e3a1 RAR0=fc:4c:ea:ae:a1:e3 valid=1 prev=c4:d6:d3:83:75:d1
> [  466.509571] igc 0000:70:00.0: MAC poll change at 1000ms:
> RAL0=0xaeea4cfc RAH0=0x8000e3a1 RAR0=fc:4c:ea:ae:a1:e3 valid=1
> prev=c4:d6:d3:83:75:d1
> 

Please include the info into commit message, so users can grep error and find the fix.
Exact bash commands for reproduction can also help administrators to decide whether they need to patch their OS.

Thank you

...