Re: "panic: page fault" in iwn signal handler(?) at r367127

From: Aaron H Farias Martinez <timido_at_ubuntu.com>
Date: Fri, 30 Oct 2020 14:28:01 -0400
On Fri, 2020-10-30 at 05:37 -0700, David Wolfskill wrote:
> I've copied the dump and core.txt files to
> http://www.catwhisker.org/~david/FreeBSD/head/r367127/
> 
> Here's a copy/paste of the stack trace (from the core.txt.3 file):
> p 12: page fault while in kernel mode
> cpuid = 4; apic id = 04
> fault virtual address = 0xfffff80840000000
> fault code  = supervisor read data, page not present
> instruction pointer = 0x20:0xffffffff80495f03
> stack pointer         = 0x0:0xffffffff8241d748
> frame pointer         = 0x0:0xffffffff8241d7a0
> code segment  = base 0x0, limit 0xfffff, type 0x1b
>    = DPL 0, pres 1, long 1, def32 0, gran 1
> processor eflags = interrupt enabled, resume, IOPL = 0
> current process  = 12 (irq36: iwn0)
> trap number  = 12
> panic: page fault
> cpuid = 4
> time = 1604056852
> KDB: stack backtrace:
> db_trace_self_wrapper() at 0xffffffff804a69db =
> db_trace_self_wrapper+0x2b/frame 0xffffffff8241d3f0
> vpanic() at 0xffffffff80baf802 = vpanic+0x182/frame
> 0xffffffff8241d440
> panic() at 0xffffffff80baf5c3 = panic+0x43/frame 0xffffffff8241d4a0
> trap_fatal() at 0xffffffff8102c2f7 = trap_fatal+0x387/frame
> 0xffffffff8241d500
> trap_pfault() at 0xffffffff8102c397 = trap_pfault+0x97/frame
> 0xffffffff8241d560
> trap() at 0xffffffff8102b98b = trap+0x2ab/frame 0xffffffff8241d670
> calltrap() at 0xffffffff80fffa08 = calltrap+0x8/frame
> 0xffffffff8241d670
> --- trap 0xc, rip = 0xffffffff80495f03, rsp = 0xffffffff8241d748, rbp
> = 0xffffffff8241d7a0 ---
> rijndaelEncrypt() at 0xffffffff80495f03 = rijndaelEncrypt+0x233/frame
> 0xffffffff8241d7a0
> ccmp_decap() at 0xffffffff80d08bc1 = ccmp_decap+0x421/frame
> 0xffffffff8241d8b0
> ieee80211_crypto_decap() at 0xffffffff80d07955 =
> ieee80211_crypto_decap+0x125/frame 0xffffffff8241d900
> sta_input() at 0xffffffff80d41dec = sta_input+0x43c/frame
> 0xffffffff8241d9a0
> iwn_notif_intr() at 0xffffffff8069949c = iwn_notif_intr+0x137c/frame
> 0xffffffff8241dab0
> iwn_intr() at 0xffffffff8068f4f8 = iwn_intr+0x2b8/frame
> 0xffffffff8241db20
> ithread_loop() at 0xffffffff80b6dbb9 = ithread_loop+0x279/frame
> 0xffffffff8241dbb0
> fork_exit() at 0xffffffff80b6a690 = fork_exit+0x80/frame
> 0xffffffff8241dbf0
> fork_trampoline() at 0xffffffff81000a5e = fork_trampoline+0xe/frame
> 0xffffffff8241dbf0
> --- trap 0, rip = 0, rsp = 0, rbp = 0 ---
> KDB: enter: panic
> 
> __curthread () at /usr/src/sys/amd64/include/pcpu_aux.h:55
> 55  __asm("movq %%gs:%P1,%0" : "=r" (td) : "n" (offsetof(struct pcpu,
> (kgdb) #0  __curthread () at /usr/src/sys/amd64/include/pcpu_aux.h:55
> #1  doadump (textdump=0) at /usr/src/sys/kern/kern_shutdown.c:394
> #2  0xffffffff804a3cea in db_dump (dummy=<optimized out>, 
>     dummy2=<optimized out>, dummy3=<unavailable>,
> dummy4=<unavailable>)
>     at /usr/src/sys/ddb/db_command.c:575
> #3  0xffffffff804a3ab0 in db_command (last_cmdp=<optimized out>, 
>     cmd_table=<optimized out>, dopager=1) at
> /usr/src/sys/ddb/db_command.c:482
> #4  0xffffffff804a380d in db_command_loop ()
>     at /usr/src/sys/ddb/db_command.c:535
> #5  0xffffffff804a6b26 in db_trap (type=<optimized out>,
> code=<optimized out>)
>     at /usr/src/sys/ddb/db_main.c:270
> #6  0xffffffff80bfb5c4 in kdb_trap (type=3, code=0, tf=<optimized
> out>)
>     at /usr/src/sys/kern/subr_kdb.c:699
> #7  0xffffffff8102be9e in trap (frame=0xffffffff8241d320)
>     at /usr/src/sys/amd64/amd64/trap.c:576
> #8  <signal handler called>
> #9  kdb_enter (why=0xffffffff8120d701 "panic", msg=<optimized out>)
>     at /usr/src/sys/kern/subr_kdb.c:486
> #10 0xffffffff80baf81e in vpanic (fmt=<optimized out>, ap=<optimized
> out>)
>     at /usr/src/sys/kern/kern_shutdown.c:901
> #11 0xffffffff80baf5c3 in panic (
>     fmt=0xffffffff81c79aa8 <cnputs_mtx>
> "\362\357\034\201\377\377\377\377")
>     at /usr/src/sys/kern/kern_shutdown.c:838
> #12 0xffffffff8102c2f7 in trap_fatal (frame=0xffffffff8241d680, 
>     eva=18446735313050009600) at /usr/src/sys/amd64/amd64/trap.c:915
> #13 0xffffffff8102c397 in trap_pfault (frame=0xffffffff8241d680, 
>     usermode=<optimized out>, signo=<optimized out>, ucode=<optimized
> out>)
>     at /usr/src/sys/amd64/amd64/trap.c:732
> #14 0xffffffff8102b98b in trap (frame=0xffffffff8241d680)
>     at /usr/src/sys/amd64/amd64/trap.c:398
> #15 <signal handler called>
> #16 rijndaelEncrypt (rk=<optimized out>, Nr=<optimized out>, 
>     pt=<optimized out>, 
>     ct=0xffffffff8241d830
> "\277\243\ff\211\335\330\v5\234\035{\210\330\320\327Fe\235>\226\026\0
> 25c\266n\325\305\205]\251%\001\002\004\030\326!\"\037")
>     at /usr/src/sys/crypto/rijndael/rijndael-alg-fst.c:1000
> #17 0xffffffff80d08bc1 in ccmp_decrypt (key=0xfffffe106978a160,
> pn=25627, 
>     m=0xfffff8010ffc9b00, hdrlen=<optimized out>)
>     at /usr/src/sys/net80211/ieee80211_crypto_ccmp.c:623
> #18 ccmp_decap (k=<optimized out>, m=<optimized out>,
> hdrlen=<optimized out>)
>     at /usr/src/sys/net80211/ieee80211_crypto_ccmp.c:284
> #19 0xffffffff80d07955 in ieee80211_crypto_decap (ni=<optimized out>,
>     m=0xfffff8010ffc9b00, hdrlen=26, key=0xffffffff8241d920)
>     at /usr/src/sys/net80211/ieee80211_crypto.c:684
> #20 0xffffffff80d41dec in sta_input (ni=<optimized out>, 
>     m=0xfffff8010ffc9b00, rxs=<optimized out>, rssi=<optimized out>, 
>     nf=<optimized out>) at /usr/src/sys/net80211/ieee80211_sta.c:773
> #21 0xffffffff8069949c in iwn_rx_done (sc=0xfffffe1033319000, 
>     desc=<optimized out>, data=<optimized out>)
>     at /usr/src/sys/dev/iwn/if_iwn.c:3191
> #22 iwn_notif_intr (sc=<optimized out>) at
> /usr/src/sys/dev/iwn/if_iwn.c:4018
> #23 0xffffffff8068f4f8 in iwn_intr (arg=0xfffffe1033319000)
>     at /usr/src/sys/dev/iwn/if_iwn.c:4337
> #24 0xffffffff80b6dbb9 in intr_event_execute_handlers (p=<optimized
> out>, 
>     ie=0xfffff8000c52b300) at /usr/src/sys/kern/kern_intr.c:1168
> #25 ithread_execute_handlers (p=<optimized out>,
> ie=0xfffff8000c52b300)
>     at /usr/src/sys/kern/kern_intr.c:1181
> #26 ithread_loop (arg=<optimized out>) at
> /usr/src/sys/kern/kern_intr.c:1269
> #27 0xffffffff80b6a690 in fork_exit (
>     callout=0xffffffff80b6d940 <ithread_loop>,
> arg=0xfffff8000d18ef00, 
>     frame=0xffffffff8241dc00) at /usr/src/sys/kern/kern_fork.c:1052
> #28 <signal handler called>
> (kgdb) 
> 
> 
> This happened while my laptop was running:
> FreeBSD g1-55.catwhisker.org 13.0-CURRENT FreeBSD 13.0-CURRENT #43
> r367127M/367127: Thu Oct 29 05:52:40 PDT 2020    
> root_at_g1-55.catwhisker.org:/common/S4/obj/usr/src/amd64.amd64/sys/CANA
> RY  amd64 1300123 1300123
> 
> during the "make buildkernel" phase of an in-place source update to
> r367160.
> 
> As often happens while I'm running head, there was an "iwn firmware
> panic" (see, e.g.,
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=214435); record of
> it
> may be found in /var/log/messages, starting around:
> 
> <2>1 2020-10-30T11:05:07.327958+00:00 g1-55.catwhisker.org kernel - -
> - Expensive timeout(9) function:
> 0xffffffff80d8d2f0(0xfffffe1067a408f0) 0.840172647 s
> <2>1 2020-10-30T11:07:36.367805+00:00 g1-55.catwhisker.org kernel - -
> - iwn0: iwn_intr: fatal firmware error
> <2>1 2020-10-30T11:07:36.367830+00:00 g1-55.catwhisker.org kernel - -
> - firmware error log:
> <2>1 2020-10-30T11:07:36.367839+00:00 g1-55.catwhisker.org kernel - -
> -   error type      = "UNKNOWN" (0x0000001D)
> 
> 
> and the "WiFi" LED on the laptop went dark.  As I was trying to do
> some work on another machine (while logged in to that machine from
> the
> laptop), the loss of connectivity was ... disruptive.  While I was
> mildly gratified that (this time) the "make buildkernel" appeared to
> be
> proceeding despite the iwn(4) issue(s), I also wanted to get back to
> what I was doing.
> 
> So after a few minutes -- when it became apparent that the link
> wasn't
> being recovered on its own -- I switched from X11 to vty1 (to leave
> vty0
> for console messages), logged in as root, and issued:
> 
>         service netif restart wlan0
> 
> after a couple of minutes (during which the "make buildkernel" was
> continuing), the "service netif restart wlan0" had not yet completed,
> so
> I sent it a SIGNIFO (via ^T), and (as I recall), it indocated that
> the
> process was invoking ifconfig, and there was some mention of a
> function
> whose name included "epoch".
> 
> I resumed waiting; after another minute or so, I trued ^T again, and
> there appeared to be no progress.
> 
> After waiting another 30 seconds or so, I tried to bail out via ^C;
> that
> appeared to be ineffective.  So after waiting another 10 - 15 seconds
> or
> so, I tried backgrounding (^Z), followed by "kill %1".
> 
> It was shortly after that the panic occurred.  Which may well -- to
> some
> extent -- have been self-inflicted.  That said, the iwn firmware
> panics
> are not something I can control (as far as I know -- please let me
> know
> how I can control them if I'm incoorrect on that score).  For that
> matter, I have no particular attachment to this NIC -- I'm open to a
> suggestion for any NIC with the same (miniPCI) form factor that will
> work well with FreeBSD.
> 
> Peace,
> david

I got the same issue.

Received on Fri Oct 30 2020 - 17:28:09 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:41:25 UTC