Andrew Morton <[EMAIL PROTECTED]> writes:
>
> So I queued this, and then another patch to revert it so that the
> x86_64-clockevents conversion would apply. But I was unable to locate the
> corresponding bug in the post-x86_64-clockevents tree. Did it get fixed by
> other means in there?
Yes,
Andrew Morton [EMAIL PROTECTED] writes:
So I queued this, and then another patch to revert it so that the
x86_64-clockevents conversion would apply. But I was unable to locate the
corresponding bug in the post-x86_64-clockevents tree. Did it get fixed by
other means in there?
Yes, the
On Sat, 14 Jul 2007 10:41:39 +0200 Thomas Gleixner <[EMAIL PROTECTED]> wrote:
> The current SMI detection logic in read_hpet_tsc() makes sure,
> that when a SMI happens between the read of the HPET counter and
> the read of the TSC, this wrong value is used for TSC calibration.
>
> This is not
On Sat, 14 Jul 2007 10:41:39 +0200 Thomas Gleixner [EMAIL PROTECTED] wrote:
The current SMI detection logic in read_hpet_tsc() makes sure,
that when a SMI happens between the read of the HPET counter and
the read of the TSC, this wrong value is used for TSC calibration.
This is not the
The current SMI detection logic in read_hpet_tsc() makes sure,
that when a SMI happens between the read of the HPET counter and
the read of the TSC, this wrong value is used for TSC calibration.
This is not the intention of the function. The comparison must ensure,
that we do _NOT_ use such a
The current SMI detection logic in read_hpet_tsc() makes sure,
that when a SMI happens between the read of the HPET counter and
the read of the TSC, this wrong value is used for TSC calibration.
This is not the intention of the function. The comparison must ensure,
that we do _NOT_ use such a
6 matches
Mail list logo
