-
Notifications
You must be signed in to change notification settings - Fork 103
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Missing data for Pentium III #220
Comments
Interesting. Could you run |
Of course. Here's the result:
Also not sure why it's reporting itself as x86_64 on a 32-bit machine. |
…uid leaf (e.g., no cpuid 0x80000002) (#220)
Okay, so there are a few things that we can try to solve (if you find more issues just let me know):
I have created a branch I agree it is not common to see an Intel Pentium, but I like messing around with old chips too 👍 and I would like to support as much hardware as possible in cpufetch. |
Unfortunately, the new branch segfaults. Here's your stack trace:
Let me know if you want me to inspect any variables too. Here's the output of
And the equivalent on the master branch:
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 😉 Anyways, the branch unfortunately still segfaults. Looks like the
Went up another frame and grabbed the struct for you too:
Finally, if it's useful, here's the recursive listing of the
|
My bad, it should be working now 👍 |
Okay, it works again, though we're basically back to the original situation. Verbose:
Debug results:
|
Updated. I think this is it 😅 |
It has a name now!
Another possible fallback would be to grab the more detailed name from I see you're covering your bases for the platform in the debug/version text 😄
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 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. |
…tium uarch detection and adding support to infer the CPU name from uarch when the corresponding CPUID level is not available
The experimental frequency measurement is now available in branch |
Thanks for this! First, it seems to require some non-standard permission, so I guess normal use would need to use
I also noticed some warnings on the build where it appears to be assuming 64-bit OS type sizes:
The floating point number that gets printed is pretty close to what cpuinfo shows, so that seems to be doing the right thing 🙂. |
This feature requires root if
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 🙂. 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 😉. But yeah, they're never quite the same as the real thing. Here is the latest output; I also threw a
|
- [v1.05][X86] Show SSE if AVX/FMA is not supported - [v1.05][X86] Do not stop if cach is NULL and check for non-NULL cache in get_topology_info functions - [v1.05][X86] Fix bug where the number of cpus were not set if NULL was returned inside the loop. Ensure topo is not NULL in get_peak_performance. Fallback to UNKNOWN_DATA when we have no information about topology
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
(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 🙁 |
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 |
Running from that branch (omitting the time because it's less important now):
|
Reviewing old commits, I found that in an old commit I forced the number of cores to be |
That looks to have done it! And I even have a performance number somehow 🙂
Though I guess it should be singular with only one core 🙂 |
Indeed, attention to detail matters! I have pushed a fix, can you confirm it works as expected? |
Yup!
I'm good to close this after it's merged in 🙂. |
- Use udev to get topo when apic failed or is not available. - Assume single core in udev when total cores is 1. - Print core/cores accordingly to the number of cores.
Merged! Thank you for your excellent support. This clearly deserves a place in the acknowledgements of the project 🙂 |
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 🙂.
The text was updated successfully, but these errors were encountered: