Compilation x11/libX11 fails with panic
Ulrich Grey
usenet at ulrich-grey.de
Wed Nov 19 13:01:05 UTC 2014
After the last crash the system compiled
editors/texworks without problems (uptime ca. 18 hours)
with superpages disabled:
root at quad:/usr/home/gwgpi # sysctl vm.pmap.
vm.pmap.sp_enabled: 0
vm.pmap.pv_entry_count: 10917
vm.pmap.pv_entry_max: 1744848
vm.pmap.shpgperproc: 200
vm.pmap.section.demotions: 0
vm.pmap.section.mappings: 0
vm.pmap.section.p_failures: 0
vm.pmap.section.promotions: 0
root at quad:/usr/home/gwgpi #
In the following I have done:
make -j10 buildworld in /usr/src
The system crashes after ca. 1 hour.
I tryed to get a coredump, but that did not work:
vm_fault(0xc75dc4f0, 0, 1, 0) -> 0
Fatal kernel mode data abort: 'Translation Fault (P)'
trapframe: 0xfb289cb0
FSR=00000017, FAR=00000008, spsr=200000d3
r0 =00000000, r1 =00000001, r2 =000000ac, r3 =000000ac
r4 =fb289d94, r5 =00000000, r6 =00000000, r7 =00000014
r8 =000006c0, r9 =c25ab8c0, r10=0000
0
0v0m0_,f aru1l1t=(f0bx2c8295db8906
5
8r,1 20=,c 215,b 90b)5 0-,> s0s
p
=Ffabt2a8l9 dk0e0r,n esll rm=ocd2e4 6dda1tfac ,a bpocr t=:c
2'1T6r1afnes0l a
t
i
on Fault (P)'
trapframe: 0xf4920d40
FSR=00000017, FAR=00000000, spsr=600001d3
r0 =00000000, r1 =00000001, r2 =c6f64680, r3 =c25ab8d0
r4 =00000000, r5 =c6f64680, r6 =0000000b, r7 =00000000
r8 =c25ba41c, r9 =c6f64680, r10=c6f64990, r11=f4920de0
r12=00000001, ssp=f4920d94, slr=c21d09ac, pc =c2187f84
timeout stopping cpus
[ thread pid 87965 tid 100174 ]
Stopped at $a+0x148: ldr r1, [r0, #0x008]
db> timeout stopping cpus
[ thread pid 11 tid 100007 ]
Stopped at thread_lock_block+0xc: ldr r1, [r0]
db> d
db> qum
No such command
db> p
c2187f84
db> u
Ambiguous
db> dputm
No such command
db> p[A
c2187f84
db>
c2187f84
db> [A [ [A [ [A
Bad character
?
db>
c218c72f8148
7
f8d4b
>
db> q
No such command
db> cpasl la udxo
No such command
db> adduummpp
No such command
db>
d
Not set.
db> duummpp
No such command
db>
Not set.
db> dd uu m
vm_fault(0xc25b9658, 0, 1, 0) -> 0
Fatal kernel mode data abort: 'Translation Fault (P)'
trapframe: 0xf4920d40
FSR=00000017, FAR=00000000, spsr=600001d3
r0 =00000000, r1 =00000001, r2 =c6f64680, r3 =c25ab8d0
r4 =00000000, r5 =c6f64680, r6 =0000000b, r7 =00000000
r8 =c25ba41c, r9 =c6f64680, r10=c6f64990, r11=f4920de0
r12=00000001, ssp=f4920d94, slr=c21d09ac, pc =c2187f84
panic: Fatal abort
cpuid = 0
KDB: stack backtrace:
db_trace_self() at db_trace_self
pc = 0xc246968c lr = 0xc20435f0 (db_trace_self_wrapper+0x30)
sp = 0xf4920b00 fp = 0xf4920c18
r10 = 0xc6f64680
db_trace_self_wrapper() at db_trace_self_wrapper+0x30
pc = 0xc20435f0 lr = 0xc21e3d14 (kdb_backtrace+0x38)
sp = 0xf4920c20 fp = 0xf4920c28
r4 = 0xc25ad634 r5 = 0xc24e1e8a
r6 = 0x00000001 r7 = 0xc259e310
kdb_backtrace() at kdb_backtrace+0x38
pc = 0xc21e3d14 lr = 0xc219f68c (panic+0x124)
sp = 0xf4920c30 fp = 0xf4920c50
r4 = 0x00000100
panic() at panic+0x124
pc = 0xc219f68c lr = 0xc24814e0 ($d)
sp = 0xf4920c68 fp = 0xf4920c80
r4 = 0xf4920d40 r5 = 0x00000017
r6 = 0x600001d3 r7 = 0x00000000
r8 = 0xf4920d40 r9 = 0x00000017
r10 = 0x00000000
$d() at $d
pc = 0xc24814e0 lr = 0xc248127c (data_abort_handler+0x560)
sp = 0xf4920c88 fp = 0xf4920d38
r4 = 0x00000013 r5 = 0xc6f64680
r6 = 0xf4920eb0 r7 = 0x00000000
data_abort_handler() at data_abort_handler+0x560
pc = 0xc248127c lr = 0xc246b44c (exception_exit)
sp = 0xf4920d40 fp = 0xf4920de0
r4 = 0x00000000 r5 = 0xc6f64680
r6 = 0x0000000b r7 = 0x00000000
r8 = 0xc25ba41c r9 = 0xc6f64680
r10 = 0xc6f64990
exception_exit() at exception_exit
pc = 0xc246b44c lr = 0xc21d09ac (sched_switch+0x3fc)
sp = 0xf4920d94 fp = 0xf4920de0
r0 = 0x00000000 r1 = 0x00000001
r2 = 0xc6f64680 r3 = 0xc25ab8d0
r4 = 0x00000000 r5 = 0xc6f64680
r6 = 0x0000000b r7 = 0x00000000
r8 = 0xc25ba41c r9 = 0xc6f64680
r10 = 0xc6f64990 r12 = 0x00000001
thread_lock_block() at thread_lock_block+0xc
pc = 0xc2187f84 lr = 0xc21aa4b4 (mi_switch+0x12c)
sp = 0xf4920de8 fp = 0xf4920e00
r4 = 0x00000000
mi_switch() at mi_switch+0x12c
pc = 0xc21aa4b4 lr = 0xc21662a4 (ithread_loop+0x18c)
sp = 0xf4920e08 fp = 0xf4920e38
r4 = 0xc6e19eb0 r5 = 0xc6f64680
r6 = 0xc6e39900 r7 = 0xc6e39970
r8 = 0xc256aaf0 r9 = 0x00000000
ithread_loop() at ithread_loop+0x18c
pc = 0xc21662a4 lr = 0xc216245c (fork_exit+0xa4)
sp = 0xf4920e40 fp = 0xf4920e58
r4 = 0xc6f64680 r5 = 0xc6f62000
r6 = 0xc2166118 r7 = 0xc6e19eb0
r8 = 0xf4920e60 r9 = 0x00000000
r10 = 0x00000000
fork_exit() at fork_exit+0xa4
pc = 0xc216245c lr = 0xc246b3dc (swi_exit)
sp = 0xf4920e60 fp = 0x00000000
r4 = 0xc2166118 r5 = 0xc6e19eb0
r6 = 0x00000000 r7 = 0x00000000
r8 = 0x00000000
swi_exit() at swi_exit
pc = 0xc246b3dc lr = 0xc246b3dc (swi_exit)
sp = 0xf4920e60 fp = 0x00000000
Uptime: 19h16m19s
panicA:ft eUnr de42f iniends triunscttiruocnsti o(n0 ilnoa kdser,n e0l
s.t o
r
ecsp)u,
i
d [ = t1h
r
eUadpt ipmied: 1 11 9thi16dm 1190s0
0
07 ]
Stopped at thread_lock_block+0x4c: ldmea r13!,
{r4, r11, r15}
db> p
c2187fc4
db>
c2187fc4
db> panic
panic: from debugger
cpuid = 0
KDB: enter: panic
After 42 instructions (0 loads, 0 stores),
[ thread pid 11 tid 100007 ]
Stopped at $d: ldrb r15, [r15, r15, ror r15]!
db> dump
Physical memory: 2040 MB
Dumping 145 MB:
----------------------------------------------------------------
On Tue, 18 Nov 2014 11:27:28 -0700
Ian Lepore <ian at FreeBSD.org> wrote:
> On Tue, 2014-11-18 at 19:16 +0100, Ulrich Grey wrote:
> > I am trying to compile x11/libX11 with a Wandboard-Quad:
> >
> > FreeBSD 11.0-CURRENT #0 r274634M: Tue Nov 18 00:44:36 UTC 2014
> > gwgpi at quad:/usr/local/DEVEL/obj/usr/local/DEVEL/SRC/head/sys/WANDBOARD-QUAD
> > arm
> > FreeBSD clang version 3.4.1 (tags/RELEASE_34/dot1-final 208032)
> > 20140512 CPU: Cortex A9-r2 rev 10 (Cortex-A core)
> > Supported features: ARM_ISA THUMB2 JAZELLE THUMBEE ARMv4
> > Security_Ext
> >
> > The compilation fails with this message:
> >
> > --- XKBGeom.lo
> > --- CC
> > XKBGeom.lo
> > --- XKBSetGeom.lo
> > --- CC
> > XKBSetGeom.lo <jemalloc>: jemalloc_arena.c:600: Failed assertion:
> > "arena_mapbits_unzeroed_get(chunk, i) == unzeroed"
> [...]
>
> I'm curious whether the workaround mentioned recently by Jurgen Weiss
> also works for you, that is, setting:
>
> vm.pmap.sp_enabled=0
>
> in loader.conf or using sysctl. It's not a fix of course, but it
> might help you make progress, and it would be a clue where we should
> start looking for trouble.
>
> -- Ian
>
>
More information about the freebsd-arm
mailing list