On Sat, Feb 25, 2006 at 10:22:59PM -0800, Garrett Cooper wrote: > >>>>re0: diagnostic failed to receive packet in loopback mode > >>>>re0: attach aborted due to hardware diagnostic failure > >>>>panic: mtx_lock() of spin mutex (null) @ > >>>>/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. > >>>> > >>>> > >>>> > >>>> > >>>You need to at least get a traceback from the panic, and preferably a > >>>crashdump. > >>> > >>>Kris > >>> > >>> > >>> > >>> > >>Probably should pass this onto some devs. It seems like a null value was > >>passed for locking a mutex in the OS, which is important. Having a > >>traceback would be good though... but at least mentioning that the issue > >>laid with the re (?) kernel driver would be a start. > >> > >> > > > >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 > > > > > True, but at least you'd be able to find a way to the affected code... > After that it's just tests and debugging =\...
I don't understand what you're suggesting; how do you find the affected code without a traceback? Kris
pgpdVvOcWJEZU.pgp
Description: PGP signature