Date: Wed, 26 Sep 2007 15:20:59 -0400 From: "Benjie Chen" <benjie@addgene.org> To: "Ivan Voras" <ivoras@freebsd.org>, "Kris Kennaway" <kris@freebsd.org> Cc: freebsd-hackers@freebsd.org Subject: Re: Kernel panic on PowerEdge 1950 under certain stress load Message-ID: <c53be070709261220x69cbe494k3ce409fd09cfdf8b@mail.gmail.com> In-Reply-To: <c53be070709260955y77c9d02v6e5ca8a9656eda54@mail.gmail.com> References: <c53be070709211526j2178ebb7ia6ea39e1a5df303c@mail.gmail.com> <fd84qf$ejl$1@sea.gmane.org> <c53be070709240842h6875d45ct761d0fa5790f70e2@mail.gmail.com> <9bbcef730709241211o479e3e5dwf64382596c837dfb@mail.gmail.com> <c53be070709260955y77c9d02v6e5ca8a9656eda54@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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@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@freebsd.org> wrote: > > > > On 24/09/2007, Benjie Chen <benjie@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?c53be070709261220x69cbe494k3ce409fd09cfdf8b>