Date: Fri, 30 Oct 2020 14:26:53 -0400 From: Aaron H Farias Martinez <timido@ubuntu.com> To: current@freebsd.org Subject: Re: "panic: page fault" in iwn signal handler(?) at r367127 Message-ID: <503577abda2d455126c6639de9c5faea88bc413d.camel@ubuntu.com> In-Reply-To: <20201030123744.GT1430@albert.catwhisker.org> References: <20201030123744.GT1430@albert.catwhisker.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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/ >=20 > Here's a copy/paste of the stack trace (from the core.txt.3 file): > p 12: page fault while in kernel mode > cpuid =3D 4; apic id =3D 04 > fault virtual address =3D 0xfffff80840000000 > fault code=C2=A0 =3D supervisor read data, page not present > instruction pointer =3D 0x20:0xffffffff80495f03 > stack pointer=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =3D 0x0:0xf= fffffff8241d748 > frame pointer=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =3D 0x0:0xf= fffffff8241d7a0 > code segment=C2=A0 =3D base 0x0, limit 0xfffff, type 0x1b > =C2=A0=C2=A0 =3D DPL 0, pres 1, long 1, def32 0, gran 1 > processor eflags =3D interrupt enabled, resume, IOPL =3D 0 > current process=C2=A0 =3D 12 (irq36: iwn0) > trap number=C2=A0 =3D 12 > panic: page fault > cpuid =3D 4 > time =3D 1604056852 > KDB: stack backtrace: > db_trace_self_wrapper() at 0xffffffff804a69db =3D > db_trace_self_wrapper+0x2b/frame 0xffffffff8241d3f0 > vpanic() at 0xffffffff80baf802 =3D vpanic+0x182/frame > 0xffffffff8241d440 > panic() at 0xffffffff80baf5c3 =3D panic+0x43/frame 0xffffffff8241d4a0 > trap_fatal() at 0xffffffff8102c2f7 =3D trap_fatal+0x387/frame > 0xffffffff8241d500 > trap_pfault() at 0xffffffff8102c397 =3D trap_pfault+0x97/frame > 0xffffffff8241d560 > trap() at 0xffffffff8102b98b =3D trap+0x2ab/frame 0xffffffff8241d670 > calltrap() at 0xffffffff80fffa08 =3D calltrap+0x8/frame > 0xffffffff8241d670 > --- trap 0xc, rip =3D 0xffffffff80495f03, rsp =3D 0xffffffff8241d748, rbp > =3D 0xffffffff8241d7a0 --- > rijndaelEncrypt() at 0xffffffff80495f03 =3D rijndaelEncrypt+0x233/frame > 0xffffffff8241d7a0 > ccmp_decap() at 0xffffffff80d08bc1 =3D ccmp_decap+0x421/frame > 0xffffffff8241d8b0 > ieee80211_crypto_decap() at 0xffffffff80d07955 =3D > ieee80211_crypto_decap+0x125/frame 0xffffffff8241d900 > sta_input() at 0xffffffff80d41dec =3D sta_input+0x43c/frame > 0xffffffff8241d9a0 > iwn_notif_intr() at 0xffffffff8069949c =3D iwn_notif_intr+0x137c/frame > 0xffffffff8241dab0 > iwn_intr() at 0xffffffff8068f4f8 =3D iwn_intr+0x2b8/frame > 0xffffffff8241db20 > ithread_loop() at 0xffffffff80b6dbb9 =3D ithread_loop+0x279/frame > 0xffffffff8241dbb0 > fork_exit() at 0xffffffff80b6a690 =3D fork_exit+0x80/frame > 0xffffffff8241dbf0 > fork_trampoline() at 0xffffffff81000a5e =3D fork_trampoline+0xe/frame > 0xffffffff8241dbf0 > --- trap 0, rip =3D 0, rsp =3D 0, rbp =3D 0 --- > KDB: enter: panic >=20 > __curthread () at /usr/src/sys/amd64/include/pcpu_aux.h:55 > 55=C2=A0 __asm("movq %%gs:%P1,%0" : "=3Dr" (td) : "n" (offsetof(struct pc= pu, > (kgdb) #0=C2=A0 __curthread () at /usr/src/sys/amd64/include/pcpu_aux.h:5= 5 > #1=C2=A0 doadump (textdump=3D0) at /usr/src/sys/kern/kern_shutdown.c:394 > #2=C2=A0 0xffffffff804a3cea in db_dump (dummy=3D<optimized out>,=20 > =C2=A0=C2=A0=C2=A0 dummy2=3D<optimized out>, dummy3=3D<unavailable>, > dummy4=3D<unavailable>) > =C2=A0=C2=A0=C2=A0 at /usr/src/sys/ddb/db_command.c:575 > #3=C2=A0 0xffffffff804a3ab0 in db_command (last_cmdp=3D<optimized out>,= =20 > =C2=A0=C2=A0=C2=A0 cmd_table=3D<optimized out>, dopager=3D1) at > /usr/src/sys/ddb/db_command.c:482 > #4=C2=A0 0xffffffff804a380d in db_command_loop () > =C2=A0=C2=A0=C2=A0 at /usr/src/sys/ddb/db_command.c:535 > #5=C2=A0 0xffffffff804a6b26 in db_trap (type=3D<optimized out>, > code=3D<optimized out>) > =C2=A0=C2=A0=C2=A0 at /usr/src/sys/ddb/db_main.c:270 > #6=C2=A0 0xffffffff80bfb5c4 in kdb_trap (type=3D3, code=3D0, tf=3D<optimi= zed > out>) > =C2=A0=C2=A0=C2=A0 at /usr/src/sys/kern/subr_kdb.c:699 > #7=C2=A0 0xffffffff8102be9e in trap (frame=3D0xffffffff8241d320) > =C2=A0=C2=A0=C2=A0 at /usr/src/sys/amd64/amd64/trap.c:576 > #8=C2=A0 <signal handler called> > #9=C2=A0 kdb_enter (why=3D0xffffffff8120d701 "panic", msg=3D<optimized ou= t>) > =C2=A0=C2=A0=C2=A0 at /usr/src/sys/kern/subr_kdb.c:486 > #10 0xffffffff80baf81e in vpanic (fmt=3D<optimized out>, ap=3D<optimized > out>) > =C2=A0=C2=A0=C2=A0 at /usr/src/sys/kern/kern_shutdown.c:901 > #11 0xffffffff80baf5c3 in panic ( > =C2=A0=C2=A0=C2=A0 fmt=3D0xffffffff81c79aa8 <cnputs_mtx> > "\362\357\034\201\377\377\377\377") > =C2=A0=C2=A0=C2=A0 at /usr/src/sys/kern/kern_shutdown.c:838 > #12 0xffffffff8102c2f7 in trap_fatal (frame=3D0xffffffff8241d680,=20 > =C2=A0=C2=A0=C2=A0 eva=3D18446735313050009600) at /usr/src/sys/amd64/amd6= 4/trap.c:915 > #13 0xffffffff8102c397 in trap_pfault (frame=3D0xffffffff8241d680,=20 > =C2=A0=C2=A0=C2=A0 usermode=3D<optimized out>, signo=3D<optimized out>, u= code=3D<optimized > out>) > =C2=A0=C2=A0=C2=A0 at /usr/src/sys/amd64/amd64/trap.c:732 > #14 0xffffffff8102b98b in trap (frame=3D0xffffffff8241d680) > =C2=A0=C2=A0=C2=A0 at /usr/src/sys/amd64/amd64/trap.c:398 > #15 <signal handler called> > #16 rijndaelEncrypt (rk=3D<optimized out>, Nr=3D<optimized out>,=20 > =C2=A0=C2=A0=C2=A0 pt=3D<optimized out>,=20 > =C2=A0=C2=A0=C2=A0 ct=3D0xffffffff8241d830 > "\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") > =C2=A0=C2=A0=C2=A0 at /usr/src/sys/crypto/rijndael/rijndael-alg-fst.c:100= 0 > #17 0xffffffff80d08bc1 in ccmp_decrypt (key=3D0xfffffe106978a160, > pn=3D25627,=20 > =C2=A0=C2=A0=C2=A0 m=3D0xfffff8010ffc9b00, hdrlen=3D<optimized out>) > =C2=A0=C2=A0=C2=A0 at /usr/src/sys/net80211/ieee80211_crypto_ccmp.c:623 > #18 ccmp_decap (k=3D<optimized out>, m=3D<optimized out>, > hdrlen=3D<optimized out>) > =C2=A0=C2=A0=C2=A0 at /usr/src/sys/net80211/ieee80211_crypto_ccmp.c:284 > #19 0xffffffff80d07955 in ieee80211_crypto_decap (ni=3D<optimized out>, > =C2=A0=C2=A0=C2=A0 m=3D0xfffff8010ffc9b00, hdrlen=3D26, key=3D0xffffffff8= 241d920) > =C2=A0=C2=A0=C2=A0 at /usr/src/sys/net80211/ieee80211_crypto.c:684 > #20 0xffffffff80d41dec in sta_input (ni=3D<optimized out>,=20 > =C2=A0=C2=A0=C2=A0 m=3D0xfffff8010ffc9b00, rxs=3D<optimized out>, rssi=3D= <optimized out>,=20 > =C2=A0=C2=A0=C2=A0 nf=3D<optimized out>) at /usr/src/sys/net80211/ieee802= 11_sta.c:773 > #21 0xffffffff8069949c in iwn_rx_done (sc=3D0xfffffe1033319000,=20 > =C2=A0=C2=A0=C2=A0 desc=3D<optimized out>, data=3D<optimized out>) > =C2=A0=C2=A0=C2=A0 at /usr/src/sys/dev/iwn/if_iwn.c:3191 > #22 iwn_notif_intr (sc=3D<optimized out>) at > /usr/src/sys/dev/iwn/if_iwn.c:4018 > #23 0xffffffff8068f4f8 in iwn_intr (arg=3D0xfffffe1033319000) > =C2=A0=C2=A0=C2=A0 at /usr/src/sys/dev/iwn/if_iwn.c:4337 > #24 0xffffffff80b6dbb9 in intr_event_execute_handlers (p=3D<optimized > out>,=20 > =C2=A0=C2=A0=C2=A0 ie=3D0xfffff8000c52b300) at /usr/src/sys/kern/kern_int= r.c:1168 > #25 ithread_execute_handlers (p=3D<optimized out>, > ie=3D0xfffff8000c52b300) > =C2=A0=C2=A0=C2=A0 at /usr/src/sys/kern/kern_intr.c:1181 > #26 ithread_loop (arg=3D<optimized out>) at > /usr/src/sys/kern/kern_intr.c:1269 > #27 0xffffffff80b6a690 in fork_exit ( > =C2=A0=C2=A0=C2=A0 callout=3D0xffffffff80b6d940 <ithread_loop>, > arg=3D0xfffff8000d18ef00,=20 > =C2=A0=C2=A0=C2=A0 frame=3D0xffffffff8241dc00) at /usr/src/sys/kern/kern_= fork.c:1052 > #28 <signal handler called> > (kgdb)=20 >=20 >=20 > 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=C2=A0=C2=A0=C2=A0=C2=A0 > root@g1-55.catwhisker.org:/common/S4/obj/usr/src/amd64.amd64/sys/CANA > RY=C2=A0 amd64 1300123 1300123 >=20 > during the "make buildkernel" phase of an in-place source update to > r367160. >=20 > 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=3D214435); record of > it > may be found in /var/log/messages, starting around: >=20 > <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 - - > -=C2=A0=C2=A0 error type=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =3D "UNKNOWN" (0x0= 000001D) >=20 >=20 > and the "WiFi" LED on the laptop went dark.=C2=A0 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.=C2=A0 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. >=20 > 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: >=20 > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0service netif restart wla= n0 >=20 > 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". >=20 > I resumed waiting; after another minute or so, I trued ^T again, and > there appeared to be no progress. >=20 > After waiting another 30 seconds or so, I tried to bail out via ^C; > that > appeared to be ineffective.=C2=A0 So after waiting another 10 - 15 second= s > or > so, I tried backgrounding (^Z), followed by "kill %1". >=20 > It was shortly after that the panic occurred.=C2=A0 Which may well -- to > some > extent -- have been self-inflicted.=C2=A0 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).=C2=A0 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. >=20 > Peace, > david I got the same issue.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?503577abda2d455126c6639de9c5faea88bc413d.camel>