Panic "Fatal trap 18: integer divide fault while in kernel mode"

[pluknet]

2009/4/30 Jung-uk Kim <jkim at freebsd.org>:
> On Thursday 30 April 2009 12:37 pm, pluknet wrote:
>> 2009/4/30 Andriy Gapon <avg at 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