Re: Help me grok the ath(4) device attach code
Date: Wed, 31 May 2023 04:56:04 UTC
On Tue, 30 May 2023 at 20:56, John Nielsen <lists@jnielsen.net> wrote: > > On May 30, 2023, at 8:02 PM, Adrian Chadd <adrian@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 > Yeah, this bit right here is the problem. It's not finding a valid calibration. I wonder what ath9k is doing here? Is there some weird pci based workaround/flag for the given NIC PCI id? -a