Date: Sat, 4 May 2013 15:44:37 -0700 From: Tim Kientzle <tim@kientzle.com> To: Tim Kientzle <tim@kientzle.com> Cc: freebsd-arm@freebsd.org Subject: Re: Is this related to the general panic discussed in freebsd-current? Message-ID: <6D0E82C9-79D1-4804-9B39-3440F99AA8FE@kientzle.com> In-Reply-To: <CCABA43A-6D7E-4310-9F68-AEE54C88F431@kientzle.com> References: <51835891.4050409@thieprojects.ch> <03971BD1-4ADE-4435-BDD0-B94B62634F1D@bsdimp.com> <5183BF8C.4040406@thieprojects.ch> <CCABA43A-6D7E-4310-9F68-AEE54C88F431@kientzle.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On May 4, 2013, at 2:41 PM, Tim Kientzle wrote: >=20 > On May 3, 2013, at 6:45 AM, Werner Thie wrote: >=20 >> On 5/3/13 3:13 PM, Warner Losh wrote: >>> On May 3, 2013, at 12:26 AM, Werner Thie wrote: >>>=20 >>>> Hi all >>>>=20 >>>> just came around yesterday to start playing with crochet, built an = image and KDB entering panic when booting >>>>=20 >>>> FreeBSD 10.0-CURRENT #0 r250144M: Thu May 2 10:10:20 CEST 2013 >>>> = root@xtools:/usr/home/wthie/proj/crochet-freebsd/work/obj/arm.armv6/usr/lo= cal/src/sys/BEAGLEBONE arm >>>> FreeBSD clang version 3.3 (trunk 178860) 20130405 >>>> WARNING: WITNESS option enabled, expect reduced performance. >>>> panic: acquiring blockable sleep lock with spinlock or critical = section held (rw) pmap pv global @ = /usr/local/src/sys/arm/arm/pmap-v6.c:1187 >>>> KDB: enter: panic >>>> [ thread pid 0 tid 0 ] >>>> Stopped at $d: ldrb r15, [r15, r15, ror r15]! >=20 > I think I've managed to isolate this to the stack_capture function in = sys/arm/arm/stack_machdep.c. >=20 > Here's the breadcrumb trail I've followed so far: >=20 > 1. Witness is complaining about pmap_fault_fixup trying to acquire the = "pmap pv global" lock before it dies. >=20 > 2. Inserted printfs, found that pmap_fault_fixup was being called from = data_abort_handler (in sys/arm/arm/trap.c). >=20 > 3. Uncommenting the printf in data_abort_handler gives the next step: >=20 > data abort: fault address=3D0xe28db008 (from pc=3D0xc0519d08 = lr=3D0xc0519d14) >=20 > 4. According to objdump, the PC address above is in stack_save = (actually, the inlined version of stack_capture), in = sys/arm/arm/stack_machdep.c. >=20 > If I add a printf() to the middle of stack_capture, the kernel boots. = So it definitely smells like a code-generation error of some sort. >=20 > I'm going to start digging through the assembly next. I'm baffled. If I insert a printf into the loop in stack_capture, the = kernel boots. But the generated assembly looks perfectly correct to me in either case. So inserting the printf must have some side-effect. The stack does end up aligned differently: The failing version puts 16 = bytes on the stack, the working version puts 24 bytes. But I can't figure out = how that would explain what I'm seeing... Tim
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?6D0E82C9-79D1-4804-9B39-3440F99AA8FE>