From owner-freebsd-current Fri Jan 12 18:56:18 2001 Delivered-To: freebsd-current@freebsd.org Received: from meow.osd.bsdi.com (meow.osd.bsdi.com [204.216.28.88]) by hub.freebsd.org (Postfix) with ESMTP id 5F03137B400 for ; Fri, 12 Jan 2001 18:56:00 -0800 (PST) Received: from laptop.baldwin.cx (john@jhb-laptop.osd.bsdi.com [204.216.28.241]) by meow.osd.bsdi.com (8.11.1/8.9.3) with ESMTP id f0D2tD147465; Fri, 12 Jan 2001 18:55:13 -0800 (PST) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <18670.979354005@winston.osd.bsdi.com> Date: Fri, 12 Jan 2001 18:55:59 -0800 (PST) From: John Baldwin To: Jordan Hubbard Subject: RE: Anybody else seeing a broken /dev/lpt with SMP on -current? Cc: current@FreeBSD.org Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 13-Jan-01 Jordan Hubbard wrote: > I've actually been seeing this for about 2 months now but only just > now got motivated enough to enable crashdumps and get some information > on what happens whenver I try to use the printer attached to my (sadly :) > -current SMP box: > > IdlePTD 3682304 > initial pcb at 2e70e0 > panicstr: page fault > panic messages: > --- > Fatal trap 12: page fault while in kernel mode > cpuid = 0; lapic.id = 00000000 > fault virtual address = 0xffff8640 > fault code = supervisor write, page not present > instruction pointer = 0x8:0xc8dc8676 > stack pointer = 0x10:0xc8280f88 > frame pointer = 0x10:0xc8280f9c > code segment = base 0x0, limit 0xfffff, type 0x1b > = DPL 0, pres 1, def32 1, gran 1 > processor eflags = interrupt enabled, resume, IOPL = 0 > current process = 12322 (irq7: lpt0) > trap number = 12 > panic: page fault > cpuid = 0; lapic.id = 00000000 > boot() called on cpu#0 > > If anybody wants a fuller traceback then I'll compile up a kernel with > debugging symbols, but it's going to be pretty sparse anyway since it > basically only shows the trap() from the page fault and the subsequent > panic. All the other traces show the kerenl having returned to an address that is beyongd the end of the kernel (which causes the page fault) meaning that the stack is fubar'd, so the trace isn't meaningful anyways. :( Knowing how and why the lpd interrupt handler trashes the stack is the useful info, and with teh stack already trashed, I don't know of an easy way to figure that out. Suggestions welcome. > - Jordan -- John Baldwin -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/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