Re: Easily reproducible stable/13 kernel crash

From: Herbert J. Skuhra <herbert_at_gojira.at>
Date: Fri, 11 Jun 2021 11:47:46 +0200
On Fri, 11 Jun 2021 09:18:32 +0200, Hans Petter Selasky wrote:
> 
> On 6/11/21 9:02 AM, Herbert J. Skuhra wrote:
> > On Fri, 11 Jun 2021 08:00:56 +0200, "Herbert J. Skuhra" wrote:
> >> 
> >> On Fri, 11 Jun 2021 07:42:27 +0200, Matthew Grooms wrote:
> >>> 
> >>> Hey all,
> >>> 
> >>> If I build an up-to-date stable/13 arm64 kernel and type sysctl -a on
> >>> a rpi4 system, it reboots every time. I've blown away the source and
> >>> object tree multiple times and still get the same result.
> >>> 
> >>> FreeBSD generic 13.0-STABLE FreeBSD 13.0-STABLE #1
> >>> stable/13-n245932-04c4bd7f7b5: Fri Jun 11 00:09:11 CDT 2021
> >>> mgrooms_at_x.x.x:/var/rpi4/build/usr/src/arm64.aarch64/sys/GENERIC arm64
> >>> 
> >>> Has anyone else been testing stable builds recently? I'll try to build
> >>> a debug kernel and see if I can dig up more info.
> >> 
> >> I can confirm this issue: Rasperry Pi 2 (armv7), 3 and 4 (both aarch64).
> >> When booting kernel.old (from May 17th; e0f2b8aaf1ed) 'sysctl -a'
> >> doesn't crash the system.
> > 
> > The kernel from the May 27th snapshot (stable/13-n245691-024a9aa7010)
> > is OK, the one from June 3rd (13-n245852-4775325dd66) isn't.
> > 
> 
> Do you have the kernel backtrace of the resulting panic?

So far I could only get:

# sysctl net.inet.tcp.lro
Fatal data abort:
  x0: ffff000000b25820
  x1: ffff000000e4b6d8
  x2:                0
  x3: ffff0000abf7a650
  x4: ffff0000abf7a5d8
  x5:                0
  x6:                0
  x7: ffff0000abf7aaa0
  x8:                0
  x9:                0
 x10:                0
 x11:                0
 x12:                3
 x13: ffff000000e3a750
 x14:                f
 x15:                f
 x16:         4048d2e8
 x17:         403d15e4
 x18: ffff0000abf7a540
 x19: ffff000000e4b6d8
 x20: ffff0000abf7a650
 x21: ffff0000abf7a650
 x22:                0
 x23: ffff000000e4b6d8
 x24: ffff000000b8e000
 x25: ffff000000b8e000
 x26:            40800
 x27:               14
 x28:           234000
 x29: ffff0000abf7a540
  sp: ffff0000abf7a540
  lr: ffff0000004caef4
 elr: ffff00000050355c
spsr:         60000145
 far:                0
 esr:         96000006
panic: vm_fault failed: ffff00000050355c
cpuid = 1
time = 1623404572
KDB: stack backtrace:
#0 0xffff00000050d794 at kdb_backtrace+0x60
#1 0xffff0000004b9160 at vpanic+0x184
#2 0xffff0000004b8fd8 at panic+0x44
#3 0xffff0000007e86e8 at data_abort+0x1d8
#4 0xffff0000007c8874 at handle_el1h_sync+0x74
#5 0xffff0000004caef0 at sysctl_root_handler_locked+0x118
#6 0xffff0000004caef0 at sysctl_root_handler_locked+0x118
#7 0xffff0000004ca350 at sysctl_root+0x218
#8 0xffff0000004ca944 at userland_sysctl+0x18c
#9 0xffff0000004ca778 at sys___sysctl+0x68
#10 0xffff0000007e7d34 at do_el0_sync+0x498
#11 0xffff0000007c8a1c at handle_el0_sync+0x90
Uptime: 1m26s
Resetting system ... 

--
Herbert
Received on Fri Jun 11 2021 - 09:47:46 UTC

Original text of this message