[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20071210230425.GA641@elte.hu>
Date: Tue, 11 Dec 2007 00:04:25 +0100
From: Ingo Molnar <mingo@...e.hu>
To: Andrew Morton <akpm@...ux-foundation.org>
Cc: rjw@...k.pl, linux-kernel@...r.kernel.org,
torvalds@...ux-foundation.org,
Stefano Brivio <stefano.brivio@...imi.it>,
Guillaume Chazarain <guichaz@...oo.fr>
Subject: Re: 2.6.24-rc4-git5: Reported regressions from 2.6.23
* Ingo Molnar <mingo@...e.hu> wrote:
> * Andrew Morton <akpm@...ux-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.)
Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists