From owner-freebsd-current Sun Sep 10 21:40: 5 2000 Delivered-To: freebsd-current@freebsd.org Received: from pike.osd.bsdi.com (pike.osd.bsdi.com [204.216.28.222]) by hub.freebsd.org (Postfix) with ESMTP id 79AA237B42C for ; Sun, 10 Sep 2000 21:40:00 -0700 (PDT) Received: (from jhb@localhost) by pike.osd.bsdi.com (8.9.3/8.9.3) id VAA32934; Sun, 10 Sep 2000 21:39:28 -0700 (PDT) (envelope-from jhb) From: John Baldwin Message-Id: <200009110439.VAA32934@pike.osd.bsdi.com> Subject: Re: New Fatal trap in Current SMP (random.dev changes ??) In-Reply-To: from Boris Popov at "Sep 11, 2000 11:37:34 am" To: Boris Popov Date: Sun, 10 Sep 2000 21:39:28 -0700 (PDT) Cc: Manfred Antar , current@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL68 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Boris Popov wrote: > On Sun, 10 Sep 2000, John Baldwin wrote: > > > > I think the random dev kicks in at this point > > > > > > Fatal trap 12: page fault while in kernel mode > > > cpuid = 1; lapic.id = 0c000000 > > > fault virtual address = 0x2c > > > fault code = supervisor read, page not present > > > instruction pointer = 0x8:0xc014f280 > > > stack pointer = 0x10:0xc9a74f84 > > > frame pointer = 0x10:0xc9a74f9c > > > code segment = base 0x0, limit 0xfffff, type 0x1b > > > = DPL 0, pres 1,def 32 1,gran 1 > > > processor flags = interrupt enabled, resume, IOPL = 0 > > > current process = 2 (random) > > > trap number = 12 > > > panic: page fault > > > cpuid = 1; lapic.id = 0x000000 > > > boot() called on cpu#1 > > > > > > syncing disks....... > > > > > > The machine then is frozen and needs a reset to work again > > > the debugger is unavailable > > > > ddb works fine here with this new trap, but I can't get remote gdb to work > > to save my life. I think that remote gdb must not like me or something. > > Yes, after trap is occured ddb works. But it is impossible to > continue from ddb because after typing 'c' machine becomes frozen. > The same thing occur after any other panic (this is with SMP kernel). It only does this in cases when the sched_lock is held by the CPU that traps. If the trapping CPU does not hold sched_lock when it faults, then you can do continue and steps as normal. I _think_ that maybe having the debugger release sched_lock when it enters the debugger and acquire it on the way out would work, but I'm not sure, and I haven't explored all the interactions of that yet. > -- > Boris Popov > http://www.butya.kz/~bp/ -- John Baldwin -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.cslab.vt.edu/~jobaldwi/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message