Date: Sun, 26 Feb 2006 03:14:59 -0500 From: Kris Kennaway <kris@obsecurity.org> To: Garrett Cooper <youshi10@u.washington.edu> Cc: freebsd-questions@freebsd.org Subject: Re: anyone recognize this panic? Message-ID: <20060226081459.GA52382@xor.obsecurity.org> In-Reply-To: <44015808.1000201@u.washington.edu> References: <17409.8562.677322.222883@jerusalem.litteratus.org> <20060226033858.GA10985@xor.obsecurity.org> <440145EF.5000101@u.washington.edu> <20060226061343.GA4483@xor.obsecurity.org> <44014943.8050905@u.washington.edu> <20060226070300.GA59714@xor.obsecurity.org> <44015808.1000201@u.washington.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
--4Ckj6UjgE2iN1+kY Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Feb 25, 2006 at 11:26:00PM -0800, Garrett Cooper wrote: > Kris Kennaway wrote: >=20 > >On Sat, Feb 25, 2006 at 10:22:59PM -0800, Garrett Cooper wrote: > > > >=20 > > > >>>>>>re0: diagnostic failed to receive packet in loopback mode > >>>>>>re0: attach aborted due to hardware diagnostic failure > >>>>>>panic: mtx_lock() of spin mutex (null) @=20 > >>>>>>/usr/src/sys/netinet/in_pcb,c:862 > >>>>>> > >>>>>> "re0" is a Linksys EG-1032, less than two months old. It was > >>>>>>connected, but had zero traffic at the time of the crash. > >>>>>> Before I take this to current@ - has anyone seen anything like > >>>>>>this before? A quick check of the archives and the web in general > >>>>>>didn't show anything. > >>>>>> > >>>>>> > >>>>>> =20 > >>>>>> > >>>>>> =20 > >>>>>> > >>>>>You need to at least get a traceback from the panic, and preferably a > >>>>>crashdump. > >>>>> > >>>>>Kris > >>>>> > >>>>> > >>>>> =20 > >>>>> > >>>>> =20 > >>>>> > >>>>Probably should pass this onto some devs. It seems like a null value= =20 > >>>>was passed for locking a mutex in the OS, which is important. Having = a=20 > >>>>traceback would be good though... but at least mentioning that the=20 > >>>>issue laid with the re (?) kernel driver would be a start. > >>>>=20 > >>>> > >>>> =20 > >>>> > >>>Unfortunately without a traceback the panic string is useless since it > >>>gives you no clue about how the system got into that state. This kind > >>>of panic is often a secondary effect of some other problem. > >>> > >>>Kris > >>> > >>> > >>> =20 > >>> > >>True, but at least you'd be able to find a way to the affected code...= =20 > >>After that it's just tests and debugging =3D\... > >> =20 > >> > > > >I don't understand what you're suggesting; how do you find the > >affected code without a traceback? > > > >Kris > > > I'm thinking of the "old fashioned way" of doing things... reading tons= =20 > of code. Lol. OK, let us know if you find anything :^) Kris --4Ckj6UjgE2iN1+kY Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.1 (FreeBSD) iD8DBQFEAWODWry0BWjoQKURAp/QAJwMc2kGaE0MvDHkrGX8488l93ft8wCgrNFj Q7tUaQt4pa1503+pOZEQJCE= =cv4v -----END PGP SIGNATURE----- --4Ckj6UjgE2iN1+kY--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060226081459.GA52382>