Date: Tue, 19 Apr 2005 16:26:22 -0700 From: Kris Kennaway <kris@obsecurity.org> To: Robert Watson <rwatson@FreeBSD.org> Cc: Kris Kennaway <kris@obsecurity.org> Subject: Re: "panic: trap: fast data access mmu miss" in m_copym Message-ID: <20050419232622.GA30734@xor.obsecurity.org> In-Reply-To: <20050419083350.V31061@fledge.watson.org> References: <20050419032947.GA23047@xor.obsecurity.org> <20050419083350.V31061@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--5vNYLRcllDrimb99 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Apr 19, 2005 at 08:36:28AM +0100, Robert Watson wrote: > On Mon, 18 Apr 2005, Kris Kennaway wrote: >=20 > >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=20 > >problem (the other 7 machines with the same kernel have been running for= =20 > >months) it will be hard to tell empirically. > > > >Unfortunately I don't seem to have a kernel.debug for this machine. >=20 > Is it possible to build a kernel from around the right date and see how= =20 > closely things match? Do you have the full trap message? There was a=20 > 2005/01/12 change to tcp_output.c that corrected a possible crash, but I= =20 > don't have the details of the crash on-hand to know if it's the same one.= =20 > A lin number would be very helpful, even approximate, for the call to=20 > 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 =3D 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 --5vNYLRcllDrimb99 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (FreeBSD) iD8DBQFCZZOeWry0BWjoQKURAgNEAJ9aCWsTYN0ClVDHRnCRn0WzX4p9VgCgtO7m wypARvw6cVYoTof94S0VVUk= =9KFk -----END PGP SIGNATURE----- --5vNYLRcllDrimb99--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20050419232622.GA30734>