Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 6 Jan 2016 16:30:03 -0800
From:      Bryan Drewery <bdrewery@FreeBSD.org>
To:        current@freebsd.org
Subject:   Re: Panic in ld_ldt() @r292914 (amd64) -- just after launching CPUs
Message-ID:  <568DB18B.4050002@FreeBSD.org>
In-Reply-To: <20151230142528.GD3625@kib.kiev.ua>
References:  <20151230135407.GH1222@albert.catwhisker.org> <20151230142528.GD3625@kib.kiev.ua>

next in thread | previous in thread | raw e-mail | index | archive | help
On 12/30/15 6:25 AM, Konstantin Belousov wrote:
> On Wed, Dec 30, 2015 at 05:54:07AM -0800, David Wolfskill wrote:
>> Found this on both my build machine and my laptop, each of which just
>> built head @r292914 (while running r292864 during the build) -- e.g.:
>>
>> FreeBSD g1-252.catwhisker.org 11.0-CURRENT FreeBSD 11.0-CURRENT #287  r292864M/292864:1100092: Tue Dec 29 05:01:42 PST 2015     root@g1-252.catwhisker.org:/common/S4/obj/usr/src/sys/CANARY  amd64
>>
>> Unfortunately, the panic occurs early enough that I can't get a crash
>> dump (I'm don't think the swap device has yet been discovered), and
>> serial console isn't working for my build machine.
>>
>> I took some screen shots of the laptop, but I don't seem to be able
>> to connect the phone to the laptop in a way to allow data interchange,
>> so I'll try to hand-transcribe the more obviously-relevant bits:
>>
>> ...
>> SMP: AP CPU #5 Launched!
>> kernel trap 9 with interrupts disabled
>>
>> Fatal trap 9: general protection fault while in kernel mode
>> cpuid = 6; apic id = 86
>> instruction pointer	= 0x28:0xffffffff80d9b505
>> stack pointer		= 0x28:0xfffffe06015ca8f0
>> frame pointer		= 0x28:0xfffffe06015ca950
>> code segment		= base 0x0, limit 0xfffff, type 0x1b
>> 			= DPL 0, pres 1, long 1, def32 0, gran 1
>> processor eflags	= resume, IOPL = 0
>> current process		= 11 (idle: cpu6)
>> [ thread pid 11 tid 100010 ]
>> Stopped at	0xffffffff80d9b505 = ld_ldt:	lldt	%ax
>> db> bt
>> Tracing pid 11 tid 100010 td 0xfffff800067f69a0
>> ld_ldt() at 0xffffffff80d9b505 = ld_ldt/frame 0xfffffe06015ca900
>> sched_switch() at 0xffffffff80a176c5 = sched_switch+0x495/frame 0xfffffe06015ca950
>> mi_switch() at 0xffffffff809f8759 = mi_switch+0x169/frame 0xfffffe06015ca980
>> sched_idletd() at 0xffffffff80a1a211 = sched_idletd+0x391/frame 0xfffffe06015caa70
>> fork_exit() at 0xffffffff809b5324 = fork_exit+0x84/frame 0xfffffe06015aab0
>> fork_trampoline() at 0xffffffff80d9eade = fork_trampoline+0xe/frame 0xfffffe06015caab0
>> --- trap 0, rip = 0, rsp = 0, rpb = 0 ---
>> db> 
>>
>> I'm happy to try testing, but as I actually use the laptop for
>> day-to-day activities, I'm likely to need to do some priority-shifting.
>>
> 
> Try clean build first.  struct proc layout was changed recently, and the
> instruction at ld_ldt would fault if using the wrong offsets.

This sounds like another incremental build bug.  The last one David
reported I was unable to figure out.  I'll look at this one soon.


-- 
Regards,
Bryan Drewery



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?568DB18B.4050002>