Re: hostap kernel lockup?

Re: hostap kernel lockup?

[Sitsofe Wheeler]

Sitsofe Wheeler wrote:

> hostap_pci on a 32bit x86 machine seems to be unstable under load in
> next-20080604. Using iperf between a wired machine on the other side of
> the AP and the hostap box makes hostap output the message
> wifi0: SW TICK stuck? bits=0x0 EvStat=8000 IntEn=e09f
> before things slowly grind to a halt in a lockup that seemingly needs a
> sysrq reboot. This problem seems to be reproducible every time but does
> not happen with Ubuntu's 2.6.22 kernel.

This issue seems to be happening at least as far back as 2.6.22 vanilla with
the config on http://sucs.org/~sits/test/config-2.6.22.txt although things
always seem to be recoverable. Sometimes the system will recover after the
lockup with a message like:
Clocksource tsc unstable (delta = 9377016871 ns)
Time acpi_pm clocksource has been installed.
Unfortunately even after if this does happen supsequent runs can still
freeze things to the extent that caps lock will stop responding. It can get
to the stage where screen updates in X only seem to happen when a key is
pressed on the keyboard. 

-- 
Sitsofe | http://sucs.org/~sits/

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

DEBUG_LOCK_ALLOC causes hostap kernel lockup

[Sitsofe Wheeler]

Sitsofe Wheeler wrote:

> Sitsofe Wheeler wrote:
> 
>> hostap_pci on a 32bit x86 machine seems to be unstable under load in
>> next-20080604. Using iperf between a wired machine on the other side of
>> the AP and the hostap box makes hostap output the message
>> wifi0: SW TICK stuck? bits=0x0 EvStat=8000 IntEn=e09f
>> before things slowly grind to a halt in a lockup that seemingly needs a
> 
> things always seem to be recoverable. Sometimes the system will recover
> after the lockup with a message like:
> Clocksource tsc unstable (delta = 9377016871 ns)
> Time acpi_pm clocksource has been installed.

The lockups seem to be down to DEBUG_LOCK_ALLOC (Lock debugging: detect
incorrect freeing of live locks). If that is enabled then after enough
iperf runs the kernel will lock solid. This problems seems to happen in
kernels from at least 2.6.22 onwards.

I had no idea that enabling lock checking could itself result in a lockup...

-- 
Sitsofe | http://sucs.org/~sits/

--
To unsubscribe from this list: send the line "unsubscribe kernel-testers" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html