* radeon breaks with clocksource_jiffies
@ 2007-02-23 21:45 David Miller
2007-02-23 22:03 ` David Miller
[not found] ` <1f1b08da0702231408l19207805o5555ee3ebf6bd426@mail.gmail.com>
0 siblings, 2 replies; 5+ messages in thread
From: David Miller @ 2007-02-23 21:45 UTC (permalink / raw)
To: linux-kernel
While probeing PLL information via radeon_get_pllinfo(), it does a
"gettimeofday(); do_something(); gettimeofday();" type sequence
explicitly with interrupts disabled, so ends up with a zero
measurement which then results in a bunch of divisions by zero.
We should decide whether gettimeofday() can be expected to advance with
interrupts disabled, or that clocksource_jiffies is simply invalid because
of this behavior.
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: radeon breaks with clocksource_jiffies
2007-02-23 21:45 radeon breaks with clocksource_jiffies David Miller
@ 2007-02-23 22:03 ` David Miller
2007-02-23 22:10 ` john stultz-lkml
[not found] ` <1f1b08da0702231408l19207805o5555ee3ebf6bd426@mail.gmail.com>
1 sibling, 1 reply; 5+ messages in thread
From: David Miller @ 2007-02-23 22:03 UTC (permalink / raw)
To: linux-kernel
From: David Miller <davem@davemloft.net>
Date: Fri, 23 Feb 2007 13:45:05 -0800 (PST)
> While probeing PLL information via radeon_get_pllinfo(), it does a
> "gettimeofday(); do_something(); gettimeofday();" type sequence
> explicitly with interrupts disabled, so ends up with a zero
> measurement which then results in a bunch of divisions by zero.
>
> We should decide whether gettimeofday() can be expected to advance with
> interrupts disabled, or that clocksource_jiffies is simply invalid because
> of this behavior.
Actually, with clocksource based gettimeofday(), radeon built-in cannot
work at all.
The reason is that the clocksource code will not jump over to a
clock source other than clocksource_jiffies until the late initcalls
are run, because of this code:
/* clocksource_done_booting - Called near the end of bootup
*
* Hack to avoid lots of clocksource churn at boot time
*/
static int __init clocksource_done_booting(void)
{
finished_booting = 1;
return 0;
}
late_initcall(clocksource_done_booting);
...
struct clocksource *clocksource_get_next(void)
{
unsigned long flags;
spin_lock_irqsave(&clocksource_lock, flags);
if (next_clocksource && finished_booting) {
curr_clocksource = next_clocksource;
next_clocksource = NULL;
}
spin_unlock_irqrestore(&clocksource_lock, flags);
return curr_clocksource;
}
So even if other clock sources are provided, they'll never show up until
after the radeon driver tries to initialize.
I understand the intention of the clocksource_get_next() code, it doesn't
want to hop onto several different clocksource implementations as the
drivers for those startup, but going through all the module_init() calls
for various drivers without a sane clocksource is just as bad of a problem
and is in fact fatal in this radeon case.
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: radeon breaks with clocksource_jiffies
2007-02-23 22:03 ` David Miller
@ 2007-02-23 22:10 ` john stultz-lkml
2007-02-23 22:32 ` David Miller
0 siblings, 1 reply; 5+ messages in thread
From: john stultz-lkml @ 2007-02-23 22:10 UTC (permalink / raw)
To: David Miller; +Cc: linux-kernel
On 2/23/07, David Miller <davem@davemloft.net> wrote:
> > While probeing PLL information via radeon_get_pllinfo(), it does a
> > "gettimeofday(); do_something(); gettimeofday();" type sequence
> > explicitly with interrupts disabled, so ends up with a zero
> > measurement which then results in a bunch of divisions by zero.
> >
> > We should decide whether gettimeofday() can be expected to advance with
> > interrupts disabled, or that clocksource_jiffies is simply invalid because
> > of this behavior.
>
> Actually, with clocksource based gettimeofday(), radeon built-in cannot
> work at all.
>
> The reason is that the clocksource code will not jump over to a
> clock source other than clocksource_jiffies until the late initcalls
> are run, because of this code:
Check out the patch I sent out yesterday. It should resolve this problem.
thanks
-john
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: radeon breaks with clocksource_jiffies
[not found] ` <1f1b08da0702231408l19207805o5555ee3ebf6bd426@mail.gmail.com>
@ 2007-02-23 22:13 ` john stultz
0 siblings, 0 replies; 5+ messages in thread
From: john stultz @ 2007-02-23 22:13 UTC (permalink / raw)
To: David Miller; +Cc: lkml
Crud, my poor gmail skills dropped lkml on the CC list for this one.
On 2/23/07, john stultz <johnstul@us.ibm.com> wrote:
> On 2/23/07, David Miller <davem@davemloft.net> wrote:
> > While probeing PLL information via radeon_get_pllinfo(), it does a
> > "gettimeofday(); do_something(); gettimeofday();" type sequence
> > explicitly with interrupts disabled, so ends up with a zero
> > measurement which then results in a bunch of divisions by zero.
>
> This is at module init time? If so I just sent out a patch yesterday
> to akpm that might help this issue (assuming other clocksources are
> available on the hardware).
>
>
> > We should decide whether gettimeofday() can be expected to advance with
> > interrupts disabled, or that clocksource_jiffies is simply invalid because
> > of this behavior.
>
> Some arches have no fine-grained timekeeping, so I don't think it can
> always be assumed, but where hardware is available it should function.
>
> It should be noted that with older kernels, if interrupts were
> disabled right before a tick, it would be possible that
> gettimeofday()'s limiting code would cause time to stop advancing
> until interrupts were re-enabled. So theoretically its not really a
> new issue.
>
> The timekeeping_is_continuous() function could be used to flag this
> sort of "software driven vs continuous" clocksource cases.
>
> thanks
> -john
>
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: radeon breaks with clocksource_jiffies
2007-02-23 22:10 ` john stultz-lkml
@ 2007-02-23 22:32 ` David Miller
0 siblings, 0 replies; 5+ messages in thread
From: David Miller @ 2007-02-23 22:32 UTC (permalink / raw)
To: johnstul.lkml; +Cc: linux-kernel
From: "john stultz-lkml" <johnstul.lkml@gmail.com>
Date: Fri, 23 Feb 2007 14:10:07 -0800
> Check out the patch I sent out yesterday. It should resolve this problem.
Yep, changing that finished_booting setting into an fs_initcall()
fixes this issue.
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2007-02-23 22:32 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2007-02-23 21:45 radeon breaks with clocksource_jiffies David Miller
2007-02-23 22:03 ` David Miller
2007-02-23 22:10 ` john stultz-lkml
2007-02-23 22:32 ` David Miller
[not found] ` <1f1b08da0702231408l19207805o5555ee3ebf6bd426@mail.gmail.com>
2007-02-23 22:13 ` john stultz
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.