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

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.
>


-- 
wbr,
pluknet