I have been running a plug in for xmms for some time that uses the
aviplay program and avifile library...then when upgrading to test5/6 I
start getting this error message when running xmms:
ERROR: no time-stamp counter found! Quitting.
I finally trace it down to my avi plugin and then from there to the
actual aviplay program. I have played with a newer version that had
more specific error messages one of which told me I had a non-intel
compatible x86 with no time-stamp counter and to use ./configure
--disable-tsc to fix the situation, this is all well and good if the
plugin didn't rely on an older version where even using the config
option will not work, here is my /proc/cpuinfo which shows tsc but
something has got to be wrong with it in recent versions.
contents of /proc/cpuinfo:
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 8
model name : Pentium III (Coppermine)
stepping : 3
cpu MHz : 733.000092
cache size : 256 KB
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 2
wp : yes
features : fpu vme de pse tsc msr pae mce cx8 sep mtrr pge mca
cmov pat pse36 mmx fxsr sse
bogomips : 1461.45
Jordan Breeding
Jordan writes:
> I have been running a plug in for xmms for some time that uses the
> aviplay program and avifile library...then when upgrading to test5/6 I
> start getting this error message when running xmms:
>
> ERROR: no time-stamp counter found! Quitting.
> ...
> contents of /proc/cpuinfo:
> ...
> features : fpu vme de pse tsc msr pae mce cx8 sep mtrr pge mca
The 'flags' line in /proc/cpuinfo was recently renamed 'features', due to
some semantic changes. You have a user-space program which parses /proc/cpuinfo
instead of executing CPUID itself, so it breaks.
/Mikael
On Fri, 17 Nov 2000, Mikael Pettersson wrote:
> You have a user-space program which parses /proc/cpuinfo instead of
> executing CPUID itself, so it breaks.
Hi Mikael,
Arguably, it is always better to parse /proc/cpuinfo instead of executing
CPUID directly (think PCI -- drivers should _NOT_ get their irq/io/etc
values from config space directly but only what the kernel puts on a plate
for them in the struct pci_dev).
So, one could imagine the kernel which emulates in software some of the
processor features and then CPUID would lie but /proc/cpuinfo would tell
the truth.
Also, Linux is very stable wrt to application interfaces (I compare Linux
with Linux and not Linux with "non-Linux", cf 1Cor 2:13) so one can safely
rely on the exported data formats to stay always the same (to a reasonable
extent).
Regards,
Tigran
On Fri, Nov 17, 2000 at 12:39:59PM +0100, Mikael Pettersson wrote:
> Jordan writes:
> > I have been running a plug in for xmms for some time that uses the
> > aviplay program and avifile library...then when upgrading to test5/6 I
> > start getting this error message when running xmms:
> >
> > ERROR: no time-stamp counter found! Quitting.
> > ...
> > contents of /proc/cpuinfo:
> > ...
> > features : fpu vme de pse tsc msr pae mce cx8 sep mtrr pge mca
>
> The 'flags' line in /proc/cpuinfo was recently renamed 'features', due to
> some semantic changes. You have a user-space program which parses /proc/cpuinfo
> instead of executing CPUID itself, so it breaks.
The program would be broken if it executed CPUID itself, because it has no way to guarantee
that the CPUID is executed on all CPUs the scheduler may later move the task too.
I think it is also nasty to break non broken programs this way, looking for
flags in /proc/cpuinfo is the only reliable way to do the checks on 2.2.
-Andi (proud owner of an AMP system with one CPU implementing FXSR and one not,
which causes lots of interesting problems)
> > You have a user-space program which parses /proc/cpuinfo instead of
> > executing CPUID itself, so it breaks.
>
> Arguably, it is always better to parse /proc/cpuinfo instead of executing
Actually this is definitively the case.
It is not safe to use cpuid to check the availability of RDTSC in Linux because
the CPU itself does not know if the TSC is buggy (Some MediaGX, some WinChip,..)
or if the TSC on an SMP box is constant across all processors.
Even checking the cpuinfo for the TSC should be done with care, and its far
far better to use gettimeofday unless doing very tiny timings (eg for
optimising code paths)
Alan
On Fri, Nov 17, 2000 at 01:04:18PM +0100, Andi Kleen wrote:
> The program would be broken if it executed CPUID itself, because it has no way to guarantee
> that the CPUID is executed on all CPUs the scheduler may later move the task too.
I wonder what's the right way for an app to ask the kernel if, for example,
tsc is available. As you stated above, executing CPUID is probably wrong.
But if the process parses /proc/cpuinfo, it has to make sure tsc is available
on all cpus it may run on, doesn't it?
What about some system call stating 'I want to use feature XYZ'. If all CPUs
implement XYZ, the system call simply returns some ACK, and NACK if no CPU
implements it (and no emulation is available).
If only some CPUs implement the feature, the kernel may return NACK,
or it may make sure the process will only run on CPUs implementing the
feature and return ACK. Is this usefull? It's just an idea ;-) I wonder
if there are many features that may be available only on some CPUs in an
'SMP' system.
Jan
On Fri, Nov 17, 2000 at 01:14:30PM +0100, Jan Niehusmann wrote:
> On Fri, Nov 17, 2000 at 01:04:18PM +0100, Andi Kleen wrote:
> > The program would be broken if it executed CPUID itself, because it has no way to guarantee
> > that the CPUID is executed on all CPUs the scheduler may later move the task too.
>
> I wonder what's the right way for an app to ask the kernel if, for example,
> tsc is available. As you stated above, executing CPUID is probably wrong.
> But if the process parses /proc/cpuinfo, it has to make sure tsc is available
> on all cpus it may run on, doesn't it?
Just check all the flags and fall back to the code not using the feature
if any doesn't support it.
>
> What about some system call stating 'I want to use feature XYZ'. If all CPUs
> implement XYZ, the system call simply returns some ACK, and NACK if no CPU
> implements it (and no emulation is available).
That would strike me as overkill.
>
> If only some CPUs implement the feature, the kernel may return NACK,
> or it may make sure the process will only run on CPUs implementing the
> feature and return ACK. Is this usefull? It's just an idea ;-) I wonder
> if there are many features that may be available only on some CPUs in an
> 'SMP' system.
Generally it is probably a rare case, otherwise there would be more bug reports
on it (because e.g. for the FXSR case a lot of SSE supporting kernels panic
on boot)
-Andi
Hi Alan,
On Fri, 17 Nov 2000, Alan Cox wrote:
> Even checking the cpuinfo for the TSC should be done with care, and
> its far far better to use gettimeofday unless doing very tiny
> timings (eg for optimising code paths)
gettimeofday is _way_ to slow for a lot of every day uses. So
applications will use rdtsc until we have some really fast
(non-syscall) way to have high resolution time diffs.
Greetings
Christoph
Christoph Rohland wrote:
>
> Hi Alan,
>
> On Fri, 17 Nov 2000, Alan Cox wrote:
> > Even checking the cpuinfo for the TSC should be done with care, and
> > its far far better to use gettimeofday unless doing very tiny
> > timings (eg for optimising code paths)
>
> gettimeofday is _way_ to slow for a lot of every day uses. So
> applications will use rdtsc until we have some really fast
> (non-syscall) way to have high resolution time diffs.
IIRC, this came up a long time ago WRT Apache, which made a lot of
gettimeofday() calls. Someone (Linus?) proposed the solution of a
'magic page' which holds information like gettimeofday() stuff, but
could be handled much more rapidly than a standard syscall.
--
Jeff Garzik |
Building 1024 | The chief enemy of creativity is "good" sense
MandrakeSoft | -- Picasso
Hi Jeff,
On Fri, 17 Nov 2000, Jeff Garzik wrote:
> IIRC, this came up a long time ago WRT Apache, which made a lot of
> gettimeofday() calls. Someone (Linus?) proposed the solution of a
> 'magic page' which holds information like gettimeofday() stuff, but
> could be handled much more rapidly than a standard syscall.
Yes, I followed that thread closely and would love to see this as the
implementation for gettimeofday. This would make rdtsc for
applications superfluous.
Greetings
Christoph
It used to be..
flags : fpu vme de pse tsc msr pae
but now called features
It's a simple enough change. Contact me privately if you can't any
avifile people to help.
Jordan wrote:
>
> I have been running a plug in for xmms for some time that uses the
> aviplay program and avifile library...then when upgrading to test5/6 I
> start getting this error message when running xmms:
>
> ERROR: no time-stamp counter found! Quitting.
>
> I finally trace it down to my avi plugin and then from there to the
> actual aviplay program. I have played with a newer version that had
> more specific error messages one of which told me I had a non-intel
> compatible x86 with no time-stamp counter and to use ./configure
> --disable-tsc to fix the situation, this is all well and good if the
> plugin didn't rely on an older version where even using the config
> option will not work, here is my /proc/cpuinfo which shows tsc but
> something has got to be wrong with it in recent versions.
>
> contents of /proc/cpuinfo:
>
> processor : 0
> vendor_id : GenuineIntel
> cpu family : 6
> model : 8
> model name : Pentium III (Coppermine)
> stepping : 3
> cpu MHz : 733.000092
> cache size : 256 KB
> fdiv_bug : no
> hlt_bug : no
> f00f_bug : no
> coma_bug : no
> fpu : yes
> fpu_exception : yes
> cpuid level : 2
> wp : yes
> features : fpu vme de pse tsc msr pae mce cx8 sep mtrr pge mca
> cmov pat pse36 mmx fxsr sse
> bogomips : 1461.45
>
> Jordan Breeding
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> Please read the FAQ at http://www.tux.org/lkml/
--
=====================================================================
Mohammad A. Haque http://www.haque.net/
[email protected]
"Alcohol and calculus don't mix. Project Lead
Don't drink and derive." --Unknown http://wm.themes.org/
[email protected]
=====================================================================
On Fri, Nov 17, 2000 at 02:21:03PM +0100, Christoph Rohland wrote:
> Hi Jeff,
>
> On Fri, 17 Nov 2000, Jeff Garzik wrote:
> > IIRC, this came up a long time ago WRT Apache, which made a lot of
> > gettimeofday() calls. Someone (Linus?) proposed the solution of a
> > 'magic page' which holds information like gettimeofday() stuff, but
> > could be handled much more rapidly than a standard syscall.
>
> Yes, I followed that thread closely and would love to see this as the
> implementation for gettimeofday. This would make rdtsc for
> applications superfluous.
No it would not. Often you want cycle accurate couting for profiling
purposes.
-Andi
Hmm, my CPUID vs /proc/cpuinfo comment seemed somewhat controversial.
Tigran Aivazian wrote:
> Arguably, it is always better to parse /proc/cpuinfo instead of executing
> CPUID directly (think PCI -- drivers should _NOT_ get their irq/io/etc
> values from config space directly but only what the kernel puts on a plate
> for them in the struct pci_dev).
In priciple I would agree, but CPUID is a lot easier to use than to open and
parse /proc/cpuinfo, specially when the format of the latter changes...
> So, one could imagine the kernel which emulates in software some of the
> processor features and then CPUID would lie but /proc/cpuinfo would tell
> the truth.
In this case, I'd REALLY like to know whether the feature is emulated or not.
Imagine a kernel emulating MMX instructions, with a 10x performance loss.
My MPEG viewer has builtin support for MMX and non-MMX capable processors,
with the non-MMX version 2x slower. On a non-MMX processor, we'll still
be a lot better off using the non-MMX rendering libs.
In other cases it may not matter, only the user can tell.
Andi Kleen wrote:
> The program would be broken if it executed CPUID itself, because it has no way to guarantee
> that the CPUID is executed on all CPUs the scheduler may later move the task too.
> ...
> -Andi (proud owner of an AMP system with one CPU implementing FXSR and one not,
> which causes lots of interesting problems)
Yes, this is a problem. There are two alternatives:
- hpa's cpuid driver lets you execute cpuid on a specific processor
(but it's an optional driver, so you can't count on it)
- Something like Solaris' processor_bind() which lets a user-space application
"bind" itself to a given processor. AFAIK, Linux doesn't have this :-(
Alan Cox wrote:
> It is not safe to use cpuid to check the availability of RDTSC in Linux because
> the CPU itself does not know if the TSC is buggy (Some MediaGX, some WinChip,..)
User-space can also check vendor/family/mode/stepping values and choose not to
trust certain announced feature flags. No big deal.
> or if the TSC on an SMP box is constant across all processors.
A recurring theme: asymmetric MP boxen :-(
Yeah, you and Andi are right, asymmetric MP boxen require kernel support.
I didn't consider that case...
/Mikael
Andi Kleen wrote:
> No it would not. Often you want cycle accurate couting for profiling
> purposes.
Isn't that why /dev/cpu/%d/msr exists?
--
Jeff Garzik |
Building 1024 | The chief enemy of creativity is "good" sense
MandrakeSoft | -- Picasso
On Fri, Nov 17, 2000 at 08:40:27AM -0500, Jeff Garzik wrote:
> Andi Kleen wrote:
> > No it would not. Often you want cycle accurate couting for profiling
> > purposes.
>
> Isn't that why /dev/cpu/%d/msr exists?
Requires either root privileges or is a big security hole.
[of course rdtsc only works properly on UP or with bind_cpu()]
-Andi
On Fri, 17 Nov 2000, Andi Kleen wrote:
> [of course rdtsc only works properly on UP or with bind_cpu()]
I thought Linux kernel does synchronize them on boot? So, you are saying I
cannot rely on this being 100% correct?
Regards,
Tigran
Hi Tigran,
On Fri, 17 Nov 2000, Tigran Aivazian wrote:
> On Fri, 17 Nov 2000, Andi Kleen wrote:
>> [of course rdtsc only works properly on UP or with bind_cpu()]
>
> I thought Linux kernel does synchronize them on boot? So, you are
> saying I cannot rely on this being 100% correct?
Yes, it does so far. And if we cannot assume this to be correct in the
microsecond scale on smp machines with homogenous non-powersaving cpus
we will loose on some benchmarks. So far it works on all our servers.
Greetings
Christoph
> > I thought Linux kernel does synchronize them on boot? So, you are
> > saying I cannot rely on this being 100% correct?
>
> Yes, it does so far. And if we cannot assume this to be correct in the
> microsecond scale on smp machines with homogenous non-powersaving cpus
> we will loose on some benchmarks. So far it works on all our servers.
It works on most machines. Nothing in the intel specifications says it works.
We cope with offset TSC's in the kernel and those are unusual but exist. If
you have two differently clocked cpus you have to boot notsc.
On Fri, Nov 17, 2000 at 01:51:11PM +0100, Christoph Rohland wrote:
> gettimeofday is _way_ to slow for a lot of every day uses. So
> applications will use rdtsc until we have some really fast
> (non-syscall) way to have high resolution time diffs.
During the x86-64 design I made sure that in x86-64 glibc will only know about
vgettimeofday (vsyscall).
If the machine is Asymetric MP with CPU running at different frequency (so that
you need to know on which CPU you're running on to use rdtsc) the kernel will
setup the vsyscall trampoline to fallback in the real slow syscall (but all SMP
and UP machines will not need to enter/exit kernel this way and the vsyscall
will be completly lock less... for obvious reasons :).
So as worse you'll have to wait x86-64 to get that lightweight vgettimeofday.
Andrea
Hi Andrea,
On Fri, 17 Nov 2000, Andrea Arcangeli wrote:
> So as worse you'll have to wait x86-64 to get that lightweight
> vgettimeofday.
Could I get this for i686? :-)
Greetings
Christoph
On Fri, Nov 17, 2000 at 05:06:49PM +0100, Christoph Rohland wrote:
> Could I get this for i686? :-)
If we break binary compatibility yes. I mean: new glibc binaries wouldn't
run anymore on older kernels. Also new static binaries wouldn't run
anymore on older kernels. At least if we don't introduce runtime
checks to guess if current kernel supports vsyscall or not (and if we do
that it means we're adding slow checks in an extremely fast path and that's
not what we want :).
As about the broken calling conventions of the IA32 ABI, I think it doesn't
worth to break the binary compatibility at this late stage.
Andrea
Andrea Arcangeli <[email protected]> writes:
> On Fri, Nov 17, 2000 at 05:06:49PM +0100, Christoph Rohland wrote:
> > Could I get this for i686? :-)
>
> If we break binary compatibility yes.
OK, I'll stick to rdtsc on ix86
Christoph
> As about the broken calling conventions of the IA32 ABI, I think it
> doesn't worth to break the binary compatibility at this late stage.
We are not at any late stage. The new 64-bit PC processors might
be accepted about as well as Microchannel and EISA were accepted.
Crummy old 32-bit processors will be around much longer than we'd
like them to be.