Error in x86 CPU capabilities starting with test5/6

DISCUSSION Jordan 12 participants 24 messages Nov 17, 2000 – Nov 19, 2000

Share & tools

Jordan

author

2000-11-17 10:20 UTC #0 lore raw

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/

Mikael Pettersson

2000-11-17 12:10 UTC #1 lore raw

Quoted 9 lines · Jordan

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
-
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/

Tigran Aivazian

2000-11-17 12:30 UTC #2 lore raw

Quoted 2 lines · Mikael Pettersson

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

-
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/

Andi Kleen

2000-11-17 12:34 UTC #20 lore raw

In reply to Jordan

Quoted 11 lines · Mikael Pettersson

Quoted 9 lines · Jordan
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

Quoted 3 lines

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)
-
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/

Alan Cox

2000-11-17 12:39 UTC #3 lore raw

In reply to Tigran Aivazian

Quoted 4 lines

Quoted 2 lines
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

-
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/

Jan Niehusmann

2000-11-17 12:45 UTC #21 lore raw

In reply to Jordan

Quoted 2 lines · Andi Kleen

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

-
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/

Andi Kleen

2000-11-17 12:52 UTC #22 lore raw

In reply to Jordan

Quoted 8 lines · Jan Niehusmann

Quoted 2 lines · Andi Kleen
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.

Quoted 4 lines

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.

Quoted 6 lines

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

-
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/

Christoph Rohland

2000-11-17 13:22 UTC #4 lore raw

In reply to Alan Cox

Hi Alan,

Quoted 3 lines · Alan Cox

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

-
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/

Jeff Garzik

2000-11-17 13:39 UTC #5 lore raw

In reply to Alan Cox

Quoted 11 lines · Christoph Rohland

Hi Alan,
Quoted 3 lines · Alan Cox
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.

Signature · 7 lines

Jeff Garzik             |
Building 1024           | The chief enemy of creativity is "good" sense
MandrakeSoft            |          -- Picasso
-
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/

Christoph Rohland

2000-11-17 13:51 UTC #6 lore raw

In reply to Alan Cox

Hi Jeff,

Quoted 4 lines · Jeff Garzik

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

-
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

2000-11-17 13:56 UTC #23 lore raw

In reply to Jordan

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.

Quoted 43 lines · Jordan

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/

Signature · 12 lines

=====================================================================
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]
=====================================================================
-
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/

Andi Kleen

2000-11-17 14:05 UTC #7 lore raw

In reply to Alan Cox

Quoted 11 lines · Christoph Rohland

Hi Jeff,
Quoted 4 lines · Jeff Garzik
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
-
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/

Mikael Pettersson

2000-11-17 14:08 UTC #8 lore raw

In reply to Alan Cox

Hmm, my CPUID vs /proc/cpuinfo comment seemed somewhat controversial.

Quoted 4 lines · Tigran Aivazian

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...

Quoted 3 lines

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.

Quoted 5 lines · Andi Kleen

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 :-(

Quoted 2 lines · Alan Cox

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.

Quoted 1 line

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
-
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/

Jeff Garzik

2000-11-17 14:11 UTC #9 lore raw

In reply to Alan Cox

Quoted 2 lines · Andi Kleen

No it would not. Often you want cycle accurate couting for profiling purposes.

Isn't that why /dev/cpu/%d/msr exists?

Signature · 7 lines

Jeff Garzik             |
Building 1024           | The chief enemy of creativity is "good" sense
MandrakeSoft            |          -- Picasso
-
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/

Andi Kleen

2000-11-17 14:27 UTC #10 lore raw

In reply to Alan Cox

Quoted 5 lines · Jeff Garzik

Quoted 2 lines · Andi Kleen
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
-
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/

Arjan van de Ven

2000-11-17 14:32 UTC #14 lore raw

In reply to Alan Cox

Quoted 5 lines · In article <[email protected]> you wrote:

Quoted 2 lines · Andi Kleen
No it would not. Often you want cycle accurate couting for profiling purposes.
Isn't that why /dev/cpu/%d/msr exists?

This is root only though......

(Yes, you can crash AMD boxes by reading MSR's)

Greetings,
Arjan van de Ven

-
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/

Tigran Aivazian

2000-11-17 14:37 UTC #11 lore raw

In reply to Andi Kleen

Quoted 1 line · Andi Kleen

[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

-
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/

Christoph Rohland

2000-11-17 15:01 UTC #12 lore raw

Hi Tigran,

Quoted 5 lines · Tigran Aivazian

Quoted 1 line · Andi Kleen
[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

-
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/

Alan Cox

2000-11-17 15:20 UTC #13 lore raw

Quoted 6 lines

Quoted 2 lines
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.

-
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/

Andrea Arcangeli

2000-11-17 15:50 UTC #15 lore raw

In reply to Alan Cox

Quoted 3 lines · Christoph Rohland

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
-
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/

Christoph Rohland

2000-11-17 16:37 UTC #16 lore raw

In reply to Alan Cox

Hi Andrea,

Quoted 2 lines · Andrea Arcangeli

So as worse you'll have to wait x86-64 to get that lightweight vgettimeofday.

Could I get this for i686? :-)

Greetings
Christoph

-
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/

Andrea Arcangeli

2000-11-17 18:59 UTC #17 lore raw

In reply to Alan Cox

Quoted 1 line · Christoph Rohland

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
-
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/

Christoph Rohland

2000-11-18 15:03 UTC #19 lore raw

In reply to Alan Cox

Quoted 4 lines · Andrea Arcangeli

Quoted 1 line · Christoph Rohland
Could I get this for i686? :-)
If we break binary compatibility yes.

OK, I'll stick to rdtsc on ix86

Christoph

-
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/

Albert D. Cahalan

2000-11-19 11:01 UTC #18 lore raw

In reply to Andrea Arcangeli

Quoted 2 lines

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.

-
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/