Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 30 Apr 2009 15:51:59 -0400
From:      Jung-uk Kim <jkim@FreeBSD.org>
To:        freebsd-current@FreeBSD.org
Cc:        pluknet <pluknet@gmail.com>, 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:  <200904301552.03118.jkim@FreeBSD.org>
In-Reply-To: <a31046fc0904300937q6483002fy124ed918962c925c@mail.gmail.com>
References:  <20090429161626.GQ1387@albert.catwhisker.org> <49F9CD25.70102@icyb.net.ua> <a31046fc0904300937q6483002fy124ed918962c925c@mail.gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help

--Boundary-00=_jFg+JVteRvql0NH
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

--Boundary-00=_jFg+JVteRvql0NH
Content-Type: text/plain;
  charset="iso-8859-1";
  name="mp_machdep.diff"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename="mp_machdep.diff"

--- sys/amd64/amd64/mp_machdep.c	(revision 191699)
+++ sys/amd64/amd64/mp_machdep.c	(working copy)
@@ -214,6 +214,8 @@
 		else if (type == CPUID_TYPE_CORE)
 			cpu_cores = cnt;
 	}
+	if (cpu_cores == 0)
+		cpu_cores = 1;
 	if (cpu_logical == 0)
 		cpu_logical = 1;
 	cpu_cores /= cpu_logical;
--- sys/i386/i386/mp_machdep.c	(revision 191699)
+++ sys/i386/i386/mp_machdep.c	(working copy)
@@ -267,6 +267,8 @@
 		else if (type == CPUID_TYPE_CORE)
 			cpu_cores = cnt;
 	}
+	if (cpu_cores == 0)
+		cpu_cores = 1;
 	if (cpu_logical == 0)
 		cpu_logical = 1;
 	cpu_cores /= cpu_logical;

--Boundary-00=_jFg+JVteRvql0NH--



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200904301552.03118.jkim>