From nobody Fri Jun 2 05:28:07 2023 X-Original-To: wireless@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4QXWkj497Bz4YWK8 for ; Fri, 2 Jun 2023 05:28:45 +0000 (UTC) (envelope-from lists@jnielsen.net) Received: from webmail5.jnielsen.net (webmail5.jnielsen.net [IPv6:2607:f170:34:11::b0]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "mail.freebsdsolutions.net", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4QXWkb60Jcz47PJ; Fri, 2 Jun 2023 05:28:39 +0000 (UTC) (envelope-from lists@jnielsen.net) Authentication-Results: mx1.freebsd.org; dkim=none; spf=pass (mx1.freebsd.org: domain of lists@jnielsen.net designates 2607:f170:34:11::b0 as permitted sender) smtp.mailfrom=lists@jnielsen.net; dmarc=none Received: from smtpclient.apple ([50.207.241.62]) (authenticated bits=0) by webmail5.jnielsen.net (8.17.1/8.17.1) with ESMTPSA id 3525SM3T073953 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 1 Jun 2023 23:28:30 -0600 (MDT) (envelope-from lists@jnielsen.net) X-Authentication-Warning: webmail5.jnielsen.net: Host [50.207.241.62] claimed to be smtpclient.apple From: John Nielsen Message-Id: <8CEDC118-5FCA-434D-B7F7-B0C4A7AC3ACC@jnielsen.net> Content-Type: multipart/alternative; boundary="Apple-Mail=_0601CF93-4FB8-43DE-9BAD-B9075B1001E7" List-Id: Discussions List-Archive: https://lists.freebsd.org/archives/freebsd-wireless List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-wireless@freebsd.org X-BeenThere: freebsd-wireless@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.600.7\)) Subject: Re: Help me grok the ath(4) device attach code Date: Thu, 1 Jun 2023 23:28:07 -0600 In-Reply-To: <5264D290-EB82-4D24-A812-85E3E6B5C88E@jnielsen.net> Cc: "Bjoern A. Zeeb" , "wireless@freebsd.org" To: Adrian Chadd References: <49AEA1CB-FA85-432F-89D7-8C49B5F3A344@jnielsen.net> <85BF3AB2-2EBF-4398-A507-ABA35505A56C@jnielsen.net> <5264D290-EB82-4D24-A812-85E3E6B5C88E@jnielsen.net> X-Mailer: Apple Mail (2.3731.600.7) X-Spamd-Result: default: False [-2.80 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+a:mailers.freebsdsolutions.net]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; DMARC_NA(0.00)[jnielsen.net]; MLMMJ_DEST(0.00)[wireless@freebsd.org]; R_DKIM_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; ASN(0.00)[asn:6364, ipnet:2607:f170:30::/44, country:US]; MIME_TRACE(0.00)[0:+,1:+,2:~]; BLOCKLISTDE_FAIL(0.00)[2607:f170:34:11::b0:server fail,50.207.241.62:query timed out]; TO_DN_EQ_ADDR_SOME(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; RCPT_COUNT_THREE(0.00)[3]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_SOME(0.00)[]; HAS_XAW(0.00)[]; FROM_HAS_DN(0.00)[]; ARC_NA(0.00)[]; RCVD_TLS_ALL(0.00)[] X-Rspamd-Queue-Id: 4QXWkb60Jcz47PJ X-Spamd-Bar: -- X-ThisMailContainsUnwantedMimeParts: N --Apple-Mail=_0601CF93-4FB8-43DE-9BAD-B9075B1001E7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On May 31, 2023, at 1:52 PM, John Nielsen wrote: >=20 >> On May 30, 2023, at 11:17 PM, Adrian Chadd = wrote: >>=20 >> On Tue, 30 May 2023 at 22:12, John Nielsen > wrote: >>>> On May 30, 2023, at 10:56 PM, Adrian Chadd > wrote: >>>>=20 >>>> On Tue, 30 May 2023 at 20:56, John Nielsen > wrote: >>>>> > On May 30, 2023, at 8:02 PM, Adrian Chadd > wrote: >>>>> >=20 >>>>> > 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. >>>>> >=20 >>>>> > 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. >>>>>=20 >>>>> 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=99= ve been missing those messages when grep-ing. Here=E2=80=99s the whole = snippet: >>>>>=20 >>>>> ath0: 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 >>>>=20 >>>> Yeah, this bit right here is the problem. It's not finding a valid = calibration. >>>=20 >>>> oh err, is there a wifi enable/disable switch or something? maybe = it's asserted and somehow it's mucking up the NIC? >>>=20 >>> There is a physical switch and it=E2=80=99s in the =E2=80=9Cenable=E2=80= =9D position. >>>=20 >>>> I wonder what ath9k is doing here? Is there some weird pci based = workaround/flag for the given NIC PCI id? >>>=20 >>> That was the first breadcrumb BZ threw me but I can=E2=80=99t find = anything. There are some .driver_data hints for adjacent subdevice IDs = but none for this one (Dell 0x020d) in either FreeBSD or Linux that I = could find. >>>=20 >>> [snip] >>> There is this commit in ath9k which mentions an alternative EEPROM = address, but I=E2=80=99m not sure if that=E2=80=99s relevant. =46rom = what I can tell the probe should succeed at the normal base_address = 0x3ff instead of needing to try the =E2=80=9C4k=E2=80=9D one 0xfff. >>> = https://git.kernel.org/pub/scm/linux/kernel/git/kvalo/ath.git/commit/drive= rs/net/wireless/ath/ath9k?id=3D528782ecf59f7bab2f1368628a479f49be59b512 >>=20 >> Yeah i'd try that. It'd be nice if I knew that the NIC used OTP or = EEPROM though. >>=20 >> 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. :( >=20 > The 4k EEPROM read didn=E2=80=99t work. But I did notice that where it = says it=E2=80=99s restoring Cal data from OTP it actually just does an = EEPROM read again. Shouldn=E2=80=99t this line be a call to = ar9300_otp_read() instead of ar9300_eeprom_restore_internal_address()? >=20 > = https://cgit.freebsd.org/src/tree/sys/contrib/dev/ath/ath_hal/ar9300/ar930= 0_eeprom.c#n4292 >=20 > Otherwise it doesn=E2=80=99t use the 0x14000 (0x30000 for some cards) = OTP offset as a starting point. I=E2=80=99d love to know if I=E2=80=99m up in the night about my theory = above about the OTP call not actually happening. In the meantime I=E2=80=99= ll carry on either trying to find/build a Linux kernel with = CONFIG_ATH_DEBUG enabled that I can boot on the laptop (to see which = EEPROM retrieval/check actually succeeds) and/or try to reimplement bits = from the ath9k ar9300_eeprom_restore_internal() to match its behavior on = FreeBSD. ( = https://git.kernel.org/pub/scm/linux/kernel/git/kvalo/ath.git/tree/drivers= /net/wireless/ath/ath9k/ar9003_eeprom.c#n3266 ) Thanks, JN --Apple-Mail=_0601CF93-4FB8-43DE-9BAD-B9075B1001E7 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On May 31, 2023, = at 1:52 PM, John Nielsen <lists@jnielsen.net> wrote:

On May 30, 2023, at 11:17 PM, Adrian Chadd = <adrian@freebsd.org> wrote:

On Tue, 30 = May 2023 at 22:12, John Nielsen <lists@jnielsen.net> = wrote:
On May 30, 2023, at 10:56 = PM, Adrian Chadd <adrian@freebsd.org> wrote:

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=E2=80=99t = prepend =E2=80=9Cath%d=E2=80=9D so I=E2=80=99ve been missing 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 = template
ar9300_hw_attach: ar9300_eeprom_attach returned = 0

Yeah, this bit right here is the = problem. It's not finding a valid = calibration.

oh err, is there a wifi enable/disable switch or = something? maybe it's asserted and somehow it's mucking up the = NIC?

There is a physical switch and = it=E2=80=99s in the =E2=80=9Cenable=E2=80=9D = position.

 I wonder what ath9k is doing here? Is = there some weird pci based workaround/flag for the given NIC PCI = id?

That was the first = breadcrumb BZ threw me but I can=E2=80=99t find anything. There are some = .driver_data hints for adjacent subdevice IDs but none for this one = (Dell 0x020d) in either FreeBSD or Linux that I could = find.

[snip]
There is this commit in ath9k = which mentions an alternative EEPROM address, but I=E2=80=99m not sure = if that=E2=80=99s relevant. =46rom what I can tell the probe should = succeed at the normal base_address 0x3ff instead of needing to try the = =E2=80=9C4k=E2=80=9D one 0xfff.

Yeah i'd = try that. It'd be nice if I knew that the NIC used OTP or EEPROM = though.

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. :(

The 4k EEPROM = read didn=E2=80=99t work. But I did notice that where it says it=E2=80=99s= restoring Cal data from OTP it actually just does an EEPROM read again. = Shouldn=E2=80=99t this line be a call to ar9300_otp_read() instead of = ar9300_eeprom_restore_internal_address()?


Otherwise it = doesn=E2=80=99t use the 0x14000 (0x30000 for some cards) OTP offset as a = starting point.

I=E2=80=99d love = to know if I=E2=80=99m up in the night about my theory above about the = OTP call not actually happening. In the meantime I=E2=80=99ll carry on = either trying to find/build a Linux kernel with CONFIG_ATH_DEBUG enabled = that I can boot on the laptop (to see which EEPROM retrieval/check = actually succeeds) and/or try to reimplement bits from the ath9k = ar9300_eeprom_restore_internal() to match its behavior on = FreeBSD.
( = https://git.kernel.org/pub/scm/linux/kernel/git/kvalo/ath.git/tree/drivers= /net/wireless/ath/ath9k/ar9003_eeprom.c#n3266 = )

Thanks,

JN
<= br>
= --Apple-Mail=_0601CF93-4FB8-43DE-9BAD-B9075B1001E7-- From nobody Sun Jun 4 21:00:16 2023 X-Original-To: wireless@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4QZ8Jd1j1tz4Yrs6 for ; Sun, 4 Jun 2023 21:00:17 +0000 (UTC) (envelope-from bugzilla-noreply@FreeBSD.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4QZ8Jc5kVbz3FTf for ; Sun, 4 Jun 2023 21:00:16 +0000 (UTC) (envelope-from bugzilla-noreply@FreeBSD.org) ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1685912416; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=ijsFZNUY82eHbHEzQYmMWLBg6FKUDbEnOAXHba34o0k=; b=bsN9JMSWVxaC1HkzL1Ac5ZbTq3lbcFoIH8UyDl4fBs69fO9YaY0XyKw9banRUzqPMmzPn1 CwwiAFCpMKFSmNwGR3P6elQg3dwaV201sDs1Dhd+5Fw4Zsuy6vW6ERdnVDavd+r8hDr+CV lBHF8Q7QPGqUmiu58CKmn751TdZGEFYhJJfMYhoRMGO4Szjz8cIllT4kMZbV9P/yY66yce mAg6EL4yE5JlhxLHxmDIqfTdcHifFVwVePLVZWsw/0yBEu/cHYCALXHMTVl7em41e89z/Y 5LMrvwuZ93BLLGv1sRzypWjrVdiOK4gVX2I8ZFxYyUvGTQ3FJj/OBD5U/3zNEA== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1685912416; a=rsa-sha256; cv=none; b=O0vLt2VsCL1f8VBQaubKNG9rJ0Z6LQW0L/WMsyXcF/gFg2zbdEP9ODlYD/1SIh7DJYZtMK UgZSf4MO29yh+I3/L1V7dLxxdZrBH3D1tZPfPf9+uWgSEWJpgxjlNS4B6Y/tMy47DWso34 OeHfftc8z+qg9S0uPI5HQIV5uOmJWlo6vNDwSGTN8O5Pff3DrD653yTphON3q6c4FbwxCL 88MmlgoJtuVRc8hanD9CBxKpZiVyvf8tFafdW+Awz6w04iJdXN46T7vVdZvLeuG3rF8dcx ntDNmlOyql3ex+sV4eqKPqvRTtNmdR4yGIZSyD8Bh3EoOX8hRwh7vSug5xou1Q== Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 4QZ8Jc4cSVzLtH for ; Sun, 4 Jun 2023 21:00:16 +0000 (UTC) (envelope-from bugzilla-noreply@FreeBSD.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 354L0GjK014962 for ; Sun, 4 Jun 2023 21:00:16 GMT (envelope-from bugzilla-noreply@FreeBSD.org) Received: (from bugzilla@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 354L0GIR014961 for wireless@FreeBSD.org; Sun, 4 Jun 2023 21:00:16 GMT (envelope-from bugzilla-noreply@FreeBSD.org) Message-Id: <202306042100.354L0GIR014961@kenobi.freebsd.org> X-Authentication-Warning: kenobi.freebsd.org: bugzilla set sender to bugzilla-noreply@FreeBSD.org using -f From: bugzilla-noreply@FreeBSD.org To: wireless@FreeBSD.org Subject: Problem reports for wireless@FreeBSD.org that need special attention Date: Sun, 4 Jun 2023 21:00:16 +0000 List-Id: Discussions List-Archive: https://lists.freebsd.org/archives/freebsd-wireless List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-wireless@freebsd.org X-BeenThere: freebsd-wireless@freebsd.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="16859124165.1eafF.13176" Content-Transfer-Encoding: 7bit X-ThisMailContainsUnwantedMimeParts: N --16859124165.1eafF.13176 Date: Sun, 4 Jun 2023 21:00:16 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" To view an individual PR, use: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=(Bug Id). The following is a listing of current problems submitted by FreeBSD users, which need special attention. These represent problem reports covering all versions including experimental development code and obsolete releases. Status | Bug Id | Description ------------+-----------+--------------------------------------------------- Open | 236918 | Crash: in iwn_ampdu_tx_stop (or ieee80211_ht_node Open | 238636 | ath: Fix kernel addresses printed in if_ath_sysct 2 problems total for which you should take action. --16859124165.1eafF.13176 Date: Sun, 4 Jun 2023 21:00:16 +0000 MIME-Version: 1.0 Content-Type: text/html; charset="UTF-8" 
The following is a listing of current problems submitted by FreeBSD users,
which need special attention. These represent problem reports covering
all versions including experimental development code and obsolete releases.

Status      |    Bug Id | Description
------------+-----------+---------------------------------------------------
Open        |    236918 | Crash: in iwn_ampdu_tx_stop (or ieee80211_ht_node
Open        |    238636 | ath: Fix kernel addresses printed in if_ath_sysct

2 problems total for which you should take action.
--16859124165.1eafF.13176-- From nobody Thu Jun 8 22:54:29 2023 X-Original-To: wireless@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4Qcfg54tZXz4bpnc for ; Thu, 8 Jun 2023 22:54:57 +0000 (UTC) (envelope-from lists@jnielsen.net) Received: from webmail5.jnielsen.net (webmail5.jnielsen.net [IPv6:2607:f170:34:11::b0]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "mail.freebsdsolutions.net", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Qcfg35hLvz3Mhr; Thu, 8 Jun 2023 22:54:55 +0000 (UTC) (envelope-from lists@jnielsen.net) Authentication-Results: mx1.freebsd.org; dkim=none; spf=pass (mx1.freebsd.org: domain of lists@jnielsen.net designates 2607:f170:34:11::b0 as permitted sender) smtp.mailfrom=lists@jnielsen.net; dmarc=none Received: from smtpclient.apple ([50.207.241.62]) (authenticated bits=0) by webmail5.jnielsen.net (8.17.1/8.17.1) with ESMTPSA id 358Msi6u068226 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 8 Jun 2023 16:54:47 -0600 (MDT) (envelope-from lists@jnielsen.net) X-Authentication-Warning: webmail5.jnielsen.net: Host [50.207.241.62] claimed to be smtpclient.apple Content-Type: text/plain; charset=utf-8 List-Id: Discussions List-Archive: https://lists.freebsd.org/archives/freebsd-wireless List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-wireless@freebsd.org X-BeenThere: freebsd-wireless@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.600.7\)) Subject: Re: Help me grok the ath(4) device attach code From: John Nielsen In-Reply-To: <8CEDC118-5FCA-434D-B7F7-B0C4A7AC3ACC@jnielsen.net> Date: Thu, 8 Jun 2023 16:54:29 -0600 Cc: "Bjoern A. Zeeb" , "wireless@freebsd.org" Content-Transfer-Encoding: quoted-printable Message-Id: <3AD06513-B42D-4C65-83AC-F9AC588C0E59@jnielsen.net> References: <49AEA1CB-FA85-432F-89D7-8C49B5F3A344@jnielsen.net> <85BF3AB2-2EBF-4398-A507-ABA35505A56C@jnielsen.net> <5264D290-EB82-4D24-A812-85E3E6B5C88E@jnielsen.net> <8CEDC118-5FCA-434D-B7F7-B0C4A7AC3ACC@jnielsen.net> To: Adrian Chadd X-Mailer: Apple Mail (2.3731.600.7) X-Spamd-Result: default: False [-2.79 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.99)[-0.991]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+mx]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[jnielsen.net]; MLMMJ_DEST(0.00)[wireless@freebsd.org]; R_DKIM_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; ASN(0.00)[asn:6364, ipnet:2607:f170:30::/44, country:US]; MIME_TRACE(0.00)[0:+]; BLOCKLISTDE_FAIL(0.00)[50.207.241.62:server fail,2607:f170:34:11::b0:server fail]; TO_DN_EQ_ADDR_SOME(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; RCPT_COUNT_THREE(0.00)[3]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_SOME(0.00)[]; HAS_XAW(0.00)[]; FROM_HAS_DN(0.00)[]; ARC_NA(0.00)[]; RCVD_TLS_ALL(0.00)[] X-Rspamd-Queue-Id: 4Qcfg35hLvz3Mhr X-Spamd-Bar: -- X-ThisMailContainsUnwantedMimeParts: N > On Jun 1, 2023, at 11:28 PM, John Nielsen wrote: >=20 >> On May 31, 2023, at 1:52 PM, John Nielsen wrote: >>=20 >>> On May 30, 2023, at 11:17 PM, Adrian Chadd = wrote: >>>=20 >>> On Tue, 30 May 2023 at 22:12, John Nielsen = wrote: >>>> On May 30, 2023, at 10:56 PM, Adrian Chadd = wrote: >>>>=20 >>>> On Tue, 30 May 2023 at 20:56, John Nielsen = wrote: >>>> > On May 30, 2023, at 8:02 PM, Adrian Chadd = wrote: >>>> >=20 >>>> > 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. >>>> >=20 >>>> > 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. >>>>=20 >>>> 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=99= ve been missing those messages when grep-ing. Here=E2=80=99s the whole = snippet: >>>>=20 >>>> ath0: 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 >>>>=20 >>>> Yeah, this bit right here is the problem. It's not finding a valid = calibration. >>>=20 >>>=20 >>>> oh err, is there a wifi enable/disable switch or something? maybe = it's asserted and somehow it's mucking up the NIC? >>>=20 >>> There is a physical switch and it=E2=80=99s in the =E2=80=9Cenable=E2=80= =9D position. >>>=20 >>>> I wonder what ath9k is doing here? Is there some weird pci based = workaround/flag for the given NIC PCI id? >>>=20 >>> That was the first breadcrumb BZ threw me but I can=E2=80=99t find = anything. There are some .driver_data hints for adjacent subdevice IDs = but none for this one (Dell 0x020d) in either FreeBSD or Linux that I = could find. >>>=20 >>> [snip] >>> There is this commit in ath9k which mentions an alternative EEPROM = address, but I=E2=80=99m not sure if that=E2=80=99s relevant. =46rom = what I can tell the probe should succeed at the normal base_address = 0x3ff instead of needing to try the =E2=80=9C4k=E2=80=9D one 0xfff. >>> = https://git.kernel.org/pub/scm/linux/kernel/git/kvalo/ath.git/commit/drive= rs/net/wireless/ath/ath9k?id=3D528782ecf59f7bab2f1368628a479f49be59b512 >>>=20 >>> Yeah i'd try that. It'd be nice if I knew that the NIC used OTP or = EEPROM though. >>>=20 >>> 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. :( >>=20 >>=20 >> The 4k EEPROM read didn=E2=80=99t work. But I did notice that where = it says it=E2=80=99s restoring Cal data from OTP it actually just does = an EEPROM read again. Shouldn=E2=80=99t this line be a call to = ar9300_otp_read() instead of ar9300_eeprom_restore_internal_address()? >>=20 >> = https://cgit.freebsd.org/src/tree/sys/contrib/dev/ath/ath_hal/ar9300/ar930= 0_eeprom.c#n4292 >>=20 >> Otherwise it doesn=E2=80=99t use the 0x14000 (0x30000 for some cards) = OTP offset as a starting point. >=20 >=20 > I=E2=80=99d love to know if I=E2=80=99m up in the night about my = theory above about the OTP call not actually happening. In the meantime = I=E2=80=99ll carry on either trying to find/build a Linux kernel with = CONFIG_ATH_DEBUG enabled that I can boot on the laptop (to see which = EEPROM retrieval/check actually succeeds) and/or try to reimplement bits = from the ath9k ar9300_eeprom_restore_internal() to match its behavior on = FreeBSD. > ( = https://git.kernel.org/pub/scm/linux/kernel/git/kvalo/ath.git/tree/drivers= /net/wireless/ath/ath9k/ar9003_eeprom.c#n3266 ) After learning more than I planned to about archiso and building kernel = packages for Arch I managed to boot the laptop on a Linux kernel with = CONFIG_ATH_DEBUG enabled and set as ath9k.debug=3D0x4 to get the EEPROM = debug output. And.. it looks a lot more normal than I would have = guessed. The EEPROM is located, identified and loaded from the default = 0x3ff address (first try!) and everything just goes smoothly. Full = output below. That at least tells me where to focus in the FreeBSD code but as always = I=E2=80=99d love some input or advice from Adrian or anyone who=E2=80=99s = looked at this more than I have. Thanks! -JN =3D=3D=3D dmesg|grep ath output =3D=3D=3D [ 0.039398] Kernel command line: = BOOT_IMAGE=3D/arch/boot/x86_64/vmlinuz-linux-jn archisobasedir=3Darch = archisodevice=3DUUID=3D2023-06-08-21-40-20-00 ath9k.debug=3D0x4 [ 17.692752] ath9k 0000:04:00.0: enabling device (0000 -> 0002) [ 17.696711] ath: phy0: Trying EEPROM access at Address 0x03ff [ 17.697238] ath: phy0: Found valid EEPROM data [ 17.697763] ath: phy0: Found block at 3ff: code=3D3 ref=3D4 = length=3D794 major=3D4 minor=3D6 [ 17.803208] ath: phy0: checksum a5cc a5cc [ 17.803214] ath: phy0: restore eeprom 0: block, reference 4, length = 794 [ 17.803217] ath: phy0: Restore at 0: spot=3D2 offset=3D2 length=3D22 [ 17.803219] ath: phy0: Restore at 24: spot=3D28 offset=3D4 length=3D1 [ 17.803222] ath: phy0: Restore at 27: spot=3D35 offset=3D6 length=3D1 [ 17.803224] ath: phy0: Restore at 30: spot=3D43 offset=3D7 length=3D1 [ 17.803226] ath: phy0: Restore at 33: spot=3D48 offset=3D4 length=3D31 [ 17.803228] ath: phy0: Restore at 66: spot=3D106 offset=3D27 = length=3D10 [ 17.803230] ath: phy0: Restore at 78: spot=3D128 offset=3D12 length=3D8= [ 17.803232] ath: phy0: Restore at 88: spot=3D141 offset=3D5 length=3D3 [ 17.803234] ath: phy0: Restore at 93: spot=3D147 offset=3D3 length=3D3 [ 17.803236] ath: phy0: Restore at 98: spot=3D153 offset=3D3 length=3D3 [ 17.803238] ath: phy0: Restore at 103: spot=3D159 offset=3D3 length=3D3= [ 17.803240] ath: phy0: Restore at 108: spot=3D165 offset=3D3 length=3D3= [ 17.803241] ath: phy0: Restore at 113: spot=3D171 offset=3D3 length=3D3= [ 17.803243] ath: phy0: Restore at 118: spot=3D205 offset=3D31 = length=3D31 [ 17.803245] ath: phy0: Restore at 151: spot=3D240 offset=3D4 = length=3D10 [ 17.803247] ath: phy0: Restore at 163: spot=3D254 offset=3D4 = length=3D10 [ 17.803249] ath: phy0: Restore at 175: spot=3D268 offset=3D4 = length=3D10 [ 17.803251] ath: phy0: Restore at 187: spot=3D282 offset=3D4 = length=3D10 [ 17.803253] ath: phy0: Restore at 199: spot=3D296 offset=3D4 = length=3D10 [ 17.803255] ath: phy0: Restore at 211: spot=3D328 offset=3D22 = length=3D9 [ 17.803257] ath: phy0: Restore at 222: spot=3D344 offset=3D7 length=3D9= [ 17.803259] ath: phy0: Restore at 233: spot=3D356 offset=3D3 = length=3D79 [ 17.803261] ath: phy0: Restore at 314: spot=3D438 offset=3D3 length=3D5= [ 17.803263] ath: phy0: Restore at 321: spot=3D479 offset=3D36 = length=3D2 [ 17.803265] ath: phy0: Restore at 325: spot=3D489 offset=3D8 = length=3D25 [ 17.803267] ath: phy0: Restore at 352: spot=3D517 offset=3D3 length=3D3= [ 17.803269] ath: phy0: Restore at 357: spot=3D523 offset=3D3 length=3D3= [ 17.803271] ath: phy0: Restore at 362: spot=3D529 offset=3D3 length=3D3= [ 17.803273] ath: phy0: Restore at 367: spot=3D535 offset=3D3 length=3D3= [ 17.803275] ath: phy0: Restore at 372: spot=3D541 offset=3D3 length=3D3= [ 17.803277] ath: phy0: Restore at 377: spot=3D547 offset=3D3 length=3D3= [ 17.803279] ath: phy0: Restore at 382: spot=3D553 offset=3D3 length=3D3= [ 17.803280] ath: phy0: Restore at 387: spot=3D559 offset=3D3 length=3D3= [ 17.803282] ath: phy0: Restore at 392: spot=3D565 offset=3D3 length=3D3= [ 17.803284] ath: phy0: Restore at 397: spot=3D571 offset=3D3 length=3D3= [ 17.803286] ath: phy0: Restore at 402: spot=3D577 offset=3D3 length=3D3= [ 17.803288] ath: phy0: Restore at 407: spot=3D583 offset=3D3 length=3D3= [ 17.803290] ath: phy0: Restore at 412: spot=3D589 offset=3D3 length=3D3= [ 17.803292] ath: phy0: Restore at 417: spot=3D595 offset=3D3 length=3D3= [ 17.803294] ath: phy0: Restore at 422: spot=3D601 offset=3D3 length=3D3= [ 17.803296] ath: phy0: Restore at 427: spot=3D678 offset=3D74 = length=3D43 [ 17.803298] ath: phy0: Restore at 472: spot=3D725 offset=3D4 = length=3D10 [ 17.803300] ath: phy0: Restore at 484: spot=3D739 offset=3D4 = length=3D10 [ 17.803302] ath: phy0: Restore at 496: spot=3D753 offset=3D4 = length=3D10 [ 17.803304] ath: phy0: Restore at 508: spot=3D767 offset=3D4 = length=3D10 [ 17.803306] ath: phy0: Restore at 520: spot=3D781 offset=3D4 = length=3D10 [ 17.803308] ath: phy0: Restore at 532: spot=3D795 offset=3D4 = length=3D10 [ 17.803309] ath: phy0: Restore at 544: spot=3D809 offset=3D4 = length=3D10 [ 17.803311] ath: phy0: Restore at 556: spot=3D823 offset=3D4 = length=3D10 [ 17.803313] ath: phy0: Restore at 568: spot=3D837 offset=3D4 = length=3D10 [ 17.803315] ath: phy0: Restore at 580: spot=3D851 offset=3D4 = length=3D10 [ 17.803317] ath: phy0: Restore at 592: spot=3D865 offset=3D4 = length=3D10 [ 17.803319] ath: phy0: Restore at 604: spot=3D879 offset=3D4 = length=3D10 [ 17.803321] ath: phy0: Restore at 616: spot=3D893 offset=3D4 = length=3D10 [ 17.803323] ath: phy0: Restore at 628: spot=3D907 offset=3D4 = length=3D10 [ 17.803325] ath: phy0: Restore at 640: spot=3D921 offset=3D4 = length=3D10 [ 17.803327] ath: phy0: Restore at 652: spot=3D945 offset=3D14 = length=3D15 [ 17.803329] ath: phy0: Restore at 669: spot=3D963 offset=3D3 length=3D5= [ 17.803331] ath: phy0: Restore at 676: spot=3D971 offset=3D3 = length=3D37 [ 17.803333] ath: phy0: Restore at 715: spot=3D1011 offset=3D3 = length=3D77 [ 17.805147] ath: EEPROM regdomain: 0x6c [ 17.805150] ath: EEPROM indicates we should expect a direct regpair = map [ 17.805152] ath: Country alpha2 being used: 00 [ 17.805154] ath: Regpair used: 0x6c [several more pages of calibration correction data omitted] From nobody Thu Jun 8 23:02:19 2023 X-Original-To: wireless@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4Qcfqb6s5Nz4br3V for ; Thu, 8 Jun 2023 23:02:19 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Qcfqb5ls5z3PDx for ; Thu, 8 Jun 2023 23:02:19 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1686265339; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=WkLuqhvIJo30DpW/U1vOTocHLbOq17ng//tA3TBXek0=; b=x13vxFFMniSjpwLgEGbxvCE+vJEcLmpjaru1GzgPZGXhOq3pBKqFhTFkBdSO/1jeQ3VStu w5fXFSnVfQaNm6twRXQRMJkS04rAwrterNvXH1BpJ3CoINNAXoqbRhgHrOdp4qXWDpCJVW slCdMLAjKJkuj9fY2FKyo7k3oWBJimZ6yP0h33C4jTxadhHNCWCjvfGZj8lDNjNpwqGxeI kGrkqpnfr7Zk/Jh1ilIIgl2KI6z117WdvIUck8iNlslUhugTIjxZPyS6el+OYiwBIgH+CH Q69Uo538dmCi9wq39XZJkcYE4VzDvB1omxmJmLjYXzNBU9stxOZMJ7CJ0u+UFQ== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1686265339; a=rsa-sha256; cv=none; b=lWlexaEYEO/dcr2O6k3oPtYH22zCMUZDrMfceYGxCJeq2EoLIupKDdrPyt9JnyyZR78o87 +dq86jt9vuaDPH/aHRA98ToskcCAIT2kH3F77Hd/N1JiavjZWul05VDZtvqwu72Fq2g+aS KfVRk2Ag5p9UAf9SMEwRDw9ioKscJrrnVAi9CTsNnR9oJSSBKw6VifM77ObV6Vj2r/yQpz 6XR0qX5l9W2zyb6GtAy0KHUAxbmiklC0VlTQwTQ2H40ANEwiZ830kKLzI7seSHV3ooUeQ+ NVvdf6wdu1FXbwColOo/zq149jQlfCIacysa8NhgX58WXJVcH2UELCfMsChO3g== Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 4Qcfqb4qvfz1Bsh for ; Thu, 8 Jun 2023 23:02:19 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 358N2J1c023110 for ; Thu, 8 Jun 2023 23:02:19 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 358N2J8K023109 for wireless@FreeBSD.org; Thu, 8 Jun 2023 23:02:19 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: wireless@FreeBSD.org Subject: [Bug 255337] ath(4): Atheros AR9462 identified correctly but does not function Date: Thu, 08 Jun 2023 23:02:19 +0000 X-Bugzilla-Reason: AssignedTo CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: wireless X-Bugzilla-Version: 13.0-RELEASE X-Bugzilla-Keywords: needs-qa X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: john@jnielsen.net X-Bugzilla-Status: Open X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: wireless@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated List-Id: Discussions List-Archive: https://lists.freebsd.org/archives/freebsd-wireless List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-wireless@freebsd.org X-BeenThere: freebsd-wireless@freebsd.org MIME-Version: 1.0 X-ThisMailContainsUnwantedMimeParts: N https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D255337 --- Comment #10 from John Nielsen --- According to feedback from Adrian and others on freebsd-wireless it seems t= he EEPROM is not being read correctly for this card under FreeBSD. This is par= t of the dmesg output from FreeBSD on my laptop: ath0: mem 0xf7a00000-0xf7a7ffff at device 0.0 on pc= i4 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 It tries to read all the places and doesn't succeed from any of them. The hard-coded ar9300 default template is where the 00:02:03:04:05:06 MAC addre= ss comes from. I was able to boot the same laptop under Linux (where the wireless works as expected) with the ath9k EEPROM debug messages enabled and got the followin= g: [ 0.039398] Kernel command line: BOOT_IMAGE=3D/arch/boot/x86_64/vmlinuz-linux-jn archisobasedir=3Darch archisodevice=3DUUID=3D2023-06-08-21-40-20-00 ath9k.debug=3D0x4 [ 17.692752] ath9k 0000:04:00.0: enabling device (0000 -> 0002) [ 17.696711] ath: phy0: Trying EEPROM access at Address 0x03ff [ 17.697238] ath: phy0: Found valid EEPROM data [ 17.697763] ath: phy0: Found block at 3ff: code=3D3 ref=3D4 length=3D794= major=3D4 minor=3D6 [ 17.803208] ath: phy0: checksum a5cc a5cc [ 17.803214] ath: phy0: restore eeprom 0: block, reference 4, length 794 It succeeds at reading the EEPROM data on the first attempt and gets all the appropriate information (including a valid MAC address). Hopefully this gets us closer to at least knowing where the problem is. I p= lan to keep poking at it as I have time. --=20 You are receiving this mail because: You are the assignee for the bug. You are on the CC list for the bug.= From nobody Fri Jun 9 00:33:40 2023 X-Original-To: wireless@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4QchsH3c7hz4c6XJ for ; Fri, 9 Jun 2023 00:33:55 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-lj1-f181.google.com (mail-lj1-f181.google.com [209.85.208.181]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4QchsH201dz3mhW for ; Fri, 9 Jun 2023 00:33:55 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-lj1-f181.google.com with SMTP id 38308e7fff4ca-2b1a46ad09fso12560781fa.2 for ; Thu, 08 Jun 2023 17:33:55 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1686270833; x=1688862833; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=qnfwSKAQnvA6vQykydQnGdV+WIZmHpkdVjxRm8Romp8=; b=Bquw5Ap4FtaRy2JoFm09jmlPlRUe8C7Wig+4HMoP/Wd+o7l2L5NuFEceo6ryNnjkLQ /wUSZ18syrdcehvLk7+s3V6sTOgsFVhu9Z65fRQ18nHSH//EAHpcmH6k6g1S0QnTfgBn qbyIO/DQyN7VCABaEZ/9xpKthRcxlf5lKvcxmL1tZA/w9xVFQl+asnaVx/pKBnIqhCRa UDWfyPktiOZRw0c5hsieNQDoC51jUZ4wD8kCu5YHxD5QFnAfH65wk7tkT0MU3qxtp+rL KqiyXhqls4kzFGg+9xEt2FtzDq9YjDCluymZhu/e0TUsFjJztueeZh0j5f9K1Ew9Dba2 2spw== X-Gm-Message-State: AC+VfDyeuOErtBLzotJ7YqHMhjsVTED2XJNtnim+RjH3gfem0Bpu1xm5 ZGhu2jCfG9Gtzt1Voa5EbCeAfZeABrvmsDJlN7hLbWXR X-Google-Smtp-Source: ACHHUZ4zbK+gI/p7qWsPZeMiE+QsILNHJ1UXXgRIUtbEDOr/Jw2QWqze2q61hwZMJ3uAHXpCsWRQUUBs9RdPoyVrGzU= X-Received: by 2002:a2e:9582:0:b0:2b1:c6e9:3e5c with SMTP id w2-20020a2e9582000000b002b1c6e93e5cmr91319ljh.10.1686270832808; Thu, 08 Jun 2023 17:33:52 -0700 (PDT) List-Id: Discussions List-Archive: https://lists.freebsd.org/archives/freebsd-wireless List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-wireless@freebsd.org X-BeenThere: freebsd-wireless@freebsd.org MIME-Version: 1.0 References: <49AEA1CB-FA85-432F-89D7-8C49B5F3A344@jnielsen.net> <85BF3AB2-2EBF-4398-A507-ABA35505A56C@jnielsen.net> <5264D290-EB82-4D24-A812-85E3E6B5C88E@jnielsen.net> <8CEDC118-5FCA-434D-B7F7-B0C4A7AC3ACC@jnielsen.net> <3AD06513-B42D-4C65-83AC-F9AC588C0E59@jnielsen.net> In-Reply-To: <3AD06513-B42D-4C65-83AC-F9AC588C0E59@jnielsen.net> From: Adrian Chadd Date: Thu, 8 Jun 2023 17:33:40 -0700 Message-ID: Subject: Re: Help me grok the ath(4) device attach code To: John Nielsen Cc: "Bjoern A. Zeeb" , "wireless@freebsd.org" Content-Type: multipart/alternative; boundary="000000000000fc157905fda7851f" X-Rspamd-Queue-Id: 4QchsH201dz3mhW X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; TAGGED_FROM(0.00)[] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N --000000000000fc157905fda7851f Content-Type: text/plain; charset="UTF-8" hm, does ath9k do a specific pci bus reset somewhere? -a --000000000000fc157905fda7851f Content-Type: text/html; charset="UTF-8"
hm, does ath9k do a specific pci bus reset somewhere?


-a

--000000000000fc157905fda7851f-- From nobody Fri Jun 9 03:31:11 2023 X-Original-To: wireless@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4Qcmnq62ZVz4bM2H for ; Fri, 9 Jun 2023 03:31:11 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Qcmnq4sLJz4FGS for ; Fri, 9 Jun 2023 03:31:11 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1686281471; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=o4nK/wwtSWzpVT9qlj6tIoamh2sAuaV+rE7ykMdHx+M=; b=JQ3gOwLWIkzyDLmLV11EulbuD1L3WXePibm2XtDZnk7fZLwndzdvHc2RqAFb2mPWAblOa+ PJjlxwKC+2++olXU/OvXsB/HPXQoFbgW9DRT+5UlJCp5GzTd3mgCkc3+jKb5OZ4E5FXm9c +tMfOaL8Fh23G7jujnlgDkD3wHDe54h8kl0wyV+0R9tUk9cfKUliltjczXc7hh+u9eXyG7 HwN/MY7FQUQ3ZmMz9/kX8QeEyE7gV1b6t17l+rXvZZFAD7XwRMBNn8LLJJvueSCDoZge3x KtC/mR3WzAtmYBnI9DZnx0SUc10jml+iFHPOPH8TPsCetexzluB1EY+ioQZv/g== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1686281471; a=rsa-sha256; cv=none; b=W5VnCsQaA5BjN3xaDpDHr5+GhIlg6KsTpnBVhL2MHbPunV1VL3v9bhd/jIbodeZpTOdSt7 9b0i5XCbkvWYbWYhmel33q2QPzqiTmkJWTlIe84DhSMYi9/3ApjfCXkdCdmUvoVg59Z2rO cV6ORz7vLjbfnWesncA8mIvhH7sruu666rhXsepMAdc2iSFwOQ9BXvRrD4LfOgKctZFeWV hFmCFvVdueEmDwMexRc5JDrvPGGVVKwZ0L4pfY8+8VX+5qt/bA1BjN7ZRbje+ya7pSuRSX zM7T58TCtjw7XhOzGr1VMLWIz4dwfdwbv/b4PnmvMoZZmkVLiIltt9G1v4Y9nw== Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 4Qcmnq3xxvzL45 for ; Fri, 9 Jun 2023 03:31:11 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 3593VB0I013302 for ; Fri, 9 Jun 2023 03:31:11 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 3593VBvI013301 for wireless@FreeBSD.org; Fri, 9 Jun 2023 03:31:11 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: wireless@FreeBSD.org Subject: [Bug 255337] ath(4): Atheros AR9462 identified correctly but does not function Date: Fri, 09 Jun 2023 03:31:11 +0000 X-Bugzilla-Reason: AssignedTo CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: wireless X-Bugzilla-Version: 13.0-RELEASE X-Bugzilla-Keywords: needs-qa X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: danielthedeer@outlook.com X-Bugzilla-Status: Open X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: wireless@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated List-Id: Discussions List-Archive: https://lists.freebsd.org/archives/freebsd-wireless List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-wireless@freebsd.org X-BeenThere: freebsd-wireless@freebsd.org MIME-Version: 1.0 X-ThisMailContainsUnwantedMimeParts: N https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D255337 --- Comment #11 from Daniel Cervus --- And things are a little strange for me. The card is correctly recognised on 12.4 boot up and it does can connect to the 5GHz Wi-Fi. But error messages occasionally show up and connecting options do not work in bsdconfig. Refer= to my bug report https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D256255 fo= r more information. dmesg: ath0: mem 0xff600000-0xff67ffff irq 18 at device 0.= 0 on pci2 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_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] 2 RX streams; 2 TX streams ath0: AR9460 mac 640.2 RF5110 phy 4062.13 ath0: 2GHz radio: 0x0000; 5GHz radio: 0x0000 --=20 You are receiving this mail because: You are the assignee for the bug. You are on the CC list for the bug.= From nobody Sat Jun 10 17:30:11 2023 X-Original-To: wireless@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4QdlN23tC8z4c6DZ for ; Sat, 10 Jun 2023 17:30:42 +0000 (UTC) (envelope-from lists@jnielsen.net) Received: from webmail5.jnielsen.net (webmail5.jnielsen.net [IPv6:2607:f170:34:11::b0]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "mail.freebsdsolutions.net", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4QdlN15Kx9z3wTm; Sat, 10 Jun 2023 17:30:41 +0000 (UTC) (envelope-from lists@jnielsen.net) Authentication-Results: mx1.freebsd.org; dkim=none; spf=pass (mx1.freebsd.org: domain of lists@jnielsen.net designates 2607:f170:34:11::b0 as permitted sender) smtp.mailfrom=lists@jnielsen.net; dmarc=none Received: from smtpclient.apple (166-70-14-17.xmission.com [166.70.14.17] (may be forged)) (authenticated bits=0) by webmail5.jnielsen.net (8.17.1/8.17.1) with ESMTPSA id 35AHULm7020881 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO); Sat, 10 Jun 2023 11:30:27 -0600 (MDT) (envelope-from lists@jnielsen.net) X-Authentication-Warning: webmail5.jnielsen.net: Host 166-70-14-17.xmission.com [166.70.14.17] (may be forged) claimed to be smtpclient.apple Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: John Nielsen List-Id: Discussions List-Archive: https://lists.freebsd.org/archives/freebsd-wireless List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-wireless@freebsd.org X-BeenThere: freebsd-wireless@freebsd.org Mime-Version: 1.0 (1.0) Subject: Re: Help me grok the ath(4) device attach code Date: Sat, 10 Jun 2023 11:30:11 -0600 Message-Id: <43B0F165-F0A8-4221-BF44-1A3221192EFB@jnielsen.net> References: Cc: "Bjoern A. Zeeb" , wireless@freebsd.org In-Reply-To: To: Adrian Chadd X-Mailer: iPhone Mail (20F66) X-Spamd-Result: default: False [-2.65 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.85)[-0.850]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+mx]; MIME_GOOD(-0.10)[text/plain]; MLMMJ_DEST(0.00)[wireless@freebsd.org]; ASN(0.00)[asn:6364, ipnet:2607:f170:30::/44, country:US]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MIME_TRACE(0.00)[0:+]; R_DKIM_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; DMARC_NA(0.00)[jnielsen.net]; MID_RHS_MATCH_FROM(0.00)[]; ARC_NA(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; RCPT_COUNT_THREE(0.00)[3]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; HAS_XAW(0.00)[]; RCVD_TLS_ALL(0.00)[] X-Rspamd-Queue-Id: 4QdlN15Kx9z3wTm X-Spamd-Bar: -- X-ThisMailContainsUnwantedMimeParts: N > On Jun 8, 2023, at 6:34 PM, Adrian Chadd wrote: >=20 > hm, does ath9k do a specific pci bus reset somewhere? Not that I=E2=80=99ve encountered but I=E2=80=99ll take another look. On a side note, is AH_DEBUG broken for anyone else or am I doing something w= rong? I=E2=80=99m trying to get some of the built-in debug messages as well a= s adding my own but not having any luck. I=E2=80=99ve compiled it in and hav= e =E2=80=98hw.ath.hal.debug=3D=E2=80=9C0xffffffff=E2=80=9D=E2=80=99 but neve= r get any messages at boot and once I can log in the sysctl is set to 0. (AT= H_DEBUG seems to work fine, but I need the HAL messages.) I=E2=80=99m runnin= g 14-CURRENT from a few weeks ago.=