On Sun, 2012-08-12 at 09:03 -0600, Jesse Rhodes wrote: > Yes, it does! Confirmed on both bcf3655... and 3.2.0-3 from sid. Why > would a cpufreq module break a PCI wireless card like that?
According to a comment in the code that logs the error message:
* If we are in a noisy environment, AGC calibration may time
* out and/or noise floor calibration might timeout.
Maybe the CPU frequency changes create additional noise in the wifi
band. If so, I don't know how this can reasonably be avoided. CPU
frequency scaling should normally be enabled, and Debian has for long a
time enabled it by default on any computer detected as being a laptop or
similar. (The kernel change just automated this at a slightly lower
level.)
ath5k developers, have you seen this failure mode before? The comment
suggests there is a known hardware bug that can cause it; is it possible
to work around that by retrying? Or is the timeout actually too low?
Ben.
> On Sat, Aug 11, 2012 at 9:43 PM, Ben Hutchings <[email protected]>
> wrote:
> On Sat, 2012-08-11 at 21:17 -0600, Jesse Rhodes wrote:
> > sney@bivouac:~/data/debian/linux$ git bisect good
> > bcf3655971d24d7f08f373ed5830e8e11010088a is the first bad
> commit
> > commit bcf3655971d24d7f08f373ed5830e8e11010088a
> > Author: Andi Kleen <[email protected]>
> > Date: Thu Jan 26 00:09:12 2012 +0100
> >
> > cpufreq: Add support for x86 cpuinfo auto loading v4
>
> [...]
>
> So does the problem go away if you unload the cpufreq driver
> (powernow_k8)?
>
> Ben.
>
> --
> Ben Hutchings
> Sturgeon's Law: Ninety percent of everything is crap.
>
--
Ben Hutchings
Sturgeon's Law: Ninety percent of everything is crap.
signature.asc
Description: This is a digitally signed message part
