Analyzing a 4.0/amd64 panic

[Edgar Fuß <ef%math.uni-bonn.de@localhost>]

I'm trying to analyze a panic on our 4.0/amd64 file server.

Unfortunately, I don't have the panic string. The colleague who rebooted the
machine from ddb forgot to take a screen picture.

Fortunately, I do have a dump. Unfortunately, the message buffer in the dump
is completely filled by the dump block countdown, so I don't have the panic
string from the message buffer either.

Unfortunately, gdb doesn't give me a backtrace. The rip is 0x100. My knowledge
of 8086 assembler is, ehm, limited.

So I dumped memory at rsp and looked for addresses that could be saved ip's.
What I get is approximately the following:

dumpsys+682
sddump
cpu_reboot+290
db_reboot_cmd+72
db_command+139
wsemul_vt100_output+813
wsdisplay_cnputc+81
cnputc+29
db_putchar+382
db_putchar+382
db_readline+654
db_command_loop+66
db_trap+220
kdb_trap+215
logwakeup+50
printf+246
lockmgr+2189
trap+563
vfs_busy+226
copystr_return
dqget+238
lockmgr+1663
secmodel_bsd44_suser_generic_cb+31
...

I don't understand why I have ddb's internal procedures in that backtrace but
apart from that it looks like the compiler optimized a call from knote (called
by logwakeup) and there was a trap inside that function.

Any hints how I can analyze this further?

Would it be possible to have the dump block countdown not fill the message
buffer?