The driver does not load with this error
[ 16.900844] ath: phy0: Couldn't reset chip
[ 16.905035] ath: phy0: Unable to initialize hardware; initialization status: -5
[ 16.944899] ath9k 18100000.wmac: failed to initialize device
[ 16.950695] ath9k 18100000.wmac: probe with driver ath9k failed with error -5
Until the version 24.10.6 everything works perfectly.
Thanks for the work
Larsen
You're running 25.12.2?
Yes
but I also tried other versions: 25.12.0-rc1 25.12.0-1-2
Can confirm, in 25.12.4, the primary 2.4 GHz radio is not detected. (Only the primary 5 GHz radio and the low power scanning radio are detected and work.) 24.10.6 works well.
Yes, I've got the same here. OpenWRT 25.12.4 with kernel 6.12.87 is broken on MR18.
The primary 2.4GHz radio is not detected; the problem does not seem to be intermittent and it is always this radio (phy0).
Previously it worked fine on the exact same hardware with 24.10.4 on kernel 6.6.110.
Does anyone have a workaround or fix yet?
I tried apk install kmod-ath9k-htc just because of the similar name, with the same results.
dmesg on the broken kernel looks like:
[ 16.653392] ath: phy0: Couldn't reset chip
[ 16.657574] ath: phy0: Unable to initialize hardware; initialization status: -5
[ 16.891653] ath9k 18100000.wmac: failed to initialize device
[ 16.897454] ath9k 18100000.wmac: probe with driver ath9k failed with error -5
[ 16.905121] ath9k 0000:00:00.0: enabling device (0000 -> 0002)
[ 16.956864] ath: EEPROM regdomain: 0x0
[ 16.956891] ath: EEPROM indicates default country code should be used
[ 16.956898] ath: doing EEPROM country->regdmn map search
[ 16.956913] ath: country maps to regdmn code: 0x3a
[ 16.956921] ath: Country alpha2 being used: US
[ 16.956929] ath: Regpair used: 0x3a
[ 16.966418] ieee80211 phy1: Selected rate control algorithm 'minstrel_ht'
[ 16.967356] ieee80211 phy1: Atheros AR9300 Rev:4 mem=0x2985e2fd, irq=14
[ 16.974379] ath9k 0000:01:00.0: enabling device (0000 -> 0002)
[ 17.047140] ath: EEPROM regdomain: 0x0
[ 17.047166] ath: EEPROM indicates default country code should be used
[ 17.047173] ath: doing EEPROM country->regdmn map search
[ 17.047188] ath: country maps to regdmn code: 0x3a
[ 17.047196] ath: Country alpha2 being used: US
[ 17.047204] ath: Regpair used: 0x3a
[ 17.056125] ieee80211 phy2: Selected rate control algorithm 'minstrel_ht'
[ 17.057063] ieee80211 phy2: Atheros AR9300 Rev:4 mem=0x86b8a1ea, irq=15
A working dmesg (from another MR18 device I have yet to upgrade) is:
[ 15.940699] ath: EEPROM regdomain: 0x0
[ 15.940724] ath: EEPROM indicates default country code should be used
[ 15.940730] ath: doing EEPROM country->regdmn map search
[ 15.940744] ath: country maps to regdmn code: 0x3a
[ 15.940752] ath: Country alpha2 being used: US
[ 15.940760] ath: Regpair used: 0x3a
[ 15.956626] ieee80211 phy0: Selected rate control algorithm 'minstrel_ht'
[ 15.957516] ieee80211 phy0: Atheros AR9550 Rev:0 mem=0x7fe12bc5, irq=13
[ 15.964627] ath9k 0000:00:00.0: enabling device (0000 -> 0002)
[ 16.007868] ath: EEPROM regdomain: 0x0
[ 16.007893] ath: EEPROM indicates default country code should be used
[ 16.007899] ath: doing EEPROM country->regdmn map search
[ 16.007914] ath: country maps to regdmn code: 0x3a
[ 16.007921] ath: Country alpha2 being used: US
[ 16.007929] ath: Regpair used: 0x3a
[ 16.017448] ieee80211 phy1: Selected rate control algorithm 'minstrel_ht'
[ 16.018392] ieee80211 phy1: Atheros AR9300 Rev:4 mem=0x0a7c6ff3, irq=14
[ 16.025390] ath9k 0000:01:00.0: enabling device (0000 -> 0002)
[ 16.118988] ath: EEPROM regdomain: 0x0
[ 16.119013] ath: EEPROM indicates default country code should be used
[ 16.119019] ath: doing EEPROM country->regdmn map search
[ 16.119034] ath: country maps to regdmn code: 0x3a
[ 16.119042] ath: Country alpha2 being used: US
[ 16.119049] ath: Regpair used: 0x3a
[ 16.127965] ieee80211 phy2: Selected rate control algorithm 'minstrel_ht'
[ 16.128962] ieee80211 phy2: Atheros AR9300 Rev:4 mem=0x9ff5a070, irq=15
With the ath9k-htc package installed, this additional message is present, but I don't know if that is indicating any different code is being used:
[ 16.497659] usbcore: registered new interface driver ath9k_htc
I realised the code is a kernel module so I can un-load it and force re-initialisation. This also does not work, so I think that rules out some kind of 'cold' start or race happening on boot:
rmmod ath9k
rmmod ath9k_common
rmmod atk9k_hw
modprobe atk9k
dmesg same as before, with the device now known named 'phy3':
[ 507.483502] ath9k: ath9k: Driver unloaded
[ 538.216076] ath: phy3: Couldn't reset chip
[ 538.220260] ath: phy3: Unable to initialize hardware; initialization status: -5
[ 538.228238] ath9k 18100000.wmac: failed to initialize device
[ 538.234092] ath9k 18100000.wmac: probe with driver ath9k failed with error -5
On both the working and broken systems, lspci lists two PCI network adaptors (ie. even the working system only has two):
# lspci
00:00.0 Network controller: Qualcomm Atheros AR958x 802.11abgn Wireless Network Adapter (rev 01)
01:00.0 Network controller: Qualcomm Atheros AR958x 802.11abgn Wireless Network Adapter (rev 01)
That drew my attention to the device name. The faulty device has a distinct identifier on both systems: 18100000.wmac rather than a PCI bus (0000:00:00.0 or 0000:01:00.0)
I'm guessing here, but the failing device seems to be unique in being connected on a different bus.
Wrong driver, harmless, but useless - this exclusively covers ar9271/ ar7010 USB WLAN cards, aka not yours.
I suppose kmod-ath9k-usb would have been too easy 
It would have been, because there are two distinct USB drivers for ar9xxx hardware. carl9170 for ar9170 and ath9k_htc for ar9271 and ar7010.
This is fixed in https://github.com/openwrt/openwrt/pull/24042
I can confirm it works fine in today's snapshot. Waiting for next service release. I hope wiki gets updated.