Re: [REGRESSION] mt7925e: fails to read EEPROM MAC on 7.2-rc2, falls back to random MAC (worked on 7.1-rc7 and 7.0.x)

B X <[email protected]>
8:12 AM (1 hour ago)
to linux-wireless, nbd, lorenzo, ryder.lee, shayne.chen, sean.wang,
regressions, Brent

Hi,

Reporting a regression in the mt7925e driver: on Linux 7.2.0-rc2 the adapter
fails to read its stored (EEPROM/efuse) MAC address and substitutes a random
one. The same hardware read its real MAC correctly on every earlier kernel,
including the immediately-preceding boot one day earlier on 7.0.0-22.

Verified with Claude Code when my ATT fiber kept failing to pin IP on
my Halo Strix

Hardware
--------
MediaTek MT7925 (RZ717) Wi-Fi 7 160MHz
PCI ID: [14c3:0717], driver mt7925e
Platform: AMD "Strix Halo" (Ryzen AI Max) mini-PC
linux-firmware: 20260319.git217ca6e4

Symptom (kernel 7.2.0-rc2, 2026-07-06)
--------------------------------------
  mt7925e 0000:c3:00.0: enabling device (0000 -> 0002)
  mt7925e 0000:c3:00.0: ASIC revision: 79250000
  mt7925e 0000:c3:00.0: HW/SW Version: 0x8a108a10, Build Time: 20260106153007a
  mt7925e 0000:c3:00.0: WM Firmware Version: ____000000, Build Time:
20260106153120
  mt7925e 0000:c3:00.0: Invalid MAC address, using random address
12:1f:34:c6:57:04
  mt7925e 0000:c3:00.0 wlp195s0: renamed from wlan0

The driver then brings the interface up with the random MAC 12:1f:34:c6:57:04.

Last known good (kernel 7.0.0-22, 2026-07-05, same machine, no MAC override)
----------------------------------------------------------------------------
  mt7925e 0000:c3:00.0: ASIC revision: 79250000
  mt7925e 0000:c3:00.0: HW/SW Version: 0x8a108a10, Build Time: 20260106153007a
  mt7925e 0000:c3:00.0: WM Firmware Version: ____000000, Build Time:
20260106153120
  ...
  wlp195s0: authenticate with <ap> (local address=ac:f2:3c:35:31:15)

i.e. the real MAC ac:f2:3c:35:31:15 was read straight off the adapter. Note
the firmware init lines (ASIC revision, HW/SW Version, WM Firmware Version,
build times) are byte-identical between the good and bad boots -- only the
kernel differs, and only the MAC read fails. This rules out a firmware or
bad-NVRAM cause: the same silicon read the MAC correctly ~24h earlier.

Regression range
----------------
Confirmed good on: 7.0.0, 7.0.0-22, 7.0.0-27, 7.1.0-rc7 (dozens of boots,
journal-verified, no "Invalid MAC address" line on any of them).
First and only bad boot: 7.2.0-rc2.

So the regression landed between 7.1-rc7 and 7.2-rc2. I have not bisected to
the exact commit yet, but I can -- the machine builds kernels quickly -- if a
bisect would help pin it down.

Not reboot-type dependent: on the good kernels (7.0.0-22 / 7.0.0-27) the
correct MAC was read reliably across both warm/clean reboots and cold/hard
power cycles. The failure does not correlate with reboot type or chip power
state -- it correlates only with the kernel version (7.2-rc2).

Impact
------
The substituted MAC is random per boot, changing the adapter's L2 identity.
This breaks router-side DHCP reservations / fixed-IP allocations keyed on MAC:
the host stops receiving its pinned address and lands on an arbitrary lease.
Any MT7925 user relying on MAC-based address pinning is affected. Current
workaround here is forcing the real MAC via NetworkManager cloned-mac-address.

#regzbot introduced: v7.1..v7.2-rc2



Thanks,


Brent Paine, AWS, CCNP

git bkpaine1
Medium bkpaine1


On Mon, Jul 6, 2026 at 8:12 AM B X <[email protected]> wrote:
>
> Hi,
>
> Reporting a regression in the mt7925e driver: on Linux 7.2.0-rc2 the adapter
> fails to read its stored (EEPROM/efuse) MAC address and substitutes a random
> one. The same hardware read its real MAC correctly on every earlier kernel,
> including the immediately-preceding boot one day earlier on 7.0.0-22.
>
> Verified with Claude Code when my ATT fiber kept failing to pin IP on my Halo Strix
>
> Hardware
> --------
> MediaTek MT7925 (RZ717) Wi-Fi 7 160MHz
> PCI ID: [14c3:0717], driver mt7925e
> Platform: AMD "Strix Halo" (Ryzen AI Max) mini-PC
> linux-firmware: 20260319.git217ca6e4
>
> Symptom (kernel 7.2.0-rc2, 2026-07-06)
> --------------------------------------
>   mt7925e 0000:c3:00.0: enabling device (0000 -> 0002)
>   mt7925e 0000:c3:00.0: ASIC revision: 79250000
>   mt7925e 0000:c3:00.0: HW/SW Version: 0x8a108a10, Build Time: 20260106153007a
>   mt7925e 0000:c3:00.0: WM Firmware Version: ____000000, Build Time: 20260106153120
>   mt7925e 0000:c3:00.0: Invalid MAC address, using random address 12:1f:34:c6:57:04
>   mt7925e 0000:c3:00.0 wlp195s0: renamed from wlan0
>
> The driver then brings the interface up with the random MAC 12:1f:34:c6:57:04.
>
> Last known good (kernel 7.0.0-22, 2026-07-05, same machine, no MAC override)
> ----------------------------------------------------------------------------
>   mt7925e 0000:c3:00.0: ASIC revision: 79250000
>   mt7925e 0000:c3:00.0: HW/SW Version: 0x8a108a10, Build Time: 20260106153007a
>   mt7925e 0000:c3:00.0: WM Firmware Version: ____000000, Build Time: 20260106153120
>   ...
>   wlp195s0: authenticate with <ap> (local address=ac:f2:3c:35:31:15)
>
> i.e. the real MAC ac:f2:3c:35:31:15 was read straight off the adapter. Note
> the firmware init lines (ASIC revision, HW/SW Version, WM Firmware Version,
> build times) are byte-identical between the good and bad boots -- only the
> kernel differs, and only the MAC read fails. This rules out a firmware or
> bad-NVRAM cause: the same silicon read the MAC correctly ~24h earlier.
>
> Regression range
> ----------------
> Confirmed good on: 7.0.0, 7.0.0-22, 7.0.0-27, 7.1.0-rc7 (dozens of boots,
> journal-verified, no "Invalid MAC address" line on any of them).
> First and only bad boot: 7.2.0-rc2.
>
> So the regression landed between 7.1-rc7 and 7.2-rc2. I have not bisected to
> the exact commit yet, but I can -- the machine builds kernels quickly -- if a
> bisect would help pin it down.
>
> Not reboot-type dependent: on the good kernels (7.0.0-22 / 7.0.0-27) the
> correct MAC was read reliably across both warm/clean reboots and cold/hard
> power cycles. The failure does not correlate with reboot type or chip power
> state -- it correlates only with the kernel version (7.2-rc2).
>
> Impact
> ------
> The substituted MAC is random per boot, changing the adapter's L2 identity.
> This breaks router-side DHCP reservations / fixed-IP allocations keyed on MAC:
> the host stops receiving its pinned address and lands on an arbitrary lease.
> Any MT7925 user relying on MAC-based address pinning is affected. Current
> workaround here is forcing the real MAC via NetworkManager cloned-mac-address.
>
> #regzbot introduced: v7.1..v7.2-rc2
>
>
>
> Thanks,
>
>
> Brent Paine, AWS, CCNP
>
> git bkpaine1
> Medium bkpaine1