> fatal kernel trap:
   > 
   >     trap entry = 0x4 (unaligned access fault)
   >     a0         = 0xfffffe004a5f472c
   >     a1         = 0x2d
   >     a2         = 0x4
   >     pc         = 0xfffffc0000351ad4
   >     ra         = 0xfffffc00003507dc
   >     curproc    = 0xfffffe004a5eae00
   >         pid = 144, comm = httpd
   > 
   > panic: trap

   "oh cool!"  I've not seen an unaligned access fault in the kernel for
   ... a long time.  8-S


   could you run gdb on the kernel binary with debugging symbols that
   corresponds to the kernel you're running?  (When your kernel was
   built, a 'netbsd.gdb' was built at the same time as your 'netbsd'.)

Yes, not a problem.....

   In gdb, 'list *0xfffffc0000351ad4' and 'list *0xfffffc00003507dc', and
   reply to this message with the results.

(gdb) list *0xfffffc0000351ad4
0xfffffc0000351ad4 is in unp_internalize (../../../../kern/uipc_usrreq.c:682).
677             }
678             rp = (struct file **)(cm + 1);
679             for (i = 0; i < oldfds; i++) {
680                     fp = fdp->fd_ofiles[*(int *)rp];
681                     *rp++ = fp;
682                     fp->f_count++;
683                     fp->f_msgcount++;
684                     unp_rights++;
685             }
686             return (0);

(gdb) list *0xfffffc00003507dc
0xfffffc00003507dc is in uipc_usrreq (../../../../kern/uipc_usrreq.c:219).
214                             panic("uipc 2");
215                     }
216                     break;
217
218             case PRU_SEND:
219                     if (control && (error = unp_internalize(control, p)))
220                             break;
221                     switch (so->so_type) {
222
223                     case SOCK_DGRAM: {


Hopefully, that is helpful...

   This is probably pretty repeatable, so you can probably cause the same
   result on a new kernel if you need to build one from scratch to get a
   'reasonable' (i.e. fitting your sources and kernel binary) netbsd.gdb.

It is completely repeatable...

   If you have to build a new kernel and make it crash (so you have an
   up-to-date netbsd.gdb), use the pc and ra values reported by the fatal
   trap in those 'list' commands.

I actually found the panic on a system build over a month ago, so the
first thing I did was sup and build a new system.  Of course, the same
thing happened.

   chris



Brad Spencer - brad@anduin.eldar.org   http://anduin.eldar.org