From nobody Wed May 31 04:56:04 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 4QWH6F2yNgz4Y2g0 for ; Wed, 31 May 2023 04:56:21 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-lj1-f179.google.com (mail-lj1-f179.google.com [209.85.208.179]) (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 4QWH6C2K5hz4DN3 for ; Wed, 31 May 2023 04:56:19 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-lj1-f179.google.com with SMTP id 38308e7fff4ca-2af1c884b08so6722311fa.1 for ; Tue, 30 May 2023 21:56:19 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1685508977; x=1688100977; 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=+nq3iW37VCsm/+xCv6gepKcYPk0k2xdAB4LiWZLehHE=; b=NhTn6T8TTCu8TGkC52dFpoBJMJVsKU5qwO4Ct6NGGNRtu9P5CKg2OeMXy+Maju5bVH tjSDJ0s3hlIN3on+EwfQQOfhjQ17R35w3DVbyLKDsff4V27h5D0dVtNZPk9Z56YJuiGb MbTZ7vlRHbfFCRCEgI/tu2I9cxgrIKVaSXyI3ZoRB1t9/E7GWgSDu8DTbH8TTepXpNM3 a5vCYVyeJh3n2T5GBNcYQRc2W+oPZkWomwhWV/wgUgnmJ2+GIbmwzac8kcBtb1ssvWpr 8RgwPppRcmsjJetylDBRXstN+rUONUTwSFHzVLQdQiobD9mIncVwGSOeAjjSfrftIKtK ksSg== X-Gm-Message-State: AC+VfDwiI/A2d2v+U/Ckw4AqLnnTDMrnzJflZ95TFb+413oG1i+ilybe Uw1KXYI1OcFNmWTrjhfGCSK7tuavPqaHLVAnA+9bqhsk X-Google-Smtp-Source: ACHHUZ7AJgblAAYlLxw/YqNla8/lSqdndzWBToOGEqEpGGb8JikG9EBRqeprz13cmuRh0/H3pCVagGFcUXil7BqbDYk= X-Received: by 2002:a05:651c:11cd:b0:2ad:d8e2:3948 with SMTP id z13-20020a05651c11cd00b002add8e23948mr4729097ljo.24.1685508976812; Tue, 30 May 2023 21:56:16 -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> In-Reply-To: <85BF3AB2-2EBF-4398-A507-ABA35505A56C@jnielsen.net> From: Adrian Chadd Date: Tue, 30 May 2023 21:56:04 -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="000000000000d4282205fcf623c2" X-Rspamd-Queue-Id: 4QWH6C2K5hz4DN3 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 --000000000000d4282205fcf623c2 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, 30 May 2023 at 20:56, John Nielsen wrote: > > On May 30, 2023, at 8:02 PM, Adrian Chadd 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: 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


=
On Tue, 30 May 2023 at 20:56, John Ni= elsen <lists@jnielsen.net> = wrote:
> On M= ay 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 a= ttaching right to the OTP/EEPROM calibration information. That's the bi= g 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 missin= g 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<= br> ar9300_hw_attach: ar9300_eeprom_attach returned 0

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

=C2=A0I wonder what ath9k is d= oing here? Is there some weird pci based workaround/flag for the given NIC = PCI id?


-a

--000000000000d4282205fcf623c2--