From nobody Wed Dec 01 14:28:34 2021 X-Original-To: dev-commits-src-main@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 1033218C9158; Wed, 1 Dec 2021 14:28:39 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4J41fZ5SYVz4mbs; Wed, 1 Dec 2021 14:28:38 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from [192.168.0.88] (unknown [195.64.148.76]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: avg/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 05E6821FA0; Wed, 1 Dec 2021 14:28:37 +0000 (UTC) (envelope-from avg@FreeBSD.org) Message-ID: <56188d19-f5da-9590-5d96-d47ad1abf6eb@FreeBSD.org> Date: Wed, 1 Dec 2021 16:28:34 +0200 List-Id: Commit messages for the main branch of the src repository List-Archive: https://lists.freebsd.org/archives/dev-commits-src-main List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-dev-commits-src-main@freebsd.org X-BeenThere: dev-commits-src-main@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101 Firefox/91.0 Thunderbird/91.3.0 From: Andriy Gapon Subject: Re: git: d3a8f98acbf5 - main - Make CPU children explicitly share parent unit numbers. Content-Language: en-US To: Alexander Motin , src-committers@FreeBSD.org, dev-commits-src-all@FreeBSD.org, dev-commits-src-main@FreeBSD.org References: <202109250332.18P3W9UM008783@gitrepo.freebsd.org> <3c211281-ce4a-3d99-ab45-4d8a6fbdbe55@FreeBSD.org> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1638368918; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=pZ1BwgTWDK1LgMl4lEf937dUCFXHBfYIxLch9Xy/EHk=; b=G/Sb3EEHbSGoYSOzlEMt+2A8av6JFDLHUTqDKhpBk8Ncha/8fm/3AhNHtXYr6TQL8aR0Fb IzihkWTzwHRqZYutrdPxD2eLphNJKW+tePpBDV1M+3TD8bVioJgJUGrakq8bBP3U+HzLrL Z2wGEI4VcRqqBeMd3C54SMgNsipRw2iLAbNjm5b13q2W1rWgb/X3gNRqJi+TCJlbORn2N4 owouDWeWuAPReQlWjmIh8MMnoyfkxmfGQwRqxTnwDrFFNPDc8TUBq1L2Tyv39NI4zLTXva Bl5ScVMY0SEMUOuQ9U1A/yWXW+WitO1lK4chWm95xGtnlt0m2lfjji9xzbhq1w== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1638368918; a=rsa-sha256; cv=none; b=ypj3wlaNn6PAAwwtRmPOCHs0h3MpNFV8UO9mZkWA9o+dIjL2QauF/dwUrlD6HvVkZjJmmK DCn1faxDWSVtdPlvCSXwTlJWYe/Oz5yl+ZLPDfmJ7lKwLDnPogpVpDKT6R2sV2CsmOd/xD 91pt1Xecgg2tycXrx7m+r0IuGGNglHRHUMCCV4+DBXe0v1KLIchYzHMkjRuv1LC13VQc/p QzHY+gtJyQlxLzcZa7/Q1iJq2rSm81FKkmXF7lMe8Tz32YYS2nXxbr1vQgiXIUhFkw1X8v fk87knu4LF/xZ9O4q614k85OYVAQJNbaFBjZgYcFz4eKHIEPlrBEyN+LJBysiQ== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N 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 >>> AuthorDate: 2021-09-25 03:25:46 +0000 >>> Commit:     Alexander Motin >>> 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