Re: A kernel crash after compiling a fresh kernel
Date: Wed, 08 Jun 2022 03:06:03 UTC
On Tue, Jun 07, 2022 at 09:37:52PM -0400, Oleg Lelchuk wrote: > The 14-CURRENT running a fresh kernel crashes with these messages: > > __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 dump_savectx () at /usr/src/sys/kern/kern_shutdown.c:401 > #2 0xffffffff80be8ba5 in dumpsys (di=0x0) > at /usr/src/sys/x86/include/dump.h:87 > #3 doadump (textdump=1) at /usr/src/sys/kern/kern_shutdown.c:430 > #4 kern_reboot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:537 > #5 0xffffffff80be8fee in vpanic (fmt=<optimized out>, > ap=ap@entry=0xfffffe01042395a0) at > /usr/src/sys/kern/kern_shutdown.c:975 > #6 0xffffffff80be8d53 in panic (fmt=<unavailable>) > at /usr/src/sys/kern/kern_shutdown.c:899 > #7 0xffffffff810c0877 in trap_fatal (frame=0xfffffe0104239690, eva=0) > at /usr/src/sys/amd64/amd64/trap.c:942 > #8 0xffffffff810c092b in trap_pfault (frame=0xfffffe0104239690, > usermode=false, signo=<optimized out>, ucode=<optimized out>) > at /usr/src/sys/amd64/amd64/trap.c:761 > #9 <signal handler called> > #10 tcp_sack_output (tp=tp@entry=0xfffffe0187312140, > sack_bytes_rexmt=sack_bytes_rexmt@entry=0xfffffe010423983c) > at /usr/src/sys/netinet/tcp_sack.c:970 > #11 0xffffffff80dd47a2 in tcp_default_output (tp=0xfffffe0187312140) > at /usr/src/sys/netinet/tcp_output.c:310 > #12 0xffffffff80dcd240 in tcp_output (tp=tp@entry=0xfffffe0187312140) > at /usr/src/sys/netinet/tcp_var.h:407 > #13 0xffffffff80dcc81a in tcp_do_segment (m=0xfffff80203467700, > th=0xfffff8001f190022, so=0xfffff80015d0fb40, > tp=0xfffffe0187312140, > drop_hdrlen=64, tlen=<optimized out>, iptos=0 '\000') > at /usr/src/sys/netinet/tcp_input.c:2788 > #14 0xffffffff80dc8def in tcp_input_with_port (mp=<optimized out>, > offp=<optimized out>, proto=<optimized out>, port=port@entry > =0) > at /usr/src/sys/netinet/tcp_input.c:1397 > #15 0xffffffff80dc9c8b in tcp_input (mp=0xfffff8011c764010, offp=0x4, > proto=-2128851986) at /usr/src/sys/netinet/tcp_input.c:1492 > #16 0xffffffff80db8cd7 in ip_input (m=0x0) > at /usr/src/sys/netinet/ip_input.c:840 > #17 0xffffffff80d3842f in netisr_dispatch_src (proto=1, > source=source@entry=0, m=0xfffff80203467700) > at /usr/src/sys/net/netisr.c:1153 > #18 0xffffffff80d3878f in netisr_dispatch (proto=477511696, > m=0xffffffff811c4bee) at /usr/src/sys/net/netisr.c:1244 > #19 0xffffffff80d1a7cc in ether_demux (ifp=ifp@entry=0xfffff80002873800, > m=0x4) at /usr/src/sys/net/if_ethersubr.c:925 > #20 0xffffffff80d1be53 in ether_input_internal (ifp=0xfffff80002873800, > m=0x4) > at /usr/src/sys/net/if_ethersubr.c:711 > #21 ether_nh_input (m=<optimized out>) at > /usr/src/sys/net/if_ethersubr.c:741 > #22 0xffffffff80d3842f in netisr_dispatch_src (proto=proto@entry=5, > source=source@entry=0, m=m@entry=0xfffff80203467700) > at /usr/src/sys/net/netisr.c:1153 > #23 0xffffffff80d3878f in netisr_dispatch (proto=477511696, proto@entry=5, > m=0xffffffff811c4bee, m@entry=0xfffff80203467700) > at /usr/src/sys/net/netisr.c:1244 > #24 0xffffffff80d1ac89 in ether_input (ifp=0xfffff80002873800, > m=0xfffff80203467700) at /usr/src/sys/net/if_ethersubr.c:832 > #25 0xffffffff808f41f7 in re_rxeof (sc=sc@entry=0xfffffe00e1cce000, > rx_npktsp=0x0) at /usr/src/sys/dev/re/if_re.c:2386 > #26 0xffffffff808f1a16 in re_intr_msi (xsc=0xfffffe00e1cce000) > at /usr/src/sys/dev/re/if_re.c:2682 > #27 0xffffffff80ba3d49 in intr_event_execute_handlers > (ie=0xfffff800020fde00, > p=<optimized out>) at /usr/src/sys/kern/kern_intr.c:1205 > #28 ithread_execute_handlers (ie=0xfffff800020fde00, p=<optimized out>) > at /usr/src/sys/kern/kern_intr.c:1218 > #29 ithread_loop (arg=arg@entry=0xfffff800020fbf80) > at /usr/src/sys/kern/kern_intr.c:1306 > #30 0xffffffff80ba03e0 in fork_exit ( > callout=0xffffffff80ba3ad0 <ithread_loop>, > arg=0xfffff800020fbf80, > frame=0xfffffe0104239f40) at > /usr/src/sys/kern/kern_fork.c:1102 > #31 <signal handler called> I had a ... vaguely-similar panic on one laptop, after updating sources from main-n256013-85d7875d4291 to main-n256025-91d6afe6e2a9. I placed a screenshot of the backtrace at https://www.catwhisker.org/~david/FreeBSD/head/n256025/console.jpg The files updated were: Updating 85d7875d4291..91d6afe6e2a9 Fast-forward contrib/bsddialog/lib/lib_util.c | 7 +-- sys/arm64/arm64/identcpu.c | 85 +++++++++++++++++++++++++++++++++ sys/arm64/include/armreg.h | 30 ++++++++++++ sys/dev/alc/if_alc.c | 5 +- sys/dev/hwpmc/hwpmc_logging.c | 21 ++++---- sys/dev/hwpmc/hwpmc_mod.c | 17 ++++--- sys/dev/iommu/iommu_gas.c | 13 ++++- sys/fs/fdescfs/fdesc_vnops.c | 10 +++- sys/kern/subr_smp.c | 4 +- sys/kern/uipc_usrreq.c | 37 ++++++-------- sys/netinet/tcp_sack.c | 12 +++++ sys/sys/pmc.h | 4 ++ tests/sys/kern/unix_passfd_test.c | 37 ++++++++++---- usr.bin/gcore/elfcore.c | 29 ++--------- usr.sbin/bsdinstall/scripts/docsinstall | 3 +- 15 files changed, 223 insertions(+), 91 deletions(-) Command exit status: 0 I noted that there was a subsequent commit to sys/netinet/tcp_sack.c (231e0dd5d1fb7778b1cb285e5ebee5502d5ad253, to avoid a NULL dereference); while I don't believe I was using SACK, I went ahead and hand-applied that small change & rebuilt; that did not seem to help (as I got a similar-looking panic after the rebuild). Peace, david -- David H. Wolfskill david@catwhisker.org "Putin is a paranoid dictator. Putin must go. He started a senseless war and is leading Russia into a ditch." - Egor Polyakov & Alexandra Miroshnikova See https://www.catwhisker.org/~david/publickey.gpg for my public key.