Missing data for Pentium III #220

zerkerX · 2024-01-29T21:34:34Z

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:


                                                              
                                                              
                                                              
                                                              
                                                              
                                                              
                                                              
                                                              Name:                Unknown
                                                              Microarchitecture:   P6 Pentium III
                                                              Technology:          2.50um
                                                              Peak Performance:    Unknown

Or as an image:

Note the various "unknown" entries and rather sparse data in general.

Here is the data in /proc/cpuinfo for reference:

processor       : 0
vendor_id       : GenuineIntel
cpu family      : 6
model           : 7
model name      : Pentium III (Katmai)
stepping        : 3
microcode       : 0xe
cpu MHz         : 448.979
cache size      : 512 KB
physical id     : 0
siblings        : 1
core id         : 0
cpu cores       : 1
apicid          : 0
initial apicid  : 0
fdiv_bug        : no
f00f_bug        : no
coma_bug        : no
fpu             : yes
fpu_exception   : yes
cpuid level     : 2
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 sep mtrr pge mca cmov pse36 mmx fxsr sse cpuid pti
bugs            : cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass l1tf mds swapgs itlb_multihit mmio_unknown
bogomips        : 897.95
clflush size    : 32
cache_alignment : 32
address sizes   : 36 bits physical, 32 bits virtual
power management:

Let me know if there's anything else I can add 🙂.

The text was updated successfully, but these errors were encountered:

Dr-Noob · 2024-01-30T08:22:25Z

Interesting. Could you run cpufetch --debug, please?

zerkerX · 2024-01-30T23:14:39Z

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.

…uid leaf (e.g., no cpuid 0x80000002) (#220)

Dr-Noob · 2024-02-01T22:08:12Z

Okay, so there are a few things that we can try to solve (if you find more issues just let me know):

CPU name
Frequency
Showing 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 👍 and I would like to support as much hardware as possible in cpufetch.

zerkerX · 2024-02-01T23:39:02Z

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.

Dr-Noob · 2024-02-02T23:03:52Z

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!

zerkerX · 2024-02-03T00:43:52Z

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

Dr-Noob · 2024-02-04T11:36:49Z

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 👍

zerkerX · 2024-02-04T19:11:33Z

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

Dr-Noob · 2024-02-06T08:29:08Z

Updated. I think this is it 😅

zerkerX · 2024-02-07T00:03:56Z

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 😄

cpufetch v1.04-41-gc885 (Linux x86 / x86_64 build)

If you get more features added, I'd be happy to keep testing.

Dr-Noob · 2024-02-09T08:37:28Z

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.

…tium uarch detection and adding support to infer the CPU name from uarch when the corresponding CPUID level is not available

Dr-Noob · 2024-02-14T08:52:11Z

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

zerkerX · 2024-02-15T00:20:38Z

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

Dr-Noob · 2024-02-18T21:12:13Z

This feature requires root if perf_event_paranoidhas 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:

If cpuid is supported, cpufetch will use it
If the previous is not supported and /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_max_freq exist, cpufetch will use it
If the previous is not supported and the performance events are available (because they can be read by an unprivileged user or because it is run as root), cpufetch will measure the frequency.
If the previous is not possible...then give up! 😢

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

zerkerX · 2024-02-19T13:05:08Z

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

Dr-Noob added a commit that referenced this issue Feb 1, 2024

[v1.04][X86] Deduce CPU name for CPUs without support for extended cp…

5a82e3c

…uid leaf (e.g., no cpuid 0x80000002) (#220)

Dr-Noob added the bug Something isn't working label Feb 1, 2024

Dr-Noob added a commit that referenced this issue Feb 13, 2024

[v1.05][X86] Improve support for old x86 CPUs (#220) by improving Pen…

cc16bc5

…tium uarch detection and adding support to infer the CPU name from uarch when the corresponding CPUID level is not available

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Missing data for Pentium III #220

Missing data for Pentium III #220

zerkerX commented Jan 29, 2024 •

edited

Dr-Noob commented Jan 30, 2024

zerkerX commented Jan 30, 2024 •

edited

Dr-Noob commented Feb 1, 2024 •

edited

zerkerX commented Feb 1, 2024

Dr-Noob commented Feb 2, 2024 •

edited

zerkerX commented Feb 3, 2024 •

edited

Dr-Noob commented Feb 4, 2024

zerkerX commented Feb 4, 2024

Dr-Noob commented Feb 6, 2024

zerkerX commented Feb 7, 2024

Dr-Noob commented Feb 9, 2024 •

edited

Dr-Noob commented Feb 14, 2024

zerkerX commented Feb 15, 2024

Dr-Noob commented Feb 18, 2024

zerkerX commented Feb 19, 2024

Missing data for Pentium III #220

Missing data for Pentium III #220

Comments

zerkerX commented Jan 29, 2024 • edited

Dr-Noob commented Jan 30, 2024

zerkerX commented Jan 30, 2024 • edited

Dr-Noob commented Feb 1, 2024 • edited

zerkerX commented Feb 1, 2024

Dr-Noob commented Feb 2, 2024 • edited

zerkerX commented Feb 3, 2024 • edited

Dr-Noob commented Feb 4, 2024

zerkerX commented Feb 4, 2024

Dr-Noob commented Feb 6, 2024

zerkerX commented Feb 7, 2024

Dr-Noob commented Feb 9, 2024 • edited

Dr-Noob commented Feb 14, 2024

zerkerX commented Feb 15, 2024

Dr-Noob commented Feb 18, 2024

zerkerX commented Feb 19, 2024

zerkerX commented Jan 29, 2024 •

edited

zerkerX commented Jan 30, 2024 •

edited

Dr-Noob commented Feb 1, 2024 •

edited

Dr-Noob commented Feb 2, 2024 •

edited

zerkerX commented Feb 3, 2024 •

edited

Dr-Noob commented Feb 9, 2024 •

edited