Re: 2.6.24-rc4-git5: Reported regressions from 2.6.23

[Stefano Brivio <stefano.brivio@polimi.it>]

On Tue, 11 Dec 2007 00:04:25 +0100
Ingo Molnar <mingo@elte.hu> wrote:
> 
> * Ingo Molnar <mingo@elte.hu> wrote:
> 
> > * Andrew Morton <akpm@linux-foundation.org> 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