Date: Tue, 5 Sep 2006 12:30:52 -0400 From: John Baldwin <jhb@freebsd.org> To: pyunyh@gmail.com Cc: David Christensen <davidch@broadcom.com>, freebsd-current@freebsd.org, LI Xin <delphij@delphij.net> Subject: Re: Simplified Steps for Building a Loadable module on -CURRENT Message-ID: <200609051230.52827.jhb@freebsd.org> In-Reply-To: <20060902005708.GA60963@cdnetworks.co.kr> References: <09BFF2FA5EAB4A45B6655E151BBDD90301E2F278@NT-IRVA-0750.brcm.ad.broadcom.com> <200609011214.28664.jhb@freebsd.org> <20060902005708.GA60963@cdnetworks.co.kr>
next in thread | previous in thread | raw e-mail | index | archive | help
On Friday 01 September 2006 20:57, Pyun YongHyeon wrote: > On Fri, Sep 01, 2006 at 12:14:28PM -0400, John Baldwin wrote: > > On Thursday 31 August 2006 23:59, Pyun YongHyeon wrote: > > > On Thu, Aug 31, 2006 at 03:28:13PM -0400, John Baldwin wrote: > > > > On Thursday 31 August 2006 06:22, Pyun YongHyeon wrote: > > > > > On Thu, Aug 31, 2006 at 05:32:13PM +0800, LI Xin wrote: > > > > > > Pyun YongHyeon wrote: > > > > > > > On Wed, Aug 30, 2006 at 03:12:59PM -0700, David Christensen wrote: > > > > > > > > I've been able to successfully build drivers in the past as > > > > > > > > loadable modules but I'm getting some kernel panics > > with -CURRENT > > > > > > > > when installing a module using kldload now where things used to > > > > > > > > > > > > > > I wonder you encountered the same panic I have been seeing on > > CURRENT. > > > > > > > I get "Fatal trap 30" message when I load em(4) module with > > kldload. > > > > > > > > > > > > What does Fatal trap 30 mean in these places? I get some strange > > fatal > > > > > > trap 30's in acpi_cpi_idle, but I can not imagine how can these > > > > happen :-( > > > > > > > > > > > > > > > > Don't know what's cause of the panic since it used to work ok. > > > > > See > > > > > > http://lists.freebsd.org/pipermail/freebsd-current/2006-August/065243.html > > > > > > > > Trap 30 means an IDT vector fired that we didn't expect. In this case, I > > > > think it may only happen on SMP, and it maybe that the interrupt gets > > sent to > > > > > > Yes, it's SMP(i386). > > > > Can you try disabling SMP via kern.smp.disabled? > > > > Thank you. Setting kern.smp.disabled fixed the panic. s/fixed/masked/. It still needs fixing. The only thing I can think of the smp_rendezvous() change should have fixed. :( -- John Baldwin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200609051230.52827.jhb>