On Fri, 10 Oct 2008, Thomas Gleixner wrote:
> On Fri, 10 Oct 2008, Elias Oltmanns wrote:
> > That printk() has not been hit, I'm afraid. The output of
> > sysrq_timer_list_show() looks much the same but there is no message
> > about softirqs. Just for the record, I've switched to 2.6.27 because I'm
> > debugging something else at the same time, but it doesn't make any
> > difference.
> >
> > Now, here is another question: There are various snippets like the
> > following in the ath5k driver:
> >
> > /* Wait until the noise floor is calibrated and read the value */
> > for (i = 20; i > 0; i--) {
> > mdelay(1);
>
> Uurgh. That's broken. mdelay sleeps so this should not be called in
> softirq context.
>
> > noise_floor = ath5k_hw_reg_read(ah, AR5K_PHY_NF);
> > noise_floor = AR5K_PHY_NF_RVAL(noise_floor);
> > if (noise_floor & AR5K_PHY_NF_ACTIVE) {
> > noise_floor = AR5K_PHY_NF_AVAL(noise_floor);
> >
> > if (noise_floor <= AR5K_TUNE_NOISE_FLOOR)
> > break;
> > }
> > }
> >
> > This particular one is in
> > drivers/net/wireless/ath5k/phy.c:ath5k_hw_noise_floor_calibration()
> > which is called from ath5k_calibrate(), the callback executed every ten
> > seconds in softirq context. Could this have anything to do with our
>
> That makes sense. The timer expires early events are multiples of 10s
> apart.
Ok, I thought more about it and aside of the fact that the ath5k is
doing something nasty, you unearthed a weakness in the broadcast code.
Can you please try the following:
Compile the acpi_processor module in to the kernel
(CONFIG_ACPI_PROCESSOR=y) and add processor.max_cstate=1 to the kernel
command line. If I analysed the problem correctly this will make the
jiffies problem go away. I'm working on a fix.
Thanks,
tglx
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
