From owner-freebsd-current@freebsd.org Tue Nov 17 13:21:22 2020 Return-Path: Delivered-To: freebsd-current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 374552ECD55 for ; Tue, 17 Nov 2020 13:21:22 +0000 (UTC) (envelope-from yuripv@yuripv.dev) Received: from mailman.nyi.freebsd.org (mailman.nyi.freebsd.org [IPv6:2610:1c1:1:606c::50:13]) by mx1.freebsd.org (Postfix) with ESMTP id 4Cb65s6Rpcz4fYp for ; Tue, 17 Nov 2020 13:21:21 +0000 (UTC) (envelope-from yuripv@yuripv.dev) Received: by mailman.nyi.freebsd.org (Postfix) id DD2BC2ECDB8; Tue, 17 Nov 2020 13:21:21 +0000 (UTC) Delivered-To: current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id DCEE72ED006 for ; Tue, 17 Nov 2020 13:21:21 +0000 (UTC) (envelope-from yuripv@yuripv.dev) Received: from new4-smtp.messagingengine.com (new4-smtp.messagingengine.com [66.111.4.230]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4Cb65s5gyGz4fJ6 for ; Tue, 17 Nov 2020 13:21:21 +0000 (UTC) (envelope-from yuripv@yuripv.dev) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailnew.nyi.internal (Postfix) with ESMTP id 13C46580259; Tue, 17 Nov 2020 08:21:21 -0500 (EST) Received: from imap22 ([10.202.2.72]) by compute1.internal (MEProxy); Tue, 17 Nov 2020 08:21:21 -0500 X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrudeffedgheduucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvffutgesthdtredtreertdenucfhrhhomhepfdgjuhhr ihcurfgrnhhkohhvfdcuoeihuhhrihhpvheshihurhhiphhvrdguvghvqeenucggtffrrg htthgvrhhnpeelhfevtdefkeffveehudetkeeggfeuiedvvddvudegudefveeljeffgeel gfevteenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpe ihuhhrihhpvheshihurhhiphhvrdguvghv X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 3AD0A6680078; Tue, 17 Nov 2020 08:21:20 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.0-622-g4a97c0b-fm-20201115.001-g4a97c0b3 Mime-Version: 1.0 Message-Id: In-Reply-To: <274d456e15ce621889bfe9e7eda190da@kondratyev.su> References: <7dc142d3-1e0b-41d4-bdb4-7217bd09bbef@www.fastmail.com> <7b80877ae59fdd90f2f3b5dbf3db2113@kondratyev.su> <5bb9ac64-ebab-4d22-8a43-1305b16f28cd@www.fastmail.com> <274d456e15ce621889bfe9e7eda190da@kondratyev.su> Date: Tue, 17 Nov 2020 16:20:59 +0300 From: "Yuri Pankov" To: "Vladimir Kondratyev" Cc: current@freebsd.org Subject: Re: acpi_wmi noisy without EC Content-Type: text/plain X-Rspamd-Queue-Id: 4Cb65s5gyGz4fJ6 X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Nov 2020 13:21:22 -0000 On Tue, Nov 17, 2020, at 4:00 PM, Vladimir Kondratyev wrote: > On 2020-11-17 15:29, Yuri Pankov wrote: > > On Tue, Nov 17, 2020, at 11:07 AM, Vladimir Kondratyev wrote: > >> On 2020-11-17 10:57, Vladimir Kondratyev wrote: > >> > On 2020-11-17 03:00, Yuri Pankov wrote: > >> >> I have started seeing the following on boot since some time: > >> >> > >> >> acpi_wmi0: on acpi0 > >> >> acpi_wmi0: cannot find EC device > >> >> device_attach: acpi_wmi0 attach returned 6 > >> >> acpi_wmi0: on acpi0 > >> >> acpi_wmi0: cannot find EC device > >> >> device_attach: acpi_wmi0 attach returned 6 > >> >> acpi_wmi0: on acpi0 > >> >> acpi_wmi0: cannot find EC device > >> >> device_attach: acpi_wmi0 attach returned 6 > >> >> acpi_wmi0: on acpi0 > >> >> acpi_wmi0: cannot find EC device > >> >> device_attach: acpi_wmi0 attach returned 6 > >> >> > >> >> Likely following this commit: > >> >> > >> >> commit 708d048ccfdacf6199cc08a56aa05a9c899441fd > >> >> Author: Vladimir Kondratyev > >> >> Date: Sat Oct 31 22:19:39 2020 +0000 > >> >> > >> >> acpi_wmi(4): Add ACPI_PNP_INFO > >> >> > >> >> While the reason is obvious -- there's no EC in this system (Gigabyte > >> >> X299X AORUS MASTER desktop motherboard), at least searching the > >> >> `acpidump -dt` output doesn't show any PNP0C09 entries -- it certainly > >> >> looks like "something is broken" when first noticed. I wonder if we > >> >> could/should handle this gracefully -- no EC, do nothing, simply exit? > >> > > >> > Following patch should ignore missing EC like Linux does. Could you > >> > test it? > >> > > >> > diff --git a/sys/dev/acpi_support/acpi_wmi.c > >> > b/sys/dev/acpi_support/acpi_wmi.c > >> > index 379cfd1705f1..efae96cdcc9a 100644 > >> > --- a/sys/dev/acpi_support/acpi_wmi.c > >> > +++ b/sys/dev/acpi_support/acpi_wmi.c > >> > @@ -246,7 +246,7 @@ acpi_wmi_attach(device_t dev) > >> > if ((sc->ec_dev = devclass_get_device(devclass_find("acpi_ec"), 0)) > >> > == NULL) > >> > device_printf(dev, "cannot find EC device\n"); > >> > - else if (ACPI_FAILURE((status = > >> > AcpiInstallNotifyHandler(sc->wmi_handle, > >> > + if (ACPI_FAILURE((status = AcpiInstallNotifyHandler(sc->wmi_handle, > >> > ACPI_DEVICE_NOTIFY, acpi_wmi_notify_handler, sc)))) > >> > device_printf(sc->wmi_dev, "couldn't install notify handler - %s\n", > >> > AcpiFormatException(status)); > >> > @@ -701,6 +701,8 @@ acpi_wmi_ec_handler(UINT32 function, > >> > ACPI_PHYSICAL_ADDRESS address, > >> > return (AE_BAD_PARAMETER); > >> > if (address + (width / 8) - 1 > 0xFF) > >> > return (AE_BAD_ADDRESS); > >> > + if (sc->ec_dev == NULL) > >> > + return (AE_NOT_FOUND); > >> > if (function == ACPI_READ) > >> > *value = 0; > >> > ec_addr = address; > >> > >> @#@##! Web client ate all the tabs. > >> > >> Patch is in attachment. > > > > Output changed, though it's still somewhat noisy -- I guess there > > isn't a way to NOT report the device that we are not going to attach > > to, or do that e.g. only for verbose boot? > > > > acpi_wmi0: on acpi0 > > acpi_wmi0: cannot find EC device > > acpi_wmi0: Embedded MOF found > > ACPI: \134GSA1.WQCC: 1 arguments were passed to a non-method ACPI > > object (Buffer) (20201113/nsarguments-361) > > acpi_wmi1: on acpi0 > > acpi_wmi1: cannot find EC device > > acpi_wmi2: on acpi0 > > acpi_wmi2: cannot find EC device > > acpi_wmi3: on acpi0 > > acpi_wmi3: cannot find EC device > > acpi_wmi does not try to attach to EC node (PNP0C09). It only queries it > in OpRegion handler. > WMI's _HID/_CID is PNP0C14. According to your output, acpi_wmi has > successfully attached to 4 nodes. Oh great, I misunderstood then. And indeed, sysctl -b dev.acpi_wmi.0.bmof | bmf2mof provides some interesting information. All other 3 instances do not though. In any case, it seems to work now. > Verbosity can be reduced with attached patch if current level is too > high for you. Works for me both ways, I simply had the wrong impression that if we don't have EC, we can't attach at all.