From owner-freebsd-smp Wed Jan 3 22: 1:34 2001 From owner-freebsd-smp@FreeBSD.ORG Wed Jan 3 22:01:31 2001 Return-Path: Delivered-To: freebsd-smp@freebsd.org Received: from io.yi.org (cr66388-a.rchrd1.on.wave.home.com [24.114.165.24]) by hub.freebsd.org (Postfix) with ESMTP id ADF2337B400 for ; Wed, 3 Jan 2001 22:01:30 -0800 (PST) Received: from io.yi.org (localhost.gvcl1.bc.wave.home.com [127.0.0.1]) by io.yi.org (Postfix) with ESMTP id 1D055BA7D; Thu, 4 Jan 2001 00:56:45 -0500 (EST) X-Mailer: exmh version 2.1.1 10/15/1999 To: "Thomas D. Dean" Cc: freebsd-smp@FreeBSD.ORG Subject: Re: Continuing Fatal Trap 12 In-Reply-To: Message from "Thomas D. Dean" of "Wed, 03 Jan 2001 19:08:00 PST." <200101040308.f04380L00892@celebris.tddhome> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 04 Jan 2001 00:56:44 -0500 From: Jake Burkholder Message-Id: <20010104055645.1D055BA7D@io.yi.org> Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > I tried -current SMP as of early this AM, PST. > > I still have the fatal trap 12 problem. I can generate it with a max > of three transactions to lpd. > > The current process is (irq7: lpt0). trace shows only _end() and > fork_trampoline. I posted the output of DDB a week ago. > > I have: > options DDB > options INVARIANT_SUPPORT > options INVARIANTS > options WITNESS > options KTRACE > > How can I produce a stack trace, etc., so I can help find this problem? Hi, I don't own a printer so its difficult for me to help, but having browsed the driver source there are a couple things that might be useful. I think you said before you can print fine with a uni-processor kernel, is that correct? Please send me the output of dmesg. Sorry if you posted it before, I can't find it. If you have a serial console, please compile a kernel with LPT_DEBUG, save the console messages to a file and send them to me. Include everything from the initial boot messages. To turn on the debugging go into /sys/dev/ppbus/lpt.c and add the line #define LPT_DEBUG anywhere in the file. Compile a new kernel and print stuff till it crashes. It will probably generate huge amounts of output. A possible workaround is to try to force the driver to use polling mode, since its crashing in the interrupt thread. To do this go into lpt.c again and make the following changes: --- lpt.c Thu Dec 7 17:33:12 2000 +++ lpt.c.hack Thu Jan 4 00:46:41 2001 @@ -394,6 +394,7 @@ /* retrieve the ppbus irq */ BUS_READ_IVAR(ppbus, dev, PPBUS_IVAR_IRQ, &irq); +#if 0 if (irq > 0) { /* declare our interrupt handler */ sc->intr_resource = bus_alloc_resource(dev, SYS_RES_IRQ, @@ -403,9 +404,12 @@ sc->sc_irq = LP_HAS_IRQ | LP_USE_IRQ | LP_ENABLE_IRQ; device_printf(dev, "Interrupt-driven port\n"); } else { +#endif sc->sc_irq = 0; device_printf(dev, "Polled port\n"); +#if 0 } +#endif lprintf(("irq %x %x\n", irq, sc->sc_irq)); lpt_release_ppbus(dev); It should say "Polled port" in dmesg instead of "Interrupt-driven port". Compile a new kernel and print some more stuff. The console output of a print job in polled mode with LPT_DEBUG enabled would also be helpful. This should work, but as I said I can't test it. Thanks Jake To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message