[ltp] Re: Interference of wlan usage and hdaps?

[Elias Oltmanns]

Henrique de Moraes Holschuh <hmh@hmh.eng.br> wrote:
> On Tue, 22 Sep 2009, Elias Oltmanns wrote:
>> Henrique de Moraes Holschuh <hmh@hmh.eng.br> wrote:
>
>> > On Tue, 22 Sep 2009, Elias Oltmanns wrote:
>> >> The rather annoying result of it all is that hdapsd frequently parks the
>> >
>> >> disk heads, sometimes preventing all I/O for tens of seconds without
>> >> interruption. Clearly, this strange behaviour only occurs once I have
>> >> connected to my wlan and goes on persistently afterwards, irrespective
>> >> of the current state of the wlan interface.
>> >
>> > Is it a function of the interrupt handling of the kernel driver (i.e. normal
>> > behaviour is restored if you rmmod the kernel driver for the wlan card), or
>> > of the hardware itself?
>> 
>> Well, I have done very little testing on the current machine yet, but
>> the problem persisted even after unloading the driver last time. Still,
>> after my experience with the atheros driver, I am inclined to believe
>> that this is a software issue and probably very similar too. It may, of
>> course, be hidden in the binary firmware image loaded by the hotplug
>> agent.
>
> It is possible that the accelerometer is not properly shielded in the X40,
> and once the WLAN card is put in D0, it starts borking.  Try hacking the ipw
> driver to put the WLAN card in D3 on rmmod, maybe that would cure hdaps :-)
>
> From what I recall, the firmware hdaps interface is really horrible, but it
> is not supposed to go crazy because of some added latencies or time spent in
> lala-land with interrupts disabled.

Sorry, I should have explained in more detail what is going on here. The
atheros issue definitely is the kernel's fault, as far as I can tell,
neither the EC controller nor the BIOS is to blame, for once ;-). Here
is how it works:

Excessive spinning in sw interrupt context has a rather severe impact on
other timers running at the time. If they have fired shortly after the
atheros tasklet has started, the interrupt handler is delayed
considerably. Apart from everything else, this really messes up hdapsd's
book keeping, thus making it believe that a minor change in the accel
data has occurred in a particularly short time frame. For all hdapsd
knows, this indicates an emergency condition and it parks the heads
accordingly.

Sorry, this still is a rather patchy explanation, but some time has
passed since I carefully studied the code and thought it all through
properly. Maybe, I'll get round to having another look at it over the
next days if you would like me to. First, I need some sleep.

[...]
>> Interesting, perhaps I'm barking up the wrong tree after all.
>
> Maybe you're at the correct tree.  It is early to tell :)

Hopefully it is. I would be uneasy about wasting your time.

Regards,

Elias