Opened 15 years ago

Last modified 4 years ago

#4644 assigned bug

[AboutSystem] Celeron is detected as Pentium III

Reported by: totish Owned by: waddlesplash
Priority: low Milestone: Unscheduled
Component: Applications/AboutSystem Version: R1/alpha1
Keywords: Cc:
Blocked By: Blocking:
Platform: All

Description

Attachments (5)

screenshot8.png (89.0 KB ) - added by totish 15 years ago.
sysinfo.txt (1.1 KB ) - added by totish 15 years ago.
AboutSystem.2.png (34.5 KB ) - added by totish 15 years ago.
AboutSystem.png (34.5 KB ) - added by totish 15 years ago.
cat_proc_cpuinfo.txt (395 bytes ) - added by totish 15 years ago.
created under Ubuntu 7.0.4 LiveCD

Download all attachments as: .zip

Change History (18)

by totish, 15 years ago

Attachment: screenshot8.png added

by totish, 15 years ago

Attachment: sysinfo.txt added

comment:1 by mmadia, 15 years ago

related to #3541

by totish, 15 years ago

Attachment: AboutSystem.2.png added

by totish, 15 years ago

Attachment: AboutSystem.png added

by totish, 15 years ago

Attachment: cat_proc_cpuinfo.txt added

created under Ubuntu 7.0.4 LiveCD

comment:2 by siarzhuk, 15 years ago

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

Last edited 11 years ago by mmadia (previous) (diff)

comment:3 by bonefish, 15 years ago

Owner: changed from bonefish to nobody
Status: newassigned

in reply to:  2 ; comment:4 by v, 15 years ago

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:

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

in reply to:  4 ; comment:5 by siarzhuk, 15 years ago

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

in reply to:  5 ; comment:6 by v, 15 years ago

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.

in reply to:  6 ; comment:7 by siarzhuk, 15 years ago

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?

in reply to:  7 comment:8 by v, 15 years ago

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

in reply to:  7 comment:9 by v, 15 years ago

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

comment:10 by pulkomandy, 10 years ago

Priority: normallow

comment:11 by pulkomandy, 4 years ago

Milestone: R1Unscheduled

comment:12 by waddlesplash, 4 years ago

Owner: changed from nobody to waddlesplash

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

comment:13 by waddlesplash, 4 years ago

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

Note: See TracTickets for help on using tickets.