On 01/12/2021 16:23, Alexander Motin wrote:
Hi Andriy,
On 01.12.2021 01:39, Andriy Gapon wrote:
On 25/09/2021 06:32, Alexander Motin wrote:
The branch main has been updated by mav:
URL:
https://cgit.FreeBSD.org/src/commit/?id=d3a8f98acbf51e728411f10c5f179a30b9ca683c
commit d3a8f98acbf51e728411f10c5f179a30b9ca683c
Author: Alexander Motin <[email protected]>
AuthorDate: 2021-09-25 03:25:46 +0000
Commit: Alexander Motin <[email protected]>
CommitDate: 2021-09-25 03:31:51 +0000
Make CPU children explicitly share parent unit numbers.
Before this device unit number match was coincidental and
broke if I
disabled some CPU device(s). Aside of cosmetics, for some drivers
(may be considered broken) it caused talking to wrong CPUs.
---
sys/dev/acpica/acpi_perf.c | 3 ++-
sys/dev/acpica/acpi_throttle.c | 3 ++-
sys/dev/amdtemp/amdtemp.c | 3 ++-
It seems that the amdtemp part of this change broke creation of
dev.cpu.0.temperature sysctl node on my (old hardware) system.
I have 4 cores and amdtemp attaches under hostb4:
cpu0 pnpinfo _HID=none _UID=0 _CID=none at handle=\_PR_.P001
acpi_perf0
acpi_throttle0
hwpstate0
cpufreq0
cpu1 pnpinfo _HID=none _UID=0 _CID=none at handle=\_PR_.P002
acpi_perf1
hwpstate1
cpu2 pnpinfo _HID=none _UID=0 _CID=none at handle=\_PR_.P003
acpi_perf2
hwpstate2
cpu3 pnpinfo _HID=none _UID=0 _CID=none at handle=\_PR_.P004
acpi_perf3
hwpstate3
...
pcib0 pnpinfo _HID=PNP0A03 _UID=0 _CID=none at handle=\_SB_.PCI0
pci0
...
hostb4 pnpinfo vendor=0x1022 device=0x1203 subvendor=0x0000
subdevice=0x0000 class=0x060000 at slot=24 function=3 dbsf=pci0:0:24:3
amdtemp4
As you can see amdtemp attaches in a different sub-tree from cpus and
its parent's unit number does not have any relation to any processor.
It seems you are right about the parent. But I see that the driver does
care about its unit number when adding sysctls to CPUs. I am not sure
that default sequential numbering is working by more than coincidence.
Well, on this kind of (consumer) hardware there is only one instance of amdtemp
and it used to have a unit number of zero. And there's always CPU #0. So, it
was a perfect match, even if by accident.
I am not sure how that worked on multi-socket systems with hardware from that
generation (AMD family 10h).
--
Andriy Gapon