Hard hangs running 6-current.
Sam Leffler
sam at errno.com
Tue Feb 22 04:53:56 GMT 2005
Frank Mayhar wrote:
> Doug White wrote:
>
>>Try one of these loader tunables:
>>1. Disabling SMP (kern.smp.disabled=1)
>>2. Disabling mpsafenet (debug.mpsafenet=0)
>
>
> I run with debug.mpsafenet=0 (due to a bug I ran into some time ago which I
> haven't looked at recently).
>
> The current kernel is running with HTT turned off and no SMP builtin. So
> kern.smp.disabled=1 is kind of redundant.
>
> So no dice on either one of these.
>
>
>>This may be a symptom of a deadlock we're observing on
>>sparc64 in the network stack. Either one of these should stop the
>>problem, if its the issue we were seeing earlier today.
>
>
> Doesn't look like it, I'm afraid.
>
>
>>If you especially adventurous, try setting net.inet.tcp.do_tcpdrain=0
>>instead of the options above. This might cause mbuf exhaustion but is
>>implicated in the deadlock.
>>
>>This is a total hunch and I may be influenced by the time put in on this
>>issue today :)
>
>
> If you're interested, you might take a look at
> http://www.freebsd.org/cgi/query-pr.cgi?pr=77751
> It has my results for the day. Warning: Lots of ath debug output. I'm
> pretty sure it's the ath driver that's the problem, particularly in light
> of my most recent results.
>
> Thanks for the ideas, though.
Other than a busted card the only thing I can think of is you're getting
an interrupt storm from the MIB counters. If so try disabling
HAL_INT_MIB in the driver. The easiest way to do that is probably to
force sc_needmib to 0 in ath_attach by disabling the following code:
/*
* Check if the device has hardware counters for PHY
* errors. If so we need to enable the MIB interrupt
* so we can act on stat triggers.
*/
if (ath_hal_hwphycounters(ah))
sc->sc_needmib = 1;
If your problem does not go away then I can only suggest trying another
card. FWIW I haven't seen this.
Sam
More information about the freebsd-current
mailing list