[EMAIL PROTECTED] wrote on Wed, 16 Jan 2008 16:31 +0100:
>
> * Pete Wyckoff <[EMAIL PROTECTED]> wrote:
>
> > > pretty sure this is the culprit is that num_possible_cpus() > 1,
> > > which would mean cpu_possible_map contains the second cpu... but i'm
> > > not quite sure what the right fix
* Pete Wyckoff <[EMAIL PROTECTED]> wrote:
> > pretty sure this is the culprit is that num_possible_cpus() > 1,
> > which would mean cpu_possible_map contains the second cpu... but i'm
> > not quite sure what the right fix is... or perhaps this is all
> > intended.
>
> We've seen the same
* Pete Wyckoff [EMAIL PROTECTED] wrote:
pretty sure this is the culprit is that num_possible_cpus() 1,
which would mean cpu_possible_map contains the second cpu... but i'm
not quite sure what the right fix is... or perhaps this is all
intended.
We've seen the same problem. We use
[EMAIL PROTECTED] wrote on Wed, 16 Jan 2008 16:31 +0100:
* Pete Wyckoff [EMAIL PROTECTED] wrote:
pretty sure this is the culprit is that num_possible_cpus() 1,
which would mean cpu_possible_map contains the second cpu... but i'm
not quite sure what the right fix is... or perhaps
Pete Wyckoff <[EMAIL PROTECTED]> writes:
> We've seen the same problem. We use gettimeofday() for timing of
> network-ish operations on the order of 10-50 us. But not having
> the TSC makes gettimeofday() itself very slow, on the order of 30 us.
>
> Here's what we've been using for quite a few
[EMAIL PROTECTED] wrote on Sat, 12 Jan 2008 11:48 -0800:
> if i boot an x86 64-bit 2.6.24-rc7 kernel with nosmp, maxcpus=0 or 1 it
> still disables TSC :)
>
> Marking TSC unstable due to TSCs unsynchronized
>
> this is an opteron 2xx box which does have two cpus and no clock-divide in
> halt
[EMAIL PROTECTED] wrote on Sat, 12 Jan 2008 11:48 -0800:
if i boot an x86 64-bit 2.6.24-rc7 kernel with nosmp, maxcpus=0 or 1 it
still disables TSC :)
Marking TSC unstable due to TSCs unsynchronized
this is an opteron 2xx box which does have two cpus and no clock-divide in
halt or
Pete Wyckoff [EMAIL PROTECTED] writes:
We've seen the same problem. We use gettimeofday() for timing of
network-ish operations on the order of 10-50 us. But not having
the TSC makes gettimeofday() itself very slow, on the order of 30 us.
Here's what we've been using for quite a few kernel
if i boot an x86 64-bit 2.6.24-rc7 kernel with nosmp, maxcpus=0 or 1 it
still disables TSC :)
Marking TSC unstable due to TSCs unsynchronized
this is an opteron 2xx box which does have two cpus and no clock-divide in
halt or cpufreq enabled so TSC should be fine with only one cpu.
pretty sure
if i boot an x86 64-bit 2.6.24-rc7 kernel with nosmp, maxcpus=0 or 1 it
still disables TSC :)
Marking TSC unstable due to TSCs unsynchronized
this is an opteron 2xx box which does have two cpus and no clock-divide in
halt or cpufreq enabled so TSC should be fine with only one cpu.
pretty sure
10 matches
Mail list logo
