Date: Thu, 19 Mar 2015 19:10:40 +1100 (EST) From: Ian Smith <smithi@nimnet.asn.au> To: Warner Losh <imp@bsdimp.com> Cc: Anthony Jenkins <Anthony.B.Jenkins@att.net>, freebsd-acpi@freebsd.org Subject: Re: [PATCH] ACPI CMOS region support rev. 5 Message-ID: <20150319184348.X22641@sola.nimnet.asn.au> In-Reply-To: <D1E7A1AE-51FD-4BFB-A861-13E16F95BB77@bsdimp.com> References: <20150222180817.GD27984@strugglingcoder.info> <54EB8C21.2080600@att.net> <2401337.2oUs7iAbtB@ralph.baldwin.cx> <54EF3D5D.4010106@att.net> <20150227222203.P38620@sola.nimnet.asn.au> <20150228125857.D1277@besplex.bde.org> <54F14368.4020807@att.net> <20150302002647.W42658@sola.nimnet.asn.au> <54F5E53D.1090601@att.net> <20150306025800.U46361@sola.nimnet.asn.au> <54F9D7E6.4050807@att.net> <5504FF32.3020202@att.net> <20150317001401.X22641@sola.nimnet.asn.au> <5506F00A.3030708@att.net> <5506FBE3.1000009@att.net> <20150317041624.K22641@sola.nimnet.asn.au> <55073442.5060005@att.net> <20150317222704.K22641@sola.nimnet.asn.au> <550825DE.7030406@att.net> <56B494A3-2058-4B7B-8183-646A46753A53@bsdimp.com> <5509A282.6070207@att.net> <D1E7A1AE-51FD-4BFB-A861-13E16F95BB77@bsdimp.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 18 Mar 2015 15:30:23 -0600, Warner Losh wrote: > > On Mar 18, 2015, at 10:06 AM, Anthony Jenkins <Anthony.B.Jenkins@att.net> wrote: > > > > On 03/18/2015 11:29 AM, Warner Losh wrote: > >>> On Mar 17, 2015, at 7:02 AM, Anthony Jenkins <Anthony.B.Jenkins@att.net> wrote: > >>>> \Where else might ATRTC_VERBOSE be set otherwise? > >>> I'm picturing a (future?) config(5) knob, e.g. > >>> > >>> device atrtc > >>> options ATRTC_VERBOSE=1 > >>> > >>> > >>> so it can be set at compile time. > >> Why not just boot verbose? history has shown too many options like > >> this is hard to use. You can blame this on me :) I agree about the option not being needed; the way it is you can just set sysctl hw.acpi.atrtc_verbose=0 to quell reports of successful access, if it turns out these are routine on some machines, especially outside of boot/suspend/resume contexts. However I'll still argue that, this being a new gadget and that we could use finding out which vendors want to read or write which locations in CMOS for whatever reason, at least while it's in head, we should log all access by default unless setting atrtc_verbose=0, and in _any_ case we should be logging attempts to R/W out-of-bounds CMOS locations. > > I think I understand what you're saying... I also prefer fewer config(5) > > knobs. So you're suggesting I determine (at runtime) the boot verbose > > setting (kenv(2) or however it's properly done) and dump the > > compile-time verbosity setting? > > if (bootverbose) > do verbose things; > > is how that˙˙s done. Sure, and maybe successful access could be limited to bootverbose, and we could ask people whose boxes fail to boot/suspend/resume/whatever to boot verbose to reveal such as why Anthony's HP Envy either failed to suspend or immediately resumed - which isn't entirely clear, even with the messages - unless its ACPI AML succeeded in reading minute, hour and weekday, but I have a feeling we may see more of this sort of thing. cheers, Ian From owner-freebsd-acpi@FreeBSD.ORG Thu Mar 19 13:11:17 2015 Return-Path: <owner-freebsd-acpi@FreeBSD.ORG> Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B8A8BDF3 for <freebsd-acpi@freebsd.org>; Thu, 19 Mar 2015 13:11:17 +0000 (UTC) Received: from nm12.bullet.mail.ne1.yahoo.com (nm12.bullet.mail.ne1.yahoo.com [98.138.90.75]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 759B6ED0 for <freebsd-acpi@freebsd.org>; Thu, 19 Mar 2015 13:11:16 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=att.net; s=s1024; t=1426770670; bh=AmpkyMRIAmOjUJPxUaox6qc6M/BJ4Nz3fBZY+GGDijU=; h=Date:From:To:CC:Subject:References:In-Reply-To:From:Subject; b=rKgGRcw1kmOCLqhLTU3jUKs4ioTPyJKlZrtOJOyUx6f8/O+svcTRk7hi/1jkdG1uKKVoQ/zSnPQzL6wNoSOeFoED6xhDs9N4+HB+HgA1K+yWks2YO0wy+vZNEDIpENWI+VsoTJ+YRxjtVqKpmEuFj65EQmQo/M89jne/oUx3hXM= Received: from [98.138.226.180] by nm12.bullet.mail.ne1.yahoo.com with NNFMP; 19 Mar 2015 13:11:10 -0000 Received: from [98.138.226.130] by tm15.bullet.mail.ne1.yahoo.com with NNFMP; 19 Mar 2015 13:11:10 -0000 Received: from [127.0.0.1] by smtp217.mail.ne1.yahoo.com with NNFMP; 19 Mar 2015 13:11:10 -0000 X-Yahoo-Newman-Id: 235953.59350.bm@smtp217.mail.ne1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: b2OiB2wVM1m7izx63TRrzL04fr4_zF29OQFtO0lR50lxlqV v.pgHT3jxlMqhtCDAFuRhsRCjbVv44eYl35OrAlkUXCgi.FJJdZYd_.A5Wp8 .CTcgxceQvwEw6pcaLtdiyodtuZ2TWbWTLUfFD66H5KWkB6HyFSiWOjWMf.7 NFuEh1z3Jbf7kF8Y4zQgHjl6AUffv88ALGMKTjdmD8KakyNoxyr_DIyky71W TdCrB9osaCN5JhfrXGnHaFMGRMmus9w9rKSEjUPBoMUBUWqemeBZ1868XUUw axxLZ0x7rs7ex0BNqiLUnY2vtnQVBwz.XNtT_4Rj7Vd2L8LZL8SNo3nQqvWa DbvAuHf6XoBSSFn..F0RlK7I4vHovLDbRjdDQIGGOYbnTMmKxzDbgPBsSd7P Bk0y3_T8epKwvT8JUvfLzsSJOVDmpwxf3_qagoTzijyANDvc4bNq21zMv.Vp BnhTALw0WrVwkYpW8lqsV18rvGoaw4f1d11dWXU6QRFx.VjXRgVXK_.sU76C fX_dwQip.fWF2GHWDJ4bHOZSLfaAf.ODMgiYDNoMXeNYu97Vj X-Yahoo-SMTP: OKD1keCswBBTAmAF1s00hLyKW3wE3YfSK0Eazl6b4VZG4LTqJxg- Message-ID: <550ACAEC.3060808@att.net> Date: Thu, 19 Mar 2015 09:11:08 -0400 From: Anthony Jenkins <Anthony.B.Jenkins@att.net> User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Ian Smith <smithi@nimnet.asn.au>, Warner Losh <imp@bsdimp.com> Subject: Re: [PATCH] ACPI CMOS region support rev. 5 References: <20150222180817.GD27984@strugglingcoder.info> <54EB8C21.2080600@att.net> <2401337.2oUs7iAbtB@ralph.baldwin.cx> <54EF3D5D.4010106@att.net> <20150227222203.P38620@sola.nimnet.asn.au> <20150228125857.D1277@besplex.bde.org> <54F14368.4020807@att.net> <20150302002647.W42658@sola.nimnet.asn.au> <54F5E53D.1090601@att.net> <20150306025800.U46361@sola.nimnet.asn.au> <54F9D7E6.4050807@att.net> <5504FF32.3020202@att.net> <20150317001401.X22641@sola.nimnet.asn.au> <5506F00A.3030708@att.net> <5506FBE3.1000009@att.net> <20150317041624.K22641@sola.nimnet.asn.au> <55073442.5060005@att.net> <20150317222704.K22641@sola.nimnet.asn.au> <550825DE.7030406@att.net> <56B494A3-2058-4B7B-8183-646A46753A53@bsdimp.com> <5509A282.6070207@att.net> <D1E7A1AE-51FD-4BFB-A861-13E16F95BB77@bsdimp.com> <20150319184348.X22641@sola.nimnet.asn.au> In-Reply-To: <20150319184348.X22641@sola.nimnet.asn.au> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Cc: freebsd-acpi@freebsd.org X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: ACPI and power management development <freebsd-acpi.freebsd.org> List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-acpi>, <mailto:freebsd-acpi-request@freebsd.org?subject=unsubscribe> List-Archive: <http://lists.freebsd.org/pipermail/freebsd-acpi/>; List-Post: <mailto:freebsd-acpi@freebsd.org> List-Help: <mailto:freebsd-acpi-request@freebsd.org?subject=help> List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-acpi>, <mailto:freebsd-acpi-request@freebsd.org?subject=subscribe> X-List-Received-Date: Thu, 19 Mar 2015 13:11:17 -0000 On 03/19/2015 04:10 AM, Ian Smith wrote: > On Wed, 18 Mar 2015 15:30:23 -0600, Warner Losh wrote: > > > On Mar 18, 2015, at 10:06 AM, Anthony Jenkins <Anthony.B.Jenkins@att.net> wrote: > > > > > > On 03/18/2015 11:29 AM, Warner Losh wrote: > > >>> On Mar 17, 2015, at 7:02 AM, Anthony Jenkins <Anthony.B.Jenkins@att.net> wrote: > > >>>> \Where else might ATRTC_VERBOSE be set otherwise? > > >>> I'm picturing a (future?) config(5) knob, e.g. > > >>> > > >>> device atrtc > > >>> options ATRTC_VERBOSE=1 > > >>> > > >>> > > >>> so it can be set at compile time. > > >> Why not just boot verbose? history has shown too many options like > > >> this is hard to use. > > You can blame this on me :) I agree about the option not being needed; > the way it is you can just set sysctl hw.acpi.atrtc_verbose=0 to quell > reports of successful access, if it turns out these are routine on some > machines, especially outside of boot/suspend/resume contexts. > > However I'll still argue that, this being a new gadget and that we could > use finding out which vendors want to read or write which locations in > CMOS for whatever reason, at least while it's in head, we should log all > access by default unless setting atrtc_verbose=0, So the default verbosity of ACPI CMOS region accesses should be "verbose"? I personally don't mind the default being "silent" and asking people triaging an ACPI problem to boot verbosely and send the logs (I think that's in the FreeBSD ACPI handbook anyway). > and in _any_ case we > should be logging attempts to R/W out-of-bounds CMOS locations. Error logs are always printed; they don't honor atrtc_verbose. > > > I think I understand what you're saying... I also prefer fewer config(5) > > > knobs. So you're suggesting I determine (at runtime) the boot verbose > > > setting (kenv(2) or however it's properly done) and dump the > > > compile-time verbosity setting? > > > > if (bootverbose) > > do verbose things; > > > > is how that˙˙s done. > > Sure, and maybe successful access could be limited to bootverbose, and > we could ask people whose boxes fail to boot/suspend/resume/whatever to > boot verbose to reveal such as why Anthony's HP Envy either failed to > suspend or immediately resumed - which isn't entirely clear, even with > the messages - unless its ACPI AML succeeded in reading minute, hour and > weekday, but I have a feeling we may see more of this sort of thing. Now that I think about it, adding this ACPI CMOS region access should simply eliminate a class of failures where FreeBSD wasn't giving the BIOS access to CMOS. Logging /successful/ R/W accesses to CMOS by the BIOS (AML) won't really provide any useful info (IMHO), but the user can flip on bootverbose if she's curious. If a user's box fails to boot/suspend/resume/whatever, we'll see any ACPI CMOS region access errors. Anthony > cheers, Ian
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20150319184348.X22641>