* john stultz <[email protected]> wrote:
> > yes. traces show that the new calibration code results in a bogomips
> > value on Athlon64 CPUs that halve the timeout. I.e. udelay(100) now
> > takes 50 usecs (!). The calibration code seems to assume the number of
> > cycles == number of loops in __delay() - that is not valid.
>
> Yea, that makes sense, because the READ_CURRENT_TIMER calibration is
> all TSC based and with my code we use the loop based delay (since the
> TSC based one can have a number of problems). So that doesn't mesh
> well when the loop/cycle values are not equivalent.
>
> That still leaves open the question why Dinakar is seeing issues w/
> the loop based calibration, but I've got some similar hardware in my
> lab, so I can probably work that out.
>
> I'll see if I can't avoid touching the delay code. Its such a sketchy
> calibration sensitive code path that I'd really like to see it killed,
> but maybe there's something simple that can be done.
>
> Grumble. :( I was hoping to submit my tod code to Andrew tomorrow, but
> this might block that.
hm, ARCH_HAS_READ_CURRENT_TIMER is upstream already. I have not measured
the udelay thing upstream, but i thought it would have the same issue.
Does the GTOD code impact this code?
Ingo
-
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/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
