Re: Easily reproducible stable/13 kernel crash

"Herbert J. Skuhra" <[email protected]>
Newsgroups gmane.os.freebsd.devel.arm
Message-ID <[email protected]>
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
> >>> [email protected]:/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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.