From smithi at nimnet.asn.au Sun Mar 1 14:29:22 2015
From: smithi at nimnet.asn.au (Ian Smith)
Date: Mon, 2 Mar 2015 01:29:06 +1100 (EST)
Subject: [PATCH] ACPI CMOS region support rev. 3 [was Re: No acpi_dell(4)]
In-Reply-To: <54F14368.4020807@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>
Message-ID: <20150302002647.W42658@sola.nimnet.asn.au>
On Fri, 27 Feb 2015 23:26:16 -0500, Anthony Jenkins wrote:
> On 02/27/15 21:56, Bruce Evans wrote:
> > On Sat, 28 Feb 2015, Ian Smith wrote:
I'm going to contract this down to a couple of points, ok fellas?
> > > Don't worry about any extra locking; this is going to be used at boot
> > > and/or resume we assume;
>
> Bleah... I hate assumptions like that.
So let's log everything at least while this is experimental in head, get
lots of people using all sorts of hardware to report any surprises, and
find out whenever else such service might be requested?
Sure, add a sysctl hw.acpi.cmosaccess.STFU for when we find benign stuff
being logged at other times than boot and suspend/resume, but when Jo
Blo reports here or in questions@ or laptop@ that her Hidden Dragon
Kneetop won't boot / suspend / resume / whatever with these funny lines
in /var/log/messages, we'll know what it's about without undertaling the
sort of research you had to do to get your HP Envy going, eh? :)
% sysctl smithi.STFU=1 # enough already ..
> +static ACPI_STATUS
> +acpi_rtc_cmos_handler(UINT32 function, ACPI_PHYSICAL_ADDRESS address,
> + UINT32 width, UINT64 *value, void *context, void *region_context)
> +{
> + struct atrtc_softc *sc;
> +
> + sc = (struct atrtc_softc *)context;
> + if (!value || !sc)
> + return AE_BAD_PARAMETER;
> + if (width > 32 || (width & 0x07) || address >= 64)
> + return AE_BAD_PARAMETER;
Width 0 passes, and address 61 width 32 passes. Maybe simpler:
int bytes; /* or size, whatever, above */
bytes = width >> 3;
and substitute 'bytes' subsequently, and here, perhaps:
if (bytes < 1 || bytes > 4 || (width & 0x07) || address > (64 - bytes))
> + if (!acpi_check_rtc_byteaccess(function == ACPI_READ, address))
> + return AE_BAD_PARAMETER;
acpi_check_rtc_byteaccess() needs to be called per byte of 1, 2 or 4
bytes - or pass it 'bytes' also, and loop over each of them within?
Failing this _really_ needs a printf, as below + 'REJECTED' ono, IMO.
> +
> + switch (function) {
> + case ACPI_READ:
> + acpi_cmos_read(address, (UINT8 *)value, width >> 3);
> + break;
> + case ACPI_WRITE:
> + acpi_cmos_write(address, (const UINT8 *)value,
> + width >> 3);
> + break;
> + default:
> + return AE_BAD_PARAMETER;
> + }
> + printf("%s: %-5s%02u address=%04lx value=%08x\n",
> + __FUNCTION__, function == ACPI_READ ? "READ" : "WRITE", width >> 3,
> + address, *((UINT32 *)value));
> + return AE_OK;
> +}
cheers, Ian
From Anthony.B.Jenkins at att.net Tue Mar 3 16:48:58 2015
From: Anthony.B.Jenkins at att.net (Anthony Jenkins)
Date: Tue, 03 Mar 2015 11:45:49 -0500
Subject: [PATCH] ACPI CMOS region support rev. 3 [was Re: No acpi_dell(4)]
In-Reply-To: <20150302002647.W42658@sola.nimnet.asn.au>
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>
Message-ID: <54F5E53D.1090601@att.net>
On 03/01/2015 09:29 AM, Ian Smith wrote:
> On Fri, 27 Feb 2015 23:26:16 -0500, Anthony Jenkins wrote:
> > On 02/27/15 21:56, Bruce Evans wrote:
> > > On Sat, 28 Feb 2015, Ian Smith wrote:
>
> I'm going to contract this down to a couple of points, ok fellas?
>
> > > > Don't worry about any extra locking; this is going to be used at
> boot
> > > > and/or resume we assume;
> > > Bleah... I hate assumptions like that.
>
> So let's log everything at least while this is experimental in head,
> get lots of people using all sorts of hardware to report any
> surprises, and find out whenever else such service might be requested?
No problem adding logging. The bit I'm confused about (unless I'm
misunderstanding the argument) is why
# ugly pseudocode
function original_cmos_xfer():
lock();
transfer byte to/from CMOS
unlock();
function acpi_cmos_xfer():
foreach byte in num_bytes:
call original_cmos_xfer(byte)
end foreach
is preferable to
# ugly pseudocode
function acpi_cmos_xfer():
lock();
foreachbyte in num_bytes:
transfer byte to/from CMOS
end foreach
unlock();
function original_cmos_xfer():
call acpi_cmos_xfer(num_bytes = 1);
There was no "extra locking", but I did introduce an extra function call
which would slow down CMOS accesses to the RTC for some performance
timers; I assume that's the main complaint. To me, the former
pseudocode is "incorrect" because it allows the possibility of another
thread of execution mucking with a multibyte CMOS access by ACPIBIOS. I
agree it's /probably/ unlikely tho.
> Sure, add a sysctl hw.acpi.cmosaccess.STFU for when we find benign
> stuff being logged at other times than boot and suspend/resume, but
> when Jo Blo reports here or in questions@ or laptop@ that her Hidden
> Dragon Kneetop won't boot / suspend / resume / whatever with these
> funny lines in /var/log/messages, we'll know what it's about without
> undertaling the sort of research you had to do to get your HP Envy
> going, eh? :)
Agreed; just saving logging tweaks for last.
>
> % sysctl smithi.STFU=1 # enough already ..
>
> > +static ACPI_STATUS
> > +acpi_rtc_cmos_handler(UINT32 function, ACPI_PHYSICAL_ADDRESS address,
> > + UINT32 width, UINT64 *value, void *context, void *region_context)
> > +{
> > + struct atrtc_softc *sc;
> > +
> > + sc = (struct atrtc_softc *)context;
> > + if (!value || !sc)
> > + return AE_BAD_PARAMETER;
> > + if (width > 32 || (width & 0x07) || address >= 64)
> > + return AE_BAD_PARAMETER;
>
> Width 0 passes, and address 61 width 32 passes. Maybe simpler:
> int bytes; /* or size, whatever, above */
> bytes = width >> 3;
> and substitute 'bytes' subsequently, and here, perhaps:
>
> if (bytes < 1 || bytes > 4 || (width & 0x07) || address > (64 -
> bytes))
>
> > + if (!acpi_check_rtc_byteaccess(function == ACPI_READ, address))
> > + return AE_BAD_PARAMETER;
>
> acpi_check_rtc_byteaccess() needs to be called per byte of 1, 2 or 4
> bytes - or pass it 'bytes' also, and loop over each of them within?
Thought I had done/fixed that... I'll check.
> Failing this _really_ needs a printf, as below + 'REJECTED' ono, IMO.
Agreed.
Thanks,
Anthony
>
> > +
> > + switch (function) {
> > + case ACPI_READ:
> > + acpi_cmos_read(address, (UINT8 *)value, width
> >> 3);
> > + break;
> > + case ACPI_WRITE:
> > + acpi_cmos_write(address, (const UINT8 *)value,
> > + width >> 3);
> > + break;
> > + default:
> > + return AE_BAD_PARAMETER;
> > + }
> > + printf("%s: %-5s%02u address=%04lx value=%08x\n",
> > + __FUNCTION__, function == ACPI_READ ? "READ" : "WRITE",
> width >> 3,
> > + address, *((UINT32 *)value));
> > + return AE_OK;
> > +}
>
> cheers, Ian
From smithi at nimnet.asn.au Fri Mar 6 11:58:40 2015
From: smithi at nimnet.asn.au (Ian Smith)
Date: Fri, 6 Mar 2015 22:49:19 +1100 (EST)
Subject: [PATCH] ACPI CMOS region support rev. 3 [was Re: No acpi_dell(4)]
In-Reply-To: <54F5E53D.1090601@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>
Message-ID: <20150306025800.U46361@sola.nimnet.asn.au>
On Tue, 3 Mar 2015 11:45:49 -0500, Anthony Jenkins wrote:
> On 03/01/2015 09:29 AM, Ian Smith wrote:
[..]
> No problem adding logging. The bit I'm confused about (unless I'm
> misunderstanding the argument) is why
>
> # ugly pseudocode
> function original_cmos_xfer():
> lock();
> transfer byte to/from CMOS
> unlock();
>
> function acpi_cmos_xfer():
> foreach byte in num_bytes:
> call original_cmos_xfer(byte)
> end foreach
>
>
> is preferable to
>
> # ugly pseudocode
> function acpi_cmos_xfer():
> lock();
> foreachbyte in num_bytes:
> transfer byte to/from CMOS
> end foreach
> unlock();
>
> function original_cmos_xfer():
> call acpi_cmos_xfer(num_bytes = 1);
>
>
> There was no "extra locking", but I did introduce an extra function call
> which would slow down CMOS accesses to the RTC for some performance
> timers; I assume that's the main complaint.
And slow down all other callers of rtcin() and writertc(), as well as
any timer using the RTC periodic interrupt. Most callers are right here
in /sys/x86/isa/atrtc.c; I make it 37 plus another 9 #ifdef DDB. This
works for me on a 9.3-R system, not checked on 10.x or head ..
smithi at x200:~ % find /usr/src -type f -name "*.[ch]" \
-exec egrep -Hl 'rtcin\(|writertc\(|readrtc\(' {} + | xargs less
:/rtcin|writertc|readrtc
All in /sys/ of course. Ignoring mips/malta, most callers likely don't
care if these calls take twice(?) as long, but to me it seems suboptimal
to impede likely more frequently used calls for the sake of a much less
frequently used high-level function, that itself is not timing-critical.
I know nothing about how much xen/clock.c cares about timing. nvram.c
doesn't seem bothered, nor fetching memory size, fdc or vga parameters.
On the other hand, interrupt service needs to care a lot about timing.
Remember that FreeBSD is running on other than latest kit, including eg
266MHz 5x86 Soekris routers and the like, and smaller embedded systems
that may very well need not to have RTC ISRs time-pessimised, at up to
8kHz rates; such are also less likely to have HPETs to use as timers.
And for that matter, many older and smaller boards are unlikely to be
running ACPI BIOS at all - which brings up another question, below ..
> To me, the former
> pseudocode is "incorrect" because it allows the possibility of another
> thread of execution mucking with a multibyte CMOS access by ACPIBIOS. I
> agree it's /probably/ unlikely tho.
I've no idea whether that may be possible, or if or how it might matter.
But all that's just me, the Time Lords are likely having a good laugh :)
Regarding systems without ACPI loaded, or active: what happens when the
below AcpiInstallAddressSpaceHandler() call fails, but returns 0? Would
not that prevent rtc_start() from running atrtc_start() etc for non-ACPI
clock initialisation and registration?
I suppose there's a global kernel variable for acpi_is_active ono?
> +static int
> rtc_start(struct eventtimer *et, sbintime_t first, sbintime_t period)
> {
>
> @@ -245,10 +323,17 @@
> int i;
>
> sc = device_get_softc(dev);
> + sc->acpi_handle = acpi_get_handle(dev);
> sc->port_res = bus_alloc_resource(dev, SYS_RES_IOPORT, &sc->port_rid,
> IO_RTC, IO_RTC + 1, 2, RF_ACTIVE);
> if (sc->port_res == NULL)
> device_printf(dev, "Warning: Couldn't map I/O.\n");
> + if (ACPI_FAILURE(AcpiInstallAddressSpaceHandler(sc->acpi_handle,
> + ACPI_ADR_SPACE_CMOS, acpi_rtc_cmos_handler, NULL, sc)))
> + {
> + device_printf(dev, "Error registering ACPI CMOS address space handler.\n");
> + return 0;
> + }
> atrtc_start();
> clock_register(dev, 1000000);
> bzero(&sc->et, sizeof(struct eventtimer));
> @@ -286,6 +371,15 @@
> return(0);
> }
Might that not matter for detach, as you're not testing for return code?
> +static int atrtc_detach(device_t dev)
> +{
> + struct atrtc_softc *sc;
> +
> + sc = device_get_softc(dev);
> + AcpiRemoveAddressSpaceHandler(sc->acpi_handle,
> ACPI_ADR_SPACE_CMOS, acpi_rtc_cmos_handler);
> + return bus_generic_detach(dev);
> +}
cheers, Ian
From Anthony.B.Jenkins at att.net Fri Mar 6 16:40:41 2015
From: Anthony.B.Jenkins at att.net (Anthony Jenkins)
Date: Fri, 06 Mar 2015 11:37:58 -0500
Subject: [PATCH] ACPI CMOS region support rev. 3 [was Re: No acpi_dell(4)]
In-Reply-To: <20150306025800.U46361@sola.nimnet.asn.au>
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>
Message-ID: <54F9D7E6.4050807@att.net>
On 03/06/2015 06:49 AM, Ian Smith wrote:
> On Tue, 3 Mar 2015 11:45:49 -0500, Anthony Jenkins wrote:
> > On 03/01/2015 09:29 AM, Ian Smith wrote:
> [..]
> Regarding systems without ACPI loaded, or active: what happens when the
> below AcpiInstallAddressSpaceHandler() call fails, but returns 0? Would
> not that prevent rtc_start() from running atrtc_start() etc for non-ACPI
> clock initialisation and registration?
Good catch, there's technically no reason to bail on rtc_start() if I
fail to register the ACPI CMOS handler; it'll just never get called
(same as old behaviour). I'll change "Error" to "Warning" and remove
the return 0.
> I suppose there's a global kernel variable for acpi_is_active ono?
>
> > +static int
> > rtc_start(struct eventtimer *et, sbintime_t first, sbintime_t period)
> > {
> >
> > @@ -245,10 +323,17 @@
> > int i;
> >
> > sc = device_get_softc(dev);
> > + sc->acpi_handle = acpi_get_handle(dev);
> > sc->port_res = bus_alloc_resource(dev, SYS_RES_IOPORT, &sc->port_rid,
> > IO_RTC, IO_RTC + 1, 2, RF_ACTIVE);
> > if (sc->port_res == NULL)
> > device_printf(dev, "Warning: Couldn't map I/O.\n");
> > + if (ACPI_FAILURE(AcpiInstallAddressSpaceHandler(sc->acpi_handle,
> > + ACPI_ADR_SPACE_CMOS, acpi_rtc_cmos_handler, NULL, sc)))
> > + {
> > + device_printf(dev, "Error registering ACPI CMOS address space handler.\n");
> > + return 0;
> > + }
> > atrtc_start();
> > clock_register(dev, 1000000);
> > bzero(&sc->et, sizeof(struct eventtimer));
> > @@ -286,6 +371,15 @@
> > return(0);
> > }
>
> Might that not matter for detach, as you're not testing for return code?
Yeah I'd prefer to remember the failure to install the handler and
conditionally uninstall it in the detach method.
I'll fix up the logging and add these suggestions this weekend.
Thanks,
Anthony
> > +static int atrtc_detach(device_t dev)
> > +{
> > + struct atrtc_softc *sc;
> > +
> > + sc = device_get_softc(dev);
> > + AcpiRemoveAddressSpaceHandler(sc->acpi_handle,
> > ACPI_ADR_SPACE_CMOS, acpi_rtc_cmos_handler);
> > + return bus_generic_detach(dev);
> > +}
>
> cheers, Ian
> _______________________________________________
> freebsd-acpi at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
> To unsubscribe, send any mail to "freebsd-acpi-unsubscribe at freebsd.org"
From bugzilla-noreply at freebsd.org Thu Mar 12 04:20:25 2015
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Thu, 12 Mar 2015 04:20:25 +0000
Subject: [Bug 197367] [psm][acpi] There no support Touchpad DELL Inspiron
17.3" 5000 series (DELL 5748)
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=197367
Mark Linimon changed:
What |Removed |Added
----------------------------------------------------------------------------
Assignee|freebsd-bugs at FreeBSD.org |freebsd-acpi at FreeBSD.org
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Thu Mar 12 04:20:47 2015
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Thu, 12 Mar 2015 04:20:47 +0000
Subject: [Bug 195116] Display brightness control/resuming require acpi_video
to be loaded after i915kms
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=195116
Mark Linimon changed:
What |Removed |Added
----------------------------------------------------------------------------
Assignee|freebsd-bugs at FreeBSD.org |freebsd-acpi at FreeBSD.org
Keywords| |i915
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Thu Mar 12 04:20:59 2015
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Thu, 12 Mar 2015 04:20:59 +0000
Subject: [Bug 194601] FreeBSD 10.1-RC3 does not update acpi battery status
from discharging when charging
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194601
Mark Linimon changed:
What |Removed |Added
----------------------------------------------------------------------------
Assignee|freebsd-bugs at FreeBSD.org |freebsd-acpi at FreeBSD.org
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Thu Mar 12 04:21:31 2015
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Thu, 12 Mar 2015 04:21:31 +0000
Subject: [Bug 193720] Adopt a new acpi_quirk from DragonflyBSD
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193720
Mark Linimon changed:
What |Removed |Added
----------------------------------------------------------------------------
Assignee|freebsd-bugs at FreeBSD.org |freebsd-acpi at FreeBSD.org
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Thu Mar 12 04:21:45 2015
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Thu, 12 Mar 2015 04:21:45 +0000
Subject: [Bug 193671] [acpiconf] Extra whitespace at the end of the State: line
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193671
Mark Linimon changed:
What |Removed |Added
----------------------------------------------------------------------------
Assignee|freebsd-bugs at FreeBSD.org |freebsd-acpi at FreeBSD.org
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Thu Mar 12 04:22:03 2015
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Thu, 12 Mar 2015 04:22:03 +0000
Subject: [Bug 192929] ACPI suspend doesn't resume on macbook
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=192929
Mark Linimon changed:
What |Removed |Added
----------------------------------------------------------------------------
Assignee|freebsd-bugs at FreeBSD.org |freebsd-acpi at FreeBSD.org
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Thu Mar 12 04:22:16 2015
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Thu, 12 Mar 2015 04:22:16 +0000
Subject: [Bug 190786] ACPI BIOS Warning (bug): 32/64X length mismatch in
FADT/Gpe1Block
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=190786
Mark Linimon changed:
What |Removed |Added
----------------------------------------------------------------------------
Assignee|freebsd-bugs at FreeBSD.org |freebsd-acpi at FreeBSD.org
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Thu Mar 12 04:22:30 2015
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Thu, 12 Mar 2015 04:22:30 +0000
Subject: [Bug 181283] [acpi_ibm] acpi_ibm module is useless on ThinkPad W530
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=181283
Mark Linimon changed:
What |Removed |Added
----------------------------------------------------------------------------
Assignee|freebsd-bugs at FreeBSD.org |freebsd-acpi at FreeBSD.org
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Thu Mar 12 04:22:44 2015
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Thu, 12 Mar 2015 04:22:44 +0000
Subject: [Bug 172918] [pci] [suspend/resume] ACPI errors at suspend/resume
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=172918
Mark Linimon changed:
What |Removed |Added
----------------------------------------------------------------------------
Assignee|freebsd-bugs at FreeBSD.org |freebsd-acpi at FreeBSD.org
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Thu Mar 12 04:24:52 2015
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Thu, 12 Mar 2015 04:24:51 +0000
Subject: [Bug 172742] acpidump(8): confused about Method (_CRT, 0, Serialized)
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=172742
Mark Linimon changed:
What |Removed |Added
----------------------------------------------------------------------------
Assignee|freebsd-bugs at FreeBSD.org |freebsd-acpi at FreeBSD.org
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Thu Mar 12 04:25:09 2015
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Thu, 12 Mar 2015 04:25:09 +0000
Subject: [Bug 152792] [acpica] [patch] move temperature conversion macros to
a common header
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=152792
Mark Linimon changed:
What |Removed |Added
----------------------------------------------------------------------------
Assignee|freebsd-bugs at FreeBSD.org |freebsd-acpi at FreeBSD.org
Keywords| |patch
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Thu Mar 12 04:25:38 2015
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Thu, 12 Mar 2015 04:25:38 +0000
Subject: [Bug 102783] [acpi] hw.acpi has thermal controls backwards when
external power connected at bootup
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=102783
Mark Linimon changed:
What |Removed |Added
----------------------------------------------------------------------------
Assignee|freebsd-bugs at FreeBSD.org |freebsd-acpi at FreeBSD.org
--- Comment #1 from Mark Linimon ---
To submitter: is this aging PR still relevant?
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Thu Mar 12 05:13:45 2015
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Thu, 12 Mar 2015 05:13:45 +0000
Subject: [Bug 194601] FreeBSD 10.1-RC3 does not update acpi battery status
from discharging when charging
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194601
smithi at nimnet.asn.au changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |smithi at nimnet.asn.au
--- Comment #2 from smithi at nimnet.asn.au ---
This looks like another that may/should have been fixed by r277579
(see https://svnweb.freebsd.org/changeset/base/277579) in relation
to https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=162859
which was merged to stable/10 and stable/9 on 2015-01-26 21:21:42 UTC
although Marcus' Feb 18 comment suggests he should have picked that up?
If your /sys/dev/acpica/acpi_ec.c is not >= r277579 then you should
update stable/10 again .. otherwise there is perhaps still an issue?
Ian
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Thu Mar 12 06:58:36 2015
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Thu, 12 Mar 2015 06:58:36 +0000
Subject: [Bug 172918] [pci] [suspend/resume] ACPI errors at suspend/resume
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=172918
smithi at nimnet.asn.au changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |smithi at nimnet.asn.au
--- Comment #1 from smithi at nimnet.asn.au ---
These messages were not an issue in themselves, but accompanied a potential
problem affecting some systems suffering loss of USB ports on resume, which
was fixed (r267647) weeks before 9.3-RELEASE. Please try with that or later.
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Thu Mar 12 15:46:28 2015
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Thu, 12 Mar 2015 15:46:28 +0000
Subject: [Bug 102783] [acpi] hw.acpi has thermal controls backwards when
external power connected at bootup
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=102783
--- Comment #2 from jboisvert at gmail.com ---
(In reply to Mark Linimon from comment #1)
This PR is no longer relevant.
The problem originally occurred on a Gateway laptop that I no longer own.
I can confirm that this problem does not happen in FBSD-10 on a Dell 620.
--
You are receiving this mail because:
You are the assignee for the bug.
From Anthony.B.Jenkins at att.net Sun Mar 15 03:43:09 2015
From: Anthony.B.Jenkins at att.net (Anthony Jenkins)
Date: Sat, 14 Mar 2015 23:40:34 -0400
Subject: [PATCH] ACPI CMOS region support rev. 4
In-Reply-To: <54F9D7E6.4050807@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>
Message-ID: <5504FF32.3020202@att.net>
How about this one? :-) Sorry it's a week late.
Anthony
On 03/06/15 11:37, Anthony Jenkins wrote:
> On 03/06/2015 06:49 AM, Ian Smith wrote:
>> On Tue, 3 Mar 2015 11:45:49 -0500, Anthony Jenkins wrote:
>> > On 03/01/2015 09:29 AM, Ian Smith wrote:
>> [..]
>> Regarding systems without ACPI loaded, or active: what happens when the
>> below AcpiInstallAddressSpaceHandler() call fails, but returns 0? Would
>> not that prevent rtc_start() from running atrtc_start() etc for non-ACPI
>> clock initialisation and registration?
> Good catch, there's technically no reason to bail on rtc_start() if I
> fail to register the ACPI CMOS handler; it'll just never get called
> (same as old behaviour). I'll change "Error" to "Warning" and remove
> the return 0.
>
>> I suppose there's a global kernel variable for acpi_is_active ono?
>>
>> > +static int
>> > rtc_start(struct eventtimer *et, sbintime_t first, sbintime_t period)
>> > {
>> >
>> > @@ -245,10 +323,17 @@
>> > int i;
>> >
>> > sc = device_get_softc(dev);
>> > + sc->acpi_handle = acpi_get_handle(dev);
>> > sc->port_res = bus_alloc_resource(dev, SYS_RES_IOPORT, &sc->port_rid,
>> > IO_RTC, IO_RTC + 1, 2, RF_ACTIVE);
>> > if (sc->port_res == NULL)
>> > device_printf(dev, "Warning: Couldn't map I/O.\n");
>> > + if (ACPI_FAILURE(AcpiInstallAddressSpaceHandler(sc->acpi_handle,
>> > + ACPI_ADR_SPACE_CMOS, acpi_rtc_cmos_handler, NULL, sc)))
>> > + {
>> > + device_printf(dev, "Error registering ACPI CMOS address space handler.\n");
>> > + return 0;
>> > + }
>> > atrtc_start();
>> > clock_register(dev, 1000000);
>> > bzero(&sc->et, sizeof(struct eventtimer));
>> > @@ -286,6 +371,15 @@
>> > return(0);
>> > }
>>
>> Might that not matter for detach, as you're not testing for return code?
> Yeah I'd prefer to remember the failure to install the handler and
> conditionally uninstall it in the detach method.
>
> I'll fix up the logging and add these suggestions this weekend.
>
> Thanks,
> Anthony
>
>> > +static int atrtc_detach(device_t dev)
>> > +{
>> > + struct atrtc_softc *sc;
>> > +
>> > + sc = device_get_softc(dev);
>> > + AcpiRemoveAddressSpaceHandler(sc->acpi_handle,
>> > ACPI_ADR_SPACE_CMOS, acpi_rtc_cmos_handler);
>> > + return bus_generic_detach(dev);
>> > +}
>>
>> cheers, Ian
>> _______________________________________________
>> freebsd-acpi at freebsd.org mailing list
>> http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
>> To unsubscribe, send any mail to "freebsd-acpi-unsubscribe at freebsd.org"
> _______________________________________________
> freebsd-acpi at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
> To unsubscribe, send any mail to "freebsd-acpi-unsubscribe at freebsd.org"
-------------- next part --------------
A non-text attachment was scrubbed...
Name: atrtc_c_rev4.diff
Type: text/x-patch
Size: 5565 bytes
Desc: not available
URL:
From bugzilla-noreply at freebsd.org Sun Mar 15 19:59:22 2015
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Sun, 15 Mar 2015 19:59:22 +0000
Subject: [Bug 198603] [acpi] HP ProBook 430 G2: can't change brightness via
acpi_hp and acpi_video
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=198603
Mark Linimon changed:
What |Removed |Added
----------------------------------------------------------------------------
Assignee|freebsd-bugs at FreeBSD.org |freebsd-acpi at FreeBSD.org
--
You are receiving this mail because:
You are the assignee for the bug.
From smithi at nimnet.asn.au Mon Mar 16 13:59:22 2015
From: smithi at nimnet.asn.au (Ian Smith)
Date: Tue, 17 Mar 2015 00:59:07 +1100 (EST)
Subject: [PATCH] ACPI CMOS region support rev. 4
In-Reply-To: <5504FF32.3020202@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>
Message-ID: <20150317001401.X22641@sola.nimnet.asn.au>
On Sat, 14 Mar 2015 23:40:34 -0400, Anthony Jenkins wrote:
> How about this one? :-) Sorry it's a week late.
+static unsigned int atrtc_verbose = 0;
+SYSCTL_UINT(_debug, OID_AUTO, atrtc_verbose, CTLFLAG_RWTUN,
+ &atrtc_verbose, 0, "AT-RTC Debug Level (0-2)");
+#define ATRTC_DBG_PRINTF(level, format, ...) \
+ if (atrtc_verbose >= level) printf(format, ##__VA_ARGS__)
+
A sysctl is good, but it needs to default to 1 if we're ever going to
find out what various vendors are wanting to do with CMOS settings;
anyone annoyed by any extra messages outside boot or suspend/resume
could turn it off - after we've had the opportunity to get a report.
I can only reiterate part of my message before last, of March 2nd:
=======
> +static ACPI_STATUS
> +acpi_rtc_cmos_handler(UINT32 function, ACPI_PHYSICAL_ADDRESS address,
> + UINT32 width, UINT64 *value, void *context, void *region_context)
> +{
> + struct atrtc_softc *sc;
> +
> + sc = (struct atrtc_softc *)context;
> + if (!value || !sc)
> + return AE_BAD_PARAMETER;
> + if (width > 32 || (width & 0x07) || address >= 64)
> + return AE_BAD_PARAMETER;
Width 0 passes, and address 61 width 32 passes. Maybe simpler:
int bytes; /* or size, whatever, above */
bytes = width >> 3;
and substitute 'bytes' subsequently, and here, perhaps:
if (bytes < 1 || bytes > 4 || (width & 0x07) || address > (64 - bytes))
> + if (!acpi_check_rtc_byteaccess(function == ACPI_READ, address))
> + return AE_BAD_PARAMETER;
acpi_check_rtc_byteaccess() needs to be called per byte of 1, 2 or 4
bytes - or pass it 'bytes' also, and loop over each of them within?
=======
Otherwise (for example) a 2 byte read from 0x0b or 4 byte read from
0x09-0x0b will read 0x0c (clearing interrupts), or a 2 or 4 byte write
to (say) 0x01 will also write to 0x02 and 0x04 (clobbering the time).
Sorry if I'm too much of a stickler for defensive programming ..
cheers, Ian
-------------- next part --------------
A non-text attachment was scrubbed...
Name: atrtc_c_rev4.diff
Type: text/x-patch
Size: 5565 bytes
Desc:
URL:
From Anthony.B.Jenkins at att.net Mon Mar 16 15:02:58 2015
From: Anthony.B.Jenkins at att.net (Anthony Jenkins)
Date: Mon, 16 Mar 2015 11:00:26 -0400
Subject: [PATCH] ACPI CMOS region support rev. 4
In-Reply-To: <20150317001401.X22641@sola.nimnet.asn.au>
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>
Message-ID: <5506F00A.3030708@att.net>
On 03/16/2015 09:59 AM, Ian Smith wrote:
> On Sat, 14 Mar 2015 23:40:34 -0400, Anthony Jenkins wrote:
>
> > How about this one? :-) Sorry it's a week late.
>
> +static unsigned int atrtc_verbose = 0;
> +SYSCTL_UINT(_debug, OID_AUTO, atrtc_verbose, CTLFLAG_RWTUN,
> + &atrtc_verbose, 0, "AT-RTC Debug Level (0-2)");
> +#define ATRTC_DBG_PRINTF(level, format, ...) \
> + if (atrtc_verbose >= level) printf(format, ##__VA_ARGS__)
> +
>
> A sysctl is good, but it needs to default to 1 if we're ever going to
> find out what various vendors are wanting to do with CMOS settings;
> anyone annoyed by any extra messages outside boot or suspend/resume
> could turn it off - after we've had the opportunity to get a report.
I'd actually prefer debug level to be compile-time (there's no real need
for it to be runtime), but I really don't want to add a config(5) knob
(I can of course).
> I can only reiterate part of my message before last, of March 2nd:
>
> =======
>> +static ACPI_STATUS
>> +acpi_rtc_cmos_handler(UINT32 function, ACPI_PHYSICAL_ADDRESS address,
>> + UINT32 width, UINT64 *value, void *context, void *region_context)
>> +{
>> + struct atrtc_softc *sc;
>> +
>> + sc = (struct atrtc_softc *)context;
>> + if (!value || !sc)
>> + return AE_BAD_PARAMETER;
>> + if (width > 32 || (width & 0x07) || address >= 64)
>> + return AE_BAD_PARAMETER;
> Width 0 passes, and address 61 width 32 passes. Maybe simpler:
> int bytes; /* or size, whatever, above */
> bytes = width >> 3;
That should probably be
bytes = (width + 7) >>3;
or
bytes = (width + 7) / 8; /* Integer division more expensive
on x86? */
because width == 1 would result in bytes = 0.
> and substitute 'bytes' subsequently, and here, perhaps:
>
> if (bytes < 1 || bytes > 4 || (width & 0x07) || address > (64 - bytes))
>
>> + if (!acpi_check_rtc_byteaccess(function == ACPI_READ, address))
>> + return AE_BAD_PARAMETER;
> acpi_check_rtc_byteaccess() needs to be called per byte of 1, 2 or 4
> bytes - or pass it 'bytes' also, and loop over each of them within?
> =======
>
> Otherwise (for example) a 2 byte read from 0x0b or 4 byte read from
> 0x09-0x0b will read 0x0c (clearing interrupts), or a 2 or 4 byte write
> to (say) 0x01 will also write to 0x02 and 0x04 (clobbering the time).
Right, this is an (incorrect) hybrid of a few attempts, probably from
around the time I lost my SSD and only had a single backup copy of my
work to go from. In one revision I had disallowed all multibyte
accesses (width > 8) since IMHO it was more consistent/correct with the
suggested locking. I wasn't ignoring your suggestion, just making one
or a few changes at a time (generally the simpler ones).
I /believe/ the ACPI spec disallows requests for width=0. Looking at
ACPIspec50.pdf, the smallest OperationRegion that can be defined is 1
byte, and the smallest Field within an OpRegion is 1 bit, and all
accesses to an OpRegion occur via Fields (Section 19.5.96
OperationRegion (Declare Operation Region)). Doesn't hurt to check
tho. Also OpRegions operations are synchronized, so I at least don't
have to worry about AML accessing CMOS all willy-nilly.
> Sorry if I'm too much of a stickler for defensive programming ..
Oh no problem, I can handle a bit of criticism :-)
Anthony
>
> cheers, Ian
>
>
> _______________________________________________
> freebsd-acpi at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
> To unsubscribe, send any mail to "freebsd-acpi-unsubscribe at freebsd.org"
From Anthony.B.Jenkins at att.net Mon Mar 16 15:53:00 2015
From: Anthony.B.Jenkins at att.net (Anthony Jenkins)
Date: Mon, 16 Mar 2015 11:50:59 -0400
Subject: [PATCH] ACPI CMOS region support rev. 4
In-Reply-To: <5506F00A.3030708@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>
Message-ID: <5506FBE3.1000009@att.net>
On 03/16/2015 11:00 AM, Anthony Jenkins wrote:
> On 03/16/2015 09:59 AM, Ian Smith wrote:
>> On Sat, 14 Mar 2015 23:40:34 -0400, Anthony Jenkins wrote:
>>> + if (!acpi_check_rtc_byteaccess(function == ACPI_READ, address))
>>> + return AE_BAD_PARAMETER;
>> acpi_check_rtc_byteaccess() needs to be called per byte of 1, 2 or 4
>> bytes - or pass it 'bytes' also, and loop over each of them within?
>> =======
>>
>> Otherwise (for example) a 2 byte read from 0x0b or 4 byte read from
>> 0x09-0x0b will read 0x0c (clearing interrupts), or a 2 or 4 byte write
>> to (say) 0x01 will also write to 0x02 and 0x04 (clobbering the time).
> Right, this is an (incorrect) hybrid of a few attempts, probably from
> around the time I lost my SSD and only had a single backup copy of my
> work to go from. In one revision I had disallowed all multibyte
> accesses (width > 8) since IMHO it was more consistent/correct with the
> suggested locking. I wasn't ignoring your suggestion, just making one
> or a few changes at a time (generally the simpler ones).
Okay now I remember why I was reluctant to do this - suppose ACPIBIOS
does a multibyte op on a set of bytes whose last byte fails
acpi_check_rtc_byteaccess(). I will have already performed n-1
accesses. At one point I had a revision (acpi_check_rtc_access()?) that
permitted/denied the entire request (it took the starting address and
byte length), but I guess that got lost too. I'll just recreate it...
Anthony
>
>> cheers, Ian
>>
>>
>> _______________________________________________
>> freebsd-acpi at freebsd.org mailing list
>> http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
>> To unsubscribe, send any mail to "freebsd-acpi-unsubscribe at freebsd.org"
From smithi at nimnet.asn.au Mon Mar 16 17:49:29 2015
From: smithi at nimnet.asn.au (Ian Smith)
Date: Tue, 17 Mar 2015 04:49:18 +1100 (EST)
Subject: [PATCH] ACPI CMOS region support rev. 4
In-Reply-To: <5506FBE3.1000009@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>
Message-ID: <20150317041624.K22641@sola.nimnet.asn.au>
On Mon, 16 Mar 2015 11:50:59 -0400, Anthony Jenkins wrote:
> On 03/16/2015 11:00 AM, Anthony Jenkins wrote:
> > On 03/16/2015 09:59 AM, Ian Smith wrote:
> >> On Sat, 14 Mar 2015 23:40:34 -0400, Anthony Jenkins wrote:
> >>> + if (!acpi_check_rtc_byteaccess(function == ACPI_READ, address))
> >>> + return AE_BAD_PARAMETER;
> >> acpi_check_rtc_byteaccess() needs to be called per byte of 1, 2 or 4
> >> bytes - or pass it 'bytes' also, and loop over each of them within?
> >> =======
> >>
> >> Otherwise (for example) a 2 byte read from 0x0b or 4 byte read from
> >> 0x09-0x0b will read 0x0c (clearing interrupts), or a 2 or 4 byte write
> >> to (say) 0x01 will also write to 0x02 and 0x04 (clobbering the time).
> > Right, this is an (incorrect) hybrid of a few attempts, probably from
> > around the time I lost my SSD and only had a single backup copy of my
> > work to go from. In one revision I had disallowed all multibyte
> > accesses (width > 8) since IMHO it was more consistent/correct with the
> > suggested locking. I wasn't ignoring your suggestion, just making one
> > or a few changes at a time (generally the simpler ones).
>
> Okay now I remember why I was reluctant to do this - suppose ACPIBIOS
> does a multibyte op on a set of bytes whose last byte fails
> acpi_check_rtc_byteaccess(). I will have already performed n-1
> accesses. At one point I had a revision (acpi_check_rtc_access()?) that
> permitted/denied the entire request (it took the starting address and
> byte length), but I guess that got lost too. I'll just recreate it...
Yep, validating all access before doing any sounds like the way to go.
Also, bytes = width >> 3 is ok, since you then affirm !(width & 0x07),
so non-multiples of 8 bits are invalidated anyway. You should still
check that width (or bytes) > 0, even if 0 should never be passed.
I guess the Big Kids will start playing once this hits bugzilla? :)
cheers, Ian
From Anthony.B.Jenkins at att.net Mon Mar 16 19:53:52 2015
From: Anthony.B.Jenkins at att.net (Anthony Jenkins)
Date: Mon, 16 Mar 2015 15:51:30 -0400
Subject: [PATCH] ACPI CMOS region support rev. 5
In-Reply-To: <20150317041624.K22641@sola.nimnet.asn.au>
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>
Message-ID: <55073442.5060005@att.net>
On 03/16/2015 01:49 PM, Ian Smith wrote:
> On Mon, 16 Mar 2015 11:50:59 -0400, Anthony Jenkins wrote:
> > On 03/16/2015 11:00 AM, Anthony Jenkins wrote:
> > > On 03/16/2015 09:59 AM, Ian Smith wrote:
> > >> On Sat, 14 Mar 2015 23:40:34 -0400, Anthony Jenkins wrote:
> > >>> + if (!acpi_check_rtc_byteaccess(function == ACPI_READ, address))
> > >>> + return AE_BAD_PARAMETER;
> > >> acpi_check_rtc_byteaccess() needs to be called per byte of 1, 2 or 4
> > >> bytes - or pass it 'bytes' also, and loop over each of them within?
> > >> =======
> > >>
> > >> Otherwise (for example) a 2 byte read from 0x0b or 4 byte read from
> > >> 0x09-0x0b will read 0x0c (clearing interrupts), or a 2 or 4 byte write
> > >> to (say) 0x01 will also write to 0x02 and 0x04 (clobbering the time).
> > > Right, this is an (incorrect) hybrid of a few attempts, probably from
> > > around the time I lost my SSD and only had a single backup copy of my
> > > work to go from. In one revision I had disallowed all multibyte
> > > accesses (width > 8) since IMHO it was more consistent/correct with the
> > > suggested locking. I wasn't ignoring your suggestion, just making one
> > > or a few changes at a time (generally the simpler ones).
> >
> > Okay now I remember why I was reluctant to do this - suppose ACPIBIOS
> > does a multibyte op on a set of bytes whose last byte fails
> > acpi_check_rtc_byteaccess(). I will have already performed n-1
> > accesses. At one point I had a revision (acpi_check_rtc_access()?) that
> > permitted/denied the entire request (it took the starting address and
> > byte length), but I guess that got lost too. I'll just recreate it...
>
> Yep, validating all access before doing any sounds like the way to go.
>
> Also, bytes = width >> 3 is ok, since you then affirm !(width & 0x07),
> so non-multiples of 8 bits are invalidated anyway. You should still
> check that width (or bytes) > 0, even if 0 should never be passed.
Oh yeah, forgot about that!
> I guess the Big Kids will start playing once this hits bugzilla? :)
I'm just glad I get to learn how to commit stuff to FreeBSD.
Here's another iteration...comments welcome. Think I got (most)
everything in there. I need to unit test acpi_check_rtc_access() to
make sure it DTRT.
Anthony
> cheers, Ian
> _______________________________________________
> freebsd-acpi at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
> To unsubscribe, send any mail to "freebsd-acpi-unsubscribe at freebsd.org"
-------------- next part --------------
A non-text attachment was scrubbed...
Name: atrtc_c_rev5.diff
Type: text/x-patch
Size: 5684 bytes
Desc: not available
URL:
From jkim at FreeBSD.org Mon Mar 16 23:36:07 2015
From: jkim at FreeBSD.org (Jung-uk Kim)
Date: Mon, 16 Mar 2015 19:36:06 -0400
Subject: [PATCH] ACPI CMOS region support rev. 5
In-Reply-To: <55073442.5060005@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>
Message-ID: <550768E6.6000801@FreeBSD.org>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
On 03/16/2015 15:51, Anthony Jenkins wrote:
> On 03/16/2015 01:49 PM, Ian Smith wrote:
>> On Mon, 16 Mar 2015 11:50:59 -0400, Anthony Jenkins wrote:
>>> On 03/16/2015 11:00 AM, Anthony Jenkins wrote:
>>>> On 03/16/2015 09:59 AM, Ian Smith wrote:
>>>>> On Sat, 14 Mar 2015 23:40:34 -0400, Anthony Jenkins wrote:
>>>>>> + if (!acpi_check_rtc_byteaccess(function ==
>>>>>> ACPI_READ, address)) + return
>>>>>> AE_BAD_PARAMETER;
>>>>> acpi_check_rtc_byteaccess() needs to be called per byte of
>>>>> 1, 2 or 4 bytes - or pass it 'bytes' also, and loop over
>>>>> each of them within? =======
>>>>>
>>>>> Otherwise (for example) a 2 byte read from 0x0b or 4 byte
>>>>> read from 0x09-0x0b will read 0x0c (clearing interrupts),
>>>>> or a 2 or 4 byte write to (say) 0x01 will also write to
>>>>> 0x02 and 0x04 (clobbering the time).
>>>> Right, this is an (incorrect) hybrid of a few attempts,
>>>> probably from around the time I lost my SSD and only had a
>>>> single backup copy of my work to go from. In one revision I
>>>> had disallowed all multibyte accesses (width > 8) since IMHO
>>>> it was more consistent/correct with the suggested locking. I
>>>> wasn't ignoring your suggestion, just making one or a few
>>>> changes at a time (generally the simpler ones).
>>>
>>> Okay now I remember why I was reluctant to do this - suppose
>>> ACPIBIOS does a multibyte op on a set of bytes whose last byte
>>> fails acpi_check_rtc_byteaccess(). I will have already
>>> performed n-1 accesses. At one point I had a revision
>>> (acpi_check_rtc_access()?) that permitted/denied the entire
>>> request (it took the starting address and byte length), but I
>>> guess that got lost too. I'll just recreate it...
>>
>> Yep, validating all access before doing any sounds like the way
>> to go.
>>
>> Also, bytes = width >> 3 is ok, since you then affirm !(width &
>> 0x07), so non-multiples of 8 bits are invalidated anyway. You
>> should still check that width (or bytes) > 0, even if 0 should
>> never be passed.
>
> Oh yeah, forgot about that!
>
>> I guess the Big Kids will start playing once this hits bugzilla?
>> :)
>
> I'm just glad I get to learn how to commit stuff to FreeBSD.
>
> Here's another iteration...comments welcome. Think I got (most)
> everything in there. I need to unit test acpi_check_rtc_access()
> to make sure it DTRT.
I see that there are several minor style(9) bugs but the most serious
problem is this patch makes atrtc.c dependent on ACPI and it
practically kills off APM support. Please make it optional (hint:
sys/conf/files* and sys/conf/options*) although I don't mind killing
off APM support. ;-)
Jung-uk Kim
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQEcBAEBCAAGBQJVB2jgAAoJEHyflib82/FG2i4IAIVjf2fN6HcxVBzWbB5SWBGl
d4ZircYjOkq5ld8jqVBuZP+En5Jm94JABo1Hp3XV4z8GNzCT29jB8STh4WmpU8Zu
A6kURXJjAPyUZbbQKtRr1YzTOfzttUNBBnPPbFvyAZG0vLEjCwZnx/2t7yrO2A/I
7PgbW5Qtl1TTRYux/eF6zFEWo2nPrK70Rr8dKCYTUlJnYorz3YVuSkM1PrjJUjom
6C0t3N3X5BxziuW/NRwWWWCf2EOkAR3Mdefo/eFASm8+n4GTCpxflnWPuy6NjIYY
1NSmqGurTcFoyQ9igzl7J8gWteqwaPMjlpAp0GCU1ADpkhrBmcU7dFK9C7jcOaE=
=ZKAN
-----END PGP SIGNATURE-----
From Anthony.B.Jenkins at att.net Tue Mar 17 04:11:17 2015
From: Anthony.B.Jenkins at att.net (Anthony Jenkins)
Date: Tue, 17 Mar 2015 00:05:52 -0400
Subject: [PATCH] ACPI CMOS region support rev. 5
In-Reply-To: <550768E6.6000801@FreeBSD.org>
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>
<550768E6.6000801@FreeBSD.org>
Message-ID: <5507A820.5000707@att.net>
On 03/16/15 19:36, Jung-uk Kim wrote:
> On 03/16/2015 15:51, Anthony Jenkins wrote:
> > On 03/16/2015 01:49 PM, Ian Smith wrote:
> >> On Mon, 16 Mar 2015 11:50:59 -0400, Anthony Jenkins wrote:
> >>> On 03/16/2015 11:00 AM, Anthony Jenkins wrote:
> >>>> On 03/16/2015 09:59 AM, Ian Smith wrote:
> >>>>> On Sat, 14 Mar 2015 23:40:34 -0400, Anthony Jenkins wrote:
> >>>>>> + if (!acpi_check_rtc_byteaccess(function ==
> >>>>>> ACPI_READ, address)) + return
> >>>>>> AE_BAD_PARAMETER;
> >>>>> acpi_check_rtc_byteaccess() needs to be called per byte of
> >>>>> 1, 2 or 4 bytes - or pass it 'bytes' also, and loop over
> >>>>> each of them within? =======
> >>>>>
> >>>>> Otherwise (for example) a 2 byte read from 0x0b or 4 byte
> >>>>> read from 0x09-0x0b will read 0x0c (clearing interrupts),
> >>>>> or a 2 or 4 byte write to (say) 0x01 will also write to
> >>>>> 0x02 and 0x04 (clobbering the time).
> >>>> Right, this is an (incorrect) hybrid of a few attempts,
> >>>> probably from around the time I lost my SSD and only had a
> >>>> single backup copy of my work to go from. In one revision I
> >>>> had disallowed all multibyte accesses (width > 8) since IMHO
> >>>> it was more consistent/correct with the suggested locking. I
> >>>> wasn't ignoring your suggestion, just making one or a few
> >>>> changes at a time (generally the simpler ones).
> >>>
> >>> Okay now I remember why I was reluctant to do this - suppose
> >>> ACPIBIOS does a multibyte op on a set of bytes whose last byte
> >>> fails acpi_check_rtc_byteaccess(). I will have already
> >>> performed n-1 accesses. At one point I had a revision
> >>> (acpi_check_rtc_access()?) that permitted/denied the entire
> >>> request (it took the starting address and byte length), but I
> >>> guess that got lost too. I'll just recreate it...
> >>
> >> Yep, validating all access before doing any sounds like the way
> >> to go.
> >>
> >> Also, bytes = width >> 3 is ok, since you then affirm !(width &
> >> 0x07), so non-multiples of 8 bits are invalidated anyway. You
> >> should still check that width (or bytes) > 0, even if 0 should
> >> never be passed.
>
> > Oh yeah, forgot about that!
>
> >> I guess the Big Kids will start playing once this hits bugzilla?
> >> :)
>
> > I'm just glad I get to learn how to commit stuff to FreeBSD.
>
> > Here's another iteration...comments welcome. Think I got (most)
> > everything in there. I need to unit test acpi_check_rtc_access()
> > to make sure it DTRT.
>
> I see that there are several minor style(9) bugs
Ahh... style(9) is what I was looking for, thanks. Yeah I was hoping
someone would point me to FreeBSD's official coding style guide.
> but the most serious
> problem is this patch makes atrtc.c dependent on ACPI and it
> practically kills off APM support.
Not quite sure what you mean here... do you mean a non-ACPI build of the
kernel would fail to compile atrtc(4)? Yeah I can fix that.
> Please make it optional (hint:
> sys/conf/files* and sys/conf/options*) although I don't mind killing
> off APM support. ;-)
Well I'd just make the ACPI CMOS handler code conditional on ACPI being
enabled in config(5)... is that what you're looking for (or would that
work)?
Thanks,
Anthony
> Jung-uk Kim
> _______________________________________________
> freebsd-acpi at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
> To unsubscribe, send any mail to "freebsd-acpi-unsubscribe at freebsd.org"
From bugzilla-noreply at freebsd.org Tue Mar 17 07:05:02 2015
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Tue, 17 Mar 2015 07:05:01 +0000
Subject: [Bug 198603] [acpi] HP ProBook 430 G2: can't change brightness via
acpi_hp and acpi_video
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=198603
--- Comment #1 from Victor Yagofarov ---
I solved my problem by compiling intel_backlight like that :
https://forums.freebsd.org/threads/samsung-ativ-book-2-brightness.44146/#post-249316
--
You are receiving this mail because:
You are the assignee for the bug.
From smithi at nimnet.asn.au Tue Mar 17 12:28:31 2015
From: smithi at nimnet.asn.au (Ian Smith)
Date: Tue, 17 Mar 2015 23:28:21 +1100 (EST)
Subject: [PATCH] ACPI CMOS region support rev. 5
In-Reply-To: <55073442.5060005@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>
Message-ID: <20150317222704.K22641@sola.nimnet.asn.au>
On Mon, 16 Mar 2015 15:51:30 -0400, Anthony Jenkins wrote:
> On 03/16/2015 01:49 PM, Ian Smith wrote:
> > On Mon, 16 Mar 2015 11:50:59 -0400, Anthony Jenkins wrote:
> > > On 03/16/2015 11:00 AM, Anthony Jenkins wrote:
> > > > On 03/16/2015 09:59 AM, Ian Smith wrote:
> > > >> On Sat, 14 Mar 2015 23:40:34 -0400, Anthony Jenkins wrote:
> > > >>> + if (!acpi_check_rtc_byteaccess(function == ACPI_READ, address))
> > > >>> + return AE_BAD_PARAMETER;
> > > >> acpi_check_rtc_byteaccess() needs to be called per byte of 1, 2 or 4
> > > >> bytes - or pass it 'bytes' also, and loop over each of them within?
> > > >> =======
> > > >>
> > > >> Otherwise (for example) a 2 byte read from 0x0b or 4 byte read from
> > > >> 0x09-0x0b will read 0x0c (clearing interrupts), or a 2 or 4 byte write
> > > >> to (say) 0x01 will also write to 0x02 and 0x04 (clobbering the time).
> > > > Right, this is an (incorrect) hybrid of a few attempts, probably from
> > > > around the time I lost my SSD and only had a single backup copy of my
> > > > work to go from. In one revision I had disallowed all multibyte
> > > > accesses (width > 8) since IMHO it was more consistent/correct with the
> > > > suggested locking. I wasn't ignoring your suggestion, just making one
> > > > or a few changes at a time (generally the simpler ones).
> > >
> > > Okay now I remember why I was reluctant to do this - suppose ACPIBIOS
> > > does a multibyte op on a set of bytes whose last byte fails
> > > acpi_check_rtc_byteaccess(). I will have already performed n-1
> > > accesses. At one point I had a revision (acpi_check_rtc_access()?) that
> > > permitted/denied the entire request (it took the starting address and
> > > byte length), but I guess that got lost too. I'll just recreate it...
> >
> > Yep, validating all access before doing any sounds like the way to go.
> >
> > Also, bytes = width >> 3 is ok, since you then affirm !(width & 0x07),
> > so non-multiples of 8 bits are invalidated anyway. You should still
> > check that width (or bytes) > 0, even if 0 should never be passed.
>
> Oh yeah, forgot about that!
>
> > I guess the Big Kids will start playing once this hits bugzilla? :)
>
> I'm just glad I get to learn how to commit stuff to FreeBSD.
>
> Here's another iteration...comments welcome. Think I got (most)
> everything in there. I need to unit test acpi_check_rtc_access() to
> make sure it DTRT?
You've fixed all my concerns, thanks Anthony. A couple of questions:
+#ifndef ATRTC_VERBOSE
+#define ATRTC_VERBOSE 1
+#endif
Where else might ATRTC_VERBOSE be set otherwise?
+static unsigned int atrtc_verbose = ATRTC_VERBOSE;
+SYSCTL_UINT(_debug, OID_AUTO, atrtc_verbose, CTLFLAG_RWTUN,
+ &atrtc_verbose, 0, "AT-RTC Debug Level (0-2)");
+#define ATRTC_DBG_PRINTF(level, format, ...) \
+ if (atrtc_verbose >= level) printf(format, ##__VA_ARGS__)
Genuine question, I don't know .. but would not that 0 in SYSCTL_UINT
initialise atrtc_verbose to 0? Or does it keep its existing setting?
Or would replacing 0 there with ATRTC_VERBOSE work, or be clearer?
static int
+acpi_check_rtc_access(int is_read, u_long addr, u_long len)
+{
+ int retval = 1; /* Success */
+
+ if (is_read) {
+ /* Reading 0x0C will muck with interrupts */
+ if (addr + len - 1 >= 0x0C && addr <= 0x0c)
+ retval = 0;
Looks alright to me, given my uncertainty with C operator precedence.
+ } else {
+ /* Allow single-byte writes to alarm registers and
+ * addr >= 0x30, else deny.
+ */
+ if (!((len == 1 && (addr <= 5 && (addr & 1))) || addr >= 0x30))
+ retval = 0;
+ }
+ return retval;
+}
After a short struggle unwinding brackets, this looks right; but I will
suggest clarifying the comment:
+ /* Allow single-byte writes to alarm registers and
- + * addr >= 0x30, else deny.
+ + * multi-byte writes to addr >= 0x30, else deny.
I still wonder if there isn't a global acpi_loaded_and_running variable
so you could avoid even attempting ACPI init calls, perhaps making this
not so dependent on ACPI, at least at runtime.
But perhaps jkim's concern is more regarding building on platforms not
supporting ACPI at all? Is that the (only?) issue with this on ARM?
cheers, Ian
From Anthony.B.Jenkins at att.net Tue Mar 17 13:05:23 2015
From: Anthony.B.Jenkins at att.net (Anthony Jenkins)
Date: Tue, 17 Mar 2015 09:02:22 -0400
Subject: [PATCH] ACPI CMOS region support rev. 5
In-Reply-To: <20150317222704.K22641@sola.nimnet.asn.au>
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>
Message-ID: <550825DE.7030406@att.net>
On 03/17/2015 08:28 AM, Ian Smith wrote:
> On Mon, 16 Mar 2015 15:51:30 -0400, Anthony Jenkins wrote:
> > On 03/16/2015 01:49 PM, Ian Smith wrote:
> > > On Mon, 16 Mar 2015 11:50:59 -0400, Anthony Jenkins wrote:
> > > > On 03/16/2015 11:00 AM, Anthony Jenkins wrote:
> > > > > On 03/16/2015 09:59 AM, Ian Smith wrote:
> > > > >> On Sat, 14 Mar 2015 23:40:34 -0400, Anthony Jenkins wrote:
> > > > >>> + if (!acpi_check_rtc_byteaccess(function == ACPI_READ, address))
> > > > >>> + return AE_BAD_PARAMETER;
> > > > >> acpi_check_rtc_byteaccess() needs to be called per byte of 1, 2 or 4
> > > > >> bytes - or pass it 'bytes' also, and loop over each of them within?
> > > > >> =======
> > > > >>
> > > > >> Otherwise (for example) a 2 byte read from 0x0b or 4 byte read from
> > > > >> 0x09-0x0b will read 0x0c (clearing interrupts), or a 2 or 4 byte write
> > > > >> to (say) 0x01 will also write to 0x02 and 0x04 (clobbering the time).
> > > > > Right, this is an (incorrect) hybrid of a few attempts, probably from
> > > > > around the time I lost my SSD and only had a single backup copy of my
> > > > > work to go from. In one revision I had disallowed all multibyte
> > > > > accesses (width > 8) since IMHO it was more consistent/correct with the
> > > > > suggested locking. I wasn't ignoring your suggestion, just making one
> > > > > or a few changes at a time (generally the simpler ones).
> > > >
> > > > Okay now I remember why I was reluctant to do this - suppose ACPIBIOS
> > > > does a multibyte op on a set of bytes whose last byte fails
> > > > acpi_check_rtc_byteaccess(). I will have already performed n-1
> > > > accesses. At one point I had a revision (acpi_check_rtc_access()?) that
> > > > permitted/denied the entire request (it took the starting address and
> > > > byte length), but I guess that got lost too. I'll just recreate it...
> > >
> > > Yep, validating all access before doing any sounds like the way to go.
> > >
> > > Also, bytes = width >> 3 is ok, since you then affirm !(width & 0x07),
> > > so non-multiples of 8 bits are invalidated anyway. You should still
> > > check that width (or bytes) > 0, even if 0 should never be passed.
> >
> > Oh yeah, forgot about that!
> >
> > > I guess the Big Kids will start playing once this hits bugzilla? :)
> >
> > I'm just glad I get to learn how to commit stuff to FreeBSD.
> >
> > Here's another iteration...comments welcome. Think I got (most)
> > everything in there. I need to unit test acpi_check_rtc_access() to
> > make sure it DTRT?
>
> You've fixed all my concerns, thanks Anthony. A couple of questions:
>
> +#ifndef ATRTC_VERBOSE
> +#define ATRTC_VERBOSE 1
> +#endif
>
> 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.
> +static unsigned int atrtc_verbose = ATRTC_VERBOSE;
> +SYSCTL_UINT(_debug, OID_AUTO, atrtc_verbose, CTLFLAG_RWTUN,
> + &atrtc_verbose, 0, "AT-RTC Debug Level (0-2)");
> +#define ATRTC_DBG_PRINTF(level, format, ...) \
> + if (atrtc_verbose >= level) printf(format, ##__VA_ARGS__)
>
> Genuine question, I don't know .. but would not that 0 in SYSCTL_UINT
> initialise atrtc_verbose to 0? Or does it keep its existing setting?
> Or would replacing 0 there with ATRTC_VERBOSE work, or be clearer?
Ahh, good catch... guess I don't even need the variable initializer.
> static int
> +acpi_check_rtc_access(int is_read, u_long addr, u_long len)
> +{
> + int retval = 1; /* Success */
> +
> + if (is_read) {
> + /* Reading 0x0C will muck with interrupts */
> + if (addr + len - 1 >= 0x0C && addr <= 0x0c)
> + retval = 0;
>
> Looks alright to me, given my uncertainty with C operator precedence.
>
> + } else {
> + /* Allow single-byte writes to alarm registers and
> + * addr >= 0x30, else deny.
> + */
> + if (!((len == 1 && (addr <= 5 && (addr & 1))) || addr >= 0x30))
> + retval = 0;
> + }
> + return retval;
> +}
>
> After a short struggle unwinding brackets, this looks right; but I will
> suggest clarifying the comment:
>
> + /* Allow single-byte writes to alarm registers and
> - + * addr >= 0x30, else deny.
> + + * multi-byte writes to addr >= 0x30, else deny.
Okay.
>
> I still wonder if there isn't a global acpi_loaded_and_running variable
> so you could avoid even attempting ACPI init calls, perhaps making this
> not so dependent on ACPI, at least at runtime.
I haven't (yet) been able to find a compile-time flag that tells me if
the kernel supports ACPI; I'm /pretty/ sure the ACPI headers I'm
#include'ing will exist for every build of FreeBSD.
> But perhaps jkim's concern is more regarding building on platforms not
> supporting ACPI at all? Is that the (only?) issue with this on ARM?
Ehh... I'll wait for him to chime in. I could try cross-compiling the
kernel for an ARM box, but I doubt sys/x86/isa/atrtc.c is even picked up
by those.
Thanks,
Anthony
> cheers, Ian
> _______________________________________________
> freebsd-acpi at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
> To unsubscribe, send any mail to "freebsd-acpi-unsubscribe at freebsd.org"
From imp at bsdimp.com Wed Mar 18 15:27:02 2015
From: imp at bsdimp.com (Warner Losh)
Date: Wed, 18 Mar 2015 09:26:57 -0600
Subject: [PATCH] ACPI CMOS region support rev. 5
In-Reply-To: <55073442.5060005@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>
Message-ID:
Looking at patch 5:
You need to rework this so there?s an atrtc_acpi.c. Put all the ACPI attachment in there. You should also split off the little bit that?s ISA-specific into atrtc_isa. Once you do that, we can talk.
Warner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL:
From imp at bsdimp.com Wed Mar 18 15:29:50 2015
From: imp at bsdimp.com (Warner Losh)
Date: Wed, 18 Mar 2015 09:29:41 -0600
Subject: [PATCH] ACPI CMOS region support rev. 5
In-Reply-To: <550825DE.7030406@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>
Message-ID: <56B494A3-2058-4B7B-8183-646A46753A53@bsdimp.com>
> On Mar 17, 2015, at 7:02 AM, Anthony Jenkins 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.
>> I still wonder if there isn't a global acpi_loaded_and_running variable
>> so you could avoid even attempting ACPI init calls, perhaps making this
>> not so dependent on ACPI, at least at runtime.
>
> I haven't (yet) been able to find a compile-time flag that tells me if
> the kernel supports ACPI; I'm /pretty/ sure the ACPI headers I'm
> #include'ing will exist for every build of FreeBSD.
I wouldn?t count on it. However, they may exist for all platforms that
use atrtc.
But it wouldn?t be an issue if you did a separate attachment.
Warner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL:
From Anthony.B.Jenkins at att.net Wed Mar 18 15:59:47 2015
From: Anthony.B.Jenkins at att.net (Anthony Jenkins)
Date: Wed, 18 Mar 2015 11:59:38 -0400
Subject: [PATCH] ACPI CMOS region support rev. 5
In-Reply-To:
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>
Message-ID: <5509A0EA.4070208@att.net>
On 03/18/2015 11:26 AM, Warner Losh wrote:
> Looking at patch 5:
>
> You need to rework this so there?s an atrtc_acpi.c. Put all the ACPI attachment in there.
Okay, shouldn't be a problem.
> You should also split off the little bit that?s ISA-specific into atrtc_isa.
You mean rtcin() and writertc()? ...but that's not my stuff, it was
already in atrtc.c. PNP0800 (the PC-AT RTC component) is (practically)
an ISA-specific device.
Anthony
> Once you do that, we can talk.
>
> Warner
>
From Anthony.B.Jenkins at att.net Wed Mar 18 16:06:34 2015
From: Anthony.B.Jenkins at att.net (Anthony Jenkins)
Date: Wed, 18 Mar 2015 12:06:26 -0400
Subject: [PATCH] ACPI CMOS region support rev. 5
In-Reply-To: <56B494A3-2058-4B7B-8183-646A46753A53@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>
Message-ID: <5509A282.6070207@att.net>
On 03/18/2015 11:29 AM, Warner Losh wrote:
>> On Mar 17, 2015, at 7:02 AM, Anthony Jenkins 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.
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?
Thanks,
Anthony
>>> I still wonder if there isn't a global acpi_loaded_and_running variable
>>> so you could avoid even attempting ACPI init calls, perhaps making this
>>> not so dependent on ACPI, at least at runtime.
>> I haven't (yet) been able to find a compile-time flag that tells me if
>> the kernel supports ACPI; I'm /pretty/ sure the ACPI headers I'm
>> #include'ing will exist for every build of FreeBSD.
> I wouldn?t count on it. However, they may exist for all platforms that
> use atrtc.
>
> But it wouldn?t be an issue if you did a separate attachment.
>
> Warner
>
From jkim at FreeBSD.org Wed Mar 18 17:35:24 2015
From: jkim at FreeBSD.org (Jung-uk Kim)
Date: Wed, 18 Mar 2015 13:35:23 -0400
Subject: [PATCH] ACPI CMOS region support rev. 5
In-Reply-To: <20150317222704.K22641@sola.nimnet.asn.au>
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>
Message-ID: <5509B75B.3070409@FreeBSD.org>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
On 03/17/2015 08:28, Ian Smith wrote:
> I still wonder if there isn't a global acpi_loaded_and_running
> variable so you could avoid even attempting ACPI init calls,
> perhaps making this not so dependent on ACPI, at least at runtime.
For runtime, power_pm_get_type() is what you looking for. For example,
switch (power_pm_get_type()) {
case POWER_PM_TYPE_ACPI: /* Do something specific to ACPI. */
case POWER_PM_TYPE_APM: /* Do something specific to APM. */
default: /* Do something without PM. */
}
> But perhaps jkim's concern is more regarding building on platforms
> not supporting ACPI at all? Is that the (only?) issue with this on
> ARM?
sys/x86/isa/atrtc.c is only for x86 (excluding pc98). I am only
concerned about ACPI-less i386 kernel at this point.
Jung-uk Kim
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQEcBAEBCAAGBQJVCbdVAAoJEHyflib82/FGK04H/2e/DVefzoorkEuW5sxgHqGg
XGFB21wLxP4bfnkkGlTfYrEPkdB53zW6qez2nUv+zA4aTy/BTpmRN0KAhwMRCkJj
QjM757IoQr+QyWQhU62NOsu7Ox86MI6RBrPssURuwib8HWJbIUPDKKYmK+sXI7Bq
UmlBJeiK0BhzCQ7l0tIaR6VFlQSxMQC/x/fwkHI9hKPyKwq8ACeqQ2ZI05v6ZQzo
IIfVU0LLz62kDoJDicaRNfJbGtRPOvx4Nnm1RE8wVtaqlwQYrffp6QpHaRfXHEos
QwWEWXrMFfjQtCH+KCrzfZsCQD1rTe+eDb0tFD315PbpvEs6yG6VlBxf4pUJRAU=
=YDkP
-----END PGP SIGNATURE-----
From imp at bsdimp.com Wed Mar 18 21:30:32 2015
From: imp at bsdimp.com (Warner Losh)
Date: Wed, 18 Mar 2015 15:30:23 -0600
Subject: [PATCH] ACPI CMOS region support rev. 5
In-Reply-To: <5509A282.6070207@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>
Message-ID:
> On Mar 18, 2015, at 10:06 AM, Anthony Jenkins wrote:
>
> On 03/18/2015 11:29 AM, Warner Losh wrote:
>>> On Mar 17, 2015, at 7:02 AM, Anthony Jenkins 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.
>
> 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.
Warner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL:
From imp at bsdimp.com Wed Mar 18 21:32:16 2015
From: imp at bsdimp.com (Warner Losh)
Date: Wed, 18 Mar 2015 15:32:08 -0600
Subject: [PATCH] ACPI CMOS region support rev. 5
In-Reply-To: <5509A0EA.4070208@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>
<5509A0EA.4070208@att.net>
Message-ID: <85F2CFD2-14C1-43D6-8963-0D1F69F17577@bsdimp.com>
> On Mar 18, 2015, at 9:59 AM, Anthony Jenkins wrote:
>
> On 03/18/2015 11:26 AM, Warner Losh wrote:
>> Looking at patch 5:
>>
>> You need to rework this so there?s an atrtc_acpi.c. Put all the ACPI attachment in there.
>
> Okay, shouldn't be a problem.
>
>> You should also split off the little bit that?s ISA-specific into atrtc_isa.
>
> You mean rtcin() and writertc()? ...but that's not my stuff, it was
> already in atrtc.c. PNP0800 (the PC-AT RTC component) is (practically)
> an ISA-specific device.
There will be a small ?isa? specific driver. Here ISA means ?FreeBSD ISA attachment? not
necessarily what you?d find on an ISA bus. This means you?d have two separate driver
statement. You can then do the ACPI stuff in the ACPI attachment and not have to worry
about whether or not it is compiled into the kernel, since you?d only include it if acpi is
in the kernel.
Warner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL:
From smithi at nimnet.asn.au Thu Mar 19 08:11:05 2015
From: smithi at nimnet.asn.au (Ian Smith)
Date: Thu, 19 Mar 2015 19:10:40 +1100 (EST)
Subject: [PATCH] ACPI CMOS region support rev. 5
In-Reply-To:
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>
Message-ID: <20150319184348.X22641@sola.nimnet.asn.au>
On Wed, 18 Mar 2015 15:30:23 -0600, Warner Losh wrote:
> > On Mar 18, 2015, at 10:06 AM, Anthony Jenkins wrote:
> >
> > On 03/18/2015 11:29 AM, Warner Losh wrote:
> >>> On Mar 17, 2015, at 7:02 AM, Anthony Jenkins 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 Anthony.B.Jenkins at att.net Thu Mar 19 13:11:17 2015
From: Anthony.B.Jenkins at att.net (Anthony Jenkins)
Date: Thu, 19 Mar 2015 09:11:08 -0400
Subject: [PATCH] ACPI CMOS region support rev. 5
In-Reply-To: <20150319184348.X22641@sola.nimnet.asn.au>
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>
<20150319184348.X22641@sola.nimnet.asn.au>
Message-ID: <550ACAEC.3060808@att.net>
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 wrote:
> > >
> > > On 03/18/2015 11:29 AM, Warner Losh wrote:
> > >>> On Mar 17, 2015, at 7:02 AM, Anthony Jenkins 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
From Anthony.B.Jenkins at att.net Thu Mar 19 13:21:00 2015
From: Anthony.B.Jenkins at att.net (Anthony Jenkins)
Date: Thu, 19 Mar 2015 09:18:03 -0400
Subject: [PATCH] ACPI CMOS region support rev. 5
In-Reply-To: <85F2CFD2-14C1-43D6-8963-0D1F69F17577@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>
<5509A0EA.4070208@att.net>
<85F2CFD2-14C1-43D6-8963-0D1F69F17577@bsdimp.com>
Message-ID: <550ACC8B.2090201@att.net>
On 03/18/2015 05:32 PM, Warner Losh wrote:
>> On Mar 18, 2015, at 9:59 AM, Anthony Jenkins wrote:
>>
>> On 03/18/2015 11:26 AM, Warner Losh wrote:
>>> Looking at patch 5:
>>>
>>> You need to rework this so there?s an atrtc_acpi.c. Put all the ACPI attachment in there.
>> Okay, shouldn't be a problem.
>>
>>> You should also split off the little bit that?s ISA-specific into atrtc_isa.
>> You mean rtcin() and writertc()? ...but that's not my stuff, it was
>> already in atrtc.c. PNP0800 (the PC-AT RTC component) is (practically)
>> an ISA-specific device.
> There will be a small ?isa? specific driver. Here ISA means ?FreeBSD ISA attachment? not
> necessarily what you?d find on an ISA bus. This means you?d have two separate driver
> statement. You can then do the ACPI stuff in the ACPI attachment and not have to worry
> about whether or not it is compiled into the kernel, since you?d only include it if acpi is
> in the kernel.
Okay I'll look for a simple example in the existing drivers...any
suggestions?
I was just hoping to leave atrtc(4) as intact as possible, adding an
ACPI accessor for BIOSes that need it; this sounds like a reworking of
atrtc(4)...
Anthony
>
> Warner
>
From smithi at nimnet.asn.au Thu Mar 19 13:49:38 2015
From: smithi at nimnet.asn.au (Ian Smith)
Date: Fri, 20 Mar 2015 00:49:22 +1100 (EST)
Subject: [PATCH] ACPI CMOS region support rev. 5
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>
<20150319184348.X22641@sola.nimnet.asn.au> <550ACAEC.3060808@att.net>
Message-ID: <20150320002950.T22641@sola.nimnet.asn.au>
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 wrote:
> > > >
> > > > On 03/18/2015 11:29 AM, Warner Losh wrote:
> > > >>> On Mar 17, 2015, at 7:02 AM, Anthony Jenkins 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 Anthony.B.Jenkins at att.net Thu Mar 19 14:14:18 2015
From: Anthony.B.Jenkins at att.net (Anthony Jenkins)
Date: Thu, 19 Mar 2015 10:14:15 -0400
Subject: [PATCH] ACPI CMOS region support rev. 5
In-Reply-To: <20150320002950.T22641@sola.nimnet.asn.au>
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>
<20150319184348.X22641@sola.nimnet.asn.au> <550ACAEC.3060808@att.net>
<20150320002950.T22641@sola.nimnet.asn.au>
Message-ID: <550AD9B7.4090508@att.net>
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 wrote:
> > > > >
> > > > > On 03/18/2015 11:29 AM, Warner Losh wrote:
> > > > >>> On Mar 17, 2015, at 7:02 AM, Anthony Jenkins 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;
> + }
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 >= 0 is always true" warning).
> > > > > 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?
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.
>
> Thanks for flushing out this issue and doing something about it!
>
> cheers, Ian
> _______________________________________________
> freebsd-acpi at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
> To unsubscribe, send any mail to "freebsd-acpi-unsubscribe at freebsd.org"
From freebsd-acpi at herveybayaustralia.com.au Tue Mar 24 10:23:50 2015
From: freebsd-acpi at herveybayaustralia.com.au (Da Rock)
Date: Tue, 24 Mar 2015 20:23:41 +1000
Subject: HP Compaq CQ62/42 acpi
Message-ID: <55113B2D.2040609@herveybayaustralia.com.au>
I have 2 laptops as mentioned, 3 all amd athlon based. The 3rd is an
asus which I'm relatively happy with.
What I have is when I pull the AC out of it, the sysctl for cpu speed
goes from 2200 to 100 or 400. Basically the system becomes rather unusable.
I tried the acpi_hp module, and it now switches to 800. This is better,
but barely usable still.
I'd like to see a response similar to the asus if its possible; this
effectively stays the same, but drops speed if nothing is happening.
Ideally, I'd think that it would be better if the system adjusted speed
to use requirements during operation, but neither does that. I suspect
that the asus should (in theory) as it does do it on battery only; but
unless I'm really hammering all the time, it just doesn't seem to happen
when I'm looking at it.
The settings used on all for powerd is hiadaptive for AC, adaptive for
battery.
If I'm doing something wrong let me know, if more data is required I'm
happy to help the cause :)
TIA
From rkoberman at gmail.com Tue Mar 24 23:52:42 2015
From: rkoberman at gmail.com (Kevin Oberman)
Date: Tue, 24 Mar 2015 16:52:41 -0700
Subject: HP Compaq CQ62/42 acpi
In-Reply-To: <55113B2D.2040609@herveybayaustralia.com.au>
References: <55113B2D.2040609@herveybayaustralia.com.au>
Message-ID:
On Tue, Mar 24, 2015 at 3:23 AM, Da Rock <
freebsd-acpi at herveybayaustralia.com.au> wrote:
> I have 2 laptops as mentioned, 3 all amd athlon based. The 3rd is an asus
> which I'm relatively happy with.
>
> What I have is when I pull the AC out of it, the sysctl for cpu speed goes
> from 2200 to 100 or 400. Basically the system becomes rather unusable.
>
> I tried the acpi_hp module, and it now switches to 800. This is better,
> but barely usable still.
>
> I'd like to see a response similar to the asus if its possible; this
> effectively stays the same, but drops speed if nothing is happening.
>
> Ideally, I'd think that it would be better if the system adjusted speed to
> use requirements during operation, but neither does that. I suspect that
> the asus should (in theory) as it does do it on battery only; but unless
> I'm really hammering all the time, it just doesn't seem to happen when I'm
> looking at it.
>
> The settings used on all for powerd is hiadaptive for AC, adaptive for
> battery.
>
> If I'm doing something wrong let me know, if more data is required I'm
> happy to help the cause :)
>
> TIA
>
> First, let's get a bit more information. Please provide:
sysctl dev.cpu.0 (on AC and then on battery)
uname -a
/etc/sysctl.conf (If present)
/boot/loader.conf (if present)
--
Kevin Oberman, Network Engineer, Retired
E-mail: rkoberman at gmail.com
From sibananda.sahu at avagotech.com Wed Mar 25 20:24:54 2015
From: sibananda.sahu at avagotech.com (Sibananda Sahu)
Date: Thu, 26 Mar 2015 01:54:45 +0530
Subject: How to know the system state if the system is going for halt or
poweroff or reboot in FreeBSD
Message-ID:
Hi All,
Linux has an enum system_state the denotes about the current system state.
These values are set in the system_state global variable according to the
current system state of either restart, booting or power off etc.
See the below link for the header:
http://lxr.free-electrons.com/source/include/linux/kernel.h#L450
I want the similar implementation in FreeBSD.
For the same I searched the source code and following are my observations:
- For shutdown ?h now, shutdown ?p now, poweroff, init 0, init 6
and reboot sys_reboot() is called.
- Sys_reboot() will call kern_reboot() which inturn endup calling
EVENTHANDLER_INVOKE(shutdown_final, howto);
- Based on the howto variable passed to the kern_reboot() call,
corresponding event handlers will be invoked.
- For a reboot request shutdown_reset(), or for a halt request
shutdown_halt() and so on.
Initially I thought the ?rebooting? global variable used inside
kern_reboot() function is set only while rebooting the system but after
some exercises I realized that the global variable ?rebooting? is set to 1
for halt, poweroff and reboot. I mean if the system is powering off then
also the rebooting value is set to 1, which was really confusing for me.
My requirement is to know the exact reason of shutdown, whether is it a
power-off or a reboot call.
And I can get the information from the ?howto? variable that is passed to
the kern_reboot() function call, but this variable is local to
kern_reboot() only.
SO IS THERE ANY OTHER WAY TO GET THE SYSTEM STATE IN FREEBSD???
Thanks,
_Sibananda Sahu
From freebsd-acpi at herveybayaustralia.com.au Thu Mar 26 01:38:00 2015
From: freebsd-acpi at herveybayaustralia.com.au (Da Rock)
Date: Thu, 26 Mar 2015 11:37:51 +1000
Subject: HP Compaq CQ62/42 acpi
In-Reply-To:
References: <55113B2D.2040609@herveybayaustralia.com.au>
Message-ID: <551362EF.3080801@herveybayaustralia.com.au>
On 03/25/15 09:52, Kevin Oberman wrote:
> On Tue, Mar 24, 2015 at 3:23 AM, Da Rock
> > wrote:
>
> I have 2 laptops as mentioned, 3 all amd athlon based. The 3rd is
> an asus which I'm relatively happy with.
>
> What I have is when I pull the AC out of it, the sysctl for cpu
> speed goes from 2200 to 100 or 400. Basically the system becomes
> rather unusable.
>
> I tried the acpi_hp module, and it now switches to 800. This is
> better, but barely usable still.
>
> I'd like to see a response similar to the asus if its possible;
> this effectively stays the same, but drops speed if nothing is
> happening.
>
> Ideally, I'd think that it would be better if the system adjusted
> speed to use requirements during operation, but neither does that.
> I suspect that the asus should (in theory) as it does do it on
> battery only; but unless I'm really hammering all the time, it
> just doesn't seem to happen when I'm looking at it.
>
> The settings used on all for powerd is hiadaptive for AC, adaptive
> for battery.
>
> If I'm doing something wrong let me know, if more data is required
> I'm happy to help the cause :)
>
> TIA
>
> First, let's get a bit more information. Please provide:
> sysctl dev.cpu.0 (on AC and then on battery)
AC:
dev.cpu.0.%desc: ACPI CPU
dev.cpu.0.%driver: cpu
dev.cpu.0.%location: handle=\_PR_.C000
dev.cpu.0.%pnpinfo: _HID=none _UID=0
dev.cpu.0.%parent: acpi0
dev.cpu.0.temperature: 85.3C
dev.cpu.0.freq: 200
dev.cpu.0.freq_levels: 2200/7543 1925/6600 1900/6150 1662/5381 1600/4777
1400/4179 1300/3750 1137/3281 975/2812 800/2091 700/1829 600/1568
500/1306 400/1045 300/784 200/522 100/261
dev.cpu.0.cx_supported: C1/1/0
dev.cpu.0.cx_lowest: C1
dev.cpu.0.cx_usage: 100.00% last 682us
Battery:
dev.cpu.0.%desc: ACPI CPU
dev.cpu.0.%driver: cpu
dev.cpu.0.%location: handle=\_PR_.C000
dev.cpu.0.%pnpinfo: _HID=none _UID=0
dev.cpu.0.%parent: acpi0
dev.cpu.0.temperature: 85.5C
dev.cpu.0.freq: 100
dev.cpu.0.freq_levels: 2200/7543 1925/6600 1900/6150 1662/5381 1600/4777
1400/4179 1300/3750 1137/3281 975/2812 800/2091 700/1829 600/1568
500/1306 400/1045 300/784 200/522 100/261
dev.cpu.0.cx_supported: C1/1/0
dev.cpu.0.cx_lowest: C1
dev.cpu.0.cx_usage: 100.00% last 901us
> uname -a
FreeBSD laptop1 10.0-RELEASE-p7 FreeBSD 10.0-RELEASE-p7 #0: Tue Jul 8
06:37:44 UTC 2014
root at amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64
> /etc/sysctl.conf (If present)
vfs.usermount=1
kern.ipc.shm_allow_removed=1
compat.linux.osrelease=2.6.18
> /boot/loader.conf (if present)
(like it wasn't going to be present :D who doesn't?)
vboxdrv_load=YES
tmpfs_load=YES
cuse4bsd_load=YES
acpi_video_load=YES
amdtemp_load=YES
fuse_load=YES
acpi_hp_load=YES
I'd like to get this system running nicely if I can - its been just
getting there for too long now because of other projects taking my
attention and I've got bite the bullet and work this out.
BTW, just to make a liar out of me after I sent that post, the system
did start to change the cpu speed on AC - but it took a while. I had sat
there monitoring the system with little activity and it remained at
2200; when I gave up waiting and sent that post I then started to really
give it to it and the speed started dropping and rising a little.
However, given I was trying to do an encoding with ffmpeg at the time,
the speed probably should have remained at 2200 as my frames encoded per
second was about half of normal. So I don't really know what to expect :)
This is also in my dmesg:
amdtemp0: on hostb4
acpi_acad0: on acpi0
battery0: on acpi0
acpi_lid0: on acpi0
acpi_wmi0: on acpi0
acpi_hp0: on acpi_wmi0
acpi_hp0: HP event GUID detected, installing event handler
ACPI Error: Field [D128] at 1040 exceeds Buffer [NULL] size 160 (bits)
(20130823/dsopcode-249)
ACPI Error: Method parse/execution failed [\134_SB_.WMID.HWMC] (Node
0xfffff80004372e80), AE_AML_BUFFER_LIMIT (20130823/psparse-553)
ACPI Error: Method parse/execution failed [\134_SB_.WMID.WMAD] (Node
0xfffff80004372b80), AE_AML_BUFFER_LIMIT (20130823/psparse-553)
ACPI Error: Field [D128] at 1040 exceeds Buffer [NULL] size 160 (bits)
(20130823/dsopcode-249)
ACPI Error: Method parse/execution failed [\134_SB_.WMID.HWMC] (Node
0xfffff80004372e80), AE_AML_BUFFER_LIMIT (20130823/psparse-553)
ACPI Error: Method parse/execution failed [\134_SB_.WMID.WMAD] (Node
0xfffff80004372b80), AE_AML_BUFFER_LIMIT (20130823/psparse-553)
ACPI Error: Field [D128] at 1040 exceeds Buffer [NULL] size 160 (bits)
(20130823/dsopcode-249)
ACPI Error: Method parse/execution failed [\134_SB_.WMID.HWMC] (Node
0xfffff80004372e80), AE_AML_BUFFER_LIMIT (20130823/psparse-553)
ACPI Error: Method parse/execution failed [\134_SB_.WMID.WMAD] (Node
0xfffff80004372b80), AE_AML_BUFFER_LIMIT (20130823/psparse-553)
ACPI Error: Field [D128] at 1040 exceeds Buffer [NULL] size 160 (bits)
(20130823/dsopcode-249)
ACPI Error: Method parse/execution failed [\134_SB_.WMID.HWMC] (Node
0xfffff80004372e80), AE_AML_BUFFER_LIMIT (20130823/psparse-553)
ACPI Error: Method parse/execution failed [\134_SB_.WMID.WMAD] (Node
0xfffff80004372b80), AE_AML_BUFFER_LIMIT (20130823/psparse-553)
ACPI Error: Field [D128] at 1040 exceeds Buffer [NULL] size 160 (bits)
(20130823/dsopcode-249)
ACPI Error: Method parse/execution failed [\134_SB_.WMID.HWMC] (Node
0xfffff80004372e80), AE_AML_BUFFER_LIMIT (20130823/psparse-553)
ACPI Error: Method parse/execution failed [\134_SB_.WMID.WMAD] (Node
0xfffff80004372b80), AE_AML_BUFFER_LIMIT (20130823/psparse-553)
ACPI Error: Field [D128] at 1040 exceeds Buffer [NULL] size 160 (bits)
(20130823/dsopcode-249)
ACPI Error: Method parse/execution failed [\134_SB_.WMID.HWMC] (Node
0xfffff80004372e80), AE_AML_BUFFER_LIMIT (20130823/psparse-553)
ACPI Error: Method parse/execution failed [\134_SB_.WMID.WMAD] (Node
0xfffff80004372b80), AE_AML_BUFFER_LIMIT (20130823/psparse-553)
ACPI Error: Field [D128] at 1040 exceeds Buffer [NULL] size 160 (bits)
(20130823/dsopcode-249)
ACPI Error: Method parse/execution failed [\134_SB_.WMID.HWMC] (Node
0xfffff80004372e80), AE_AML_BUFFER_LIMIT (20130823/psparse-553)
ACPI Error: Method parse/execution failed [\134_SB_.WMID.WMAD] (Node
0xfffff80004372b80), AE_AML_BUFFER_LIMIT (20130823/psparse-553)
ACPI Error: Field [D128] at 1040 exceeds Buffer [NULL] size 160 (bits)
(20130823/dsopcode-249)
ACPI Error: Method parse/execution failed [\134_SB_.WMID.HWMC] (Node
0xfffff80004372e80), AE_AML_BUFFER_LIMIT (20130823/psparse-553)
ACPI Error: Method parse/execution failed [\134_SB_.WMID.WMAD] (Node
0xfffff80004372b80), AE_AML_BUFFER_LIMIT (20130823/psparse-553)
ACPI Error: Field [D128] at 1040 exceeds Buffer [NULL] size 160 (bits)
(20130823/dsopcode-249)
ACPI Error: Method parse/execution failed [\134_SB_.WMID.HWMC] (Node
0xfffff80004372e80), AE_AML_BUFFER_LIMIT (20130823/psparse-553)
ACPI Error: Method parse/execution failed [\134_SB_.WMID.WMAD] (Node
0xfffff80004372b80), AE_AML_BUFFER_LIMIT (20130823/psparse-553)
ACPI Error: Field [D128] at 1040 exceeds Buffer [NULL] size 160 (bits)
(20130823/dsopcode-249)
ACPI Error: Method parse/execution failed [\134_SB_.WMID.HWMC] (Node
0xfffff80004372e80), AE_AML_BUFFER_LIMIT (20130823/psparse-553)
ACPI Error: Method parse/execution failed [\134_SB_.WMID.WMAD] (Node
0xfffff80004372b80), AE_AML_BUFFER_LIMIT (20130823/psparse-553)
ACPI Error: Field [D128] at 1040 exceeds Buffer [NULL] size 160 (bits)
(20130823/dsopcode-249)
ACPI Error: Method parse/execution failed [\134_SB_.WMID.HWMC] (Node
0xfffff80004372e80), AE_AML_BUFFER_LIMIT (20130823/psparse-553)
ACPI Error: Method parse/execution failed [\134_SB_.WMID.WMAD] (Node
0xfffff80004372b80), AE_AML_BUFFER_LIMIT (20130823/psparse-553)
ACPI Error: Field [D128] at 1040 exceeds Buffer [NULL] size 160 (bits)
(20130823/dsopcode-249)
ACPI Error: Method parse/execution failed [\134_SB_.WMID.HWMC] (Node
0xfffff80004372e80), AE_AML_BUFFER_LIMIT (20130823/psparse-553)
ACPI Error: Method parse/execution failed [\134_SB_.WMID.WMAD] (Node
0xfffff80004372b80), AE_AML_BUFFER_LIMIT (20130823/psparse-553)
ACPI Error: Field [D128] at 1040 exceeds Buffer [NULL] size 160 (bits)
(20130823/dsopcode-249)
ACPI Error: Method parse/execution failed [\134_SB_.WMID.HWMC] (Node
0xfffff80004372e80), AE_AML_BUFFER_LIMIT (20130823/psparse-553)
ACPI Error: Method parse/execution failed [\134_SB_.WMID.WMAD] (Node
0xfffff80004372b80), AE_AML_BUFFER_LIMIT (20130823/psparse-553)
acpi_tz0: on acpi0
acpi_tz0: _CRT value is absurd, ignored (-273.2C)
And this is my /dev:
acpi
ad4
ad4p1
ad4p2
ad4p3
ad4p4
ad4p5
ada0
ada0p1
ada0p2
ada0p3
ada0p4
ada0p5
apm
apmctl
atkbd0
audit
bpf
bpf0
bpsm0
cd0
console
consolectl
ctty
cuse
devctl
devstat
dri
dsp0.1
dsp1.1
dsp2.1
dumpdev
fd
fido
fuse
geom.ctl
gpt
gptid
iic0
iic1
iic10
iic11
iic12
iic2
iic3
iic4
iic5
iic6
iic7
iic8
iic9
io
iso9660
kbd0
kbd1
kbdmux0
klog
kmem
log
mdctl
mem
midistat
mixer0
mixer1
mixer2
nfslock
null
pass0
pass1
pci
psm0
pts
random
rtc
sndstat
stderr
stdin
stdout
sysmouse
ttyv0
ttyv1
ttyv2
ttyv3
ttyv4
ttyv5
ttyv6
ttyv7
ttyv8
ttyv9
ttyva
ttyvb
ttyvc
ttyvd
ttyve
ttyvf
ufssuspend
ugen0.1
ugen1.1
ugen1.2
ugen2.1
ugen3.1
ugen4.1
ugen5.1
ugen6.1
urandom
usb
usbctl
vboxdrv
vboxdrvu
vboxnetctl
video0
wmistat0
xpt0
zero
cat wmistat0:
GUID INST EXPE METH STR EVENT OID
{5FB7F034-2C63-45E9-BE91-3D44E2C707E4} 1 NO WMAD NO NO AD
{95F24279-4D7B-4334-9387-ACCDC67EF61C} 1 NO NO NO 0x80+ -
{05901221-D566-11D1-B2F0-00A0C9062910} 1 NO NO NO NO AE
{D0992BD4-A47C-4EFE-B072-324AEC92296C} 1 NO NO NO NO BC
What do I do now?
TIA
From rkoberman at gmail.com Thu Mar 26 04:22:23 2015
From: rkoberman at gmail.com (Kevin Oberman)
Date: Wed, 25 Mar 2015 21:22:21 -0700
Subject: HP Compaq CQ62/42 acpi
In-Reply-To: <551362EF.3080801@herveybayaustralia.com.au>
References: <55113B2D.2040609@herveybayaustralia.com.au>
<551362EF.3080801@herveybayaustralia.com.au>
Message-ID:
On Wed, Mar 25, 2015 at 6:37 PM, Da Rock <
freebsd-acpi at herveybayaustralia.com.au> wrote:
> On 03/25/15 09:52, Kevin Oberman wrote:
>
> On Tue, Mar 24, 2015 at 3:23 AM, Da Rock <
> freebsd-acpi at herveybayaustralia.com.au> wrote:
>
>> I have 2 laptops as mentioned, 3 all amd athlon based. The 3rd is an asus
>> which I'm relatively happy with.
>>
>> What I have is when I pull the AC out of it, the sysctl for cpu speed
>> goes from 2200 to 100 or 400. Basically the system becomes rather unusable.
>>
>> I tried the acpi_hp module, and it now switches to 800. This is better,
>> but barely usable still.
>>
>> I'd like to see a response similar to the asus if its possible; this
>> effectively stays the same, but drops speed if nothing is happening.
>>
>> Ideally, I'd think that it would be better if the system adjusted speed
>> to use requirements during operation, but neither does that. I suspect that
>> the asus should (in theory) as it does do it on battery only; but unless
>> I'm really hammering all the time, it just doesn't seem to happen when I'm
>> looking at it.
>>
>> The settings used on all for powerd is hiadaptive for AC, adaptive for
>> battery.
>>
>> If I'm doing something wrong let me know, if more data is required I'm
>> happy to help the cause :)
>>
>> TIA
>>
>> First, let's get a bit more information. Please provide:
> sysctl dev.cpu.0 (on AC and then on battery)
>
> AC:
>
> dev.cpu.0.%desc: ACPI CPU
> dev.cpu.0.%driver: cpu
> dev.cpu.0.%location: handle=\_PR_.C000
> dev.cpu.0.%pnpinfo: _HID=none _UID=0
> dev.cpu.0.%parent: acpi0
> dev.cpu.0.temperature: 85.3C
> dev.cpu.0.freq: 200
> dev.cpu.0.freq_levels: 2200/7543 1925/6600 1900/6150 1662/5381 1600/4777
> 1400/4179 1300/3750 1137/3281 975/2812 800/2091 700/1829 600/1568 500/1306
> 400/1045 300/784 200/522 100/261
> dev.cpu.0.cx_supported: C1/1/0
> dev.cpu.0.cx_lowest: C1
> dev.cpu.0.cx_usage: 100.00% last 682us
>
> Battery:
>
> dev.cpu.0.%desc: ACPI CPU
> dev.cpu.0.%driver: cpu
> dev.cpu.0.%location: handle=\_PR_.C000
> dev.cpu.0.%pnpinfo: _HID=none _UID=0
> dev.cpu.0.%parent: acpi0
> dev.cpu.0.temperature: 85.5C
> dev.cpu.0.freq: 100
> dev.cpu.0.freq_levels: 2200/7543 1925/6600 1900/6150 1662/5381 1600/4777
> 1400/4179 1300/3750 1137/3281 975/2812 800/2091 700/1829 600/1568 500/1306
> 400/1045 300/784 200/522 100/261
> dev.cpu.0.cx_supported: C1/1/0
> dev.cpu.0.cx_lowest: C1
> dev.cpu.0.cx_usage: 100.00% last 901us
>
> uname -a
>
> FreeBSD laptop1 10.0-RELEASE-p7 FreeBSD 10.0-RELEASE-p7 #0: Tue Jul 8
> 06:37:44 UTC 2014
> root at amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64
>
> /etc/sysctl.conf (If present)
>
> vfs.usermount=1
> kern.ipc.shm_allow_removed=1
> compat.linux.osrelease=2.6.18
>
> /boot/loader.conf (if present)
>
> (like it wasn't going to be present :D who doesn't?)
> vboxdrv_load=YES
> tmpfs_load=YES
> cuse4bsd_load=YES
> acpi_video_load=YES
> amdtemp_load=YES
> fuse_load=YES
> acpi_hp_load=YES
>
> I'd like to get this system running nicely if I can - its been just
> getting there for too long now because of other projects taking my
> attention and I've got bite the bullet and work this out.
>
> BTW, just to make a liar out of me after I sent that post, the system did
> start to change the cpu speed on AC - but it took a while. I had sat there
> monitoring the system with little activity and it remained at 2200; when I
> gave up waiting and sent that post I then started to really give it to it
> and the speed started dropping and rising a little. However, given I was
> trying to do an encoding with ffmpeg at the time, the speed probably should
> have remained at 2200 as my frames encoded per second was about half of
> normal. So I don't really know what to expect :)
>
> This is also in my dmesg:
>
> amdtemp0: on hostb4
> acpi_acad0: on acpi0
> battery0: on acpi0
> acpi_lid0: on acpi0
> acpi_wmi0: on acpi0
> acpi_hp0: on acpi_wmi0
> acpi_hp0: HP event GUID detected, installing event handler
> ACPI Error: Field [D128] at 1040 exceeds Buffer [NULL] size 160 (bits)
> (20130823/dsopcode-249)
> ACPI Error: Method parse/execution failed [\134_SB_.WMID.HWMC] (Node
> 0xfffff80004372e80), AE_AML_BUFFER_LIMIT (20130823/psparse-553)
> ACPI Error: Method parse/execution failed [\134_SB_.WMID.WMAD] (Node
> 0xfffff80004372b80), AE_AML_BUFFER_LIMIT (20130823/psparse-553)
> ACPI Error: Field [D128] at 1040 exceeds Buffer [NULL] size 160 (bits)
> (20130823/dsopcode-249)
> ACPI Error: Method parse/execution failed [\134_SB_.WMID.HWMC] (Node
> 0xfffff80004372e80), AE_AML_BUFFER_LIMIT (20130823/psparse-553)
> ACPI Error: Method parse/execution failed [\134_SB_.WMID.WMAD] (Node
> 0xfffff80004372b80), AE_AML_BUFFER_LIMIT (20130823/psparse-553)
> ACPI Error: Field [D128] at 1040 exceeds Buffer [NULL] size 160 (bits)
> (20130823/dsopcode-249)
> ACPI Error: Method parse/execution failed [\134_SB_.WMID.HWMC] (Node
> 0xfffff80004372e80), AE_AML_BUFFER_LIMIT (20130823/psparse-553)
> ACPI Error: Method parse/execution failed [\134_SB_.WMID.WMAD] (Node
> 0xfffff80004372b80), AE_AML_BUFFER_LIMIT (20130823/psparse-553)
> ACPI Error: Field [D128] at 1040 exceeds Buffer [NULL] size 160 (bits)
> (20130823/dsopcode-249)
> ACPI Error: Method parse/execution failed [\134_SB_.WMID.HWMC] (Node
> 0xfffff80004372e80), AE_AML_BUFFER_LIMIT (20130823/psparse-553)
> ACPI Error: Method parse/execution failed [\134_SB_.WMID.WMAD] (Node
> 0xfffff80004372b80), AE_AML_BUFFER_LIMIT (20130823/psparse-553)
> ACPI Error: Field [D128] at 1040 exceeds Buffer [NULL] size 160 (bits)
> (20130823/dsopcode-249)
> ACPI Error: Method parse/execution failed [\134_SB_.WMID.HWMC] (Node
> 0xfffff80004372e80), AE_AML_BUFFER_LIMIT (20130823/psparse-553)
> ACPI Error: Method parse/execution failed [\134_SB_.WMID.WMAD] (Node
> 0xfffff80004372b80), AE_AML_BUFFER_LIMIT (20130823/psparse-553)
> ACPI Error: Field [D128] at 1040 exceeds Buffer [NULL] size 160 (bits)
> (20130823/dsopcode-249)
> ACPI Error: Method parse/execution failed [\134_SB_.WMID.HWMC] (Node
> 0xfffff80004372e80), AE_AML_BUFFER_LIMIT (20130823/psparse-553)
> ACPI Error: Method parse/execution failed [\134_SB_.WMID.WMAD] (Node
> 0xfffff80004372b80), AE_AML_BUFFER_LIMIT (20130823/psparse-553)
> ACPI Error: Field [D128] at 1040 exceeds Buffer [NULL] size 160 (bits)
> (20130823/dsopcode-249)
> ACPI Error: Method parse/execution failed [\134_SB_.WMID.HWMC] (Node
> 0xfffff80004372e80), AE_AML_BUFFER_LIMIT (20130823/psparse-553)
> ACPI Error: Method parse/execution failed [\134_SB_.WMID.WMAD] (Node
> 0xfffff80004372b80), AE_AML_BUFFER_LIMIT (20130823/psparse-553)
> ACPI Error: Field [D128] at 1040 exceeds Buffer [NULL] size 160 (bits)
> (20130823/dsopcode-249)
> ACPI Error: Method parse/execution failed [\134_SB_.WMID.HWMC] (Node
> 0xfffff80004372e80), AE_AML_BUFFER_LIMIT (20130823/psparse-553)
> ACPI Error: Method parse/execution failed [\134_SB_.WMID.WMAD] (Node
> 0xfffff80004372b80), AE_AML_BUFFER_LIMIT (20130823/psparse-553)
> ACPI Error: Field [D128] at 1040 exceeds Buffer [NULL] size 160 (bits)
> (20130823/dsopcode-249)
> ACPI Error: Method parse/execution failed [\134_SB_.WMID.HWMC] (Node
> 0xfffff80004372e80), AE_AML_BUFFER_LIMIT (20130823/psparse-553)
> ACPI Error: Method parse/execution failed [\134_SB_.WMID.WMAD] (Node
> 0xfffff80004372b80), AE_AML_BUFFER_LIMIT (20130823/psparse-553)
> ACPI Error: Field [D128] at 1040 exceeds Buffer [NULL] size 160 (bits)
> (20130823/dsopcode-249)
> ACPI Error: Method parse/execution failed [\134_SB_.WMID.HWMC] (Node
> 0xfffff80004372e80), AE_AML_BUFFER_LIMIT (20130823/psparse-553)
> ACPI Error: Method parse/execution failed [\134_SB_.WMID.WMAD] (Node
> 0xfffff80004372b80), AE_AML_BUFFER_LIMIT (20130823/psparse-553)
> ACPI Error: Field [D128] at 1040 exceeds Buffer [NULL] size 160 (bits)
> (20130823/dsopcode-249)
> ACPI Error: Method parse/execution failed [\134_SB_.WMID.HWMC] (Node
> 0xfffff80004372e80), AE_AML_BUFFER_LIMIT (20130823/psparse-553)
> ACPI Error: Method parse/execution failed [\134_SB_.WMID.WMAD] (Node
> 0xfffff80004372b80), AE_AML_BUFFER_LIMIT (20130823/psparse-553)
> ACPI Error: Field [D128] at 1040 exceeds Buffer [NULL] size 160 (bits)
> (20130823/dsopcode-249)
> ACPI Error: Method parse/execution failed [\134_SB_.WMID.HWMC] (Node
> 0xfffff80004372e80), AE_AML_BUFFER_LIMIT (20130823/psparse-553)
> ACPI Error: Method parse/execution failed [\134_SB_.WMID.WMAD] (Node
> 0xfffff80004372b80), AE_AML_BUFFER_LIMIT (20130823/psparse-553)
> ACPI Error: Field [D128] at 1040 exceeds Buffer [NULL] size 160 (bits)
> (20130823/dsopcode-249)
> ACPI Error: Method parse/execution failed [\134_SB_.WMID.HWMC] (Node
> 0xfffff80004372e80), AE_AML_BUFFER_LIMIT (20130823/psparse-553)
> ACPI Error: Method parse/execution failed [\134_SB_.WMID.WMAD] (Node
> 0xfffff80004372b80), AE_AML_BUFFER_LIMIT (20130823/psparse-553)
> acpi_tz0: on acpi0
> acpi_tz0: _CRT value is absurd, ignored (-273.2C)
>
> And this is my /dev:
>
> acpi
> ad4
> ad4p1
> ad4p2
> ad4p3
> ad4p4
> ad4p5
> ada0
> ada0p1
> ada0p2
> ada0p3
> ada0p4
> ada0p5
> apm
> apmctl
> atkbd0
> audit
> bpf
> bpf0
> bpsm0
> cd0
> console
> consolectl
> ctty
> cuse
> devctl
> devstat
> dri
> dsp0.1
> dsp1.1
> dsp2.1
> dumpdev
> fd
> fido
> fuse
> geom.ctl
> gpt
> gptid
> iic0
> iic1
> iic10
> iic11
> iic12
> iic2
> iic3
> iic4
> iic5
> iic6
> iic7
> iic8
> iic9
> io
> iso9660
> kbd0
> kbd1
> kbdmux0
> klog
> kmem
> log
> mdctl
> mem
> midistat
> mixer0
> mixer1
> mixer2
> nfslock
> null
> pass0
> pass1
> pci
> psm0
> pts
> random
> rtc
> sndstat
> stderr
> stdin
> stdout
> sysmouse
> ttyv0
> ttyv1
> ttyv2
> ttyv3
> ttyv4
> ttyv5
> ttyv6
> ttyv7
> ttyv8
> ttyv9
> ttyva
> ttyvb
> ttyvc
> ttyvd
> ttyve
> ttyvf
> ufssuspend
> ugen0.1
> ugen1.1
> ugen1.2
> ugen2.1
> ugen3.1
> ugen4.1
> ugen5.1
> ugen6.1
> urandom
> usb
> usbctl
> vboxdrv
> vboxdrvu
> vboxnetctl
> video0
> wmistat0
> xpt0
> zero
>
> cat wmistat0:
>
> GUID INST EXPE METH STR EVENT OID
> {5FB7F034-2C63-45E9-BE91-3D44E2C707E4} 1 NO WMAD NO NO AD
> {95F24279-4D7B-4334-9387-ACCDC67EF61C} 1 NO NO NO 0x80+ -
> {05901221-D566-11D1-B2F0-00A0C9062910} 1 NO NO NO NO AE
> {D0992BD4-A47C-4EFE-B072-324AEC92296C} 1 NO NO NO NO BC
>
> What do I do now?
>
> TIA
>
First, I suggest checking the output of kldstat to see that acpi_wmi.ko is
loaded. If not, add acpi_wmi_load=YES to loader.conf. wmi is an HP/Acer
thing and I really don't know much about it. Do you have powerd variables
in rc.conf? I assume you have powerd_enable="YES", but are you setting any
flags?
I see that you are using P4TCC. (This is default in 10, but will finally be
fixed in 11.) You can turn it off by adding:
hint.p4tcc.0.disabled=1
hint.acpi_throttle.0.disabled=1
to loader.conf. It will remove a bunch of useless "frequencies" and leave
the useful values. It will make powerd much more responsive and will
prevent C-states from locking up the system when they are enabled. I'd also
suggest setting:
performance_cx_lowest="Cmax"
economy_cx_lowest="Cmax"
as C-states are by far and away the best power saving tool available. (This
also becomes default in 11.)
For a lot of details on tuning power usage, read the article at
https://wiki.freebsd.org/TuningPowerConsumption.
Finally, so a little debug. Kill powerd (service powerd stop) and run it
with verbose on a terminal ("powerd -v" plus whatever options you have in
powerd_flags) and watch what powerd is doing.
From smithi at nimnet.asn.au Thu Mar 26 05:16:59 2015
From: smithi at nimnet.asn.au (Ian Smith)
Date: Thu, 26 Mar 2015 16:16:48 +1100 (EST)
Subject: HP Compaq CQ62/42 acpi
In-Reply-To: <551362EF.3080801@herveybayaustralia.com.au>
References: <55113B2D.2040609@herveybayaustralia.com.au>
<551362EF.3080801@herveybayaustralia.com.au>
Message-ID: <20150326144735.L22893@sola.nimnet.asn.au>
On Thu, 26 Mar 2015 11:37:51 +1000, Da Rock wrote:
> On 03/25/15 09:52, Kevin Oberman wrote:
> > On Tue, Mar 24, 2015 at 3:23 AM, Da Rock
> > > > wrote:
> >
> > I have 2 laptops as mentioned, 3 all amd athlon based. The 3rd is
> > an asus which I'm relatively happy with.
> >
> > What I have is when I pull the AC out of it, the sysctl for cpu
> > speed goes from 2200 to 100 or 400. Basically the system becomes
> > rather unusable.
> >
> > I tried the acpi_hp module, and it now switches to 800. This is
> > better, but barely usable still.
> >
> > I'd like to see a response similar to the asus if its possible;
> > this effectively stays the same, but drops speed if nothing is
> > happening.
> >
> > Ideally, I'd think that it would be better if the system adjusted
> > speed to use requirements during operation, but neither does that.
> > I suspect that the asus should (in theory) as it does do it on
> > battery only; but unless I'm really hammering all the time, it
> > just doesn't seem to happen when I'm looking at it.
> >
> > The settings used on all for powerd is hiadaptive for AC, adaptive
> > for battery.
> >
> > If I'm doing something wrong let me know, if more data is required
> > I'm happy to help the cause :)
> >
> > TIA
> >
> > First, let's get a bit more information. Please provide:
> > sysctl dev.cpu.0 (on AC and then on battery)
> AC:
>
> dev.cpu.0.%desc: ACPI CPU
> dev.cpu.0.%driver: cpu
> dev.cpu.0.%location: handle=\_PR_.C000
> dev.cpu.0.%pnpinfo: _HID=none _UID=0
> dev.cpu.0.%parent: acpi0
> dev.cpu.0.temperature: 85.3C
> dev.cpu.0.freq: 200
> dev.cpu.0.freq_levels: 2200/7543 1925/6600 1900/6150 1662/5381 1600/4777
> 1400/4179 1300/3750 1137/3281 975/2812 800/2091 700/1829 600/1568 500/1306
> 400/1045 300/784 200/522 100/261
> dev.cpu.0.cx_supported: C1/1/0
> dev.cpu.0.cx_lowest: C1
> dev.cpu.0.cx_usage: 100.00% last 682us
Kevin appears to be psychic :) as for the second time in 3 days has
replied while I was composing mine, but this time I heard the beep and
saw 'new message from Kevin ..' and of course he's well covered it,
except possibly regarding one aspect which I'll leave in:
The clue is all those freq_levels. For powerd to increase frequeny under
load requires stepping through all of them, possibly one per polling
interval, which as you've observed takes too long. If you were running
Intel I'd say you need to add to /boot/loader.conf these, and you should
add them anyway:
hint.p4tcc.0.disabled=1
hint.acpi_throttle.0.disabled=1
But from your one (1) clue that this is an AMD system, I'm not so sure:
> amdtemp0: on hostb4
so you should check dmesg to check if you're running powernow(none!)
instead of est(4) plus any other drivers providing 'thermal control',
and if so, disable it (but not powernow or amdtemp) similarly. It may
already be using acpi_throttle?, or perhaps p4tcc also covers AMD CPUs
these days, I'm not sure? If that's unclear, post /var/run/dmesg.boot
Yes, set both *_cx_lowest=Cmax and take delight in dev.cpu.0.cx_usage
Playing with powerd_flags can make quite a lot of difference to powerd's
behaviour, so I echo Kevin's request to see those, and his advice to run
powerd -v in a terminal while you play, especially with -i and -r flags,
though reducing -p interval may be beneficial to responsiveness, at a
slight increase in powerd's CPU usage.
I don't know if any of this changed between your 10.0 and 10.1 ..
cheers, Ian
From freebsd-acpi at herveybayaustralia.com.au Fri Mar 27 11:54:24 2015
From: freebsd-acpi at herveybayaustralia.com.au (Da Rock)
Date: Fri, 27 Mar 2015 21:54:10 +1000
Subject: HP Compaq CQ62/42 acpi
In-Reply-To:
References: <55113B2D.2040609@herveybayaustralia.com.au> <551362EF.3080801@herveybayaustralia.com.au>
Message-ID: <551544E2.4040205@herveybayaustralia.com.au>
On 26/03/2015 14:22, Kevin Oberman wrote:
> On Wed, Mar 25, 2015 at 6:37 PM, Da Rock
> > wrote:
>
> On 03/25/15 09:52, Kevin Oberman wrote:
>> On Tue, Mar 24, 2015 at 3:23 AM, Da Rock
>> > > wrote:
>>
>> I have 2 laptops as mentioned, 3 all amd athlon based. The
>> 3rd is an asus which I'm relatively happy with.
>>
>> What I have is when I pull the AC out of it, the sysctl for
>> cpu speed goes from 2200 to 100 or 400. Basically the system
>> becomes rather unusable.
>>
>> I tried the acpi_hp module, and it now switches to 800. This
>> is better, but barely usable still.
>>
>> I'd like to see a response similar to the asus if its
>> possible; this effectively stays the same, but drops speed if
>> nothing is happening.
>>
>> Ideally, I'd think that it would be better if the system
>> adjusted speed to use requirements during operation, but
>> neither does that. I suspect that the asus should (in theory)
>> as it does do it on battery only; but unless I'm really
>> hammering all the time, it just doesn't seem to happen when
>> I'm looking at it.
>>
>> The settings used on all for powerd is hiadaptive for AC,
>> adaptive for battery.
>>
>> If I'm doing something wrong let me know, if more data is
>> required I'm happy to help the cause :)
>>
>> TIA
>>
>> First, let's get a bit more information. Please provide:
>> sysctl dev.cpu.0 (on AC and then on battery)
> AC:
>
> dev.cpu.0.%desc: ACPI CPU
> dev.cpu.0.%driver: cpu
> dev.cpu.0.%location: handle=\_PR_.C000
> dev.cpu.0.%pnpinfo: _HID=none _UID=0
> dev.cpu.0.%parent: acpi0
> dev.cpu.0.temperature: 85.3C
> dev.cpu.0.freq: 200
> dev.cpu.0.freq_levels: 2200/7543 1925/6600 1900/6150 1662/5381
> 1600/4777 1400/4179 1300/3750 1137/3281 975/2812 800/2091 700/1829
> 600/1568 500/1306 400/1045 300/784 200/522 100/261
> dev.cpu.0.cx_supported: C1/1/0
> dev.cpu.0.cx_lowest: C1
> dev.cpu.0.cx_usage: 100.00% last 682us
>
> Battery:
>
> dev.cpu.0.%desc: ACPI CPU
> dev.cpu.0.%driver: cpu
> dev.cpu.0.%location: handle=\_PR_.C000
> dev.cpu.0.%pnpinfo: _HID=none _UID=0
> dev.cpu.0.%parent: acpi0
> dev.cpu.0.temperature: 85.5C
> dev.cpu.0.freq: 100
> dev.cpu.0.freq_levels: 2200/7543 1925/6600 1900/6150 1662/5381
> 1600/4777 1400/4179 1300/3750 1137/3281 975/2812 800/2091 700/1829
> 600/1568 500/1306 400/1045 300/784 200/522 100/261
> dev.cpu.0.cx_supported: C1/1/0
> dev.cpu.0.cx_lowest: C1
> dev.cpu.0.cx_usage: 100.00% last 901us
>> uname -a
> FreeBSD laptop1 10.0-RELEASE-p7 FreeBSD 10.0-RELEASE-p7 #0: Tue
> Jul 8 06:37:44 UTC 2014
> root at amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC
>
> amd64
>> /etc/sysctl.conf (If present)
> vfs.usermount=1
> kern.ipc.shm_allow_removed=1
> compat.linux.osrelease=2.6.18
>> /boot/loader.conf (if present)
> (like it wasn't going to be present :D who doesn't?)
> vboxdrv_load=YES
> tmpfs_load=YES
> cuse4bsd_load=YES
> acpi_video_load=YES
> amdtemp_load=YES
> fuse_load=YES
> acpi_hp_load=YES
>
> I'd like to get this system running nicely if I can - its been
> just getting there for too long now because of other projects
> taking my attention and I've got bite the bullet and work this out.
>
> BTW, just to make a liar out of me after I sent that post, the
> system did start to change the cpu speed on AC - but it took a
> while. I had sat there monitoring the system with little activity
> and it remained at 2200; when I gave up waiting and sent that post
> I then started to really give it to it and the speed started
> dropping and rising a little. However, given I was trying to do an
> encoding with ffmpeg at the time, the speed probably should have
> remained at 2200 as my frames encoded per second was about half of
> normal. So I don't really know what to expect :)
>
> This is also in my dmesg:
>
> amdtemp0: on hostb4
> acpi_acad0: on acpi0
> battery0: on acpi0
> acpi_lid0: on acpi0
> acpi_wmi0: on acpi0
> acpi_hp0: on acpi_wmi0
> acpi_hp0: HP event GUID detected, installing event handler
> ACPI Error: Field [D128] at 1040 exceeds Buffer [NULL] size 160
> (bits) (20130823/dsopcode-249)
> ACPI Error: Method parse/execution failed [\134_SB_.WMID.HWMC]
> (Node 0xfffff80004372e80), AE_AML_BUFFER_LIMIT (20130823/psparse-553)
> ACPI Error: Method parse/execution failed [\134_SB_.WMID.WMAD]
> (Node 0xfffff80004372b80), AE_AML_BUFFER_LIMIT (20130823/psparse-553)
> ACPI Error: Field [D128] at 1040 exceeds Buffer [NULL] size 160
> (bits) (20130823/dsopcode-249)
> ACPI Error: Method parse/execution failed [\134_SB_.WMID.HWMC]
> (Node 0xfffff80004372e80), AE_AML_BUFFER_LIMIT (20130823/psparse-553)
> ACPI Error: Method parse/execution failed [\134_SB_.WMID.WMAD]
> (Node 0xfffff80004372b80), AE_AML_BUFFER_LIMIT (20130823/psparse-553)
> ACPI Error: Field [D128] at 1040 exceeds Buffer [NULL] size 160
> (bits) (20130823/dsopcode-249)
> ACPI Error: Method parse/execution failed [\134_SB_.WMID.HWMC]
> (Node 0xfffff80004372e80), AE_AML_BUFFER_LIMIT (20130823/psparse-553)
> ACPI Error: Method parse/execution failed [\134_SB_.WMID.WMAD]
> (Node 0xfffff80004372b80), AE_AML_BUFFER_LIMIT (20130823/psparse-553)
> ACPI Error: Field [D128] at 1040 exceeds Buffer [NULL] size 160
> (bits) (20130823/dsopcode-249)
> ACPI Error: Method parse/execution failed [\134_SB_.WMID.HWMC]
> (Node 0xfffff80004372e80), AE_AML_BUFFER_LIMIT (20130823/psparse-553)
> ACPI Error: Method parse/execution failed [\134_SB_.WMID.WMAD]
> (Node 0xfffff80004372b80), AE_AML_BUFFER_LIMIT (20130823/psparse-553)
> ACPI Error: Field [D128] at 1040 exceeds Buffer [NULL] size 160
> (bits) (20130823/dsopcode-249)
> ACPI Error: Method parse/execution failed [\134_SB_.WMID.HWMC]
> (Node 0xfffff80004372e80), AE_AML_BUFFER_LIMIT (20130823/psparse-553)
> ACPI Error: Method parse/execution failed [\134_SB_.WMID.WMAD]
> (Node 0xfffff80004372b80), AE_AML_BUFFER_LIMIT (20130823/psparse-553)
> ACPI Error: Field [D128] at 1040 exceeds Buffer [NULL] size 160
> (bits) (20130823/dsopcode-249)
> ACPI Error: Method parse/execution failed [\134_SB_.WMID.HWMC]
> (Node 0xfffff80004372e80), AE_AML_BUFFER_LIMIT (20130823/psparse-553)
> ACPI Error: Method parse/execution failed [\134_SB_.WMID.WMAD]
> (Node 0xfffff80004372b80), AE_AML_BUFFER_LIMIT (20130823/psparse-553)
> ACPI Error: Field [D128] at 1040 exceeds Buffer [NULL] size 160
> (bits) (20130823/dsopcode-249)
> ACPI Error: Method parse/execution failed [\134_SB_.WMID.HWMC]
> (Node 0xfffff80004372e80), AE_AML_BUFFER_LIMIT (20130823/psparse-553)
> ACPI Error: Method parse/execution failed [\134_SB_.WMID.WMAD]
> (Node 0xfffff80004372b80), AE_AML_BUFFER_LIMIT (20130823/psparse-553)
> ACPI Error: Field [D128] at 1040 exceeds Buffer [NULL] size 160
> (bits) (20130823/dsopcode-249)
> ACPI Error: Method parse/execution failed [\134_SB_.WMID.HWMC]
> (Node 0xfffff80004372e80), AE_AML_BUFFER_LIMIT (20130823/psparse-553)
> ACPI Error: Method parse/execution failed [\134_SB_.WMID.WMAD]
> (Node 0xfffff80004372b80), AE_AML_BUFFER_LIMIT (20130823/psparse-553)
> ACPI Error: Field [D128] at 1040 exceeds Buffer [NULL] size 160
> (bits) (20130823/dsopcode-249)
> ACPI Error: Method parse/execution failed [\134_SB_.WMID.HWMC]
> (Node 0xfffff80004372e80), AE_AML_BUFFER_LIMIT (20130823/psparse-553)
> ACPI Error: Method parse/execution failed [\134_SB_.WMID.WMAD]
> (Node 0xfffff80004372b80), AE_AML_BUFFER_LIMIT (20130823/psparse-553)
> ACPI Error: Field [D128] at 1040 exceeds Buffer [NULL] size 160
> (bits) (20130823/dsopcode-249)
> ACPI Error: Method parse/execution failed [\134_SB_.WMID.HWMC]
> (Node 0xfffff80004372e80), AE_AML_BUFFER_LIMIT (20130823/psparse-553)
> ACPI Error: Method parse/execution failed [\134_SB_.WMID.WMAD]
> (Node 0xfffff80004372b80), AE_AML_BUFFER_LIMIT (20130823/psparse-553)
> ACPI Error: Field [D128] at 1040 exceeds Buffer [NULL] size 160
> (bits) (20130823/dsopcode-249)
> ACPI Error: Method parse/execution failed [\134_SB_.WMID.HWMC]
> (Node 0xfffff80004372e80), AE_AML_BUFFER_LIMIT (20130823/psparse-553)
> ACPI Error: Method parse/execution failed [\134_SB_.WMID.WMAD]
> (Node 0xfffff80004372b80), AE_AML_BUFFER_LIMIT (20130823/psparse-553)
> ACPI Error: Field [D128] at 1040 exceeds Buffer [NULL] size 160
> (bits) (20130823/dsopcode-249)
> ACPI Error: Method parse/execution failed [\134_SB_.WMID.HWMC]
> (Node 0xfffff80004372e80), AE_AML_BUFFER_LIMIT (20130823/psparse-553)
> ACPI Error: Method parse/execution failed [\134_SB_.WMID.WMAD]
> (Node 0xfffff80004372b80), AE_AML_BUFFER_LIMIT (20130823/psparse-553)
> ACPI Error: Field [D128] at 1040 exceeds Buffer [NULL] size 160
> (bits) (20130823/dsopcode-249)
> ACPI Error: Method parse/execution failed [\134_SB_.WMID.HWMC]
> (Node 0xfffff80004372e80), AE_AML_BUFFER_LIMIT (20130823/psparse-553)
> ACPI Error: Method parse/execution failed [\134_SB_.WMID.WMAD]
> (Node 0xfffff80004372b80), AE_AML_BUFFER_LIMIT (20130823/psparse-553)
> acpi_tz0: on acpi0
> acpi_tz0: _CRT value is absurd, ignored (-273.2C)
>
I should have clarified this before - can someone tell me what all this
means? Can I do anything about it?
>
>
> cat wmistat0:
>
> GUID INST EXPE METH STR EVENT OID
> {5FB7F034-2C63-45E9-BE91-3D44E2C707E4} 1 NO WMAD NO NO AD
> {95F24279-4D7B-4334-9387-ACCDC67EF61C} 1 NO NO NO 0x80+ -
> {05901221-D566-11D1-B2F0-00A0C9062910} 1 NO NO NO NO AE
> {D0992BD4-A47C-4EFE-B072-324AEC92296C} 1 NO NO NO NO BC
>
> What do I do now?
>
> TIA
>
>
> First, I suggest checking the output of kldstat to see that
> acpi_wmi.ko is loaded.
See just above; that device is set with the module, and the module is
loaded with acpi_hp. Check:
kldstat:
8 1 0xffffffff8189f000 83c0 acpi_hp.ko
9 2 0xffffffff818a8000 7e10 acpi_wmi.ko
> If not, add acpi_wmi_load=YES to loader.conf. wmi is an HP/Acer thing
> and I really don't know much about it. Do you have powerd variables in
> rc.conf? I assume you have powerd_enable="YES", but are you setting
> any flags?
Flags as initially provided in OP: hiadaptive on AC, adaptive on battery.
>
> I see that you are using P4TCC. (This is default in 10, but will
> finally be fixed in 11.) You can turn it off by adding:
> hint.p4tcc.0.disabled=1
> hint.acpi_throttle.0.disabled=1
> to loader.conf. It will remove a bunch of useless "frequencies" and
> leave the useful values. It will make powerd much more responsive and
> will prevent C-states from locking up the system when they are
> enabled. I'd also suggest setting:
> performance_cx_lowest="Cmax"
> economy_cx_lowest="Cmax"
> as C-states are by far and away the best power saving tool available.
> (This also becomes default in 11.)
So what exactly should I be seeing? This:
dev.cpu.0.%desc: ACPI CPU
dev.cpu.0.%driver: cpu
dev.cpu.0.%location: handle=\_PR_.C000
dev.cpu.0.%pnpinfo: _HID=none _UID=0
dev.cpu.0.%parent: acpi0
dev.cpu.0.temperature: 82.5C
dev.cpu.0.freq: 800
dev.cpu.0.freq_levels: 2200/7543 1900/6150 1600/4777 1300/3750 800/2091
dev.cpu.0.cx_supported: C1/1/0
dev.cpu.0.cx_lowest: C8
dev.cpu.0.cx_usage: 100.00% last 4934us
Why is it at c8? And what does the cx_supported do then?
>
> For a lot of details on tuning power usage, read the article at
> https://wiki.freebsd.org/TuningPowerConsumption.
>
> Finally, so a little debug. Kill powerd (service powerd stop) and run
> it with verbose on a terminal ("powerd -v" plus whatever options you
> have in powerd_flags) and watch what powerd is doing.
powerd: using sysctl for AC line status
powerd: using devd for AC line status
load 0%, current freq 2200 MHz ( 0), wanted freq 2131 MHz
load 0%, current freq 2200 MHz ( 0), wanted freq 2064 MHz
load 6%, current freq 2200 MHz ( 0), wanted freq 1999 MHz
load 9%, current freq 2200 MHz ( 0), wanted freq 1936 MHz
load 8%, current freq 2200 MHz ( 0), wanted freq 1875 MHz
changing clock speed from 2200 MHz to 1900 MHz
load 4%, current freq 1900 MHz ( 1), wanted freq 1816 MHz
load 0%, current freq 1900 MHz ( 1), wanted freq 1759 MHz
load 4%, current freq 1900 MHz ( 1), wanted freq 1704 MHz
load 0%, current freq 1900 MHz ( 1), wanted freq 1650 MHz
load 0%, current freq 1900 MHz ( 1), wanted freq 1598 MHz
changing clock speed from 1900 MHz to 1600 MHz
load 3%, current freq 1600 MHz ( 2), wanted freq 1548 MHz
load 10%, current freq 1600 MHz ( 2), wanted freq 1499 MHz
load 6%, current freq 1600 MHz ( 2), wanted freq 1452 MHz
load 6%, current freq 1600 MHz ( 2), wanted freq 1406 MHz
load 7%, current freq 1600 MHz ( 2), wanted freq 1362 MHz
load 4%, current freq 1600 MHz ( 2), wanted freq 1319 MHz
load 4%, current freq 1600 MHz ( 2), wanted freq 1277 MHz
changing clock speed from 1600 MHz to 1300 MHz
load 6%, current freq 1300 MHz ( 3), wanted freq 1237 MHz
load 13%, current freq 1300 MHz ( 3), wanted freq 1198 MHz
load 3%, current freq 1300 MHz ( 3), wanted freq 1160 MHz
load 3%, current freq 1300 MHz ( 3), wanted freq 1123 MHz
load 6%, current freq 1300 MHz ( 3), wanted freq 1087 MHz
load 22%, current freq 1300 MHz ( 3), wanted freq 1053 MHz
load 8%, current freq 1300 MHz ( 3), wanted freq 1020 MHz
load 3%, current freq 1300 MHz ( 3), wanted freq 988 MHz
load 9%, current freq 1300 MHz ( 3), wanted freq 957 MHz
load 21%, current freq 1300 MHz ( 3), wanted freq 927 MHz
load 3%, current freq 1300 MHz ( 3), wanted freq 898 MHz
load 7%, current freq 1300 MHz ( 3), wanted freq 869 MHz
load 9%, current freq 1300 MHz ( 3), wanted freq 841 MHz
load 7%, current freq 1300 MHz ( 3), wanted freq 814 MHz
load 7%, current freq 1300 MHz ( 3), wanted freq 800 MHz
changing clock speed from 1300 MHz to 800 MHz
load 6%, current freq 800 MHz ( 4), wanted freq 800 MHz
load 10%, current freq 800 MHz ( 4), wanted freq 800 MHz
load 6%, current freq 800 MHz ( 4), wanted freq 800 MHz
load 18%, current freq 800 MHz ( 4), wanted freq 800 MHz
load 30%, current freq 800 MHz ( 4), wanted freq 800 MHz
load 15%, current freq 800 MHz ( 4), wanted freq 800 MHz
load 11%, current freq 800 MHz ( 4), wanted freq 800 MHz
load 7%, current freq 800 MHz ( 4), wanted freq 800 MHz
load 9%, current freq 800 MHz ( 4), wanted freq 800 MHz
load 8%, current freq 800 MHz ( 4), wanted freq 800 MHz
load 13%, current freq 800 MHz ( 4), wanted freq 800 MHz
load 7%, current freq 800 MHz ( 4), wanted freq 800 MHz
load 7%, current freq 800 MHz ( 4), wanted freq 800 MHz
load 15%, current freq 800 MHz ( 4), wanted freq 800 MHz
load 6%, current freq 800 MHz ( 4), wanted freq 800 MHz
load 6%, current freq 800 MHz ( 4), wanted freq 800 MHz
load 10%, current freq 800 MHz ( 4), wanted freq 800 MHz
load 8%, current freq 800 MHz ( 4), wanted freq 800 MHz
load 9%, current freq 800 MHz ( 4), wanted freq 800 MHz
load 7%, current freq 800 MHz ( 4), wanted freq 800 MHz
load 9%, current freq 800 MHz ( 4), wanted freq 800 MHz
load 26%, current freq 800 MHz ( 4), wanted freq 800 MHz
load 17%, current freq 800 MHz ( 4), wanted freq 800 MHz
load 6%, current freq 800 MHz ( 4), wanted freq 800 MHz
load 8%, current freq 800 MHz ( 4), wanted freq 800 MHz
load 6%, current freq 800 MHz ( 4), wanted freq 800 MHz
load 9%, current freq 800 MHz ( 4), wanted freq 800 MHz
load 6%, current freq 800 MHz ( 4), wanted freq 800 MHz
load 6%, current freq 800 MHz ( 4), wanted freq 800 MHz
load 8%, current freq 800 MHz ( 4), wanted freq 800 MHz
load 14%, current freq 800 MHz ( 4), wanted freq 800 MHz
load 6%, current freq 800 MHz ( 4), wanted freq 800 MHz
load 12%, current freq 800 MHz ( 4), wanted freq 800 MHz
load 7%, current freq 800 MHz ( 4), wanted freq 800 MHz
load 12%, current freq 800 MHz ( 4), wanted freq 800 MHz
load 12%, current freq 800 MHz ( 4), wanted freq 800 MHz
load 10%, current freq 800 MHz ( 4), wanted freq 800 MHz
load 6%, current freq 800 MHz ( 4), wanted freq 800 MHz
load 7%, current freq 800 MHz ( 4), wanted freq 800 MHz
load 6%, current freq 800 MHz ( 4), wanted freq 800 MHz
load 8%, current freq 800 MHz ( 4), wanted freq 800 MHz
load 9%, current freq 800 MHz ( 4), wanted freq 800 MHz
load 7%, current freq 800 MHz ( 4), wanted freq 800 MHz
load 6%, current freq 800 MHz ( 4), wanted freq 800 MHz
load 7%, current freq 800 MHz ( 4), wanted freq 800 MHz
load 16%, current freq 800 MHz ( 4), wanted freq 800 MHz
load 11%, current freq 800 MHz ( 4), wanted freq 800 MHz
load 10%, current freq 800 MHz ( 4), wanted freq 800 MHz
^Ctotal joules used: 64.579
So aside from being informative, how can this help me? You guys
mentioned locking up, was that happening each line here?
The -i and -r seemed reasonable for my purposes, so no change there, at
least until I get a better feel for things anyway.
With regards powernow! I can't see it in dmesg (used grep), but est
isn't used either as far as I can tell. How would I enable powernow in
freebsd anyway? Or is it just a cpu thing and not a module?
CPU: AMD Phenom(tm) II N970 Quad-Core Processor (2194.63-MHz K8-class CPU)
Origin = "AuthenticAMD" Id = 0x100f53 Family = 0x10 Model = 0x5
Stepping = 3
Features=0x178bfbff
Features2=0x802009
AMD
Features=0xee500800
AMD
Features2=0x837ff
TSC: P-state invariant