From owner-freebsd-current@freebsd.org Tue Nov 17 08:01:26 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 492BC2D3AC0 for ; Tue, 17 Nov 2020 08:01:26 +0000 (UTC) (envelope-from vladimir@kondratyev.su) Received: from mailman.nyi.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 4CZz0k079dz3pcs for ; Tue, 17 Nov 2020 08:01:26 +0000 (UTC) (envelope-from vladimir@kondratyev.su) Received: by mailman.nyi.freebsd.org (Postfix) id 0439C2D3F8A; Tue, 17 Nov 2020 08:01:26 +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 03EE32D4183; Tue, 17 Nov 2020 08:01:26 +0000 (UTC) (envelope-from vladimir@kondratyev.su) Received: from corp.infotel.ru (corp.infotel.ru [195.170.219.3]) by mx1.freebsd.org (Postfix) with ESMTP id 4CZz0j5xn0z3pcr; Tue, 17 Nov 2020 08:01:25 +0000 (UTC) (envelope-from vladimir@kondratyev.su) Received: from corp (corp.infotel.ru [195.170.219.3]) by corp.infotel.ru (Postfix) with ESMTP id 32BA6148D12; Tue, 17 Nov 2020 11:01:18 +0300 (MSK) X-Virus-Scanned: amavisd-new at corp.infotel.ru Received: from corp.infotel.ru ([195.170.219.3]) by corp (corp.infotel.ru [195.170.219.3]) (amavisd-new, port 10024) with ESMTP id bv2SakxaveBU; Tue, 17 Nov 2020 11:01:17 +0300 (MSK) Received: from mail.cicgroup.ru (unknown [195.170.219.74]) by corp.infotel.ru (Postfix) with ESMTP id 200A8148D05; Tue, 17 Nov 2020 11:01:17 +0300 (MSK) Received: from mail.cicgroup.ru (localhost [127.0.0.1]) by mail.cicgroup.ru (Postfix) with ESMTP id AE47E42211F; Tue, 17 Nov 2020 10:57:42 +0300 (MSK) X-Virus-Scanned: amavisd-new at cicgroup.ru Received: from mail.cicgroup.ru ([127.0.0.1]) by mail.cicgroup.ru (mail.cicgroup.ru [127.0.0.1]) (amavisd-new, port 10024) with SMTP id v5K4HBwgUOKW; Tue, 17 Nov 2020 10:57:39 +0300 (MSK) Received: from localhost (localhost [127.0.0.1]) by mail.cicgroup.ru (Postfix) with ESMTPA id 8E30F42211C; Tue, 17 Nov 2020 10:57:39 +0300 (MSK) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Tue, 17 Nov 2020 10:57:39 +0300 From: Vladimir Kondratyev To: Yuri Pankov Cc: current@freebsd.org, owner-freebsd-current@freebsd.org Subject: Re: acpi_wmi noisy without EC In-Reply-To: <7dc142d3-1e0b-41d4-bdb4-7217bd09bbef@www.fastmail.com> References: <7dc142d3-1e0b-41d4-bdb4-7217bd09bbef@www.fastmail.com> Message-ID: <7b80877ae59fdd90f2f3b5dbf3db2113@kondratyev.su> X-Sender: vladimir@kondratyev.su User-Agent: Roundcube Webmail/1.3.5 X-Rspamd-Queue-Id: 4CZz0j5xn0z3pcr 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 08:01:26 -0000 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; -- WBR Vladimir Kondratyev