Date: Fri, 20 Mar 2015 00:49:22 +1100 (EST) From: Ian Smith <smithi@nimnet.asn.au> To: Anthony Jenkins <Anthony.B.Jenkins@att.net> Cc: freebsd-acpi@freebsd.org Subject: Re: [PATCH] ACPI CMOS region support rev. 5 Message-ID: <20150320002950.T22641@sola.nimnet.asn.au> In-Reply-To: <550ACAEC.3060808@att.net> 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> <550ACAEC.3060808@att.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 19 Mar 2015 09:11:08 -0400, Anthony Jenkins wrote:
> 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).
Assuming they know that their problem is ACPI related, sure.
> > 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.
That would be comforting. However I was referring to rev. 5:
+ if (bitwidth == 0 || bitwidth > 32 || (bitwidth & 0x07) ||
+ addr + bytewidth - 1 > 63) {
+ ATRTC_DBG_PRINTF(1,
+ "Invalid bitwidth (%u) or addr (0x%08lx).\n",
+ bitwidth, addr);
+ return AE_BAD_PARAMETER;
+ }
+ if (!acpi_check_rtc_access(func == ACPI_READ, addr, bytewidth)) {
+ ATRTC_DBG_PRINTF(1, "Bad CMOS %s access at addr 0x%08lx.\n",
+ func == ACPI_READ ? "read" : "write", addr);
+ return AE_BAD_PARAMETER;
+ }
> > > > 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.
Do we have other examples than your HP Envy of such a class of failures?
> 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.
Well I've made a case otherwise, likely too avidly; I'll leave it there.
Thanks for flushing out this issue and doing something about it!
cheers, Ian
From owner-freebsd-acpi@FreeBSD.ORG Thu Mar 19 14:14:18 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 C3114E09
for <freebsd-acpi@freebsd.org>; Thu, 19 Mar 2015 14:14:18 +0000 (UTC)
Received: from nm3.bullet.mail.gq1.yahoo.com (nm3.bullet.mail.gq1.yahoo.com
[98.136.218.68])
(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 87A0F7A6
for <freebsd-acpi@freebsd.org>; Thu, 19 Mar 2015 14:14:18 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=att.net; s=s1024;
t=1426774457; bh=kHdsZ9ZrVLKGCRXK3rgLmMGai9tmmCrtCWL1RlceqAE=;
h=Date:From:To:CC:Subject:References:In-Reply-To:From:Subject;
b=Zi6CNEY+GZ/tGmhVua9e9GC56FMLtc6T3LgQV+0lFWRI9yLCH20IPV2gQzZGlFR0nf8C70IYFwKUSUWIGciie+XSbclIA9xNZ3GAJ0x1mbJF5rdVOdhIoCuAylUTnnnBr441qXkjGvReKQTWiqMekSoq7A5fPM3noVmHxJvaAH4=
Received: from [98.137.12.190] by nm3.bullet.mail.gq1.yahoo.com with NNFMP;
19 Mar 2015 14:14:17 -0000
Received: from [98.138.226.63] by tm11.bullet.mail.gq1.yahoo.com with NNFMP;
19 Mar 2015 14:14:17 -0000
Received: from [127.0.0.1] by smtp214.mail.ne1.yahoo.com with NNFMP;
19 Mar 2015 14:14:16 -0000
X-Yahoo-Newman-Id: 946683.9164.bm@smtp214.mail.ne1.yahoo.com
X-Yahoo-Newman-Property: ymail-3
X-YMail-OSG: O_qPvXoVM1k38tW14eEbZdqWSNsv66Svbl7H9ima..fGeS3
2doBmzjOveuexmj_NhBun2_6cQXi8OvG58X2UzVfX5cloC30hcH8uA7Dhmby
95d8vklHo042mcVCdHZF_BtFmMcrzfPZ2HZz9wLyNlIohXm0.E_9z8pp7V78
W8Zm.B4Urp_b7fjqBA.t6EfqYqAFhvV5xXbfp.KmFoDHpBVctzvaXXEP9wpR
h38xzX9zvZApARPaaU1hOT.eKuoaSmms_3OYUhKUxp7D7A64CHcuvKugndZ1
LZNCEB76rubxFFg3qLxYTQb0embWjXPygq.PAPQjj1l4IGsGk2W.9cxCmo.g
sirUprFoAj3EZhK3ZNhiPdAHgGpNLzwK1ct9Tg81Y678NJdlTNrY6aySTDXE
B4odS9mJUy3XnkI9.gABGcN21tSwPsyy8HFQMn2u6c8u8i361SoWlxQAG5Sc
Ria0Y81_C4Gwv4cQTIjZ9X1ozb4Dsb5S3etPdOsn4exr9U5XmJaE_PyS1Nel
C1yRQfkPa0Atm6s9oVvyzLgvIL2iuDAVQhG6Scr0p7VZRyJ4B
X-Yahoo-SMTP: OKD1keCswBBTAmAF1s00hLyKW3wE3YfSK0Eazl6b4VZG4LTqJxg-
Message-ID: <550AD9B7.4090508@att.net>
Date: Thu, 19 Mar 2015 10:14:15 -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>
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> <550ACAEC.3060808@att.net>
<20150320002950.T22641@sola.nimnet.asn.au>
In-Reply-To: <20150320002950.T22641@sola.nimnet.asn.au>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
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 14:14:18 -0000
On 03/19/2015 09:49 AM, Ian Smith wrote:
> On Thu, 19 Mar 2015 09:11:08 -0400, Anthony Jenkins wrote:
> > 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.Jenk=
ins@att.net> wrote:
> > > > >=20
> > > > > On 03/18/2015 11:29 AM, Warner Losh wrote:
> > > > >>> On Mar 17, 2015, at 7:02 AM, Anthony Jenkins <Anthony.B.Jen=
kins@att.net> wrote:
> > > > >>>> \Where else might ATRTC_VERBOSE be set otherwise?
> > > > >>> I'm picturing a (future?) config(5) knob, e.g.
> > > > >>>=20
> > > > >>> device atrtc
> > > > >>> options ATRTC_VERBOSE=3D1
> > > > >>>=20
> > > > >>>=20
> > > > >>> so it can be set at compile time.
> > > > >> Why not just boot verbose? history has shown too many option=
s like
> > > > >> this is hard to use.
> > >
> > > You can blame this on me :) I agree about the option not being ne=
eded;=20
> > > the way it is you can just set sysctl hw.acpi.atrtc_verbose=3D0 to=
quell=20
> > > reports of successful access, if it turns out these are routine on=
some=20
> > > machines, especially outside of boot/suspend/resume contexts.
> > >
> > > However I'll still argue that, this being a new gadget and that we=
could=20
> > > use finding out which vendors want to read or write which location=
s in=20
> > > CMOS for whatever reason, at least while it's in head, we should l=
og all=20
> > > access by default unless setting atrtc_verbose=3D0,
> >=20
> > 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 th=
e
> > logs (I think that's in the FreeBSD ACPI handbook anyway).
>
> Assuming they know that their problem is ACPI related, sure.
>
> > > and in _any_ case we=20
> > > should be logging attempts to R/W out-of-bounds CMOS locations.
> >=20
> > Error logs are always printed; they don't honor atrtc_verbose.
>
> That would be comforting. However I was referring to rev. 5:
>
> + if (bitwidth =3D=3D 0 || bitwidth > 32 || (bitwidth & 0x07) ||
> + addr + bytewidth - 1 > 63) {
> + ATRTC_DBG_PRINTF(1,
> + "Invalid bitwidth (%u) or addr (0x%08lx).\n",
> + bitwidth, addr);
> + return AE_BAD_PARAMETER;
> + }
> + if (!acpi_check_rtc_access(func =3D=3D ACPI_READ, addr, bytewid=
th)) {
> + ATRTC_DBG_PRINTF(1, "Bad CMOS %s access at addr 0x%08lx=
=2E\n",
> + func =3D=3D ACPI_READ ? "read" : "write", addr)=
;
> + return AE_BAD_PARAMETER;
> + }
Ahh you're right, my bad. These are /supposed/ to be simple printf()s
(or ATRTC_DBG_PRINTF(0, ...)s, but I think this would trigger a
"unsigned int >=3D 0 is always true" warning).
> > > > > I think I understand what you're saying... I also prefer fewe=
r config(5)
> > > > > knobs. So you're suggesting I determine (at runtime) the boo=
t verbose
> > > > > setting (kenv(2) or however it's properly done) and dump the
> > > > > compile-time verbosity setting?
> > > >=20
> > > > if (bootverbose)
> > > > do verbose things;
> > > >=20
> > > > is how that=FF=FFs done.
> > >
> > > Sure, and maybe successful access could be limited to bootverbose,=
and=20
> > > we could ask people whose boxes fail to boot/suspend/resume/whatev=
er to=20
> > > boot verbose to reveal such as why Anthony's HP Envy either failed=
to=20
> > > suspend or immediately resumed - which isn't entirely clear, even =
with=20
> > > the messages - unless its ACPI AML succeeded in reading minute, ho=
ur and=20
> > > weekday, but I have a feeling we may see more of this sort of thin=
g.
> >=20
> > Now that I think about it, adding this ACPI CMOS region access shoul=
d
> > simply eliminate a class of failures where FreeBSD wasn't giving the=
> > BIOS access to CMOS.
>
> Do we have other examples than your HP Envy of such a class of failures=
?
Oh definitely! You should be able to search for my name in this
newsgroup and find instances where I've manually provided the patch to
someone having suspend/resume issues and they've been resolved. One has
subject "Impossible shutdown" circa 2014-June-26.
Anthony
> > 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.
>
> Well I've made a case otherwise, likely too avidly; I'll leave it there=
=2E
>
> Thanks for flushing out this issue and doing something about it!
>
> cheers, Ian
> _______________________________________________
> freebsd-acpi@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
> To unsubscribe, send any mail to "freebsd-acpi-unsubscribe@freebsd.org"=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20150320002950.T22641>