Date: Tue, 30 May 2023 21:56:04 -0700 From: Adrian Chadd <adrian@freebsd.org> To: John Nielsen <lists@jnielsen.net> Cc: "Bjoern A. Zeeb" <bzeeb-lists@lists.zabbadoz.net>, "wireless@freebsd.org" <wireless@freebsd.org> Subject: Re: Help me grok the ath(4) device attach code Message-ID: <CAJ-VmokL_Kdrgtv3YT6U=yKhr4d-wkba3Vx3AssfY3-iMuBT5Q@mail.gmail.com> In-Reply-To: <85BF3AB2-2EBF-4398-A507-ABA35505A56C@jnielsen.net> References: <49AEA1CB-FA85-432F-89D7-8C49B5F3A344@jnielsen.net> <q921p430-oq56-qo4n-rq49-0o7008pr40n3@yvfgf.mnoonqbm.arg> <E6DF8709-2767-48D3-AED1-D0608F5AABCF@jnielsen.net> <CAJ-VmokUORGzQz6bOhutucy1xTv_1ZwP0vOZN=6vW1wusCLJpg@mail.gmail.com> <85BF3AB2-2EBF-4398-A507-ABA35505A56C@jnielsen.net>
next in thread | previous in thread | raw e-mail | index | archive | help
--000000000000d4282205fcf623c2 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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_print= f > doesn=E2=80=99t prepend =E2=80=9Cath%d=E2=80=9D so I=E2=80=99ve been miss= ing those messages when grep-ing. > Here=E2=80=99s 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 templat= e > 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 --000000000000d4282205fcf623c2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div dir=3D"ltr"><br></div><br><div class=3D"gmail_quote">= <div dir=3D"ltr" class=3D"gmail_attr">On Tue, 30 May 2023 at 20:56, John Ni= elsen <<a href=3D"mailto:lists@jnielsen.net">lists@jnielsen.net</a>> = wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0= px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">> On M= ay 30, 2023, at 8:02 PM, Adrian Chadd <<a href=3D"mailto:adrian@freebsd.= org" target=3D"_blank">adrian@freebsd.org</a>> wrote:<br> > <br> > Err, if it's coming up w/ that MAC then it's not finding and a= ttaching right to the OTP/EEPROM calibration information. That's the bi= g red flag that it in general won't work correctly.<br> > <br> > 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.<br> <br> He speaks! Thanks for taking the time. I just realized that ath_hal_printf = doesn=E2=80=99t prepend =E2=80=9Cath%d=E2=80=9D so I=E2=80=99ve been missin= g those messages when grep-ing. Here=E2=80=99s the whole snippet:<br> <br> ath0: <Atheros AR946x/AR948x> mem 0xf7a00000-0xf7a7ffff at device 0.0= on pci4<br> ar9300_flash_map: unimplemented for now<br> Restoring Cal data from DRAM<br> Restoring Cal data from EEPROM<br> Restoring Cal data from Flash<br> Restoring Cal data from Flash<br> Restoring Cal data from OTP<br> ar9300_eeprom_restore_internal[4338] No vaid CAL, calling default template<= br> ar9300_hw_attach: ar9300_eeprom_attach returned 0<br></blockquote><div><br>= </div><div>Yeah, this bit right here is the problem. It's not finding a= valid calibration.</div><div><br></div><div>=C2=A0I wonder what ath9k is d= oing here? Is there some weird pci based workaround/flag for the given NIC = PCI id?</div><div><br></div><div><br></div><div>-a</div><div><br></div></di= v></div> --000000000000d4282205fcf623c2--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAJ-VmokL_Kdrgtv3YT6U=yKhr4d-wkba3Vx3AssfY3-iMuBT5Q>