[AboutSystem] Celeron is detected as Pentium III

[mmadia]

related to #3541

[totish]

created under Ubuntu 7.0.4 LiveCD

[siarzhuk]

Note that according to clause 4.1 of "Intel Processor Identification and CPUID function" application Note 485 ​http://www.intel.com/Assets/PDF/appnote/241618.pdf "Beginning with Pentium III processors the processor identification was further extended with addition of Brand ID". At the current state of CPU identification n Haiku OS only extended family, extended model, family and model values are taken into account. Looks like the mentioned CPU mis-identification can be correctly fixed only by adding Brand ID to corresponding cpu_type defines.

Does this improvement have any practical purpose beside of cosmetic and demonstration ones?

[v]

Replying to siarzhuk:

Does this improvement have any practical purpose beside of cosmetic and demonstration ones?

Probably not, there are several CPU's that are currently further identified by their CPU model string since: ​http://dev.haiku-os.org/changeset/33462#file1

Note: this change was made after this bug was reported. Some checking should be done if this bug is still valid.
Judging by:

• cat_proc_cpuinfo.txt's "cpu family : 6" and "model : 8",
  
• ​http://dev.haiku-os.org/browser/haiku/trunk/headers/os/kernel/OS.h#L485 's "B_CPU_INTEL_PENTIUM_III_MODEL_8 = 0x1068,"
  
• ​http://dev.haiku-os.org/browser/haiku/trunk/src/system/kernel/arch/x86/arch_system_info.cpp#L78 's arch_system_info_init() , and
  
• ​http://dev.haiku-os.org/browser/haiku/trunk/headers/private/shared/cpu_type.h#L166 's B_CPU_INTEL_PENTIUM_III_MODEL_8 case
  

the bug might still be valid, provided the reporter and CPU model string aren't wrong about it being a Celeron.

[siarzhuk]

Replying to v:

the bug might still be valid, provided the reporter and CPU model string aren't wrong about it being a Celeron.

AFAIR, "Intel Processor Identification and CPUID function" requires to investigate contents of Brand ID register to distingush Celeron from PIII.

IMO, all those "pagan dances" with parsing of model strings have nothign to do with consistency and should be thrown away. :-\

[v]

Replying to siarzhuk:

AFAIR, "Intel Processor Identification and CPUID function" requires to investigate contents of Brand ID register to distingush Celeron from PIII.

IMO, all those "pagan dances" with parsing of model strings have nothign to do with consistency and should be thrown away. :-\

Chapter 6, of the document you point at, prefers the Brand String (what I referred to as 'model string') over Brand ID.

[siarzhuk]

Replying to v:

Replying to siarzhuk:

AFAIR, "Intel Processor Identification and CPUID function" requires to investigate contents of Brand ID register to distingush Celeron from PIII.

IMO, all those "pagan dances" with parsing of model strings have nothign to do with consistency and should be thrown away. :-\

Chapter 6, of the document you point at, prefers the Brand String (what I referred to as 'model string') over Brand ID.

But there are nothing about parsing and interpreting it in any way. The whole brand string is mentioned as identifier but not parts of it. :-\ So we have to "cast" it into our numerical identifiers in some way. And such casting cannot be strict and robust in any way.

The Question is: Are we need this BeOS legacy numerical identifiers? May be only brand string will be enough?

[v]

The Question is: Are we need this BeOS legacy numerical identifiers? May be only brand string will be enough?

In my opinion, that would be a good question for post-R1 development, but perhaps others have an opinion on the matter.
(Although, I hope you don't mean relying on Brand String only means displaying the Brand String. Considering the amount of junk Intel (for example) puts in it, that would look very ugly.)

[v]

The Question is: Are we need this BeOS legacy numerical identifiers? May be only brand string will be enough?

In my opinion, a good question for post-R1 development. Maybe some more people have an opinion on this. (I hope by relying on Brand Strings only, you don't mean using them without modification. Considering the amount of junk Intel (for example) puts in them, that would be very ugly.)

Now, regarding the original bugreport, I don't have a up-to-date haiku tree to create a patch to fix it with get_cpuid_model_string(). So if someone thinks Brand IDs are the way to go, I think bringing the issue up on the haiku-development mailinglist might be the way to go (or go right ahead and do it if you have commit permissions).

[waddlesplash]

We probably should use the cleaned-up brand string when it is available, to be honest.

[waddlesplash]

(Assigning to myself so I don't forget this ticket exists, but I'm not sure precisely when I'll get around to it.)