NetBSD Problem Report #58331

From www@netbsd.org  Mon Jun 10 02:41:44 2024
Return-Path: <www@netbsd.org>
Received: from mail.netbsd.org (mail.netbsd.org [199.233.217.200])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256
	 client-signature RSA-PSS (2048 bits) client-digest SHA256)
	(Client CN "mail.NetBSD.org", Issuer "mail.NetBSD.org CA" (not verified))
	by mollari.NetBSD.org (Postfix) with ESMTPS id 148DA1A9238
	for <gnats-bugs@gnats.NetBSD.org>; Mon, 10 Jun 2024 02:41:44 +0000 (UTC)
Message-Id: <20240610024142.EBE1C1A923A@mollari.NetBSD.org>
Date: Mon, 10 Jun 2024 02:41:42 +0000 (UTC)
From: campbell+netbsd@mumble.net
Reply-To: campbell+netbsd@mumble.net
To: gnats-bugs@NetBSD.org
Subject: amdsmn(4) rescan doesn't notice duplicate children
X-Send-Pr-Version: www-1.0

>Number:         58331
>Category:       kern
>Synopsis:       amdsmn(4) rescan doesn't notice duplicate children
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    kern-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Mon Jun 10 02:45:00 +0000 2024
>Originator:     Taylor R Campbell
>Release:        current, 10, 9, ...
>Organization:
The NetAMDSMN Foundation
>Environment:
>Description:
amdsmn(4) scans for children such as amdzentemp(4).

But once the children are already attached, rescanning for children attaches _new_ instances of the same driver.

So if at boot you have

amdzentemp0 at amdsmn0,

then when you run `drvctl -r amdsmn0', you get a new

amdzentemp1 at amdsmn0

and if you do it again you get

amdzentemp2 at amdsmn0

and so on, with envstat(8) output growing increasingly large having more and more copies of the same sensors.
>How-To-Repeat:
drvctl -r amdsmn0
>Fix:
Yes, please!

We need some scheme to identify when a child _driver_ is already attached, and not attach another one.

It would also be nice if this had hooks for new drivers to be modloaded, too, e.g. for an AMD EDAC driver.  But maybe there's no convenient way to do that, so maybe the scheme of a few fixed interface attributes is the best we can do, like sys/dev/acpi/acpi.c.

Home	PR Database Search