Kernel panic on PowerEdge 1950 under certain stress load

[Benjie Chen]

Sorry to waste your time. I discovered a similar PR with unp_gc and there
may be a patch already. I will see if that works.

Thanks,
Benjie


On 9/26/07, Benjie Chen <benjie at addgene.org> wrote:
>
> We got this bt after setting kernel dump stuff up. For some reason kgdb
> did not find debugging symbols, even though the kernel was compiled with -g.
> Hopefully this helps and I will go dig some more to find why we don't have a
> debug symbol.
>
> #0  0xc0674fae in doadump ()
> #1  0xc067550a in boot ()
> #2  0xc0675831 in panic ()
> #3  0xc088e29c in trap_fatal ()
> #4  0xc088da0e in trap ()
> #5  0xc0879d4a in calltrap ()
> #6  0xc066c731 in _mtx_lock_sleep ()
> #7  0xc06bba96 in unp_gc ()
> #8  0xc06961b3 in taskqueue_run ()
> #9  0xc0696696 in taskqueue_thread_loop ()
> #10 0xc065ec4d in fork_exit ()
> #11 0xc0879dac in fork_trampoline ()
>
>
>
>
> On 9/24/07, Ivan Voras <ivoras at freebsd.org> wrote:
> >
> > On 24/09/2007, Benjie Chen <benjie at addgene.org> wrote:
> > > Ivan and Kris,
> > >
> > > I will try to get a kernel trace -- it may not happen for awhile since
> > I am
> > > not in the office and working remotely for awhile so it may not be
> > easy to
> > > get a trace... but I will check.
> >
> > It's fairly easy:
> >
> > 1) add lines like the following in rc.conf:
> > dumpdev="/dev/amrd0s1b"
> > dumpdir="/storage1/crashdumps"
> >
> > (dumpdev is your swap partition, which must be larger than your RAM,
> > dumpdir is where the crash dumps will be saved, also needs to be
> > larger than RAM)
> >
> > 2) add these lines to sysctl.conf:
> >
> > debug.debugger_on_panic=0
> > debug.trace_on_panic=1
> >
> > (These will cause the panic message and backtrace to be automatically
> > recorded in the message buffer saved to the kernel crash dump. If not
> > told otherwise, the machine will then reboot and at the next boot
> > generate a crash dump in your dumpdir. When you get the kernel crash
> > dump, run "kgdb vmcore.0 /boot/kernel/kernel" as root and then you can
> > inspect the trace, core dump, etc. You don't need any special
> > knowledge of (k)gdb for this. The one useful command to you may be
> > "bt" - generate a backtrace).
> >
> > > It looks like the problem reported by that link, and some of the links
> > from
> > > there though...
> >
> > I'm trying to solve that one with Craig Rodrigues. So far it's been
> > without success but we know where the problem is.
> >
>
>
>
> --
> Benjie Chen, Ph.D.
> Addgene, a better way to share plasmids
> www.addgene.org
>



-- 
Benjie Chen, Ph.D.
Addgene, a better way to share plasmids
www.addgene.org