Compilation x11/libX11 fails with panic
Zbigniew Bodek
zbb at freebsd.org
Wed Nov 19 23:15:23 UTC 2014
2014-11-19 14:00 GMT+01:00 Ulrich Grey <usenet at ulrich-grey.de>:
> 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)'
>
Hello,
I'm a little confused now. Could you please clarify whether crashes
occur exclusively when superpages are enabled or when you disable
superpages you also observe system failures?
Best regards
zbb
> 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> d d u u 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
>>
>>
> _______________________________________________
> freebsd-arm at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-arm
> To unsubscribe, send any mail to "freebsd-arm-unsubscribe at freebsd.org"
More information about the freebsd-arm
mailing list