From owner-freebsd-current@freebsd.org Thu Dec 17 09:42:08 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 23C764B23B0 for ; Thu, 17 Dec 2020 09:42:08 +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 4CxRq369wyz59NP for ; Thu, 17 Dec 2020 09:42:07 +0000 (UTC) (envelope-from vladimir@kondratyev.su) Received: by mailman.nyi.freebsd.org (Postfix) id D407D4B259F; Thu, 17 Dec 2020 09:42:07 +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 D3D044B23AF for ; Thu, 17 Dec 2020 09:42:07 +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 4CxRq34RVtz59R5 for ; Thu, 17 Dec 2020 09:42:07 +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 8AFAA166120; Thu, 17 Dec 2020 12:42:05 +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 WhNwmHstO_tp; Thu, 17 Dec 2020 12:42:04 +0300 (MSK) Received: from mail.cicgroup.ru (unknown [195.170.219.74]) by corp.infotel.ru (Postfix) with ESMTP id 8537E166110; Thu, 17 Dec 2020 12:42:04 +0300 (MSK) Received: from mail.cicgroup.ru (localhost [127.0.0.1]) by mail.cicgroup.ru (Postfix) with ESMTP id 89B6742211F; Thu, 17 Dec 2020 12:42:03 +0300 (MSK) 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 67V3VHFtPXOI; Thu, 17 Dec 2020 12:42:00 +0300 (MSK) Received: from [192.168.0.30] (gateway [10.0.2.2]) by mail.cicgroup.ru (Postfix) with ESMTPA id CF65E42211C; Thu, 17 Dec 2020 12:42:00 +0300 (MSK) Subject: Re: acpi_wmi noisy without EC To: Yuri Pankov Cc: current@freebsd.org References: <7dc142d3-1e0b-41d4-bdb4-7217bd09bbef@www.fastmail.com> <7b80877ae59fdd90f2f3b5dbf3db2113@kondratyev.su> <5bb9ac64-ebab-4d22-8a43-1305b16f28cd@www.fastmail.com> <274d456e15ce621889bfe9e7eda190da@kondratyev.su> From: Vladimir Kondratyev Message-ID: Date: Thu, 17 Dec 2020 12:41:19 +0300 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:78.0) Gecko/20100101 Thunderbird/78.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 4CxRq34RVtz59R5 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: Thu, 17 Dec 2020 09:42:08 -0000 On 17.12.2020 11:24, Yuri Pankov wrote: > Yuri Pankov wrote: >> 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:=C2=A0=C2=A0 Sat Oct 31 22:19:39 2020 +0000 >>>>>>> >>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0 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.=C2=A0 I wond= er if we >>>>>>> could/should handle this gracefully -- no EC, do nothing, simply >>>>>>> exit? >>>>>> >>>>>> Following patch should ignore missing EC like Linux does. Could yo= u >>>>>> 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) >>>>>> =C2=A0 if ((sc->ec_dev =3D devclass_get_device(devclass_find("acpi= _ec"), 0)) >>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =3D=3D NULL) >>>>>> =C2=A0 device_printf(dev, "cannot find EC device\n"); >>>>>> - else if (ACPI_FAILURE((status =3D >>>>>> AcpiInstallNotifyHandler(sc->wmi_handle, >>>>>> + if (ACPI_FAILURE((status =3D AcpiInstallNotifyHandler(sc->wmi_ha= ndle, >>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ACPI_DEVICE_NOTIFY, acpi_wmi_notify= _handler, sc)))) >>>>>> =C2=A0 device_printf(sc->wmi_dev, "couldn't install notify handler= - >>>>>> %s\n", >>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 AcpiFormatException(status)); >>>>>> @@ -701,6 +701,8 @@ acpi_wmi_ec_handler(UINT32 function, >>>>>> ACPI_PHYSICAL_ADDRESS address, >>>>>> =C2=A0 return (AE_BAD_PARAMETER); >>>>>> =C2=A0 if (address + (width / 8) - 1 > 0xFF) >>>>>> =C2=A0 return (AE_BAD_ADDRESS); >>>>>> + if (sc->ec_dev =3D=3D NULL) >>>>>> + return (AE_NOT_FOUND); >>>>>> =C2=A0 if (function =3D=3D ACPI_READ) >>>>>> =C2=A0 *value =3D 0; >>>>>> =C2=A0 ec_addr =3D 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.=C2=A0 And indeed, sysctl -b >> dev.acpi_wmi.0.bmof | bmf2mof provides some interesting information.=C2= =A0 >> All other 3 instances do not though.=C2=A0 In any case, it seems to wo= rk 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. >=20 > Could you commit this, or is it incomplete fix? I did some tests with ACER ACPI extras which left functional after OPregion handler had been disabled, so I think, fix is complete. I have created a phabricator review: https://reviews.freebsd.org/D27653