8:09 p.m.
Have a old quad core system that I've had since Fedora 10 I believe.
Recently, upgraded to Fedora 31, and it was still seeing all 4 cores.
Run BOINC, and recently notice that it was only showing 3 cpus
running? Machine is one of the 5 computers I have at house, but is
headless and access remotely via VNC. Other systems all show the right
number of cpus after updates, so not sure what might cause the issue.
The results of lshw-gui shows the 4 cores, but the dmesg shows only
CPU 0 - 2. Didn't notice this until the 5.7 kernel change, but not sure
exactly which update caused the change.
Any ideals what could fix this, or how to get specific reasons it might
have happened. Other machines are newer, some dual and one other
quad core. So, just this one??
Info from lshw-gui and dmesg
product: AMD Phenom(tm) II X4 955 Processor
vendor: Advanced Micro Devices [AMD]
bus info: cpu@0
version: AMD Phenom(tm) II X4 955 Processor
serial: To Be Filled By O.E.M.
slot: AM2
size: 3200MHz
capacity: 3200MHz
width: 64 bits
clock: 200MHz
capabilities:
64bits extensions (x86-64),
mathematical co-processor,
FPU exceptions reporting,
wp,
virtual mode extensions,
debugging extensions,
page size extensions,
time stamp counter,
model-specific registers,
4GB+ memory addressing (Physical Address Extension),
machine check exceptions,
compare and exchange 8-byte,
on-chip advanced programmable interrupt controller (APIC),
fast system calls,
memory type range registers,
page global enable,
machine check architecture,
conditional move instruction,
page attribute table,
36-bit page size extensions,
clflush,
multimedia extensions (MMX),
fast floating point save/restore,
streaming SIMD extensions (SSE),
streaming SIMD extensions (SSE2),
HyperThreading,
fast system calls,
no-execute bit (NX),
multimedia extensions (MMXExt),
fxsr_opt,
pdpe1gb,
rdtscp,
64bits extensions (x86-64),
multimedia extensions (3DNow!Ext),
multimedia extensions (3DNow!),
constant_tsc,
rep_good,
nopl,
nonstop_tsc,
cpuid,
extd_apicid,
pni,
monitor,
cx16,
popcnt,
lahf_lm,
cmp_legacy,
svm,
extapic,
cr8_legacy,
abm,
sse4a,
misalignsse,
3dnowprefetch,
osvw,
ibs,
skinit,
wdt,
hw_pstate,
vmmcall,
npt,
lbrv,
svm_lock,
nrip_save,
CPU Frequency scaling
configuration:
cores: 4
enabledcores: 4
dmesg | grep -i CPU
[ 0.092368] smpboot: Allowing 6 CPUs, 3 hotplug CPUs
[ 0.097494] setup_percpu: NR_CPUS:8192 nr_cpumask_bits:6
nr_cpu_ids:6 nr_node_ids:1
[ 0.098234] percpu: Embedded 55 pages/cpu s188416 r8192 d28672
u262144
[ 0.098239] pcpu-alloc: s188416 r8192 d28672 u262144
alloc=1*2097152
[ 0.098240] pcpu-alloc: [0] 0 1 2 3 4 5 - -
[ 0.155390] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=6,
Nodes=1
[ 0.166771] rcu: RCU restricting CPUs from NR_CPUS=8192 to
nr_cpu_ids=6.
[ 0.166773] rcu: Adjusting geometry for rcu_fanout_leaf=16,
nr_cpu_ids=6
[ 0.281801] smpboot: CPU0: AMD Phenom(tm) II X4 955 Processor
(family: 0x10, model: 0x4, stepping: 0x2)
[ 0.282522] smp: Bringing up secondary CPUs ...
[ 0.282522] .... node #0, CPUs: #1 #2
[ 0.285583] smp: Brought up 1 node, 3 CPUs
[ 0.288816] cpuidle: using governor menu
[ 0.289646] mtrr: your CPUs had inconsistent fixed MTRR settings
[ 0.289646] mtrr: probably your BIOS does not setup all CPUs.
[ 0.487753] cryptd: max_cpu_qlen set to 1000
[ 1.487099] microcode: CPU0: patch_level=0x010000db
[ 1.487103] microcode: CPU1: patch_level=0x010000db
[ 1.487108] microcode: CPU2: patch_level=0x010000db
[ 2.775723] [drm] GART: num cpu pages 131072, num gpu pages
131072
[ 2.792713] radeon 0000:01:05.0: fence driver on ring 0 use gpu addr
0x00000000a0000c00 and cpu addr 0x(____ptrval____)
[ 2.794881] radeon 0000:01:05.0: fence driver on ring 5 use gpu addr
0x00000000c0056038 and cpu addr 0x(____ptrval____)
[ 9.987542] acpi_cpufreq: overriding BIOS provided _PSD data
[ 10.196935] k10temp 0000:00:18.3: unreliable CPU thermal sensor;
monitoring disabled
Thanks.
+------------------------------------------------------------+
Michael D. Setzer II - Computer Science Instructor (Retired)
mailto:mikes@guam.net
mailto:msetzerii@gmail.com
Guam - Where America's Day Begins
G4L Disk Imaging Project maintainer
http://sourceforge.net/projects/g4l/
+------------------------------------------------------------+
8:44 p.m.
On 2020-08-08 09:09, Michael D. Setzer II via users wrote:
Have a old quad core system that I've had since Fedora 10 I
believe.
Recently, upgraded to Fedora 31, and it was still seeing all 4 cores.
Run BOINC, and recently notice that it was only showing 3 cpus
running? Machine is one of the 5 computers I have at house, but is
headless and access remotely via VNC. Other systems all show the right
number of cpus after updates, so not sure what might cause the issue.
The results of lshw-gui shows the 4 cores, but the dmesg shows only
CPU 0 - 2. Didn't notice this until the 5.7 kernel change, but not sure
exactly which update caused the change.
While it is headless, would there be any chance of booting a live-image to run a 5.6
kernel
to verify that and older kernel still detects 4?
--
The key to getting good answers is to ask good questions.
6:10 a.m.
On 8 Aug 2020 at 9:44, Ed Greshko wrote:
From: Ed Greshko <ed.greshko(a)greshko.com>
Subject: Re: Missing a CPU after the 5.7 kernels??
To: users(a)lists.fedoraproject.org
Date sent: Sat, 8 Aug 2020 09:44:02 +0800
Send reply to: Community support for Fedora users
<users(a)lists.fedoraproject.org>
On 2020-08-08 09:09, Michael D. Setzer II via users wrote:
> Have a old quad core system that I've had since Fedora 10 I believe.
> Recently, upgraded to Fedora 31, and it was still seeing all 4 cores.
>
> Run BOINC, and recently notice that it was only showing 3 cpus
> running? Machine is one of the 5 computers I have at house, but is
> headless and access remotely via VNC. Other systems all show the right
> number of cpus after updates, so not sure what might cause the issue.
> The results of lshw-gui shows the 4 cores, but the dmesg shows only
> CPU 0 - 2. Didn't notice this until the 5.7 kernel change, but not sure
> exactly which update caused the change.
While it is headless, would there be any chance of booting a live-image to run a 5.6
kernel
to verify that and older kernel still detects 4?
Hooked up a monitor, keyboard, and mouse onto system, and rebooted it.
Unfortunately all of the current kernels where 5.7 version?
Went into advanced options, and found that somehow the CPU settings
for cores was set to manual and the cpu 3 was set to Off??
Machine hasn't had a keyboard setup on it for some time, so no clue how
it got set to manual, and why cpu 3 would have been set to off.
The bios was showing that it supports 6 cpus, and all where set to on
except #3? But CPU in machine is just a quad.
Set it to automatic, and rebooted. It then showed the 4 cores running, and
it is not showing that BOINC is running 4 active processes..
So, no clue how the setting got changed??
Thanks.
--
The key to getting good answers is to ask good questions.
_______________________________________________
users mailing list -- users(a)lists.fedoraproject.org
To unsubscribe send an email to users-leave(a)lists.fedoraproject.org
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
+------------------------------------------------------------+
Michael D. Setzer II - Computer Science Instructor (Retired)
mailto:mikes@guam.net
mailto:msetzerii@gmail.com
Guam - Where America's Day Begins
G4L Disk Imaging Project maintainer
http://sourceforge.net/projects/g4l/
+------------------------------------------------------------+
12:43 p.m.
On Sat, 8 Aug 2020 at 08:10, Michael D. Setzer II via users <
users(a)lists.fedoraproject.org> wrote:
On 8 Aug 2020 at 9:44, Ed Greshko wrote:
From: Ed Greshko <ed.greshko(a)greshko.com>
Subject: Re: Missing a CPU after the 5.7 kernels??
To: users(a)lists.fedoraproject.org
Date sent: Sat, 8 Aug 2020 09:44:02 +0800
Send reply to: Community support for Fedora users
<users(a)lists.fedoraproject.org>
> On 2020-08-08 09:09, Michael D. Setzer II via users wrote:
> > Have a old quad core system that I've had since Fedora 10 I believe.
> > Recently, upgraded to Fedora 31, and it was still seeing all 4 cores.
> >
> > Run BOINC, and recently notice that it was only showing 3 cpus
> > running? Machine is one of the 5 computers I have at house, but is
> > headless and access remotely via VNC. Other systems all show the right
> > number of cpus after updates, so not sure what might cause the issue.
> > The results of lshw-gui shows the 4 cores, but the dmesg shows only
> > CPU 0 - 2. Didn't notice this until the 5.7 kernel change, but not
sure
> > exactly which update caused the change.
>
> While it is headless, would there be any chance of booting a live-image
to run a 5.6 kernel
> to verify that and older kernel still detects 4?
>
Hooked up a monitor, keyboard, and mouse onto system, and rebooted it.
Unfortunately all of the current kernels where 5.7 version?
Went into advanced options, and found that somehow the CPU settings
for cores was set to manual and the cpu 3 was set to Off??
Machine hasn't had a keyboard setup on it for some time, so no clue how
it got set to manual, and why cpu 3 would have been set to off.
Most systems use a "coin" battery to maintain BIOS settings while powered
down. Unexpected changes after power has been off usually indicate
a failed battery; they are generally easy to replace.
--
George N. White III
1:34 p.m.
On 08/08/2020 11:43 AM, George N. White III wrote:
Most systems use a "coin" battery to maintain BIOS settings while powered
down. Unexpected changes after power has been off usually indicate
a failed battery; they are generally easy to replace.
I don't know if it's still true, but PrintScreen used to work when you
were in CMOS, or the BIOS setup screen. (Probably not; useful things
like this tend to go away as people forget what they're for.) The point
is, one you get everything set up correctly, you can use this to get a
hard copy record of how your system's supposed to be. If you need to
reset things after a battery change, you can use this for a guide. And,
if there's room, you can keep it inside the case so it won't get lost.
2 p.m.
On 8/8/20 11:34 AM, Joe Zeff wrote:
On 08/08/2020 11:43 AM, George N. White III wrote:
>
> Most systems use a "coin" battery to maintain BIOS settings while powered
> down. Unexpected changes after power has been off usually indicate
> a failed battery; they are generally easy to replace.
I don't know if it's still true, but PrintScreen used to work when you
were in CMOS, or the BIOS setup screen. (Probably not; useful things
like this tend to go away as people forget what they're for.) The point
I suspect that hasn't worked since parallel port dot matrix printers
went away. There's no way for the BIOS to be able to print to a USB or
network printer and who has a parallel port any more?
5:04 p.m.
On Sat, 8 Aug 2020 at 16:00, Samuel Sieb <samuel(a)sieb.net> wrote:
On 8/8/20 11:34 AM, Joe Zeff wrote:
> On 08/08/2020 11:43 AM, George N. White III wrote:
>>
>> Most systems use a "coin" battery to maintain BIOS settings while
powered
>> down. Unexpected changes after power has been off usually indicate
>> a failed battery; they are generally easy to replace.
>
> I don't know if it's still true, but PrintScreen used to work when you
> were in CMOS, or the BIOS setup screen. (Probably not; useful things
> like this tend to go away as people forget what they're for.) The point
I suspect that hasn't worked since parallel port dot matrix printers
went away. There's no way for the BIOS to be able to print to a USB or
network printer and who has a parallel port any more?
Some recent BIOS's support printScreen to USB:
https://www.unbxtech.com/2018/04/howto-take-screenshot-motherboard-bios.html
--
George N. White III
12:15 a.m.
Michael D. Setzer II via users wrote:
So, no clue how the setting got changed??
While some may say a dying motherboard battery can be the cause for
CMOS or UEFI screw-ups, there are a plethora of possible causes.
Unless you can get it to happen again, you may never know. Just to go
through a few:
Even a good motherboard battery may have poor connection to the
terminals (dirt contamination, or poor tension against the metal). I
remember back in the 1980s being told to always wipe down coin
batteries before insertion, and not to get your finger grease on them
afterwards. While the latter is next to impossible without gloves, it
really just means don't contaminate the bits of metal on the battery
that touch the bits of metal in the battery holder. Though we were
also told that sufficient contamination across the batteries own
terminals would lead to it prematurely going flat, I think you'd have
to have particularly mucky hands to be able to do that.
Random circuitry behaviour when the mains voltage spiked or dipped (the
latter can cause some really odd things without causing damage). Logic
circuitry works by using high or low voltages to represent high (1)
bits or low (0) bits. It's either above or below a threshold. When
power goes down (a brownout) without fully turning off, circuitry can
end up with voltages in an level that's indeterminate. High mains
voltage spikes can outright destroy things, can stress and weaken
parts, or just induce voltages that interfere with operation at the
moment of the spike.
Random hardware faults that only rear their heads under a particular
set of conditions.
Software glitches that stomp over data in an area they shouldn't touch.
RAM faults.
--
uname -rsvp
Linux 3.10.0-1127.18.2.el7.x86_64 #1 SMP Sun Jul 26 15:27:06 UTC 2020 x86_64
Boilerplate: All unexpected mail to my mailbox is automatically deleted.
I will only get to see the messages that are posted to the mailing list.
4:39 p.m.
On Sun, 9 Aug 2020 at 02:16, Tim via users <users(a)lists.fedoraproject.org>
wrote:
Michael D. Setzer II via users wrote:
> So, no clue how the setting got changed??
While some may say a dying motherboard battery can be the cause for
CMOS or UEFI screw-ups, there are a plethora of possible causes.
Unless you can get it to happen again, you may never know. Just to go
through a few:
Even a good motherboard battery may have poor connection to the
terminals (dirt contamination, or poor tension against the metal). I
remember back in the 1980s being told to always wipe down coin
batteries before insertion, and not to get your finger grease on them
afterwards. While the latter is next to impossible without gloves, it
really just means don't contaminate the bits of metal on the battery
that touch the bits of metal in the battery holder. Though we were
also told that sufficient contamination across the batteries own
terminals would lead to it prematurely going flat, I think you'd have
to have particularly mucky hands to be able to do that.
Random circuitry behaviour when the mains voltage spiked or dipped (the
latter can cause some really odd things without causing damage). Logic
circuitry works by using high or low voltages to represent high (1)
bits or low (0) bits. It's either above or below a threshold. When
power goes down (a brownout) without fully turning off, circuitry can
end up with voltages in an level that's indeterminate. High mains
voltage spikes can outright destroy things, can stress and weaken
parts, or just induce voltages that interfere with operation at the
moment of the spike.
Random hardware faults that only rear their heads under a particular
set of conditions.
Software glitches that stomp over data in an area they shouldn't touch.
RAM faults.
The first step in understanding a problem is to focus on easy
mitigations and known hardware failure modes.
Visual inspection of the system board can reveal toasted parts,
green scum indicating corrosion on connections, dust
accumulation on cooling fins, bulging capacitors, etc. I've seen
drive cables that would fall off the connector under their own weight.
Periodically checking cables and memory for secure connections
doesn't take long.
Checking and replacing the CMOS backup battery is easy unless the
battery is soldered to the system board.
My experience with linux and macOS (and very different from Windows)
has been that filesystem corruption not associated with some obvious
issue like a system crash or power problem is more often caused by
hardware than by software. Whenever a disk acts up I check cables
and run smartctl or vendor tests -- some vendors have accepted smartctl
output from a linux or macOS system when issuing warranty return
authorizations.
It also pays to look for common failure modes for the hardware you
use. Some models have well-known failure modes. Examples from
my experience are capacitors, power supplies, fans, ethernet (card or
onboard), and cables.
--
George N. White III
5:48 a.m.
On Fri, 7 Aug 2020 at 22:09, Michael D. Setzer II via users <
users(a)lists.fedoraproject.org> wrote:
Have a old quad core system that I've had since Fedora 10 I
believe.
Recently, upgraded to Fedora 31, and it was still seeing all 4 cores.
Run BOINC, and recently notice that it was only showing 3 cpus
running? Machine is one of the 5 computers I have at house, but is
headless and access remotely via VNC. Other systems all show the right
number of cpus after updates, so not sure what might cause the issue.
The results of lshw-gui shows the 4 cores, but the dmesg shows only
CPU 0 - 2. Didn't notice this until the 5.7 kernel change, but not sure
exactly which update caused the change.
Any ideals what could fix this, or how to get specific reasons it might
have happened. Other machines are newer, some dual and one other
quad core. So, just this one??
There is a long thread that seems relevant:
https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg2221826.html
This is not a 5.8-rc3 problem. Almost all AMD CPUs and APUs are
looking like this.
The only CPUs I own are getting that right is a dual EPYC box,
everything else is broken
regarding the right C/T & socket(s) count, and that probably bc is
using NUAM [sic] code
to have the info.
Hardware failure?
[ 10.196935] k10temp 0000:00:18.3: unreliable CPU thermal sensor;
monitoring disabled
See: https://wiki.archlinux.org/index.php/Lm_sensors for discussion of
this message.
Having seen too many older systems act up with failed capacitors, I'd
check the system board for bad capacitors and signs of overheating.
--
George N. White III
1349
days inactive
1350
days old
9 comments
6 participants
participants (6)
-
Ed Greshko -
George N. White III -
Joe Zeff -
Michael D. Setzer II -
Samuel Sieb -
Tim