[Bug 232387] head -r339076: system crash in vnet_epair_init during kern_jail_set in a kyua test on powerpc64

[bugzilla-noreply at freebsd.org]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=232387

--- Comment #14 from Mark Millard <marklmi26-fbsd at yahoo.com> ---
I finally have a system-clang devel/powerpc64-binutils based build
that I've tested ( head -r345558 based, ELFv1 ABI ). Again I'm off
experimental futures. This was with a non-debug kernel.

This too fails. Running just:

kyua test -k /usr/tests/Kyuafile sys/netipsec/tunnel/aes_cbc_128_hmac_sha1

is sufficient for the crash to happen but it fails when a full
Kyua test gets there.


Again a data storage interrupt:
( Be warned: hand typed from a picture.)

exception      = 0x300 (data storage interrupt)
virtual address= 0x860ce198
dsisr          = 0x42000000
srr0           = 0xc0000000007b51a4 (0x7b51a4)
srr1           = 0x9000000000009032
current msr    = 0x9000000000009032
lr             = 0xc0000000007184a8 (0x7184a8)
frame          = 0xe00000008ecb0dd0
curthread      = 0xc00000000ad6c580
pid = 28966, comm = ifconfig
Panic: data storage interrupt trap
cpuid= 2
time = 1553886317

The frmae, curthread, pid, cpuid, and time can vary.

The backtrace information is better this time. Be warned: hand typed from
a picture. The example is from a full kyua run.

KDB: stack backtrace:
0xe000000008eb0b00: at vpanic+0x1d8
0xe000000008eb0bb0: at panic+0x44
0xe000000008eb0be0: at trap_fatal+0x2f4
0xe000000008eb0c70: at trap+0x698
0xe000000008eb0d50: at powerpc_interrupt+0x1a0
0xe000000008eb0da0: at kernel DSI write trap @ 0x860ce198
                       by lock_init+0x140:
                       srr1 = 0x9000000000009032
                       r1   = 0xe00000008ecb1050
                       cr   = 0x22880f488
                       xer  = 0
                       ctr  = 0xc000000000718438
                       r2   = 0xc000000001370000
                       sr   = 0x42000000
                       frame= 0xe00000008ecb0dd0
0xe00000008ecb1050: at
__set_sysctl_set_sym_sysctl___net_link_epair_netisr_maxqlen+0x4
0xe00000008ecb1080: at epair_modeevent+0xbc
0xe00000008ecb1140: at module_register_init+0x130
0xe00000008ecb11f0: at linker_load_module+0xd88
0xe00000008ecb1620: at kern_kldload+0x8c
0xe00000008ecb1690: at sys_kldload+0x8c
0xe00000008ecb16e0: at trap+0xb28
0xe00000008ecb17c0: at powerpc_interrupt+0x1a0
0xe00000008ecb1810: at user SC trap
                       by 0x810182da8:
                       srr1 = 0x900000000200f032
                       r1   = 0x3fffffffffffcf10
                       cr   = 0x24002200
                       xer  = 0x20000000
                       ctr  = 0x810182da0
                       r2   = 0x81033b900
                       frame= 0xe00000008ecb1840

Note: The 'at __set_sysctl_set_sym_sysctl___net_link_eapir_netisr_maxqlen+0x4'
at other times has shown text such as 'at 0xffffffc'. The kernel stack
addresses (0xe000 prefixes) can vary.

Otherwise the backtraces agree so far as I've noticed.

-- 
You are receiving this mail because:
You are the assignee for the bug.