Re: Analyzing a 4.0/amd64 panic

[Andrew Doran <ad%netbsd.org@localhost>]

Hi,

On Mon, Nov 24, 2008 at 05:25:21PM +0100, Edgar Fu? wrote:

> 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:

I was about to say that the backtrace looks scrambled, and suggest dumping
the stack!

> 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

There will be a 'struct trapframe' on the stack at this point.

> 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?

Was someone mounting or unmounting a file system at the time?
 
> Would it be possible to have the dump block countdown not fill the message
> buffer?

Yes. I will have a look at doing that in -current.

Andrew