Re: Help me grok the ath(4) device attach code

[John Nielsen]

Coming back to this after a busy couple of months.. On Jun 11, 2023, at 9:48 PM, Adrian Chadd <adr...@freebsd.org> wrote: On Sun, 11 Jun 2023 at 18:17, John Nielsen <li...@jnielsen.net> wrote: > On May 30, 2023, at 11:17 PM, Adrian Chadd <adr...@freebsd.org> wrote: > > There's known issues with all the Atheros chips (sigh) with how the EEPROM and PCIe bus reset .. interact. > (If the bus reset is too short then the EEPROM state machine gets stuck and nothing gets read.) It makes debugging this hard because the NIC itself will work in another device fine, because it's the BIOS/ACPI code. :( Are these “known issues” documented anywhere public? Does “nothing gets read” manifest as getting zeroes back? That does appear to be what’s happening on my laptop: Yeah that's not a good sign.   Trying (2) EEPROM access at address 0x03ff ar9300_eeprom_restore_internal_address: Found block at 3ff: code=0 ref=0 length=0 major=0 minor=0 ar9300_eeprom_restore_internal_address: word[0]=0x00 word[1]=0x00 word[2]=0x00 word[3]=0x00 ar9300_eeprom_restore_internal_address: checksum 0 0 ar9300_eeprom_restore_internal_address: EEPROM structure size mismatch memory=1088 eeprom=0 Are there any workarounds (even gross ones like sleeping 2 seconds somewhere)? The gross workaround is to manually reset the pcie RC/EP and do it for the right amount of time. ;-) How/where would I do a proof of concept of this gross workaround? Sprinkle in pcie_link_reset() somewhere? Or is it more of a rewrite of the bus initialization code? Thanks, JN