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

Reply via email to