"panic: trap: fast data access mmu miss" in m_copym

[Kris Kennaway]

On Tue, Apr 19, 2005 at 08:36:28AM +0100, Robert Watson wrote:
> On Mon, 18 Apr 2005, Kris Kennaway wrote:
> 
> >This on an u10 running
> >
> >FreeBSD 5.3-STABLE (NETBOOT) #1: Sun Dec 12 18:38:35 JST 2004
> >
> >It may already be fixed, but since this is clearly a very infrequent 
> >problem (the other 7 machines with the same kernel have been running for 
> >months) it will be hard to tell empirically.
> >
> >Unfortunately I don't seem to have a kernel.debug for this machine.
> 
> Is it possible to build a kernel from around the right date and see how 
> closely things match?  Do you have the full trap message?  There was a 
> 2005/01/12 change to tcp_output.c that corrected a possible crash, but I 
> don't have the details of the crash on-hand to know if it's the same one. 
> A lin number would be very helpful, even approximate, for the call to 
> m_copym() in tcp_output(), as well as the full fault message.

I tried building a kernel from the same source date.  gdb53
couldn't decode the vmcore with it.  With the stripped kernel I get this:

panic: trap: fast data access mmu miss
panic messages:
---
panic: trap: fast data access mmu miss
cpuid = 0
KDB: enter: panic
Dumping 512 MB (2 chunks)
  chunk at 0x10000000: 268435456 bytes |\^H
---
#0  0x00000000c0147e4c in doadump ()
(kgdb) bt
#0  0x00000000c0147e4c in doadump ()
#1  0x00000000c005d9d4 in db_fncall ()
#2  0x00000000c005dbc4 in db_command_loop ()
#3  0x00000000c0060608 in db_trap ()
#4  0x00000000c0167dc8 in kdb_trap ()
#5  0x00000000c02d30a4 in trap ()
#6  0x00000000c01677d8 in kdb_enter ()
#7  0x00000000c01677d0 in kdb_enter ()
#8  0x00000000c0148d34 in panic ()
#9  0x00000000c02d2fbc in trap ()
#10 0x00000000c018acc0 in m_copym ()
#11 0x00000000c02b2090 in uma_zalloc_arg ()
#12 0x00000000c01f4ce4 in tcp_output ()
#13 0x00000000c01f3840 in tcp_input ()
#14 0x00000000c01e83f0 in ip_input ()
#15 0x00000000c01d31fc in netisr_processqueue ()
#16 0x00000000c01d3574 in swi_net ()
#17 0x00000000c012fb44 in ithread_loop ()
#18 0x00000000c012e428 in fork_exit ()
(kgdb)

Unfortunately, the symbol addresses in the new kernel.debug aren't
even close (e.g. the offset from old and new addresses vary
significantly for different symbols), so I think I might be out of
luck.

I'll update the machine, keep the kernel.debug this time, and see what
happens over the next few months.

Kris
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-sparc64/attachments/20050419/5e86b1c9/attachment.bin