Re: git: d3a8f98acbf5 - main - Make CPU children explicitly share parent unit numbers.
Date: Wed, 01 Dec 2021 14:28:34 UTC
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 <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. 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