> On May 30, 2023, at 8:02 PM, Adrian Chadd <adr...@freebsd.org> wrote: > > Err, if it's coming up w/ that MAC then it's not finding and attaching right > to the OTP/EEPROM calibration information. That's the big red flag that it in > general won't work correctly. > > Can you provide the rest of the ath_hal messages? I'd like to see what it's > saying during boot around it checking the EEPROM/OTP contents. It's possible > there's some work around required for this NIC.
He speaks! Thanks for taking the time. I just realized that ath_hal_printf doesn’t prepend “ath%d” so I’ve been missing those messages when grep-ing. Here’s the whole snippet: ath0: <Atheros AR946x/AR948x> mem 0xf7a00000-0xf7a7ffff at device 0.0 on pci4 ar9300_flash_map: unimplemented for now Restoring Cal data from DRAM Restoring Cal data from EEPROM Restoring Cal data from Flash Restoring Cal data from Flash Restoring Cal data from OTP ar9300_eeprom_restore_internal[4338] No vaid CAL, calling default template ar9300_hw_attach: ar9300_eeprom_attach returned 0 ath0: [HT] enabling HT modes ath0: [HT] enabling short-GI in 20MHz mode ath0: [HT] 1 stream STBC receive enabled ath0: [HT] 1 stream STBC transmit enabled ath0: [HT] LDPC transmit/receive enabled ath0: [HT] 3 RX streams; 3 TX streams ath0: AR9460 mac 640.2 RF5110 phy 0.0 ath0: 2GHz radio: 0x0000; 5GHz radio: 0x0000 And the comments in ar9300_eeprom_restore_something() are less faith-inspiring the farther down you read.. I was about to add some printfs there to see when it finally returns, I’ll post what I learn. I’m happy to do any other code modifications or testing you’d suggest as well. -JN
