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
pgpDIZ23zErmf.pgp
Description: PGP signature