Date: Fri, 1 May 2009 00:25:57 +0400 From: pluknet <pluknet@gmail.com> To: Jung-uk Kim <jkim@freebsd.org> Cc: freebsd-current@freebsd.org, Andriy Gapon <avg@icyb.net.ua>, Scott Ullrich <sullrich@gmail.com> Subject: Re: Panic "Fatal trap 18: integer divide fault while in kernel mode" Message-ID: <a31046fc0904301325p6218e7ccxf68d4087484cd569@mail.gmail.com> In-Reply-To: <200904301552.03118.jkim@FreeBSD.org> References: <20090429161626.GQ1387@albert.catwhisker.org> <49F9CD25.70102@icyb.net.ua> <a31046fc0904300937q6483002fy124ed918962c925c@mail.gmail.com> <200904301552.03118.jkim@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
2009/4/30 Jung-uk Kim <jkim@freebsd.org>: > On Thursday 30 April 2009 12:37 pm, pluknet wrote: >> 2009/4/30 Andriy Gapon <avg@icyb.net.ua>: >> > on 30/04/2009 18:58 David Wolfskill said the following: >> >> On Thu, Apr 30, 2009 at 06:35:32PM +0300, Andriy Gapon wrote: >> >>> on 30/04/2009 18:18 David Wolfskill said the following: >> >>>> On Wed, Apr 29, 2009 at 09:16:26AM -0700, David Wolfskill > wrote: >> >>>>> Is there anything of use I might get from DDB? >> >>>> >> >>>> I can still poke around there for a bit, if that would be >> >>>> useful. >> >>> >> >>> In general the stack trace[*] should be provided at the very >> >>> least, otherwise people have hard figuring out where the >> >>> problem occurred, so right people may just not notice a report. >> >> >> >> Sorry; it happened so quickly, I wasn't at all certain there >> >> would be enough to show: >> >> >> >> db> bt >> >> Tracing pid 0 tid 100000 td 0xc0d43610 >> >> cpu_topo(2,c1420d34,c081ff07,c1420d58,c0820042,...) at >> >> cpu_topo+0x43 smp_topo(c0804378,2,c4145a5c,fffffff,0,...) at >> >> smp_topo+0x10b >> >> sched_setup(0,141ec00,141ec00,141e000,1425000,...) at >> >> sched_setup+0x1a mi_startup() at mi_startup+0x96 >> >> begin() at begin+0x2c >> > >> > My guess is that (cpu_cores * cpu_logical) somehow equals to >> > zero. >> >> That was masked earlier by additional checks on zero, >> and now that routine moved to the separate function >> (and to separate call path from subr_smp.c:mp_start() >> which seems not to be called). >> >> > Have you by a chance saved this crash dump? >> > I think that t would be interesting to look at it in kgdb. > > Please try the attached patch. > > Jung-uk Kim > The strange thing is why cpu_mp_start() is called at all in case when there is only one CPU in system. It should early return in mp_start(). (I saw two reports and both of them were UP systems). -- wbr, pluknet
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?a31046fc0904301325p6218e7ccxf68d4087484cd569>