Re: AC 9461 support

From: Bjoern A. Zeeb <bz_at_FreeBSD.org>
Date: Thu, 17 Jul 2025 16:40:37 UTC
On Thu, 17 Jul 2025, Andrea Venturoli wrote:

> On 7/9/25 16:14, Andrea Venturoli wrote:
>> Hello.
>> 
>> I've got a laptop with the above WiFi card.
>> I just upgraded to 14.3 in order to see if stability and/or speed could 
>> improve.
>> 
>> For stability, time will tell.
>
> As for stability...
>
> Today I rebooted the AP I was connected to: with 14.2 probably I would have 
> experienced a panic; with 14.3 however I was simply disconnected.
> After a while, all the other devices were back online, but my notebook was 
> still without any WiFi association.
> I tried "service wpa_supplicant restart", but it didn't help; so I issued 
> "service netif restart" and everything hanged.
> I tried typing some DDB commands without seeing anything and I ended up with 
> the following backtrace:

is this from core.txt?  What's the panic message?

Also what's /usr/src/sys/compat/linuxkpi/common/src/linux_80211.c:2364
for you (a few lines before/after maybe as well)?

Also if you have a core.txt, can you check the kernel message buffer if
there was a firmware crash before this and the panic is a secondary
issue?

I noticed that I have a 9xxx in a laptop I am currently using to test
suspend/resume with.  I'll give it a bit of pushing over the next
nights and see.

/bz


>> __curthread () at /usr/src/sys/amd64/include/pcpu_aux.h:57
>> (kgdb) #0  __curthread () at /usr/src/sys/amd64/include/pcpu_aux.h:57
>> #1  doadump (textdump=textdump@entry=0)
>>     at /usr/src/sys/kern/kern_shutdown.c:405
>> #2  0xffffffff803ec27a in db_dump (dummy=<optimized out>, 
>> dummy2=<optimized out>, dummy3=<optimized out>, dummy4=<optimized out>)
>>     at /usr/src/sys/ddb/db_command.c:591
>> #3  0xffffffff803ec07d in db_command (last_cmdp=<optimized out>, 
>> cmd_table=<optimized out>, dopager=true)
>>     at /usr/src/sys/ddb/db_command.c:504
>> #4  0xffffffff803ebd3d in db_command_loop ()
>>     at /usr/src/sys/ddb/db_command.c:551
>> #5  0xffffffff803ef336 in db_trap (type=<optimized out>, code=<optimized 
>> out>)
>>     at /usr/src/sys/ddb/db_main.c:268
>> #6  0xffffffff806b36c6 in kdb_trap (type=type@entry=3, code=code@entry=0, 
>> tf=tf@entry=0xfffffe00ae3689c0) at /usr/src/sys/kern/subr_kdb.c:790
>> #7  0xffffffff80a2d9d6 in trap (frame=0xfffffe00ae3689c0)
>>     at /usr/src/sys/amd64/amd64/trap.c:639
>> #8  <signal handler called>
>> #9  kdb_enter (why=<optimized out>, msg=<optimized out>)
>>     at /usr/src/sys/kern/subr_kdb.c:556
>> #10 0xffffffff80667322 in vpanic (fmt=0xffffffff80a94e40 "%s", 
>> ap=ap@entry=0xfffffe00ae368bf0) at /usr/src/sys/kern/kern_shutdown.c:955
>> #11 0xffffffff806671b3 in panic (
>>     fmt=0xffffffff80e4c6e8 <vt_conswindow+16> 
>> "B\330\253\200\377\377\377\377")
>>     at /usr/src/sys/kern/kern_shutdown.c:891
>> #12 0xffffffff80a2e41a in trap_fatal (frame=<optimized out>, 
>> eva=<optimized out>) at /usr/src/sys/amd64/amd64/trap.c:1000
>> #13 0xffffffff80a2e41a in trap_pfault (frame=0xfffffe00ae368c70, 
>> usermode=false, signo=<optimized out>, ucode=<optimized out>)
>> #14 <signal handler called>
>> #15 lkpi_sta_auth_to_scan (vap=0xfffffe00ad4e5010, nstate=<optimized out>, 
>> arg=<optimized out>)
>>     at /usr/src/sys/compat/linuxkpi/common/src/linux_80211.c:2364
>> #16 0xffffffff808a289e in lkpi_iv_newstate (vap=0xfffffe00ad4e5010, 
>> nstate=IEEE80211_S_INIT, arg=-1)
>>     at /usr/src/sys/compat/linuxkpi/common/src/linux_80211.c:3476
>> #17 0xffffffff807f979c in ieee80211_newstate_cb (xvap=0xfffffe00ad4e5010, 
>> npending=<optimized out>) at /usr/src/sys/net80211/ieee80211_proto.c:2610
>> #18 0xffffffff806c9192 in taskqueue_run_locked (
>>     queue=queue@entry=0xfffff80009aa7900)
>>     at /usr/src/sys/kern/subr_taskqueue.c:518
>> #19 0xffffffff806ca412 in taskqueue_thread_loop (
>>     arg=arg@entry=0xfffffe00ae81f110) at 
>> /usr/src/sys/kern/subr_taskqueue.c:830
>> #20 0xffffffff806213bf in fork_exit (
>>     callout=0xffffffff806ca350 <taskqueue_thread_loop>, 
>> arg=0xfffffe00ae81f110, frame=0xfffffe00ae368f40)
>>     at /usr/src/sys/kern/kern_fork.c:1153
>> #21 <signal handler called>
>> #22 0x26b0472942aba808 in ?? ()
>> Backtrace stopped: Cannot access memory at address 0xdbac636ff4cc4f62
>
>
> I don't have the sources available now, as I'm out of office, but I'll give 
> it a shot at getting better info when I can.
>
> Please let me know if you want me to check anything specifically.
>
> bye & Thanks
> 	av.
>

-- 
Bjoern A. Zeeb                                                     r15:7