* Pavel Machek <[EMAIL PROTECTED]> wrote:
> On Sun 2007-12-30 15:08:15, Ingo Molnar wrote:
> >
> > > ok, i prefer this fix a bit more. (we dont want to set last_tsc
> > > outside of the sync_lock - which your initial patch does)
> >
> > i've added your patch to x86.git - thanks Mike! (patch
* Pavel Machek [EMAIL PROTECTED] wrote:
On Sun 2007-12-30 15:08:15, Ingo Molnar wrote:
ok, i prefer this fix a bit more. (we dont want to set last_tsc
outside of the sync_lock - which your initial patch does)
i've added your patch to x86.git - thanks Mike! (patch below) I
On Fri, 2008-01-04 at 17:39 +0100, Pavel Machek wrote:
> If it is too dangerous for -final, I guess it is bad idea to push it
> into -stable.
>
> Plus it does not fix really bad bug.
The furthest back burner is fine. It's only an annoyance.
-Mike
--
To unsubscribe from this list:
On Sun 2007-12-30 15:08:15, Ingo Molnar wrote:
>
> > ok, i prefer this fix a bit more. (we dont want to set last_tsc
> > outside of the sync_lock - which your initial patch does)
>
> i've added your patch to x86.git - thanks Mike! (patch below) I think
> this would be too dangerous for v2.6.24
On Fri, 2008-01-04 at 17:39 +0100, Pavel Machek wrote:
If it is too dangerous for -final, I guess it is bad idea to push it
into -stable.
Plus it does not fix really bad bug.
The furthest back burner is fine. It's only an annoyance.
-Mike
--
To unsubscribe from this list: send
On Sun, 2007-12-30 at 15:08 +0100, Ingo Molnar wrote:
> > ok, i prefer this fix a bit more. (we dont want to set last_tsc
> > outside of the sync_lock - which your initial patch does)
>
> i've added your patch to x86.git - thanks Mike! (patch below) I think
> this would be too dangerous for
> ok, i prefer this fix a bit more. (we dont want to set last_tsc
> outside of the sync_lock - which your initial patch does)
i've added your patch to x86.git - thanks Mike! (patch below) I think
this would be too dangerous for v2.6.24 though - we can put it back into
-stable for 2.6.24.1,
* Mike Galbraith <[EMAIL PROTECTED]> wrote:
> Or, reset to pristine prior to testing, though that's more lines to
> accomplish the same thing. Either way, or some other way...
>
> If check_tsc_warp() is called after initial boot, and the TSC has in
> the meantime been set (BIOS, user,
* Mike Galbraith [EMAIL PROTECTED] wrote:
Or, reset to pristine prior to testing, though that's more lines to
accomplish the same thing. Either way, or some other way...
If check_tsc_warp() is called after initial boot, and the TSC has in
the meantime been set (BIOS, user, silicon,
ok, i prefer this fix a bit more. (we dont want to set last_tsc
outside of the sync_lock - which your initial patch does)
i've added your patch to x86.git - thanks Mike! (patch below) I think
this would be too dangerous for v2.6.24 though - we can put it back into
-stable for 2.6.24.1, once
On Sun, 2007-12-30 at 15:08 +0100, Ingo Molnar wrote:
ok, i prefer this fix a bit more. (we dont want to set last_tsc
outside of the sync_lock - which your initial patch does)
i've added your patch to x86.git - thanks Mike! (patch below) I think
this would be too dangerous for v2.6.24
On Thu, 2007-12-27 at 19:27 +0100, Mike Galbraith wrote:
> On Thu, 2007-12-27 at 12:09 -0600, Robert Hancock wrote:
>
> > Are we missing some logic to resync the TSCs after resume, or something?
>
> They used to be forcibly synchronized during boot, but it seems that was
> dropped in 2.6.21.
On Thu, 2007-12-27 at 12:09 -0600, Robert Hancock wrote:
> Are we missing some logic to resync the TSCs after resume, or something?
They used to be forcibly synchronized during boot, but it seems that was
dropped in 2.6.21.
-Mike
--
To unsubscribe from this list: send the line
Or, reset to pristine prior to testing, though that's more lines to
accomplish the same thing. Either way, or some other way...
If check_tsc_warp() is called after initial boot, and the TSC has in the
meantime been set (BIOS, user, silicon, elves) to a value lower than the
last stored/stale
Mike Galbraith wrote:
Greetings,
s2ram recently became useful here, except for the kernel's annoying
habit of disabling my P4's perfectly good TSC.
[ 107.894470] CPU 1 is now offline
[ 107.894474] SMP alternatives: switching to UP code
[ 107.895832] CPU0 attaching sched-domain:
[
Greetings,
s2ram recently became useful here, except for the kernel's annoying
habit of disabling my P4's perfectly good TSC.
[ 107.894470] CPU 1 is now offline
[ 107.894474] SMP alternatives: switching to UP code
[ 107.895832] CPU0 attaching sched-domain:
[ 107.895836] domain 0: span 1
[
Greetings,
s2ram recently became useful here, except for the kernel's annoying
habit of disabling my P4's perfectly good TSC.
[ 107.894470] CPU 1 is now offline
[ 107.894474] SMP alternatives: switching to UP code
[ 107.895832] CPU0 attaching sched-domain:
[ 107.895836] domain 0: span 1
[
Mike Galbraith wrote:
Greetings,
s2ram recently became useful here, except for the kernel's annoying
habit of disabling my P4's perfectly good TSC.
[ 107.894470] CPU 1 is now offline
[ 107.894474] SMP alternatives: switching to UP code
[ 107.895832] CPU0 attaching sched-domain:
[
On Thu, 2007-12-27 at 12:09 -0600, Robert Hancock wrote:
Are we missing some logic to resync the TSCs after resume, or something?
They used to be forcibly synchronized during boot, but it seems that was
dropped in 2.6.21.
-Mike
--
To unsubscribe from this list: send the line
Or, reset to pristine prior to testing, though that's more lines to
accomplish the same thing. Either way, or some other way...
If check_tsc_warp() is called after initial boot, and the TSC has in the
meantime been set (BIOS, user, silicon, elves) to a value lower than the
last stored/stale
On Thu, 2007-12-27 at 19:27 +0100, Mike Galbraith wrote:
On Thu, 2007-12-27 at 12:09 -0600, Robert Hancock wrote:
Are we missing some logic to resync the TSCs after resume, or something?
They used to be forcibly synchronized during boot, but it seems that was
dropped in 2.6.21.
(but out
21 matches
Mail list logo
