On Tue, 11 Dec 2007 00:04:25 +0100 Ingo Molnar <[EMAIL PROTECTED]> wrote: > > * Ingo Molnar <[EMAIL PROTECTED]> wrote: > > > * Andrew Morton <[EMAIL PROTECTED]> wrote: > > > > > > what do you think? Right now i've got them queued up for 2.6.25 in > > > > both the scheduler-devel and the x86-devel git trees - but can > > > > submit them for 2.6.24 if it's better if we did them there. I've got > > > > no strong opinion either way. > > > > > > printk_clock() doesn't seem terribly important but what's this stuff > > > about effects on udelay/mdelay? That can be serious if they're > > > getting shortened. > > > > since udelay depends on loops_per_jiffy, which is fixed up > > time_cpufreq_notifier(), i dont see how it could be affected by > > frequency changes. (but that's the theory - practice might be > > different) > > Stefano Brivio reported udelay()/mdelay() effects in the b43 driver. > (and it caused driver failures for him.) > > Stefano, could you please try to sum up your experiences with that > issue? Is it reproducable, and the 5 patches i did fix it? (if yes, > could you try to re-do the mdelay verifications perhaps, to make sure > it's not some other effect interacting here. In theory sched-clock > scaling has no effect on udelay behavior.)
Sorry for disappearing. Anyway, yes, those patches fixed it. Precision in delays isn't that good when using my crappy unstable TSC (mdelay(2000) causes delays between 2 and 2.9 seconds) but it's not depending on frequency changes anymore. So I'd say it's fixed, but please tell me if you want me to do any other test so as to be sure it is. -- Ciao Stefano -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/