Re: git: d3a8f98acbf5 - main - Make CPU children explicitly share parent unit numbers.
Date: Wed, 01 Dec 2021 14:23:29 UTC
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 <mav@FreeBSD.org> >> AuthorDate: 2021-09-25 03:25:46 +0000 >> Commit: Alexander Motin <mav@FreeBSD.org> >> 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. -- Alexander Motin