Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 11 Sep 2023 01:13:18 -0700
From:      Mark Millard <marklmi@yahoo.com>
To:        Current FreeBSD <freebsd-current@freebsd.org>
Cc:        freebsd-arm <freebsd-arm@freebsd.org>
Subject:   aarch64 main [so: 15] panic's in kyua's sys/net/if_lagg_test:status_stress
Message-ID:  <318444EA-B18D-4A6B-8D74-2A4276E366A8@yahoo.com>
References:  <318444EA-B18D-4A6B-8D74-2A4276E366A8.ref@yahoo.com>

next in thread | previous in thread | raw e-mail | index | archive | help
It will be some time before I can try this with
an official snapshot instead of a personal build.
The build is based on b6ce41118bb1 :

# uname -apKU
FreeBSD CA78C-WDK23-ZFS 15.0-CURRENT FreeBSD 15.0-CURRENT aarch64 =
1500000 #17 main-n265279-b6ce41118bb1-dirty: Sun Sep 10 14:36:47 PDT =
2023     =
root@CA78C-WDK23-ZFS:/usr/obj/BUILDs/main-CA78C-nodbg-clang/usr/main-src/a=
rm64.aarch64/sys/GENERIC-NODBG-CA78C arm64 aarch64 1500000 1500000

So it was a non-debug build, although I do not
strip symbols and such in my builds.

. . .
sys/net/if_lagg_test:create  ->  passed  [0.105s]
sys/net/if_lagg_test:create_destroy_stress  ->  skipped: Skipping this =
test because it easily panics the machine  [0.019s]
sys/net/if_lagg_test:lacp_linkstate_destroy_stress  ->  passed  =
[60.045s]
sys/net/if_lagg_test:set_ether  ->  passed  [0.066s]
sys/net/if_lagg_test:status_stress  -> =20

The core.txt.5 is not great, unfortunately:

panic: vm_fault failed: 0xffff0000006b96dc error 1

GNU gdb (GDB) 13.1 [GDB v13.1 for FreeBSD]
. . .
Reading symbols from /boot/kernel/kernel...
Reading symbols from /usr/lib/debug//boot/kernel/kernel.debug...

Unread portion of the kernel message buffer:
 (dump_iface + 0x2c0)
 elr: 0xffff0000006b96dc (dump_sa + 0x1c)
spsr: 0x0000000000400045
 far: 0x44572d4338374144
 esr: 0x0000000096000004
panic: vm_fault failed: 0xffff0000006b96dc error 1
cpuid =3D 2
time =3D 1694414226
KDB: stack backtrace:
db_trace_self() at db_trace_self
db_trace_self_wrapper() at db_trace_self_wrapper+0x30
vpanic() at vpanic+0x1a0
panic() at panic+0x44
data_abort() at data_abort+0x304
handle_el1h_sync() at handle_el1h_sync+0x14
--- exception, esr 0x96000004
dump_sa() at dump_sa+0x1c
dump_iface() at dump_iface+0x2bc
dump_cb() at dump_cb+0x18
if_foreach_sleep() at if_foreach_sleep+0x244
rtnl_handle_getlink() at rtnl_handle_getlink+0xec
rtnl_handle_message() at rtnl_handle_message+0x19c
nl_taskqueue_handler() at nl_taskqueue_handler+0x674
taskqueue_run_locked() at taskqueue_run_locked+0x194
taskqueue_thread_loop() at taskqueue_thread_loop+0xcc
fork_exit() at fork_exit+0x88
fork_trampoline() at fork_trampoline+0x14
KDB: enter: panic

get_curthread () at /usr/main-src/sys/arm64/include/pcpu.h:77
77              __asm __volatile("ldr   %0, [x18]" : "=3D&r"(td));
(kgdb) #0  get_curthread () at /usr/main-src/sys/arm64/include/pcpu.h:77
#1  doadump (textdump=3D0, textdump@entry=3D4003518992)
    at /usr/main-src/sys/kern/kern_shutdown.c:405
#2  0xffff0000000f7704 in db_dump (dummy=3D<optimized out>,      =
dummy2=3D<optimized out>, dummy3=3D<optimized out>, dummy4=3D<optimized =
out>)
    at /usr/main-src/sys/ddb/db_command.c:591
#3  0xffff0000000f74e0 in db_command (last_cmdp=3D<optimized out>,      =
cmd_table=3D<optimized out>, dopager=3Dtrue)
    at /usr/main-src/sys/ddb/db_command.c:504
#4  0xffff0000000f71b8 in db_command_loop ()
    at /usr/main-src/sys/ddb/db_command.c:551
#5  0xffff0000000fad9c in db_trap (type=3D<optimized out>, =
code=3D<optimized out>)
    at /usr/main-src/sys/ddb/db_main.c:268
#6  0xffff0000004f4ec4 in kdb_trap (type=3D60, code=3D0, tf=3D<optimized =
out>)
    at /usr/main-src/sys/kern/subr_kdb.c:790
#7  <signal handler called>
#8  <signal handler called>
#9  <signal handler called>
#10 <signal handler called>
#11 <signal handler called>
#12 <signal handler called>
#13 <signal handler called>
#14 <signal handler called>
#15 <signal handler called>
#16 <signal handler called>
#17 <signal handler called>
#18 <signal handler called>
#19 <signal handler called>
#20 <signal handler called>
#21 <signal handler called>
#22 <signal handler called>
Backtrace stopped: Cannot access memory at address 0x10
(kgdb)=20


So some transcribing of a picture in order to
show register values that were reported:

Fatal data abort:
    x0: 0xffff000leea0e7f0 (_DYNAMIC * 0x6d816648)
    x1: 0x0000000000000001
    x2: 0x44572d4338374143
    x3: 0xffff0000005d3f90 (ifdead_ioctl + 0x0)
    x4: 0xffffa00b7f0d185e
    x5: 0xffffa0023fe4b992
    x6: 0x000000006767616c
    x7: 0x00706174016f7575
    x8: 0x00000000000001a4
    x9: 0x0000000000210005
   x10: 0=C3=970000000000000800
   x11: 0xfefefefefefefeff
   x12: 0x0000000000000008
   x13: 0x0000000000000000
   x14: 0x00000000000000ff
   x15: 0x0000000000000700
   x16: 0x0000000000000008
   x17: 0x0000000000000007
   x18: 0xffff0001eea0e500 (_DYNAMIC + 0x6d816358)
   x19: 0xffff000leea0e7f0 (_DYNAMIC * 0x6d816648)
   x=EF=BB=BF20: 0xffffa00b7f0d1800
   x21: 0xffffa00b7f0d1858
   x22: 0x000000000000000c
   x23: 0X0000000000000005
   x24: 0=C3=970000000000000000
   x25: 0xffff000000c68000 (sysctl___kern_features_netlink + 0x10)
   x26: 0x0000000000000000
   x27: 0xffff000000ce9000 (cap_linkat_source_rights + 0x8)
   x28: 0xffff0000006bb0a0 (dump_cb + 0x0)
   x29: 0xffff0001eea0e520 (_DYNAMIC + 0x6d816378)
    sp: 0xffff0001eea0e500
    lr: 0xffff0000006b8fe0 (dump_iface + 0x2c0)
   elr: 0xffff0000006b96dc (dump_sa + 0x1c)
  spsr: 0x0000000000400045
   far: 0x44572d4338374144
   esr: 0x0000000096000004
panic: m_fault failed: 0xffff0000006b96dc error 1

I expect that this is similar to reports I'd made
back in 14.0-CURRENT days. As I remember, snapshot
builds of the time also got the panic.

I will note that an earlier 14.0-BETA1 snapshot
kernel test run did not panic at this point in the
sequence (or at any point). But I do not know how
repeatable the panics are in the various contexts.

I'll note that I've tried to have the various ports
installed (poudriere built) that are listed at:

=
https://github.com/freebsd/freebsd-ci/blob/master/scripts/build/build-test=
_image-head.sh#L69-L84

(The ones that build for aarch64, anyway.)

I had in /etc/kyua/kyua.conf :

test_suites.FreeBSD.disks =3D '/dev/md0 /dev/md1 /dev/md2 /dev/md3 =
/dev/md4 /dev/md5'

and used:

# more ~/prekyua-aarch64-mdconfig.sh=20
#! /bin/sh
truncate -s 4g /var/tmp/for-md0.dat
truncate -s 4g /var/tmp/for-md1.dat
truncate -s 4g /var/tmp/for-md2.dat
truncate -s 4g /var/tmp/for-md3.dat
truncate -s 4g /var/tmp/for-md4.dat
truncate -s 4g /var/tmp/for-md5.dat
mdconfig -f /var/tmp/for-md0.dat -u md0
mdconfig -f /var/tmp/for-md1.dat -u md1
mdconfig -f /var/tmp/for-md2.dat -u md2
mdconfig -f /var/tmp/for-md3.dat -u md3
mdconfig -f /var/tmp/for-md4.dat -u md4
mdconfig -f /var/tmp/for-md5.dat -u md5

I also did a:

# kldload linux64

before doing:

# /usr/bin/kyua test -k /usr/tests/Kyuafile

(Not true of linux64.ko in 14.0-CURRENT days.)


=3D=3D=3D
Mark Millard
marklmi at yahoo.com




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?318444EA-B18D-4A6B-8D74-2A4276E366A8>