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