Closed zerkerX closed 2 months ago
Interesting. Could you run cpufetch --debug
, please?
Of course. Here's the result:
$ ./cpufetch --debug
cpufetch v1.04-37-gd221 (Linux x86_64 build)
Unknown
- Max standard level: 0x00000002
- Max extended level: 0x03020101
- Hybrid Flag: 0
- CPUID dump: 0x00000673
Also not sure why it's reporting itself as x86_64 on a 32-bit machine.
Okay, so there are a few things that we can try to solve (if you find more issues just let me know):
x86_64 build
while it is actually 32 bit.I have created a branch i220
with a new patch. Hopefully, this will fix the first problem. Can you check if it works? To attack the second issue I'll need the output of cpufetch --verbose
.
I agree it is not common to see an Intel Pentium, but I like messing around with old chips too :+1: and I would like to support as much hardware as possible in cpufetch.
Unfortunately, the new branch segfaults. Here's your stack trace:
Program received signal SIGSEGV, Segmentation fault.
__GI_strlen () at ../sysdeps/i386/i586/strlen.S:93
93 ../sysdeps/i386/i586/strlen.S: No such file or directory.
(gdb) bt
#0 __GI_strlen () at ../sysdeps/i386/i586/strlen.S:93
#1 0x0040703e in abbreviate_intel_cpu_name (name=0x41f1e4)
at src/x86/cpuid.c:127
#2 0x00408eb9 in get_str_cpu_name_abbreviated (cpu=0x41f1c0)
at src/x86/cpuid.c:966
#3 0x00401d2b in get_str_cpu_name (cpu=0x41f1c0, fcpuname=false)
at src/common/cpu.c:41
#4 0x00404e30 in print_cpufetch_x86 (cpu=0x41f1c0, s=0, cs=0x0,
term=0x41f310, fcpuname=false) at src/common/printer.c:559
#5 0x004054b2 in print_cpufetch (cpu=0x41f1c0, s=0, cs=0x0,
show_full_cpu_name=false) at src/common/printer.c:1090
#6 0x00401c44 in main (argc=1, argv=0xbffff564) at src/common/main.c:123
Let me know if you want me to inspect any variables too.
Here's the output of --verbose
from the new branch before it hits the segfault:
$ ./cpufetch --verbose
[WARNING]: Can't read CPU name from cpuid (needed extended level is 0x80000004, max is 0x03020101)
[WARNING]: Can't read features information from cpuid (needed level is 0x00000007, max is 0x00000002)
[WARNING]: Can't read features information from cpuid (needed extended level is 0x80000001, max is 0x03020101)
[WARNING]: Can't read frequency information from cpuid (needed level is 0x00000016, max is 0x00000002). Using udev
[WARNING]: Could not open '/sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_max_freq'
[WARNING]: Can't read cache information from cpuid (needed level is 0x00000004, max is 0x00000002)
Segmentation fault
And the equivalent on the master branch:
[WARNING]: Can't read cpu name from cpuid (needed extended level is 0x80000004, max is 0x03020101)
[WARNING]: Can't read features information from cpuid (needed level is 0x00000007, max is 0x00000002)
[WARNING]: Can't read features information from cpuid (needed extended level is 0x80000001, max is 0x03020101)
[WARNING]: Can't read frequency information from cpuid (needed level is 0x00000016, max is 0x00000002). Using udev
[WARNING]: Could not open '/sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_max_freq'
[WARNING]: Can't read cache information from cpuid (needed level is 0x00000004, max is 0x00000002)
[WARNING]: Failed to abbreviate CPU name
.#################.
.#### ####.
.## ###
## :## ###
# ## :## ##
## ## ######. #### ###### :## ## Name: Unknown
## ## ##: ##: ## ## ### :## ### uArch: P6 Pentium III
## ## ##: ##: ## :######## :## ## Technology: 2.50um
## ## ##: ##: ## ##. . :## #### Peak Perf.: Unknown
## # ##: ##: #### #####: ##
##
###. ..o####.
######oo... ..oo#######
o###############o
PS: I appreciate how quickly this tool builds, even on my humble P3.
I have pushed a fix, it should be working now.
About the frequency, it's tricky, because the CPU does not expose this value anywhere. I've been working on an experimental future for cases like this for a couple of months now, but I haven't published it yet because of a lack of time, but it should be live soon(ish). I'll post a comment here once it is live to see if it works for you.
PS: It is a bunch of C code so it is indeed quite fast!
You say that, but there are plenty of C programs with a lot more complexity and comparably longer compile times.
... it does still take 1:30 on this old clunker tho :wink:
Anyways, the branch unfortunately still segfaults. Looks like the old_name
is null.
(gdb) bt
#0 __GI_strlen () at ../sysdeps/i386/i586/strlen.S:93
#1 0x0040703e in abbreviate_intel_cpu_name (name=0x41f1e4) at src/x86/cpuid.c:127
#2 0x00408eb9 in get_str_cpu_name_abbreviated (cpu=0x41f1c0) at src/x86/cpuid.c:966
#3 0x00401d2b in get_str_cpu_name (cpu=0x41f1c0, fcpuname=false) at src/common/cpu.c:41
#4 0x00404e30 in print_cpufetch_x86 (cpu=0x41f1c0, s=0, cs=0x0, term=0x41f310, fcpuname=false) at src/common/printer.c:559
#5 0x004054b2 in print_cpufetch (cpu=0x41f1c0, s=0, cs=0x0, show_full_cpu_name=false) at src/common/printer.c:1090
#6 0x00401c44 in main (argc=1, argv=0xbffff564) at src/common/main.c:123
(gdb) frame 1
#1 0x0040703e in abbreviate_intel_cpu_name (name=0x41f1e4) at src/x86/cpuid.c:127
127 char* new_name = ecalloc(strlen(old_name) + 1, sizeof(char));
(gdb) p old_name
$1 = 0x0
Went up another frame and grabbed the struct for you too:
(gdb) frame 2
(gdb) p *cpu
$5 = {cpu_vendor = 0, arch = 0x41f250, hv = 0x41f230, freq = 0x41f280, cach = 0x0, topo = 0x0, peak_performance = -1, feat = 0x41f210,
cpu_name = 0x0, maxLevels = 2, maxExtendedLevels = 50462977, topology_extensions = false, hybrid_flag = false, core_type = 0, next_cpu = 0x0,
num_cpus = 0 '\000', first_core_id = 0}
Finally, if it's useful, here's the recursive listing of the sys
folder for the cpu:
/sys/devices/system/cpu/cpu0:
cpuidle crash_notes crash_notes_size driver firmware_node hotplug microcode power subsystem topology uevent
/sys/devices/system/cpu/cpu0/cpuidle:
state0 state1 state2
/sys/devices/system/cpu/cpu0/cpuidle/state0:
above below default_status desc disable latency name power rejected residency time usage
/sys/devices/system/cpu/cpu0/cpuidle/state1:
above below default_status desc disable latency name power rejected residency time usage
/sys/devices/system/cpu/cpu0/cpuidle/state2:
above below default_status desc disable latency name power rejected residency time usage
/sys/devices/system/cpu/cpu0/hotplug:
fail state target
/sys/devices/system/cpu/cpu0/microcode:
processor_flags version
/sys/devices/system/cpu/cpu0/power:
async control runtime_active_kids runtime_enabled runtime_suspended_time
autosuspend_delay_ms pm_qos_resume_latency_us runtime_active_time runtime_status runtime_usage
/sys/devices/system/cpu/cpu0/topology:
cluster_cpus cluster_id core_cpus_list core_siblings die_cpus die_id package_cpus_list thread_siblings
cluster_cpus_list core_cpus core_id core_siblings_list die_cpus_list package_cpus physical_package_id thread_siblings_list
You say that, but there are plenty of C programs with a lot more complexity and comparably longer compile times.
... it does still take 1:30 on this old clunker tho đŸ˜‰
Anyways, the branch unfortunately still segfaults. Looks like the
old_name
is null.(gdb) bt #0 __GI_strlen () at ../sysdeps/i386/i586/strlen.S:93 #1 0x0040703e in abbreviate_intel_cpu_name (name=0x41f1e4) at src/x86/cpuid.c:127 #2 0x00408eb9 in get_str_cpu_name_abbreviated (cpu=0x41f1c0) at src/x86/cpuid.c:966 #3 0x00401d2b in get_str_cpu_name (cpu=0x41f1c0, fcpuname=false) at src/common/cpu.c:41 #4 0x00404e30 in print_cpufetch_x86 (cpu=0x41f1c0, s=0, cs=0x0, term=0x41f310, fcpuname=false) at src/common/printer.c:559 #5 0x004054b2 in print_cpufetch (cpu=0x41f1c0, s=0, cs=0x0, show_full_cpu_name=false) at src/common/printer.c:1090 #6 0x00401c44 in main (argc=1, argv=0xbffff564) at src/common/main.c:123 (gdb) frame 1 #1 0x0040703e in abbreviate_intel_cpu_name (name=0x41f1e4) at src/x86/cpuid.c:127 127 char* new_name = ecalloc(strlen(old_name) + 1, sizeof(char)); (gdb) p old_name $1 = 0x0
Went up another frame and grabbed the struct for you too:
(gdb) frame 2 (gdb) p *cpu $5 = {cpu_vendor = 0, arch = 0x41f250, hv = 0x41f230, freq = 0x41f280, cach = 0x0, topo = 0x0, peak_performance = -1, feat = 0x41f210, cpu_name = 0x0, maxLevels = 2, maxExtendedLevels = 50462977, topology_extensions = false, hybrid_flag = false, core_type = 0, next_cpu = 0x0, num_cpus = 0 '\000', first_core_id = 0}
Finally, if it's useful, here's the recursive listing of the
sys
folder for the cpu:/sys/devices/system/cpu/cpu0: cpuidle crash_notes crash_notes_size driver firmware_node hotplug microcode power subsystem topology uevent /sys/devices/system/cpu/cpu0/cpuidle: state0 state1 state2 /sys/devices/system/cpu/cpu0/cpuidle/state0: above below default_status desc disable latency name power rejected residency time usage /sys/devices/system/cpu/cpu0/cpuidle/state1: above below default_status desc disable latency name power rejected residency time usage /sys/devices/system/cpu/cpu0/cpuidle/state2: above below default_status desc disable latency name power rejected residency time usage /sys/devices/system/cpu/cpu0/hotplug: fail state target /sys/devices/system/cpu/cpu0/microcode: processor_flags version /sys/devices/system/cpu/cpu0/power: async control runtime_active_kids runtime_enabled runtime_suspended_time autosuspend_delay_ms pm_qos_resume_latency_us runtime_active_time runtime_status runtime_usage /sys/devices/system/cpu/cpu0/topology: cluster_cpus cluster_id core_cpus_list core_siblings die_cpus die_id package_cpus_list thread_siblings cluster_cpus_list core_cpus core_id core_siblings_list die_cpus_list package_cpus physical_package_id thread_siblings_list
My bad, it should be working now :+1:
Okay, it works again, though we're basically back to the original situation.
Verbose:
[WARNING]: Can't read CPU name from cpuid (needed extended level is 0x80000004, max is 0x03020101)
[ERROR]: infer_cpu_name_from_uarch: Unable to find CPU name
[VERSION]: cpufetch v1.04-40-geec2 (Linux x86_64 build)
[WARNING]: Can't read features information from cpuid (needed level is 0x00000007, max is 0x00000002)
[WARNING]: Can't read features information from cpuid (needed extended level is 0x80000001, max is 0x03020101)
[WARNING]: Can't read frequency information from cpuid (needed level is 0x00000016, max is 0x00000002). Using udev
[WARNING]: Could not open '/sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_max_freq'
[WARNING]: Can't read cache information from cpuid (needed level is 0x00000004, max is 0x00000002)
[WARNING]: Failed to abbreviate CPU name
.#################.
.#### ####.
.## ###
## :## ###
# ## :## ##
## ## ######. #### ###### :## ## Name: Unknown
## ## ##: ##: ## ## ### :## ### uArch: P6 (Pentium III)
## ## ##: ##: ## :######## :## ## Technology: 2.50um
## ## ##: ##: ## ##. . :## #### Peak Perf.: Unknown
## # ##: ##: #### #####: ##
##
###. ..o####.
######oo... ..oo#######
o###############o
Debug results:
[ERROR]: infer_cpu_name_from_uarch: Unable to find CPU name
[VERSION]: cpufetch v1.04-40-geec2 (Linux x86_64 build)
cpufetch v1.04-40-geec2 (Linux x86_64 build)
Unknown
- Max standard level: 0x00000002
- Max extended level: 0x03020101
- Hybrid Flag: 0
- CPUID dump: 0x00000673
Updated. I think this is it :sweat_smile:
It has a name now!
.#################.
.#### ####.
.## ###
## :## ###
# ## :## ##
## ## ######. #### ###### :## ## Name: Intel Pentium III
## ## ##: ##: ## ## ### :## ### uArch: P6 (Pentium III)
## ## ##: ##: ## :######## :## ## Technology: 2.50um
## ## ##: ##: ## ##. . :## #### Peak Perf.: Unknown
## # ##: ##: #### #####: ##
##
###. ..o####.
######oo... ..oo#######
o###############o
Another possible fallback would be to grab the more detailed name from /proc/cpuinfo
; as per above that at least knows the model name is Katmai.
I see you're covering your bases for the platform in the debug/version text :smile:
cpufetch v1.04-41-gc885 (Linux x86 / x86_64 build)
If you get more features added, I'd be happy to keep testing.
So Katmai is the "core name" or "codename", something that cpufetch does not support yet even though I've considered adding it for a long time (see #120). This now makes me realize again this is important. For now, I've added it as part of the microarchitecture which does not look too bad in my opinion.
I have also fixed the manufacturing process because it was showing you 2.50um, e.g., 2500nm, but that's wrong, it should be actually 250nm. And as you already noticed, now it prints x86 / x86_64 build
. It would be possible to differentiate between x86 / x86_64 but my intention in that message is just to have a quick idea about the build.
I think this is all, just let me know if you find something is missing. The support for the frequency will arrive later and will also enable the computation of the peak performance which currently is being reported as "unknown" because without the frequency we cannot compute it. I'll keep the issue open and I'll let you know when the frequency thingy is available.
The experimental frequency measurement is now available in branch measure-freq
. With this branch you should see the latest output you got plus a new field called "max frequency" and valid data in "Peak Perf."
Thanks for this! First, it seems to require some non-standard permission, so I guess normal use would need to use setcap
to avoid root. Running with sudo gets me:
$ sudo ./cpufetch --verbose
[WARNING]: Can't read CPU name from cpuid (needed extended level is 0x80000004, max is 0x03020101)
[WARNING]: Can't read features information from cpuid (needed level is 0x00000007, max is 0x00000002)
[WARNING]: Can't read features information from cpuid (needed extended level is 0x80000001, max is 0x03020101)
[WARNING]: Can't read frequency information from cpuid (needed level is 0x00000016, max is 0x00000002). Using udev
[WARNING]: Could not open '/sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_max_freq'
[WARNING]: All previous methods failed, measuring CPU frequency
-1423041057 4
442.275274
[WARNING]: Can't read cache information from cpuid (needed level is 0x00000004, max is 0x00000002)
[WARNING]: Failed to abbreviate CPU name
.#################.
.#### ####.
.## ###
## :## ###
# ## :## ##
## ## ######. #### ###### :## ## Name: Intel Pentium III
## ## ##: ##: ## ## ### :## ### uArch: P6 (Katmai)
## ## ##: ##: ## :######## :## ## Technology: 250nm
## ## ##: ##: ## ##. . :## #### Peak Perf.: Unknown
## # ##: ##: #### #####: ##
##
###. ..o####.
######oo... ..oo#######
o###############o
I also noticed some warnings on the build where it appears to be assuming 64-bit OS type sizes:
Don't forget that stdint.h
has some funky size-specific printf qualifiers that should work here, even if they're a bit verbose.
src/common/freq.c: In function ‘measure_max_frequency’:
src/common/freq.c:115:13: warning: format ‘%ld’ expects argument of type ‘long int’, but argument 2 has type ‘uint64_t’ {aka ‘long long unsigned int’} [-Wformat=]
115 | printf("%ld %ld\n", instructions, usecs);
| ~~^ ~~~~~~~~~~~~
| | |
| long int uint64_t {aka long long unsigned int}
| %lld
src/common/freq.c:115:17: warning: format ‘%ld’ expects argument of type ‘long int’, but argument 3 has type ‘uint64_t’ {aka ‘long long unsigned int’} [-Wformat=]
115 | printf("%ld %ld\n", instructions, usecs);
| ~~^ ~~~~~
| | |
| long int uint64_t {aka long long unsigned int}
| %lld
The floating point number that gets printed is pretty close to what cpuinfo shows, so that seems to be doing the right thing :slightly_smiling_face:.
This feature requires root if perf_event_paranoid
has a 3 (see here for more intel) which I would say it's not very common (the default value seems to be 2). To put this in another way, after this frequency measurement feature, the frequency will be retrieved in Linux following this algorithm:
Don't worry about the integer issue, that message was only used temporarily for debugging. cpufetch should print the frequency near the ASCII art, but it didn't because there was a bug that caused a struggle when the cache information could not be retrieved. I have fixed it so now it should print it (can you confirm this?).
Still...cpufetch should be able to show you that the CPU has 1 core. Fetching this information when it's not available at cpuid (like in your case) has been a TODO for so long (I created #228 today), so now I can see a use case it's a good moment to take care of.
PS: cpufetch is pretty mature when considering modern CPUs (I'd say >= 2008), but was lacking some stuff for older CPUs as it is very uncommon to see those, that's why there were so many "incomplete" things (which is also why for me issues like yours are very very valuable!)
My pleasure :slightly_smiling_face:. You may also be able to get part of the way there reproducing with QEMU or PCem depending on how much you like fiddling with those :wink:. But yeah, they're never quite the same as the real thing.
Here is the latest output; I also threw a time
around it to capture the duration of the frequency algorithm:
$ time sudo ./cpufetch --verbose
[WARNING]: Can't read CPU name from cpuid (needed extended level is 0x80000004, max is 0x03020101)
[WARNING]: Can't read features information from cpuid (needed level is 0x00000007, max is 0x00000002)
[WARNING]: Can't read features information from cpuid (needed extended level is 0x80000001, max is 0x03020101)
[WARNING]: Can't read frequency information from cpuid (needed level is 0x00000016, max is 0x00000002). Using udev
[WARNING]: Could not open '/sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_max_freq'
[WARNING]: All previous methods failed, measuring CPU frequency
-1423190070 4
442.419279
[WARNING]: Can't read cache information from cpuid (needed level is 0x00000004, max is 0x00000002)
[WARNING]: Can't read topology information from cpuid (needed level is 0x00000001, max is 0x00000002)
[WARNING]: Failed to abbreviate CPU name
.#################.
.#### ####.
.## ###
## :## ### Name: Intel Pentium III
# ## :## ## Microarchitecture: P6 (Katmai)
## ## ######. #### ###### :## ## Technology: 250nm
## ## ##: ##: ## ## ### :## ### Max Frequency: 440 MHz
## ## ##: ##: ## :######## :## ## Cores: Unknown
## ## ##: ##: ## ##. . :## #### SSE: SSE
## # ##: ##: #### #####: ## Peak Performance: Unknown
##
###. ..o####.
######oo... ..oo#######
o###############o
real 0m45.551s
user 0m45.356s
sys 0m0.103s
My bad, I completely forgot about this!
I have just merged all this and a couple of fixes into the master branch. Could you please confirm if this still works on the master branch?
I have just merged an enhancement that automatically adapts the number of ops to compute depending on the CPU speed, so in your case this reduce the runtime from 45s to a couple of seconds.
It does indeed reduce it! Thanks! Here's how it works on master
now:
$ time sudo ./cpufetch --verbose
[WARNING]: Can't read CPU name from cpuid (needed extended level is 0x80000004, max is 0x03020101)
[WARNING]: Can't read features information from cpuid (needed level is 0x00000007, max is 0x00000002)
[WARNING]: Can't read features information from cpuid (needed extended level is 0x80000001, max is 0x03020101)
[WARNING]: Can't read frequency information from cpuid (needed level is 0x00000016, max is 0x00000002). Using udev
[WARNING]: Could not open '/sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_max_freq'
[WARNING]: All previous methods failed, measuring CPU frequency
[WARNING]: Running frequency measurement with 1000000 iterations on core 0...
cpufetch is measuring the max frequency...[WARNING]: Can't read cache information from cpuid (needed level is 0x00000004, max is 0x00000002)
[WARNING]: Can't read topology information from cpuid (needed level is 0x00000001, max is 0x00000002)
[WARNING]: Failed to abbreviate CPU name
Name: Intel Pentium III
Microarchitecture: P6 (Katmai)
Technology: 250nm
Max Frequency: ~440 MHz
Cores: Unknown
SSE: SSE
Peak Performance: Unknown
real 0m5.207s
user 0m0.051s
sys 0m0.063s
(with the all block symbol Intel logo)
Sorry about the delay, I read the first update e-mail at a time where I couldn't test, then forgot :slightly_frowning_face:
That is a great result! I thought everything was fixed, but now I can see that still your core number is not detected and also there are some incorrect warning messages. I have created a branch i220v2
with a quick fix, can you give it a try?
Running from that branch (omitting the time because it's less important now):
$ sudo ./cpufetch --verbose
[WARNING]: Can't read CPU name from cpuid (needed extended level is 0x80000004, max is 0x03020101)
[WARNING]: Can't read features information from cpuid (needed level is 0x00000007, max is 0x00000002)
[WARNING]: Can't read features information from cpuid (needed extended level is 0x80000001, max is 0x03020101)
[WARNING]: Can't read frequency information from cpuid (needed level is 0x00000016, max is 0x00000002). Using udev
[WARNING]: Could not open '/sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_max_freq'
[WARNING]: All previous methods failed, measuring CPU frequency
[WARNING]: Running frequency measurement with 1000000 iterations on core 0...
cpufetch is measuring the max frequency...[WARNING]: Can't read cache information from cpuid (needed level is 0x00000004, max is 0x00000002)
[WARNING]: Can't read topology information from cpuid (needed level is 0x00000004, max is 0x00000002)
[WARNING]: Failed to retrieve topology from APIC, using udev...
[WARNING]: Failed to abbreviate CPU name
Name: Intel Pentium III
Microarchitecture: P6 (Katmai)
Technology: 250nm
Max Frequency: ~440 MHz
Cores: Unknown
SSE: SSE
Peak Performance: Unknown
Reviewing old commits, I found that in an old commit I forced the number of cores to be Unknown
even when /proc/cpuinfo
is available. I don't remember why I did this, so I have reverted this and pushed into the branch. It should now report that you have 1 core!
That looks to have done it! And I even have a performance number somehow :slightly_smiling_face:
$ sudo ./cpufetch --verbose
[sudo] password for zerker:
[WARNING]: Can't read CPU name from cpuid (needed extended level is 0x80000004, max is 0x03020101)
[WARNING]: Can't read features information from cpuid (needed level is 0x00000007, max is 0x00000002)
[WARNING]: Can't read features information from cpuid (needed extended level is 0x80000001, max is 0x03020101)
[WARNING]: Can't read frequency information from cpuid (needed level is 0x00000016, max is 0x00000002). Using udev
[WARNING]: Could not open '/sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_max_freq'
[WARNING]: All previous methods failed, measuring CPU frequency
[WARNING]: Running frequency measurement with 1000000 iterations on core 0...
cpufetch is measuring the max frequency...[WARNING]: Can't read cache information from cpuid (needed level is 0x00000004, max is 0x00000002)
[WARNING]: Can't read topology information from cpuid (needed level is 0x00000004, max is 0x00000002)
[WARNING]: Failed to retrieve topology from APIC, using udev...
[WARNING]: Failed to abbreviate CPU name
Name: Intel Pentium III
Microarchitecture: P6 (Katmai)
Technology: 250nm
Max Frequency: ~440 MHz
Cores: 1 cores
SSE: SSE
Peak Performance: 1.76 GFLOP/s
Though I guess it should be singular with only one core :slightly_smiling_face:
Indeed, attention to detail matters! I have pushed a fix, can you confirm it works as expected?
Yup!
[WARNING]: Can't read CPU name from cpuid (needed extended level is 0x80000004, max is 0x03020101)
[WARNING]: Can't read features information from cpuid (needed level is 0x00000007, max is 0x00000002)
[WARNING]: Can't read features information from cpuid (needed extended level is 0x80000001, max is 0x03020101)
[WARNING]: Can't read frequency information from cpuid (needed level is 0x00000016, max is 0x00000002). Using udev
[WARNING]: Could not open '/sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_max_freq'
[WARNING]: All previous methods failed, measuring CPU frequency
[WARNING]: Running frequency measurement with 1000000 iterations on core 0...
cpufetch is measuring the max frequency...[WARNING]: Can't read cache information from cpuid (needed level is 0x00000004, max is 0x00000002)
[WARNING]: Can't read topology information from cpuid (needed level is 0x00000004, max is 0x00000002)
[WARNING]: Failed to retrieve topology from APIC, using udev...
[WARNING]: Failed to abbreviate CPU name
.#################.
.#### ####.
.## ###
## :## ### Name: Intel Pentium III
# ## :## ## Microarchitecture: P6 (Katmai)
## ## ######. #### ###### :## ## Technology: 250nm
## ## ##: ##: ## ## ### :## ### Max Frequency: ~440 MHz
## ## ##: ##: ## :######## :## ## Cores: 1 core
## ## ##: ##: ## ##. . :## #### SSE: SSE
## # ##: ##: #### #####: ## Peak Performance: 1.76 GFLOP/s
##
###. ..o####.
######oo... ..oo#######
o###############o
I'm good to close this after it's merged in :slightly_smiling_face:.
Merged! Thank you for your excellent support. This clearly deserves a place in the acknowledgements of the project :slightly_smiling_face:
Probably not a common use case, but since I have a Pentium III machine around my place, I decided to try
cpufetch
with it. Here is the output it currently reports with a fresh source build from what's in github:Or as an image:
Note the various "unknown" entries and rather sparse data in general.
Here is the data in
/proc/cpuinfo
for reference:Let me know if there's anything else I can add :slightly_smiling_face:.