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
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:46 UTC