Random Kernel Panic on Dreamplug (FS related)
Mattia Rossi
mattia.rossi.mailinglists at gmail.com
Fri Sep 26 12:19:13 UTC 2014
This might be part of the weird FFS issues the Dreamplug has and no-one
knows why they're happening.
The panic occurred while running nsd-control reload (which should simply
re-read a config file from disk). I was previously editing files without
issues.
Result is the following:
vm_fault(0xc10a0000, d0238000, 2, 0) -> 2
Fatal kernel mode data abort: 'Permission Fault (P)'
trapframe: 0xde019898
FSR=0000000f, FAR=d0238120, spsr=20000013
r0 =d0238120, r1 =00000e60, r2 =00000000, r3 =00000000
r4 =00000120, r5 =00000000, r6 =c3f3f6c0, r7 =00001000
r8 =c443e880, r9 =00000000, r10=c3d69000, r11=de019a20
r12=d0238120, ssp=de0198e8, slr=c0d53828, pc =c0de521c
[ thread pid 21116 tid 100073 ]
Stopped at memset+0x48: undge 0xa0cc20f8
db>
db> bt
Tracing pid 21116 tid 100073 td 0xc3e97000
db_trace_self() at db_trace_self
pc = 0xc0dd5418 lr = 0xc094f8a8 (db_hex2dec+0x490)
sp = 0xde0195a0 fp = 0xde0195b8
r10 = 0xc0f5e8c8
db_hex2dec() at db_hex2dec+0x490
pc = 0xc094f8a8 lr = 0xc094f260 (db_command_loop+0x300)
sp = 0xde0195c0 fp = 0xde019660
r4 = 0x00000000 r5 = 0x00000000
r6 = 0x00000000
db_command_loop() at db_command_loop+0x300
pc = 0xc094f260 lr = 0xc094efb0 (db_command_loop+0x50)
sp = 0xde019668 fp = 0xde019678
r4 = 0xc0e2dfe4 r5 = 0xc0e4402e
r6 = 0xc0f5e8b4 r7 = 0xc0ef62b8
r8 = 0xc0f52754 r9 = 0xc0f52750
r10 = 0xc3e97000
db_command_loop() at db_command_loop+0x50
pc = 0xc094efb0 lr = 0xc09519ec (X_db_symbol_values+0x250)
sp = 0xde019680 fp = 0xde0197a0
r4 = 0x00000000 r5 = 0xc0f5e8c0
r6 = 0xc0f52778
X_db_symbol_values() at X_db_symbol_values+0x250
pc = 0xc09519ec lr = 0xc0b37b08 (kdb_trap+0xc4)
sp = 0xde0197a8 fp = 0xde0197c8
r4 = 0x00000000 r5 = 0x0000000f
r6 = 0xc0f52778 r7 = 0xc0ef62b8
kdb_trap() at kdb_trap+0xc4
pc = 0xc0b37b08 lr = 0xc0de7c60 (data_abort_handler+0x7f8)
sp = 0xde0197d0 fp = 0xde0197e8
r4 = 0xde019898 r5 = 0x0000000f
r6 = 0x600000d3 r7 = 0xd0238120
r8 = 0x00000000 r9 = 0xc0f648d4
r10 = 0xc3e97000
data_abort_handler() at data_abort_handler+0x7f8
pc = 0xc0de7c60 lr = 0xc0de7a28 (data_abort_handler+0x5c0)
sp = 0xde0197f0 fp = 0xde019890
r4 = 0xc10a0000 r5 = 0x00000013
r6 = 0xde019eb0 r7 = 0x00000002
data_abort_handler() at data_abort_handler+0x5c0
pc = 0xc0de7a28 lr = 0xc0dd711c (exception_exit)
sp = 0xde019898 fp = 0xde019a20
r4 = 0xffffffff r5 = 0xffff1004
r6 = 0xc3f3f6c0 r7 = 0x00001000
r8 = 0xc443e880 r9 = 0x00000000
r10 = 0xc3d69000
exception_exit() at exception_exit
pc = 0xc0dd711c lr = 0xc0d53828 (ffs_truncate+0xaa8)
sp = 0xde0198e8 fp = 0xde019a20
r0 = 0xd0238120 r1 = 0x00000e60
r2 = 0x00000000 r3 = 0x00000000
r4 = 0x00000120 r5 = 0x00000000
r6 = 0xc3f3f6c0 r7 = 0x00001000
r8 = 0xc443e880 r9 = 0x00000000
r10 = 0xc3d69000 r12 = 0xd0238120
memset() at memset+0x48
pc = 0xc0de521c lr = 0xc0d53828 (ffs_truncate+0xaa8)
sp = 0xde0198e8 fp = 0xde019a20
Unwind failure (no registers changed)
The sad thing is, that with fsck broken for the dreamplug, I have to
re-format the disk, reinstall everything and recreate the config files
which I didn't manage to copy to a safe place beforehand :-(
Before I do that I'll leave the system in debugging mode for a few days,
in case someone can help and needs some more information.
Cheers,
Mat
More information about the freebsd-arm
mailing list