Messages in this thread |  | | Date | Wed, 8 Nov 2000 10:10:45 -0800 (PST) | From | Linus Torvalds <> | Subject | Re: Pentium 4 and 2.4/2.5 |
| |
On Wed, 8 Nov 2000, Alan Cox wrote: > > unless that CPU is also SMP-capable). It's documented by intel these > > days, and it works on all CPU's I've ever heard of, and it even makes > > sense to me (*). > > Do the intel docs guarantee it works on i486 and higher, if so SMP athlon > will be the only check needed for the SMP users. You work for an x86 chip > cloning company so if you say it works I trust you 8)
Well, we don't make low-power SMP laptops, so as such Transmeta doesn't much care. It will work, though. And yes, as far as I know Intel made it an "architecture feature", meaning that they claim it work son all their ia32 chips.
Now, I could imagine that Intel would select an instruction that didn't work on Athlon on purpose, but I really don't think they did. I don't have an athlon to test.
It's easy enough to generate a test-program. If the following works, you're pretty much guaranteed that it's ok
int main() { printf("Testing 'rep nop' ... "); asm volatile("rep ; nop"); printf("okey-dokey\n"); return 0; }
(there's not much a "rep nop" _can_ do, after all - the most likely CPU extension would be to raise an "Illegal Opcode" fault).
> > Also, at least part of the reason Intel removed the TSC check was that > > Linux actually seems to get the extended CPU capability flags wrong, > > overwriting the _real_ capability flags which in turn caused the TSC > > check on Linux to simply not work. Peter Anvin is working on fixing > > this. I suspect that Linux-2.2 has the same problem. > > I've not seen incorrect TSC detection in 2.2, do you know the precise > circumstances this occurs and I'll check over them. I've also got no > bug reports of this failing.
It won't fail on other CPU's. The bug is, as far as I can tell, in get_model_name(),
cpuid(0x80000001, &dummy, &dummy, &dummy, &(c->x86_capability));
Notice how we overwrite the x86_capability state with whatever we read from the extended register 0x80000001. So we overwrite the _real_ capabilities that we got the right way in head.S.
This is wrong. It just happens to work on other, non-Pentium IV, processors. The extended capabilities are an _extention_, not replacement, for the regular capabilities.
> check_config would also panic with the 'Kernel compiled for ..' message > if it occurred.
Which is what it apparently does, if you compile for TSC. Even though very obviously a Pentium IV _does_ have a TSC.
NOTE! I don't actually have access to a Pentium IV myself yet, although I'm promised one soon enough. So I've only got second-hand reports on the cpuid thing so far.
Linus
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org Please read the FAQ at http://www.tux.org/lkml/
|  |