DragonFlyBSD

:New submission from Joe "Floid" Kanowitz <jkanowitz@snet.net>:
:
:Using 2.4.1 with the lone patch from http://bugs.dragonflybsd.org/issue1583
:
:DragonFly tucker 2.4.1-RELEASE DragonFly v2.4.1.40.ga038d-RELEASE #1: Sat Jan 30
:11:57:51 EST 2010 root@tucker:/usr/obj/usr/src/sys/GENERIC i386
:
:... I'm not sure when this occurred; possibly during nightly cleanup.
:The previous evening gave HAMMER a little more stress than usual via a bit of
:`undo` usage (normally none) which did seem to be turning up transient(?)
:"ITERATE ENTIRE HISTORY: Unknown error: 0" results similar to
:http://leaf.dragonflybsd.org/mailarchive/users/2009-09/msg00062.html (but here
:the HAMMER config is left at the sane defaults). Not intending to poke at them
:too much unless it relates to the panic here.
:
:Couldn't get a dump because I didn't realize I hadn't specified a dumpdev (doh!).
:
:db> trace
I think the 'iterate entire history: unknown error: 0' was cockpit
trouble in the hammer ioctl code and not a real error. It was
fixed in 2.5.x.

The panic you got looks like it was an assertion instead of a
    seg-fault, because the backtrace was btree->panic instead of
    btree->trap->panic.

Methinks the panic message must have scrolled off the screen
    (it would have been above the backtrace).  The trap below the
    trace was probably a double-fault in the debugger.

Definitely set up your dumpdev so we can get a dump if this 
    occurs for you again.  There have been a couple of assertions
    fixed in 2.5.x that have not been MFCd to 2.4.x due to the
    HAMMER codebase diverging too much between 2.4.x and 2.5.x.

-Matt

Methinks the panic message must have scrolled off the screen
(it would have been above the backtrace). The trap below the
trace was probably a double-fault in the debugger.

I'm still learning my way around the debugger - this is that 'production'
machine set up with a serial console and I only drape the cable across the room
when it acts up. The 'trap below' was from an intentional show command, pardon
any ambiguity.

What's the right way to retrieve the actual panic string after you've entered
ddb? Or is there none? [The msgbuf didn't seem to have it.]

Definitely set up your dumpdev so we can get a dump if this
occurs for you again. There have been a couple of assertions
fixed in 2.5.x that have not been MFCd to 2.4.x due to the
HAMMER codebase diverging too much between 2.4.x and 2.5.x.

Yup, set up properly now.

:What's the right way to retrieve the actual panic string after you've entered
:ddb? Or is there none? [The msgbuf didn't seem to have it.]

It should have it above the stack backtrace.  It may have scrolled
    off.  With a video console you can use scroll lock and cursor up.
    With a serial console whatever terminal program you have it in...
    well, like tip or cu inside an xterm, use the scroll bar on the xterm
    to scroll up.

-Matt
                    Matthew Dillon 
                    <dillon@backplane.com>

With a serial console whatever terminal program you have it in...
well, like tip or cu inside an xterm, use the scroll bar on the xterm
to scroll up.

That's the rub, for various spatial reasons a 'terminal' is physically not
connected most of the time. After the annoyance of not being able to see it
today (and trying to 'cheat') I'm thinking of digging out an extension cable [or
switching 'properly' to unattended mode].