> trap type=0x8, code=0x145, v=0x8
> pid = 676, pc = 0E02637C, ps = 2000, sfc = 0001, dfc = 0001
> Registers:

First, you should have DDB in your kernel, and symbols too! (Either using
the NetBSD boot or dbsym).  I'd really like a PC traceback here.  If you
have DDB and symbols, you can type 'tr'.

> dreg: 00000000 00000000 00000000 0E5D3600 00010052 00000000 00000011 FFFFFFFF
> areg: 00000000 0FBC1F40 0E540860 0E57C01C 0FBC1E1C 0E57C000 0FBC1F1C 0DFFFC48

Here's why we need to know where it panicked.

> Kernel stack (0FBC1D10):
> BC1D10: 0E0701DC 0FBC1D64 00000080 00000000 0E5D3600 00010052 00000000 
> 00000011
> BC1D30: FFFFFFFF 0E540860 0E57C01C 0FBC1E1C 0E57C000 00000001 0E07E808 
> 0E5A0100
> BC1D50: 0FBC1F1C 0E00417E 00000008 00000145 00000008 00000000 00000000 
> 00000000
> BC1D70: 0E5D3600 00010052 00000000 00000011 FFFFFFFF 00000000 0FBC1F40 
> 0E540860
> BC1D90: 0E57C01C 0FBC1E1C 0E57C000 0FBC1F1C 0DFFFC48 00000000

This much is the trap handler taking the fault and doing the panic.
What follows is the exact exception frame itself:

20000E02 
> 637CB008
> BC1DB0: 0E2C0145

At the time, we were at spl0, took a bus error (trap #2) and it appears to
be a bad data access, as opposed to a fault fetching an instruction.

The next part will be the most elucidating, provided that we know where
exactly it panicked.

2F032F0C 00000008 00000008 0E595F00 22680008 0E026384 
> 0E026382
> BC1DD0: 0E026380 00000000 0008FF0A 000F1486 0E595F00 0E5A0000 0000001F 
> 00000000

etc.

Obviously I've done this before. :-)

-- 
David Jones, M.A.Sc student, Electronics Group (VLSI), University of Toronto
           email: dej@eecg.toronto.edu, finger for PGP public key
         For a good time, telnet torfree.net and log in as `guest'.
          Click me!