Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 25 Feb 2006 22:22:59 -0800
From:      Garrett Cooper <youshi10@u.washington.edu>
To:        freebsd-questions@freebsd.org
Subject:   Re: anyone recognize this panic?
Message-ID:  <44014943.8050905@u.washington.edu>
In-Reply-To: <20060226061343.GA4483@xor.obsecurity.org>
References:  <17409.8562.677322.222883@jerusalem.litteratus.org>	<20060226033858.GA10985@xor.obsecurity.org>	<440145EF.5000101@u.washington.edu> <20060226061343.GA4483@xor.obsecurity.org>

next in thread | previous in thread | raw e-mail | index | archive | help
Kris Kennaway wrote:

>On Sat, Feb 25, 2006 at 10:08:47PM -0800, Garrett Cooper wrote:
>  
>
>>Kris Kennaway wrote:
>>
>>    
>>
>>>On Sat, Feb 25, 2006 at 10:33:06PM -0500, Robert Huff wrote:
>>>
>>>
>>>      
>>>
>>>>	I just had my -CURRENT* machine crash under moderate load.  No
>>>>dump is available because the machine locked hard, but I did copy
>>>>this off the screen:
>>>>
>>>>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 =\...
-Garrett



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?44014943.8050905>