Re: Thinkpad t460 acpi issues
On 21. 3. 29., Kevin Oberman wrote:
> The best way to support these keys is to use devd to respond to them and
> dispatch to programs that can do what the key should do.
>
> I wanted my new laptop brightness keys to work. pressing them had no
> obvious effect. I created the following file in /etc/devd/:
> notify 10 {
> match "system" "ACPI";
> match "subsystem" "IBM";
> match "notify" "0x10";
> action "/usr/local/sbin/L15-backlight.pl Brighter";
> };
> notify 10 {
> match "system" "ACPI";
> match "subsystem" "IBM";
> match "notify" "0x11";
> action "/usr/local/sbin/L15-backlight.pl Dimmer";
> };
> /*
> notify 10 {
> match "system" "ACPI";
> match "subsystem" "IBM";
> action "logger Notify = $notify";
> };
> */
> and trivial perl script (probably sh or python would be most people's
> choice) to actually do the job:
> #!/usr/local/bin/perl
> use strict;
> use Sys::Syslog;
> if ($#ARGV != 0) {
> print STDERR "usage: L15-backlight.pl (incr|decr)";
> exit 0;
> }
> #openlog("brightness", ,);
> my $new_bright;
> my $notify = $ARGV[0];
> my $curr_bright = `sysctl -n hw.acpi.video.lcd0.brightness`;
> if ($notify eq "Brighter") {$new_bright = ($curr_bright + 4)};
> if ($notify eq "Dimmer") {$new_bright = ($curr_bright - 4)};
> #syslog ("debug", "Notify = $notify, Old = $curr_bright, New = $new_bright
> ");
> `sysctl -n hw.acpi.video.lcd0.brightness=$new_bright`;
For AMD and Intel GPUs, you may use backlight(8) with amdgpukms.ko or
i915kms.ko rather than sysctl(8) with acpi_video.ko.
Jung-uk Kim
> This adjusted the brightness by 5% on each press.You may notice that the
> adjustment is + or - 4, not 5. It turns out that the brightness keys worked
> fine, but only adjusted the brightness by 1%.
>
> Similar devd entries can work for other keys. The final rule and the log
> statement in the script are commented out, but can be used to track down
> which key maps to which event number.
>
> I should thank the person who gave me the technique, but I can't seem to
> find the e-mail. My apologies to him.
>
> Kevin Oberman, Part time kid herder and retired Network Engineer
> E-mail: rkober...@gmail.com
> PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683
>
>
> On Mon, Mar 29, 2021 at 6:16 AM Softwafe Engineer
> wrote:
>
>> Hello.
>> Freebsd 13 rc3
>>
>> I'm trying to enable acpi hotkeys on my thinkpad t460 but
>> unfortunately looks lite it unsupported.
>> I've loaded acpi_ibm and acpi_video but only three hotkeys works (on
>> my laptop it's fn+F(number)).
>>
>> As well I noticed strange behaviour on closing laptop cover. When I do
>> it then laptop starts to increase funspeed and no keys or trackpad
>> reaction after opening. Only reset works (long pressing on power
>> button).
>>
>> Is it possible to add supporting for my laptop?
___
freebsd-acpi@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"
Re: ACPI Error: No handler for Region [ECOR]
On 18. 11. 20., Charlie Li wrote: > Somewhere between r340491 and r340650, probably starting from r340595, > my ThinkPad W550s started spewing these messages repeatedly in the > system log since boot: > > Nov 20 09:35:19 ardmore kernel: ACPI Error: No handler for Region [ECOR] > (0xf80003662300) [EmbeddedControl] (20181031/evregion-288) > Nov 20 09:35:19 ardmore kernel: ACPI Error: Region EmbeddedControl > (ID=3) has no handler (20181031/exfldio-428) > Nov 20 09:35:19 ardmore kernel: ACPI Error: Method parse/execution > failed \_SB.PCI0.LPC.EC.BAT1._BST, AE_NOT_EXIST (20181031/psparse-677) > > As a result, I am now unable to query battery information at the very > least. r340490 is my last built revision with this working. I am pretty sure r340644 caused the regression. https://svnweb.freebsd.org/changeset/base/340644 Jung-uk Kim ___ freebsd-acpi@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-acpi To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"
Re: Temorarily disabling ACPI errors
On 05/04/2018 16:43, Don Whitteker wrote:
> I am trying to temporarily disable my ACPI error messages I am getting on
> my laptop. I've tried disabling ACPI (crashed right at boot), tried
> hw.acpi.osname="Windows 2015" based on documentation and output from
> 'acpidump -td | grep "Windows"'(no change), and even tried
> 'hint.acpi_thermal.0.disabled="1"' since the main issue are the thermal
> sensors. I know these issues need to be addressed and that I can't just
> sweep them under the rug. However I am getting spammed with 4 lines of
> errors every 3-5 seconds. This is making it near impossible to type out
> anything but short commands at the prompt. I can't even open a file in vi
> to try to edit before the spam covers the first 4 lines and makes it
> impossible to read or edit. I would love to tackle this problem and get
> ACPI working (if even only partially) but I can't do tanything with these
> constant error messages.
>
> Is there a way to pipe the error messages to /dev/null? I have done that
> using the find command and similar commands but I don't know how to when
> it's constantly coming from the system.
Are you using head? If so, can you please try the attached patch?
Thanks,
Jung-uk Kim
--- sys/contrib/dev/acpica/components/executer/exconfig.c
+++ sys/contrib/dev/acpica/components/executer/exconfig.c
@@ -615,6 +615,11 @@ AcpiExLoadOp (
return_ACPI_STATUS (Status);
}
+/* Complete the initialization/resolution of package objects */
+
+Status = AcpiNsWalkNamespace (ACPI_TYPE_PACKAGE, ACPI_ROOT_OBJECT,
+ACPI_UINT32_MAX, 0, AcpiNsInitOnePackage, NULL, NULL, NULL);
+
/* Store the DdbHandle into the Target operand */
Status = AcpiExStore (DdbHandle, Target, WalkState);
--- sys/contrib/dev/acpica/components/namespace/nsinit.c
+++ sys/contrib/dev/acpica/components/namespace/nsinit.c
@@ -406,6 +406,61 @@ ErrorExit:
}
+/***
+ *
+ * FUNCTION:AcpiNsInitOnePackage
+ *
+ * PARAMETERS: ObjHandle - Node
+ * Level - Current nesting level
+ * Context - Not used
+ * ReturnValue - Not used
+ *
+ * RETURN: Status
+ *
+ * DESCRIPTION: Callback from AcpiWalkNamespace. Invoked for every package
+ * within the namespace. Used during dynamic load of an SSDT.
+ *
+ **/
+
+ACPI_STATUS
+AcpiNsInitOnePackage (
+ACPI_HANDLE ObjHandle,
+UINT32 Level,
+void*Context,
+void**ReturnValue)
+{
+ACPI_STATUS Status;
+ACPI_OPERAND_OBJECT *ObjDesc;
+ACPI_NAMESPACE_NODE *Node = (ACPI_NAMESPACE_NODE *) ObjHandle;
+
+
+ObjDesc = AcpiNsGetAttachedObject (Node);
+if (!ObjDesc)
+{
+return (AE_OK);
+}
+
+/* Exit if package is already initialized */
+
+if (ObjDesc->Package.Flags & AOPOBJ_DATA_VALID)
+{
+return (AE_OK);
+}
+
+Status = AcpiDsGetPackageArguments (ObjDesc);
+if (ACPI_FAILURE (Status))
+{
+return (AE_OK);
+}
+
+Status = AcpiUtWalkPackageTree (ObjDesc, NULL, AcpiDsInitPackageElement,
+NULL);
+
+ObjDesc->Package.Flags |= AOPOBJ_DATA_VALID;
+return (AE_OK);
+}
+
+
/***
*
* FUNCTION:AcpiNsInitOneObject
--- sys/contrib/dev/acpica/include/acnamesp.h
+++ sys/contrib/dev/acpica/include/acnamesp.h
@@ -204,6 +204,12 @@ ACPI_STATUS
AcpiNsInitializeDevices (
UINT32 Flags);
+ACPI_STATUS
+AcpiNsInitOnePackage (
+ACPI_HANDLE ObjHandle,
+UINT32 Level,
+void*Context,
+void**ReturnValue);
/*
* nsload - Namespace loading
signature.asc
Description: OpenPGP digital signature
Re: ACPI Error on HP ProBook 430 G2
On 01/03/2017 11:22, Hans Petter Selasky wrote: > On 01/03/17 16:26, Moore, Robert wrote: >> Not sure I understand. The fix has been committed, and is part of >> version 20161222. >> >> > > Hi Robert, > > From what I can see that patches have been pushed to the following > branch, vendor-sys/acpica/20161222/, see: > > https://svnweb.freebsd.org/changeset/base/310451 > > But not yet to "master" (12-current) ? > > Is that correct? > > My console has been filling up with messages like this: > >> ACPI Exception: AE_AML_OPERAND_TYPE, While resolving operands for >> [OpcodeName unavailable] (20161117/dswexec-498) >> ACPI Error: Method parse/execution failed >> [\134_SB.PCI0.LPCB.H_EC._Q50] (Node 0xf800047fce40), >> AE_AML_OPERAND_TYPE (20161117/psparse-560) >> acpi_ec0: evaluation of query method _Q50 failed: AE_AML_OPERAND_TYPE > > over the holidays, so I assume that means the previous version of ACPI, > 20161117 which the 20161222 version is supposed to fix. I was AFK for two weeks. I will merge ACPICA 20161222 to FreeBSD head this week when I find some free time. Jung-uk Kim signature.asc Description: OpenPGP digital signature
Re: ACPI userland patches available for review
On 05/20/16 01:30 PM, Don Lewis wrote: > On 20 May, Moore, Robert wrote: >> Is the acpidump the same one that is part of ACPICA? If so, we can >> integrate the change(s). > > Both appear to be part of ACPICA. I would prefer to see these get > integrated upstream. I've uploaded both to my account on freefall. > > <https://people.freebsd.org/~truckman/acpidb.patch> > <https://people.freebsd.org/~truckman/acpidump.patch> No, these two files are FreeBSD-specific. Jung-uk Kim signature.asc Description: OpenPGP digital signature
Re: DSDT/AML/Etc Inspiron 5748
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 03/ 2/16 02:06 PM, Larry Rosenman wrote: > So how do we get to something I can override? Unfortunately, it's not easy. You have to merge DSDT and SSDTs manually. Jung-uk Kim > On March 2, 2016 12:49:57 PM Jung-uk Kim wrote: > > On 03/ 2/16 01:41 PM, Jung-uk Kim wrote: >>>> On 03/ 2/16 01:33 PM, Larry Rosenman wrote: >>>>> On 2016-03-02 12:28, Jung-uk Kim wrote: >>>>>> -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 >>>>>> >>>>>> On 03/ 2/16 01:18 PM, Larry Rosenman wrote: >>>>>>> On 2016-03-02 12:14, Jung-uk Kim wrote: On 03/ 2/16 >>>>>>> 12:25 PM, Larry Rosenman wrote: >>>>>>>>>> Can you give me EXACT command lines to extract >>>>>>>>>> what I need to move the 0x66 stuff out of PS2K? >>>>>>>>>> >>>>>>>>>> Or to get you something to look at? >>>>>>> >>>>>>> It seems Robert wants to see ACPICA acpidump output. >>>>>>> Install sysutils/acpica-tools, do >>>>>>> "/usr/local/bin/acpidump > acpidump.txt" as root, and >>>>>>> give him the output. >>>>>>> >>>>>>>> Done. >>>>>> >>>>>> FYI, usual workflow goes like this with ACPICA tools: >>>>>> >>>>>> /usr/local/bin/acpidump > acpidump.txt >>>>>> /usr/local/bin/acpixtract acpidump.txt >>>>>> /usr/local/bin/iasl -e ssdt* -d dsdt.dat >>>>>> >>>>>> Then, you can modify disassembled dsdt.dsl. Please note >>>>>> our acpidump(8), i.e., /usr/sbin/acpidump, merges all >>>>>> SSDTs with DSDT for historical reasons. >>>>>> >>>>> and how would I compile it back again? >>>> >>>> /usr/local/bin/iasl dsdt.dsl > > BTW, you cannot directly use generated dsdt.aml to override it via > loader(8) because acpi(4) expects merged DSDT+SSDTs in one file. -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQEcBAEBCAAGBQJW1zuSAAoJEHyflib82/FGAGIIAJfEp804C3zySrz98mg+8boC 63VzcGvKsQ9Jr2DpIo+IWwQbQnLeb7IhcgMX9iO0dgGci11Baxr44cYGynUQsi6c R0ezvoSkLxJw+JYYP0LC5Rbd9x96HW9YBYvZm13lz2xrKhD/sc71hk0lZhe9gEYq mj1AWSgfUxXkZ5hLXftNuugXF4NrFsIB5ycrmUGPGpD8FayPG450kn81MmEi9tLy Si1N6zebx8YKjdHg/Z2oBu3On0Q9jZo1wIqX0wcBGei1PA07gNl0AZpZNUfaFoWv 1KBcrB4ipXdKr5CGU9ZpnqXQyiVNgNZh4LqLg3f/Bq9sEfgS3MSp3kpwTKzJ3QU= =XbdV -END PGP SIGNATURE- ___ freebsd-acpi@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-acpi To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"
Re: DSDT/AML/Etc Inspiron 5748
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 03/ 2/16 01:41 PM, Jung-uk Kim wrote: > On 03/ 2/16 01:33 PM, Larry Rosenman wrote: >> On 2016-03-02 12:28, Jung-uk Kim wrote: >>> -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 >>> >>> On 03/ 2/16 01:18 PM, Larry Rosenman wrote: >>>> On 2016-03-02 12:14, Jung-uk Kim wrote: On 03/ 2/16 12:25 >>>> PM, Larry Rosenman wrote: >>>>>>> Can you give me EXACT command lines to extract what I >>>>>>> need to move the 0x66 stuff out of PS2K? >>>>>>> >>>>>>> Or to get you something to look at? >>>> >>>> It seems Robert wants to see ACPICA acpidump output. >>>> Install sysutils/acpica-tools, do "/usr/local/bin/acpidump > >>>> acpidump.txt" as root, and give him the output. >>>> >>>>> Done. >>> >>> FYI, usual workflow goes like this with ACPICA tools: >>> >>> /usr/local/bin/acpidump > acpidump.txt >>> /usr/local/bin/acpixtract acpidump.txt /usr/local/bin/iasl -e >>> ssdt* -d dsdt.dat >>> >>> Then, you can modify disassembled dsdt.dsl. Please note our >>> acpidump(8), i.e., /usr/sbin/acpidump, merges all SSDTs with >>> DSDT for historical reasons. >>> >> and how would I compile it back again? > > /usr/local/bin/iasl dsdt.dsl BTW, you cannot directly use generated dsdt.aml to override it via loader(8) because acpi(4) expects merged DSDT+SSDTs in one file. Jung-uk Kim -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQEcBAEBCAAGBQJW1zXIAAoJEHyflib82/FG99EIAJO4TKd8nk5icPGDBOrpmIE7 ItjUZYwnpa0Xgx9JHuN2Ll6ePsIN0nQI3N6WTVXTx1qKHgXSVdisDSDnQBxDm4cW Kg3n28x/DougO+O9wDSHDxo5FMKG/d/8q4jUbUamBRhEnE7ixYIiauJh431QArVU 9vbzKRdHCegCa0qEzl7rcBzRwuBMyTF36icKWVExNO2e7tq/Znht3eZ+94jKv35m 5G+yEoN1OFCbQf6vL8+24mzRTkTmI6ok6et31F9T1Cr02r1QaGsPbGVZsIVt1Tm6 zURZzHqHWwMq6fTpikoCRfWS7N7Xcr3UNmSQWiIuK+MIiLfKqgLkIVkZeJE0fIg= =fDgl -END PGP SIGNATURE- ___ freebsd-acpi@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-acpi To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"
Re: DSDT/AML/Etc Inspiron 5748
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 03/ 2/16 01:33 PM, Larry Rosenman wrote: > On 2016-03-02 12:28, Jung-uk Kim wrote: >> -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 >> >> On 03/ 2/16 01:18 PM, Larry Rosenman wrote: >>> On 2016-03-02 12:14, Jung-uk Kim wrote: On 03/ 2/16 12:25 PM, >>> Larry Rosenman wrote: >>>>>> Can you give me EXACT command lines to extract what I >>>>>> need to move the 0x66 stuff out of PS2K? >>>>>> >>>>>> Or to get you something to look at? >>> >>> It seems Robert wants to see ACPICA acpidump output. Install >>> sysutils/acpica-tools, do "/usr/local/bin/acpidump > >>> acpidump.txt" as root, and give him the output. >>> >>>> Done. >> >> FYI, usual workflow goes like this with ACPICA tools: >> >> /usr/local/bin/acpidump > acpidump.txt /usr/local/bin/acpixtract >> acpidump.txt /usr/local/bin/iasl -e ssdt* -d dsdt.dat >> >> Then, you can modify disassembled dsdt.dsl. Please note our >> acpidump(8), i.e., /usr/sbin/acpidump, merges all SSDTs with DSDT >> for historical reasons. >> > and how would I compile it back again? /usr/local/bin/iasl dsdt.dsl Jung-uk Kim -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQEcBAEBCAAGBQJW1zO6AAoJEHyflib82/FGxGAH/i5ZHSLiuNDs0BKINwg7h+vY eoj99nfys5MXcsDEaULacn8sxu0a3KAuYS/TumaVnawtfZCv4Xjp8XiywIrCuhNP eyN7lSxHGT/0aBPLcPZWySPux+kKJSXkqEtkEzSiQwFF7RniLYh1rJQyZ9LCTdrO eufsnB6mUO+y4m/Mwugnw/xPdzbBC0t/CKQulYGuOBzDylp8jA2phApOcfXes9m9 kxV9EFPguuad0WiKIykCoBCZI1m6/DnVSIfS3wQAE5vAJ35di6qbT52AOnP/MHGh E/u4H9evSCrexKVfmmqtTQElgklnuABa12LuHYTC0Apa+vtM53MbdsWQg9ftQG4= =KIq8 -END PGP SIGNATURE- ___ freebsd-acpi@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-acpi To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"
Re: DSDT/AML/Etc Inspiron 5748
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 03/ 2/16 01:18 PM, Larry Rosenman wrote: > On 2016-03-02 12:14, Jung-uk Kim wrote: On 03/ 2/16 12:25 PM, Larry > Rosenman wrote: >>>> Can you give me EXACT command lines to extract what I need to >>>> move the 0x66 stuff out of PS2K? >>>> >>>> Or to get you something to look at? > > It seems Robert wants to see ACPICA acpidump output. Install > sysutils/acpica-tools, do "/usr/local/bin/acpidump > acpidump.txt" > as root, and give him the output. > >> Done. FYI, usual workflow goes like this with ACPICA tools: /usr/local/bin/acpidump > acpidump.txt /usr/local/bin/acpixtract acpidump.txt /usr/local/bin/iasl -e ssdt* -d dsdt.dat Then, you can modify disassembled dsdt.dsl. Please note our acpidump(8), i.e., /usr/sbin/acpidump, merges all SSDTs with DSDT for historical reasons. Jung-uk Kim >>>> On Wed, Mar 02, 2016 at 12:18:49PM -0500, Jung-uk Kim wrote: >>>> On 03/ 2/16 12:04 PM, Jung-uk Kim wrote: >>>>>>> On 03/ 2/16 10:11 AM, Moore, Robert wrote: >>>>>>>> This is probably because of external references that >>>>>>>> cannot be resolved. >>>>>>> >>>>>>>> Try : iasl -e ssdt* -d dsdt.dat >>>>>>> >>>>>>> Please note it is /usr/local/bin/iasl (i.e., >>>>>>> sysutils/acpica-tools from the ports tree), not >>>>>>> /usr/sbin/iasl from the base. >>>> >>>> And use /usr/local/bin/acpidump and >>>> /usr/local/bin/acpixtract, not /usr/sbin/acpidump, to get >>>> individual tables. >>>> >>>> Jung-uk Kim >>>> >>>>>>> Jung-uk Kim >>>>>>> >>>>>>>>> -Original Message- From: >>>>>>>>> owner-freebsd-a...@freebsd.org >>>>>>>>> [mailto:owner-freebsd- a...@freebsd.org] On Behalf >>>>>>>>> Of Larry Rosenman Sent: Tuesday, March 01, 2016 >>>>>>>>> 3:57 PM To: freebsd-acpi@freebsd.org Subject: >>>>>>>>> DSDT/AML/Etc Inspiron 5748 >>>>>>>>> >>>>>>>>> I have a Dell Inspiron 5748, and it's DSDT has the >>>>>>>>> mouse (0x66) in the keyboard resources. >>>>>>>>> >>>>>>>>> I was trying to recompile it, but even dumping the >>>>>>>>> DSDT and recompiling it with no changes garners >>>>>>>>> syntax errors from iasl. >>>>>>>>> >>>>>>>>> I've posted the DSDT at: >>>>>>>>> http://www.lerctr.org/~ler/FreeBSD/acpi/my.asl >>>>>>>>> >>>>>>>>> and the errors: >>>>>>>>> http://www.lerctr.org/~ler/FreeBSD/acpi/my.asl.err >>>>>>>>> >>>>>>>>> Can someone help me? >>>>>>>>> >>>>>>>>> System is at: >>>>>>>>> >>>>>>>>> FreeBSD trivet 11.0-CURRENT FreeBSD 11.0-CURRENT >>>>>>>>> #2 r296241: Mon Feb 29 18:02:55 CST 2016 >>>>>>>>> root@trivet:/usr/obj/usr/src/sys/GENERIC amd64 >>>>>>>>> 1100100 -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQEcBAEBCAAGBQJW1zCyAAoJEHyflib82/FGxzUIAI7RHgLPqGj7HPniCjqST4vb b197XsWayhgTY7ij+37yoYdVsmfKLI6e10JG9uGktOJMV/dvkaAiuNOjO0klzYuV DxIXKuwhBdpe2o5S0lZqfhjnpwWOUnJlwVvcbufbhp4VopW1fytkP+3QCsZSB+au aFEJeFEdlpzlq7f2dTkA2hcohmLGFGZCSB4GkS0+FQThdAbmlNynxS0WZuRHj3Fk kaDPVs98xJp3f4WW3qBz4gpcYUCQ01mE0G359vYO9oQjSNQFit9bpQYOIZ9hzJ2X K2TksHb9pYE4AP4ZHVZbbvgMjqg5jZc8tlWyuMxxCfqQTzHKWaL1kqpPgNT/GwM= =UB5a -END PGP SIGNATURE- ___ freebsd-acpi@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-acpi To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"
Re: DSDT/AML/Etc Inspiron 5748
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 03/ 2/16 12:25 PM, Larry Rosenman wrote: > Can you give me EXACT command lines to extract what I need to move > the 0x66 stuff out of PS2K? > > Or to get you something to look at? It seems Robert wants to see ACPICA acpidump output. Install sysutils/acpica-tools, do "/usr/local/bin/acpidump > acpidump.txt" as root, and give him the output. Jung-uk Kim > On Wed, Mar 02, 2016 at 12:18:49PM -0500, Jung-uk Kim wrote: On 03/ > 2/16 12:04 PM, Jung-uk Kim wrote: >>>> On 03/ 2/16 10:11 AM, Moore, Robert wrote: >>>>> This is probably because of external references that cannot >>>>> be resolved. >>>> >>>>> Try : iasl -e ssdt* -d dsdt.dat >>>> >>>> Please note it is /usr/local/bin/iasl (i.e., >>>> sysutils/acpica-tools from the ports tree), not >>>> /usr/sbin/iasl from the base. > > And use /usr/local/bin/acpidump and /usr/local/bin/acpixtract, not > /usr/sbin/acpidump, to get individual tables. > > Jung-uk Kim > >>>> Jung-uk Kim >>>> >>>>>> -Original Message- From: >>>>>> owner-freebsd-a...@freebsd.org [mailto:owner-freebsd- >>>>>> a...@freebsd.org] On Behalf Of Larry Rosenman Sent: >>>>>> Tuesday, March 01, 2016 3:57 PM To: >>>>>> freebsd-acpi@freebsd.org Subject: DSDT/AML/Etc Inspiron >>>>>> 5748 >>>>>> >>>>>> I have a Dell Inspiron 5748, and it's DSDT has the mouse >>>>>> (0x66) in the keyboard resources. >>>>>> >>>>>> I was trying to recompile it, but even dumping the DSDT >>>>>> and recompiling it with no changes garners syntax errors >>>>>> from iasl. >>>>>> >>>>>> I've posted the DSDT at: >>>>>> http://www.lerctr.org/~ler/FreeBSD/acpi/my.asl >>>>>> >>>>>> and the errors: >>>>>> http://www.lerctr.org/~ler/FreeBSD/acpi/my.asl.err >>>>>> >>>>>> Can someone help me? >>>>>> >>>>>> System is at: >>>>>> >>>>>> FreeBSD trivet 11.0-CURRENT FreeBSD 11.0-CURRENT #2 >>>>>> r296241: Mon Feb 29 18:02:55 CST 2016 >>>>>> root@trivet:/usr/obj/usr/src/sys/GENERIC amd64 1100100 -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQEcBAEBCAAGBQJW1y2iAAoJEHyflib82/FGymAH/2e3cCL+RnNGZasIZM4dB9e6 7WUJNX/8YFiy3jwaUrS1xvgBDhSC8fSKvR8Z+QpIVwZPEXaml2JW6qbM4tRWQZcN ZRT5+I+jhIPXhtcZFP3u3RvHEfSbbtFlKuHVGE1/vcTR3IjNXDNMBrTuecKCq8d0 c/gW1leN9eGd3w92/316OQamf7Im1yylW3x5shc6lZt/UPSl148OSzx4bKe+gZVl 8gxyP6XMigdC5FzVyRyEWkTHnTgKPyGCuIJTGfn07mO9axVWQ8/xeqozo8ZRWHTe acJe9JVKmd2IQXDnwZo4AwHfzW74F8mHoEh8qVEg+SUCNwtproVR3k65aERe49w= =5IhQ -END PGP SIGNATURE- ___ freebsd-acpi@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-acpi To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"
Re: DSDT/AML/Etc Inspiron 5748
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 03/ 2/16 12:04 PM, Jung-uk Kim wrote: > On 03/ 2/16 10:11 AM, Moore, Robert wrote: >> This is probably because of external references that cannot be >> resolved. > >> Try : iasl -e ssdt* -d dsdt.dat > > Please note it is /usr/local/bin/iasl (i.e., sysutils/acpica-tools > from the ports tree), not /usr/sbin/iasl from the base. And use /usr/local/bin/acpidump and /usr/local/bin/acpixtract, not /usr/sbin/acpidump, to get individual tables. Jung-uk Kim > Jung-uk Kim > >>> -Original Message- From: owner-freebsd-a...@freebsd.org >>> [mailto:owner-freebsd- a...@freebsd.org] On Behalf Of Larry >>> Rosenman Sent: Tuesday, March 01, 2016 3:57 PM To: >>> freebsd-acpi@freebsd.org Subject: DSDT/AML/Etc Inspiron 5748 >>> >>> I have a Dell Inspiron 5748, and it's DSDT has the mouse (0x66) >>> in the keyboard resources. >>> >>> I was trying to recompile it, but even dumping the DSDT and >>> recompiling it with no changes garners syntax errors from >>> iasl. >>> >>> I've posted the DSDT at: >>> http://www.lerctr.org/~ler/FreeBSD/acpi/my.asl >>> >>> and the errors: >>> http://www.lerctr.org/~ler/FreeBSD/acpi/my.asl.err >>> >>> Can someone help me? >>> >>> System is at: >>> >>> FreeBSD trivet 11.0-CURRENT FreeBSD 11.0-CURRENT #2 r296241: >>> Mon Feb 29 18:02:55 CST 2016 >>> root@trivet:/usr/obj/usr/src/sys/GENERIC amd64 1100100 -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQEcBAEBCAAGBQJW1yBxAAoJEHyflib82/FG1o8IAIaor8YWrcPaBnMAGe/2EMsL Dv1fs+dOIBl9DS4GsPhGuym8/EqOPJyOC5XMNWRJWiQJkI5P+23+KqDMmGC/JrII Qef9kcBchfgu+Zu5Khfb10nunFKmj+jRQMoVVapxKhP4s49hvvCvIKgF9uC3rdB4 VMwsSJB+pyt1Y/Xq6Ik0MqqxddADK2v+cGesOy7KFeXQTAbBfTiP+mGIFXOpGdKg YtMoHC4xIutjb1B1Lmwk5ybOfmyrJnBikAgUr99VDgfWzIcCrRSXx6gabrxIu8jm mo9/gn1NeyHGS+a2UzN7CPwJQIPpLmIKsRvP+jlVUcMQj/axorAEFhBsezFH+bA= =rhTW -END PGP SIGNATURE- ___ freebsd-acpi@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-acpi To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"
Re: DSDT/AML/Etc Inspiron 5748
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 03/ 2/16 10:11 AM, Moore, Robert wrote: > This is probably because of external references that cannot be > resolved. > > Try : iasl -e ssdt* -d dsdt.dat Please note it is /usr/local/bin/iasl (i.e., sysutils/acpica-tools from the ports tree), not /usr/sbin/iasl from the base. Jung-uk Kim >> -Original Message- From: owner-freebsd-a...@freebsd.org >> [mailto:owner-freebsd- a...@freebsd.org] On Behalf Of Larry >> Rosenman Sent: Tuesday, March 01, 2016 3:57 PM To: >> freebsd-acpi@freebsd.org Subject: DSDT/AML/Etc Inspiron 5748 >> >> I have a Dell Inspiron 5748, and it's DSDT has the mouse (0x66) >> in the keyboard resources. >> >> I was trying to recompile it, but even dumping the DSDT and >> recompiling it with no changes garners syntax errors from iasl. >> >> I've posted the DSDT at: >> http://www.lerctr.org/~ler/FreeBSD/acpi/my.asl >> >> and the errors: >> http://www.lerctr.org/~ler/FreeBSD/acpi/my.asl.err >> >> Can someone help me? >> >> System is at: >> >> FreeBSD trivet 11.0-CURRENT FreeBSD 11.0-CURRENT #2 r296241: Mon >> Feb 29 18:02:55 CST 2016 >> root@trivet:/usr/obj/usr/src/sys/GENERIC amd64 1100100 -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQEcBAEBCAAGBQJW1x0YAAoJEHyflib82/FGERAH+wagXCh2KTFmoTB7UfON1r19 6FkMEyZBvJxPG5SPQ/NpUgk/TQvCt7ta911xavVGH5xOgCajPgbjZ1VRJ8Bb6L5h sdgBSZSbfELXSKIlPjUJEOuCnSj2/rFVkxrtC7S09khCEdJrsV5diAx/8I+rCqeC 8+ZIpOqLWrBcHtdzLusAcglxBQdbuLqo1ZKOgAohRQtq/Z7qt1t0c2IqpcsDfM7+ 87cuUAt4XUAqIpff54msm13Dpw8cqm2ujXzA7xT30+8jev75T80qabjH2oK3kdml fXnULEKql+M4eYLvOnIOLbfo8LXK861uqHQVwTjWQzJNm5cMH+H4e2azrW/DpE8= =9HhI -END PGP SIGNATURE- ___ freebsd-acpi@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-acpi To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"
Re: disabling sleep when shutting down
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 09/23/2015 04:28, Colin Percival wrote:
> On 09/22/15 12:13, Jung-uk Kim wrote:
>>> I didn't want to pollute init with arch-dependent hacks.
>>> Anyway, the attached patch should do what you want (not
>>> tested).
>>
>> Or a simpler hack with sysctl(3) instead of ioctl(2).
>
> Right, this is more like what I was thinking. (I can write patches
> myself btw -- I was asking for help with figuring out the right
> solution, not with the coding itself!)
I don't doubt that. In fact, I wanted to save some electrons because
you can read/write patches and "the code speaks for itself". :-)
> A couple things I'm not sure about though:
>> +/* Temporarily block any suspend requests. */ + len =
>> sizeof(blocked); + block = 1; +if
>> (sysctlbyname("debug.acpi.sleep_blocked", &blocked, &len, +
>> &block, sizeof(block)) == -1) + blocked = 0;
>
> Wouldn't it make sense to wrap this in "if (Reboot)"? That way it
> would block suspend for poweroff / halt / reboot, but not for
> dropping to single-user mode.
I think dropping to single user should be protected, too.
Jung-uk Kim
>> +#if defined(__amd64__) || defined(__i386__) + /* Unblock suspend
>> requests. */ + if (!blocked) +
>> sysctlbyname("debug.acpi.sleep_blocked", NULL, NULL, +
>> &blocked, sizeof(blocked)); +#endif +
>
> And if we restrict the blocking to only happen if (Reboot), is
> there any point unblocking suspend when we're about to call
> reboot(2)?
-BEGIN PGP SIGNATURE-
Version: GnuPG v2
iQEcBAEBCAAGBQJWAt6IAAoJEHyflib82/FGoT4H/3eoM/O/Zj80VqT1qBmYiSoa
VFJM/RQ3c0Nvu+a+D0GHoD4G98QFclmqmeQiaSBl6LchgqTPllN3o5l8WTKVisM7
12iFzx5WrfVpdoB8u6l2wMp9YcIvsqPwEAbz+nvaZOHZWpSgjxcjImCoI1nKhHpz
SPF2jkjdTwvPvpDHgfT1GALfDXFPtFGyDZeEin5ntkTm9mJOyxd0v3Jj4iFSRzgc
D1KsTRfIjsygiNHnTvTfuKSOspU4yhlWr+NS3b3hnXpPgOmBhdS8UYjOjVCt03eE
SRfZ9FPqMI8rX8l8AXchxKHpRSkngqGTpUpMdNooqqyNfqGoHwvqQ2nI4NStHsc=
=wzTq
-END PGP SIGNATURE-
___
freebsd-acpi@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"
Re: disabling sleep when shutting down
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
> On 09/20/2015 03:16, Colin Percival wrote:
>> On 09/18/15 11:29, Anthony Jenkins wrote:
>>> Is it possible for /etc/rc.shutdown to complete, but shutdown
>>> not occur? If so, there should be a mechanism to restore the
>>> ability to suspend. Other than that, I like it.
>>
>> Hmm... well, rc.shutdown runs before the system drops into
>> single-user mode. Which makes me think that maybe we should be
>> making the kernel call from inside init instead of from
>> rc.shutdown.
>
> I didn't want to pollute init with arch-dependent hacks. Anyway,
> the attached patch should do what you want (not tested).
Or a simpler hack with sysctl(3) instead of ioctl(2).
Jung-uk Kim
-BEGIN PGP SIGNATURE-
Version: GnuPG v2
iQEcBAEBCAAGBQJWAag9AAoJEHyflib82/FGkmQH/2LM7+pCPkvCq4ljV3UMlLbc
YhvVZYr2k/j6CwjknMC0e4trF9Owgwxstnt+T8HDiGuIO553zUFPDTfgKTredv2x
UHn48KgyBupnmanT1rBmQs9zg1+yVsmUGl4YgNHTaSjDz6qEB9+Jc+OTMssqBYcP
3DujmU2HWD3XDm9M5hCxyAuzh6anolb/Ev2FePezz81D7atJJoc+yF34tm3Y/Fjh
KSybphHzib78qzLsXhz3Tf1LKbdZVBHFobkCTOUovB9bM5YPCT7/8HXSa/TBbvEV
1HLnj9GJX1x5WZIu4ACcsUkmJ2YT/JIwTUcZemw0BvG0usSkZL/G1fdybfgctxk=
=qmkC
-END PGP SIGNATURE-
Index: sbin/init/init.c
===
--- sbin/init/init.c (revision 288123)
+++ sbin/init/init.c (working copy)
@@ -1487,7 +1487,18 @@ static state_func_t
death(void)
{
session_t *sp;
+#if defined(__amd64__) || defined(__i386__)
+ size_t len;
+ int block, blocked;
+ /* Temporarily block any suspend requests. */
+ len = sizeof(blocked);
+ block = 1;
+ if (sysctlbyname("debug.acpi.sleep_blocked", &blocked, &len,
+ &block, sizeof(block)) == -1)
+ blocked = 0;
+#endif
+
/*
* Also revoke the TTY here. Because runshutdown() may reopen
* the TTY whose getty we're killing here, there is no guarantee
@@ -1503,6 +1514,13 @@ death(void)
/* Try to run the rc.shutdown script within a period of time */
runshutdown();
+#if defined(__amd64__) || defined(__i386__)
+ /* Unblock suspend requests. */
+ if (!blocked)
+ sysctlbyname("debug.acpi.sleep_blocked", NULL, NULL,
+ &blocked, sizeof(blocked));
+#endif
+
return (state_func_t) death_single;
}
Index: sys/dev/acpica/acpi.c
===
--- sys/dev/acpica/acpi.c (revision 288123)
+++ sys/dev/acpica/acpi.c (working copy)
@@ -292,6 +292,11 @@ static int acpi_susp_bounce;
SYSCTL_INT(_debug_acpi, OID_AUTO, suspend_bounce, CTLFLAG_RW,
&acpi_susp_bounce, 0, "Don't actually suspend, just test devices.");
+/* Block suspend requests. */
+static int acpi_sleep_blocked;
+SYSCTL_INT(_debug_acpi, OID_AUTO, sleep_blocked, CTLFLAG_RW,
+&acpi_sleep_blocked, 0, "Ignore any sleep requests.");
+
/*
* ACPI can only be loaded as a module by the loader; activating it after
* system bootstrap time is not useful, and can be fatal to the system.
@@ -2574,10 +2579,12 @@ acpi_ReqSleepState(struct acpi_softc *sc, int stat
if (!acpi_sleep_states[state])
return (EOPNOTSUPP);
-/* If a suspend request is already in progress, just return. */
-if (sc->acpi_next_sstate != 0) {
+/*
+ * If a reboot/shutdown/suspend request is already in progress
+ * or suspend is explicitly disabled, just return.
+ */
+if (rebooting || sc->acpi_next_sstate != 0 || acpi_sleep_blocked)
return (0);
-}
/* Wait until sleep is enabled. */
while (sc->acpi_sleep_disabled) {
___
freebsd-acpi@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"
Re: disabling sleep when shutting down
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 09/20/2015 03:16, Colin Percival wrote:
> On 09/18/15 11:29, Anthony Jenkins wrote:
>> Is it possible for /etc/rc.shutdown to complete, but shutdown
>> not occur? If so, there should be a mechanism to restore the
>> ability to suspend. Other than that, I like it.
>
> Hmm... well, rc.shutdown runs before the system drops into
> single-user mode. Which makes me think that maybe we should be
> making the kernel call from inside init instead of from
> rc.shutdown.
I didn't want to pollute init with arch-dependent hacks. Anyway, the
attached patch should do what you want (not tested).
Jung-uk Kim
-BEGIN PGP SIGNATURE-
Version: GnuPG v2
iQEcBAEBCAAGBQJWAZFAAAoJEHyflib82/FGtJEIAIEd52nb4OaB51G4A/ygOvnR
71wooCMDS/6MJBGGptdOl3YEjVpN5rfuTTr+kxZrrvONjyTdxm15/Qp3usvuNpQQ
7dMYckAc8ZjT9tXGfHQIyG8gwhRgaE/jpPY25xKrExG8NfyEXvMzSjIlJprHZgtX
JcqBLXjGKPhrbJbIBYs+7CeFKhKpPKBeiT2hAPtvHh1OfNi/J/3u5sDeEBeHkx05
dFNZ+sjGIAi/2GeEwrT0IFAfkE6+ecvVZUvYcTreYcMjsLAqwGHOG5GCX/RW50xn
yU9Cu2EWM4Rj3Zet9rXsRajnco0s/tX5wc4oMuWVRakjDupkG17oih+PkpIAIKs=
=q9E6
-END PGP SIGNATURE-
Index: sbin/init/init.c
===
--- sbin/init/init.c (revision 288120)
+++ sbin/init/init.c (working copy)
@@ -52,6 +52,10 @@ static const char rcsid[] =
#include
#include
+#if defined(__amd64__) || defined(__i386__)
+#include
+#endif
+
#include
#include
#include
@@ -1480,6 +1484,20 @@ alrm_handler(int sig)
clang = 1;
}
+static void
+block_sleep(int block)
+{
+#if defined(__amd64__) || defined(__i386__)
+ int fd;
+
+ fd = open("/dev/acpi", O_RDWR);
+ if (fd != -1) {
+ ioctl(fd, ACPIIO_BLKSLPSTATE, &block);
+ close(fd);
+ }
+#endif
+}
+
/*
* Bring the system down to single user.
*/
@@ -1488,6 +1506,9 @@ death(void)
{
session_t *sp;
+ /* Temporarily block any suspend requests. */
+ block_sleep(1);
+
/*
* Also revoke the TTY here. Because runshutdown() may reopen
* the TTY whose getty we're killing here, there is no guarantee
@@ -1503,6 +1524,9 @@ death(void)
/* Try to run the rc.shutdown script within a period of time */
runshutdown();
+ /* Unblock suspend requests. */
+ block_sleep(0);
+
return (state_func_t) death_single;
}
Index: sys/dev/acpica/acpi.c
===
--- sys/dev/acpica/acpi.c (revision 288120)
+++ sys/dev/acpica/acpi.c (working copy)
@@ -98,6 +98,9 @@ struct callout acpi_sleep_timer;
/* Bitmap of device quirks. */
int acpi_quirks;
+/* Block suspend requests. */
+static int acpi_sleep_blocked;
+
/* Supported sleep states. */
static BOOLEAN acpi_sleep_states[ACPI_S_STATE_COUNT];
@@ -2574,10 +2577,12 @@ acpi_ReqSleepState(struct acpi_softc *sc, int stat
if (!acpi_sleep_states[state])
return (EOPNOTSUPP);
-/* If a suspend request is already in progress, just return. */
-if (sc->acpi_next_sstate != 0) {
+/*
+ * If a reboot/shutdown/suspend request is already in progress
+ * or suspend is explicitly disabled, just return.
+ */
+if (rebooting || sc->acpi_next_sstate != 0 || acpi_sleep_blocked)
return (0);
-}
/* Wait until sleep is enabled. */
while (sc->acpi_sleep_disabled) {
@@ -3568,6 +3573,9 @@ acpiioctl(struct cdev *dev, u_long cmd, caddr_t ad
error = *(int *)addr;
error = acpi_AckSleepState(sc->acpi_clone, error);
break;
+case ACPIIO_BLKSLPSTATE:
+ acpi_sleep_blocked = *(int *)addr;
+ break;
case ACPIIO_SETSLPSTATE: /* DEPRECATED */
state = *(int *)addr;
if (state < ACPI_STATE_S0 || state > ACPI_S_STATES_MAX)
Index: sys/dev/acpica/acpiio.h
===
--- sys/dev/acpica/acpiio.h (revision 288120)
+++ sys/dev/acpica/acpiio.h (working copy)
@@ -41,6 +41,9 @@
/* Allow suspend to continue (0) or abort it (errno). */
#define ACPIIO_ACKSLPSTATE _IOW('P', 5, int)
+/* Allow suspend request (0) or block it. */
+#define ACPIIO_BLKSLPSTATE _IOW('P', 6, int)
+
struct acpi_battinfo {
int cap;/* percent */
int min;/* remaining time (in minutes) */
Index: usr.sbin/acpi/acpiconf/acpiconf.8
===
--- usr.sbin/acpi/acpiconf/acpiconf.8 (revision 288120)
+++ usr.sbin/acpi/acpiconf/acpiconf.8 (working copy)
@@ -35,6 +35,7 @@
.Nd control ACPI power management
.Sh SYNOPSIS
.Nm
+.Op Fl b Ar block
.Op Fl h
.Op Fl i Ar batt
.Op Fl k Ar ack
@@ -45,7 +46,10 @@ The
utility allows the user control of the ACPI power management
functions.
The following command-line options are recognized:
-.Bl -tag -width ".Fl s Ar type"
+.Bl -tag -width ".Fl b Ar block"
+.It Fl b Ar block
+Block or unblock suspend requests using the argument provided.
+.Sy Most users should not use this option di
Re: disabling sleep when shutting down
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 09/18/2015 14:29, Anthony Jenkins wrote: > On 09/18/2015 01:51 PM, Jung-uk Kim wrote: >> On 09/17/2015 19:12, Colin Percival wrote: > > On 09/17/15 13:31, >> Jung-uk Kim wrote: > >> On 09/16/2015 23:49, > Colin Percival wrote: > >>> I ran into an interesting glitch > recently: I told my laptop to > >>> shut down, then closed the > lid... and it promptly went into S3. > >>> When I opened the lid a > couple days later, it resumed... and > >>> then finished the > shutdown which it had started 2 days > >>> earlier. > >> > >> > Please try the attached patch. > > > No, this doesn't do what I > wanted. It might be a good idea anyway, > > but your patch only > disables suspend once the kernel is trying to > > reboot; what I > want is to disable suspend a bit earlier -- once > > rc.shutdown is > running and the userland is trying to shut down, > > because at > that point unless something breaks horribly we're *about > > to* > tell the kernel to shut down even though we haven't gotten > > > there quite yet. > > Okay. The attached patch is a quick-and-dirty > & untested hack for you. > > Jung-uk Kim > > Is it possible for /etc/rc.shutdown to complete, but shutdown not > occur? If so, there should be a mechanism to restore the ability > to suspend. Other than that, I like it. If something goes wrong, you can manually do "acpiconf -b 0". Jung-uk Kim -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQEcBAEBCAAGBQJV/GIBAAoJEHyflib82/FGL9EH/jLI2o2LX+8TrHY+RzwkWvq7 SEXue/Fh0wkZvwUDerqgguWDB83X3xGkP2huWkcZEQ605br9FgFBnjVu2A1sPSw+ KBh20jiggv3pEd+3uJJGp6v8Mz33HRW7Se1xCajtZhadFgbqXMT5pxXkLjELheZb H2S2b7oStkZoSw89RLGzzX0DsakvbbXUPA4RUV7niCKPR2kSKpDqER/iY1+PGzYN 6M3EnwBNGWCxWYu+j+bMR/YqoK69DdY4RlHSRd08xleLif6LaDjOQpg/Gd22HMMR 6eEPIv96KAZbN25ZV7vmw4x8a1CrU1Glp6Lg0/Kuv0usCPfmeng1gtZZqirEr5c= =jWfB -END PGP SIGNATURE- ___ freebsd-acpi@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-acpi To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"
Re: disabling sleep when shutting down
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 09/17/2015 19:12, Colin Percival wrote:
> On 09/17/15 13:31, Jung-uk Kim wrote:
>> On 09/16/2015 23:49, Colin Percival wrote:
>>> I ran into an interesting glitch recently: I told my laptop to
>>> shut down, then closed the lid... and it promptly went into S3.
>>> When I opened the lid a couple days later, it resumed... and
>>> then finished the shutdown which it had started 2 days
>>> earlier.
>>
>> Please try the attached patch.
>
> No, this doesn't do what I wanted. It might be a good idea anyway,
> but your patch only disables suspend once the kernel is trying to
> reboot; what I want is to disable suspend a bit earlier -- once
> rc.shutdown is running and the userland is trying to shut down,
> because at that point unless something breaks horribly we're *about
> to* tell the kernel to shut down even though we haven't gotten
> there quite yet.
Okay. The attached patch is a quick-and-dirty & untested hack for you.
Jung-uk Kim
-BEGIN PGP SIGNATURE-
Version: GnuPG v2
iQEcBAEBCAAGBQJV/E8NAAoJEHyflib82/FGKB4IAJud2fy+GKB8XLnbKYDv7ftx
WGB3RWXLCRkkSC41YtnVUJUeCWUmXdRpy6DWRQtQQIFvAgV1ZjjZiHQRJzRtKhKW
spPXCUXU9LL7wnYpBWejH9EuH3+xtLLSPxM32eKVRmSgMGUcIse3Q/b2Ztf5yZC5
K0p60jmLvGaXrKgf99tyyX90UUhoJ1bABCVheNuMbf/UuWOJD0AytGDGrKGZckmS
fLm8nPQIYVJIC1Xsu3Av/EfmKgQpNoFGk7pDhQqf5glmC+jgzp4KElo7KA9ekq43
ybBusp8tfjY0LVRCoMB+K35KWku9puYLeBDm/2PygzOXOIzfkBC2F4dpfmDI3vY=
=unIE
-END PGP SIGNATURE-
Index: etc/rc.shutdown
===
--- etc/rc.shutdown (revision 287937)
+++ etc/rc.shutdown (working copy)
@@ -43,6 +43,9 @@ HOME=/
PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin
export HOME PATH
+# Temporarily block any suspend requests.
+acpiconf -b 1 >/dev/null 2>&1
+
. /etc/rc.subr
load_rc_config 'XXX'
@@ -109,5 +112,8 @@ fi
# Insert other shutdown procedures here
+# Unblock suspend requests.
+acpiconf -b 0 >/dev/null 2>&1
+
echo '.'
exit 0
Index: sys/dev/acpica/acpi.c
===
--- sys/dev/acpica/acpi.c (revision 287937)
+++ sys/dev/acpica/acpi.c (working copy)
@@ -98,6 +98,9 @@ struct callout acpi_sleep_timer;
/* Bitmap of device quirks. */
int acpi_quirks;
+/* Block suspend requests. */
+static int acpi_sleep_blocked;
+
/* Supported sleep states. */
static BOOLEAN acpi_sleep_states[ACPI_S_STATE_COUNT];
@@ -2574,10 +2577,12 @@ acpi_ReqSleepState(struct acpi_softc *sc, int stat
if (!acpi_sleep_states[state])
return (EOPNOTSUPP);
-/* If a suspend request is already in progress, just return. */
-if (sc->acpi_next_sstate != 0) {
+/*
+ * If a reboot/shutdown/suspend request is already in progress
+ * or suspend is explicitly disabled, just return.
+ */
+if (rebooting || sc->acpi_next_sstate != 0 || acpi_sleep_blocked)
return (0);
-}
/* Wait until sleep is enabled. */
while (sc->acpi_sleep_disabled) {
@@ -3568,6 +3573,9 @@ acpiioctl(struct cdev *dev, u_long cmd, caddr_t ad
error = *(int *)addr;
error = acpi_AckSleepState(sc->acpi_clone, error);
break;
+case ACPIIO_BLKSLPSTATE:
+ acpi_sleep_blocked = *(int *)addr;
+ break;
case ACPIIO_SETSLPSTATE: /* DEPRECATED */
state = *(int *)addr;
if (state < ACPI_STATE_S0 || state > ACPI_S_STATES_MAX)
Index: sys/dev/acpica/acpiio.h
===
--- sys/dev/acpica/acpiio.h (revision 287937)
+++ sys/dev/acpica/acpiio.h (working copy)
@@ -41,6 +41,9 @@
/* Allow suspend to continue (0) or abort it (errno). */
#define ACPIIO_ACKSLPSTATE _IOW('P', 5, int)
+/* Allow suspend request (0) or block it. */
+#define ACPIIO_BLKSLPSTATE _IOW('P', 6, int)
+
struct acpi_battinfo {
int cap;/* percent */
int min;/* remaining time (in minutes) */
Index: usr.sbin/acpi/acpiconf/acpiconf.8
===
--- usr.sbin/acpi/acpiconf/acpiconf.8 (revision 287937)
+++ usr.sbin/acpi/acpiconf/acpiconf.8 (working copy)
@@ -27,7 +27,7 @@
.\"
.\" $FreeBSD$
.\"
-.Dd June 10, 2014
+.Dd September 18, 2015
.Dt ACPICONF 8
.Os
.Sh NAME
@@ -35,6 +35,7 @@
.Nd control ACPI power management
.Sh SYNOPSIS
.Nm
+.Op Fl b Ar block
.Op Fl h
.Op Fl i Ar batt
.Op Fl k Ar ack
@@ -45,7 +46,10 @@ The
utility allows the user control of the ACPI power management
functions.
The following command-line options are recognized:
-.Bl -tag -width ".Fl s Ar type"
+.Bl -tag -width ".Fl b Ar block"
+.It Fl b Ar block
+Block or unblock suspend requests using the argument provided.
+.Sy Most users should not use this option directly.
.It Fl h
Displays a summary of available options.
.It Fl i Ar batt
Inde
Re: disabling sleep when shutting down
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 09/16/2015 23:49, Colin Percival wrote:
> Hi ACPI people,
>
> I ran into an interesting glitch recently: I told my laptop to shut
> down, then closed the lid... and it promptly went into S3. When I
> opened the lid a couple days later, it resumed... and then finished
> the shutdown which it had started 2 days earlier. Meanwhile with
> two days of sitting in S3 instead of S5, the battery had almost
> completely drained.
>
> The obvious answer here is to disable Suspend if we're in the
> shutdown path. My first thought was to make rc.suspend slightly
> smarter, but that isn't good enough since there's a 10 second
> timeout after which the suspend will happen even if rc.suspend
> doesn't send the expected acknowledgment. So I think we need to
> get the kernel ACPI bits to disable Suspend.
>
> It looks to me like adding a sysctl to dev/acpica/acpi.c and
> checking it in acpi_ReqSleepState would work; then we just need a
> line in /etc/rc.shutdown to set the sysctl. But ACPI code scares
> me, so I figured I should check with you guys first... am I missing
> anything?
Please try the attached patch.
Jung-uk Kim
-BEGIN PGP SIGNATURE-
Version: GnuPG v2
iQEcBAEBCAAGBQJV+yM4AAoJEHyflib82/FGxSUH/3Aw2bk+fDxyLIZHxidyxDRo
jbNwkm8CIPGOOshQy8R/nMULPnCoVkLAuXA9O7rNK4G+PB96FoHHUEp/UoDnZfDF
exINmGs6DM0scx2ioVtXM50+lC1SzMfFtb5VaS5t7lAyLwYFtE2bQaUWINethUW7
WpsJ5eyyyoMwTTnRxIQcaYC9I+8oqjC4W6KOO1VeTxaj8kvnacYtCxoXbEU7NHHX
9IprjpopHz9tNlTWuh+gX2SsgaRD7PhWSAekNcN1okYa6Jj1QGAiBIsNvc0GLmUZ
hYv4GIPjxG1ZwYfu9HDCXp8Yiz3i44GIpC6EKuO2y0WO36DTM4vUYKK0OFjNdbw=
=PVmk
-END PGP SIGNATURE-
Index: sys/dev/acpica/acpi.c
===
--- sys/dev/acpica/acpi.c (revision 287922)
+++ sys/dev/acpica/acpi.c (working copy)
@@ -2574,10 +2574,9 @@ acpi_ReqSleepState(struct acpi_softc *sc, int stat
if (!acpi_sleep_states[state])
return (EOPNOTSUPP);
-/* If a suspend request is already in progress, just return. */
-if (sc->acpi_next_sstate != 0) {
+/* If a reboot or suspend request is already in progress, just return. */
+if (rebooting || sc->acpi_next_sstate != 0)
return (0);
-}
/* Wait until sleep is enabled. */
while (sc->acpi_sleep_disabled) {
___
freebsd-acpi@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"
Re: acpi suspend debugging techniques?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 09/03/2015 18:30, David Wolfskill wrote: > [Much trimming, both of older content and recipient addresses -- > dhw] > > On Thu, Sep 03, 2015 at 06:18:52PM -0400, Jung-uk Kim wrote: >> ... AFAICT, the whole suspend/resume code looks incomplete and >> very messy. In fact, I'll be very surprised if it ever worked. >> :-( >> >> Jung-uk Kim ... > > While I bow to your expertise in the area, I point out that I > routinely suspend my laptop before putting it in my backpack, then > cycling between the shuttle stop and my house during my daily > commutes to & from work -- usually running stable/10, but I'm > sometimes running head at the time. > > And I track both stable/10 and head daily on that laptop (in > different slices). > > While I do encounter "issues" from time to time, those are rare > enough that I'd call them "unusual." (To quantify that, I think > I've had 3 - 5 such incidents since November 2014, while generally > commuting 5 days/week.) > > I'll be happy to test. :-) I am not saying the patch is wrong. Actually, it is in the right direction. If you can, please test the following patch, too. - --- sys/dev/drm2/radeon/radeon_drv.c (revision 287437) +++ sys/dev/drm2/radeon/radeon_drv.c(working copy) @@ -327,14 +327,14 @@ radeon_suspend(device_t kdev) struct drm_device *dev; int ret; + ret = bus_generic_suspend(kdev); + if (ret) + return (ret); + dev = device_get_softc(kdev); ret = radeon_suspend_kms(dev); - - if (ret) - - return (-ret); - - ret = bus_generic_suspend(kdev); - - - - return (ret); + return (-ret); } static int Jung-uk Kim -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQEcBAEBCAAGBQJV6M6cAAoJEHyflib82/FGX1UH/0BaQl+/e7Cqc2+3jdcmuusd P8gJBGIFu89+6KsA2J1btQQYO2wwA9tJkpkZx4oi/pT+L+pIqZGx7/w7klsfXvXd gfI0looWxzB5ZALCrzYq50Nk67E9s6iXymRMJ95oyZ2GLkbwLqY6gOStqld7vBuE Z4iEBYHMrDtojd33w/9SRa8zNSpvwXZJliNjhpFd680ApkSO2xN/dIxI/z1JjlEw oquRpvFlR4urqCdhYmKyjoXuR7rYdl0K2imfA7EjL2RFzlFyacS+ny4BqnbvMqzC tMNxYFUOEvxMW+336DKZjiRWgAyfmJiOuoFxRoDiCq42zzjcLF+2gnLlcd4/j+4= =/r95 -END PGP SIGNATURE- ___ freebsd-acpi@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-acpi To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"
Re: acpi suspend debugging techniques?
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 09/03/2015 13:50, Andriy Gapon wrote:
> On 31/08/2015 11:53, Adrian Chadd wrote:
>> Try disabling hardware one at a time. Ie, unload usb; unload
>> wifi; leave kms loaded for mostly obvious reasons.
>
> Adrian, Garrett,
>
> thank you very much for your tips. Turned out that it was radeonkms
> that was causing the problem :-)
>
> BTW, here is another tool for the toolkit: on sufficiently recent
> system devctl suspend and devctl resume can be used to test
> individual drivers.
>
> So, I noticed that I could suspend/resume drmn0 device just fine
> but with vgapci0 I had a trouble suspending. One thing led to
> another and here is a patch that seems to fix the problem for me:
> --
- -
>
>
commit fecb5e8a90631f06600d87165cc8b6de3e035dfc
> Author: Andriy Gapon Date: Thu Sep 3 17:24:23
> 2015 +0300
>
> radeon_suspend_kms: don't mess with pci state that's managed by the
> bus
>
> The pci bus driver handles the power state and configuration state
> saving and restoring for its child devices.
>
> diff --git a/sys/dev/drm2/radeon/radeon_device.c
> b/sys/dev/drm2/radeon/radeon_device.c index
> e5c676b11ed47..73b2f4c51ada2 100644 ---
> a/sys/dev/drm2/radeon/radeon_device.c +++
> b/sys/dev/drm2/radeon/radeon_device.c @@ -1342,14 +1342,10 @@ int
> radeon_suspend_kms(struct drm_device *dev)
>
> radeon_agp_suspend(rdev);
>
> - pci_save_state(device_get_parent(dev->dev)); #ifdef FREEBSD_WIP
> if (state.event == PM_EVENT_SUSPEND) { /* Shut down the device */
> pci_disable_device(dev->pdev); -#endif /* FREEBSD_WIP */ -
> pci_set_powerstate(dev->dev, PCI_POWERSTATE_D3); -#ifdef
> FREEBSD_WIP } console_lock(); #endif /* FREEBSD_WIP */ @@ -1380,10
> +1376,6 @@ int radeon_resume_kms(struct drm_device *dev)
>
> #ifdef FREEBSD_WIP console_lock(); -#endif /* FREEBSD_WIP */ -
> pci_set_powerstate(device_get_parent(dev->dev),
> PCI_POWERSTATE_D0); -
> pci_restore_state(device_get_parent(dev->dev)); -#ifdef
> FREEBSD_WIP if (pci_enable_device(dev->pdev)) { console_unlock();
> return -1;
> --
- -
>
> However, I am not sure about an exact mechanism of the hard system
> hang that I experienced without the patch.
>
> BTW, I noticed that only very few drivers make explicit calls to
> pci_set_powerstate and pci_save_state/pci_restore_state.
> sys/dev/usb/controller/ohci_pci.c looks like a good use of
> pci_set_powerstate. sys/dev/ixgbe/if_ix.c looks like an incorrect /
> redundant use of the functions.
AFAICT, the whole suspend/resume code looks incomplete and very messy.
In fact, I'll be very surprised if it ever worked. :-(
Jung-uk Kim
-BEGIN PGP SIGNATURE-
Version: GnuPG v2
iQEcBAEBCAAGBQJV6MdGAAoJEHyflib82/FGJ68H/2W6IfhDrtciL2LmA67T0VHU
Nagp1Oghp+JDw/iVB28Sxf/EXptsZKUeKvSYYilIFHsl/d/+uPvhbaxLVWUSyhGe
C5vVCbSkyRwnz3I5iiMab9Ou+VFTVqHhNLgrCFfDvjeHssbIkD7+bEuldWyqOIFH
rvvvZ8qGebVV7jcfU3lVVUz3tNwLwgdtVPuZIohxc8M7n1pE185hnUa1b37pytC9
btrCYLstGRNBbaD530iMN0bXM02aWgUTbf9cVH31nYduQaYOPYe/JgNKLzbmJ0gL
JIhGh4eubyR4W2SonRsg1ahHHzSr1pe1o7TVuU+2G1fycz4GSLoFWzYnSTxDMc4=
=IAfV
-END PGP SIGNATURE-
___
freebsd-acpi@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"
Re: [PATCH] ACPI CMOS region support rev. 5
-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-
___
freebsd-acpi@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"
Re: [PATCH] ACPI CMOS region support rev. 5
-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- ___ freebsd-acpi@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-acpi To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"
Re: Haswell, i3, fail to acpi_throttle fail
On 01/06/2015 17:08, Sean Bruno wrote: > On 01/06/15 13:41, Jung-uk Kim wrote: >> On 01/05/2015 22:57, Kevin Oberman wrote: >>> On Mon, Jan 5, 2015 at 4:56 PM, Sean Bruno >>> wrote: >>> >>>> >>>> -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 >>>> >>>> acpi_throttle0: on cpu0 acpi_throttle0: >>>> P_CNT from P_BLK 0x1810 est0: >>> Control> on cpu0 acpi_throttle1: on >>>> cpu1 acpi_throttle1: failed to attach P_CNT device_attach: >>>> acpi_throttle1 attach returned 6 est1: >>> Frequency Control> on cpu1 acpi_throttle2: >>> Throttling> on cpu2 acpi_throttle2: failed to attach P_CNT >>>> device_attach: acpi_throttle2 attach returned 6 est2: >>>> on cpu2 >>>> acpi_throttle3: on cpu3 acpi_throttle3: >>>> failed to attach P_CNT device_attach: acpi_throttle3 attach >>>> returned 6 est3: on >>>> cpu3 >>>> >>>> >>>> The call to acpi_bus_alloc_gas() in acpi_throttle.c seems to >>>> be failing to attach. What should I be poking at here? >>>> >>> >>> Excellent! Throttling is counter-productive and always has >>> been. It's been at least 5 years since mav@ posted his >>> excellent wiki article on power management which demonstrated >>> the futility of throttling. More important, even if it was >>> useful for power management, it has long since been superseded >>> by TCC. Intel tried to make the purpose of TCC clear by the >>> name: Thermal Control Circuit. So it is ineffective for power >>> management and FreeBSD still tries to use it. Looks like the >>> vendor broke ACPI so throttling won't work. Or, maybe, Intel >>> simply removed it as unused legacy. >>> >>> Don't worry. Be happy! Make sure that >>> hint.acpi_throttle.0.disabled=1 is set in /boot/loader.conf to >>> disable it. I'd strongly urge that you also disable P4TCC with >>> hint.p4tcc.0.disabled=1. It will trivially improve battery >>> life and will seriously compromise performance if powerd is >>> enabled. It can also cause hangs with elevated C-states on some >>> systems. > >> FYI, acpi_throttle and tcc have been disabled by default for a >> while. > >> https://svnweb.freebsd.org/changeset/base/265329 > >> I guess Nathan forgot to MFC this commit? > >> Jung-uk Kim > > Well, I'm running -current. I don't know, for my case, that an MFC > is correct. Is it a bug that this stuff is appearing at all? I think you need to merge the file to /boot/device.hints manually. Jung-uk Kim ___ freebsd-acpi@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-acpi To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"
Re: Haswell, i3, fail to acpi_throttle fail
On 01/05/2015 22:57, Kevin Oberman wrote: > On Mon, Jan 5, 2015 at 4:56 PM, Sean Bruno > wrote: > >> >> -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 >> >> acpi_throttle0: on cpu0 acpi_throttle0: >> P_CNT from P_BLK 0x1810 est0: > Control> on cpu0 acpi_throttle1: on cpu1 >> acpi_throttle1: failed to attach P_CNT device_attach: >> acpi_throttle1 attach returned 6 est1: > Frequency Control> on cpu1 acpi_throttle2: >> on cpu2 acpi_throttle2: failed to attach P_CNT device_attach: >> acpi_throttle2 attach returned 6 est2: > Frequency Control> on cpu2 acpi_throttle3: >> on cpu3 acpi_throttle3: failed to attach P_CNT device_attach: >> acpi_throttle3 attach returned 6 est3: > Frequency Control> on cpu3 >> >> >> The call to acpi_bus_alloc_gas() in acpi_throttle.c seems to be >> failing to attach. What should I be poking at here? >> > > Excellent! Throttling is counter-productive and always has been. > It's been at least 5 years since mav@ posted his excellent wiki > article on power management which demonstrated the futility of > throttling. More important, even if it was useful for power > management, it has long since been superseded by TCC. Intel tried > to make the purpose of TCC clear by the name: Thermal Control > Circuit. So it is ineffective for power management and FreeBSD > still tries to use it. Looks like the vendor broke ACPI so > throttling won't work. Or, maybe, Intel simply removed it as > unused legacy. > > Don't worry. Be happy! Make sure that > hint.acpi_throttle.0.disabled=1 is set in /boot/loader.conf to > disable it. I'd strongly urge that you also disable P4TCC with > hint.p4tcc.0.disabled=1. It will trivially improve battery life > and will seriously compromise performance if powerd is enabled. It > can also cause hangs with elevated C-states on some systems. FYI, acpi_throttle and tcc have been disabled by default for a while. https://svnweb.freebsd.org/changeset/base/265329 I guess Nathan forgot to MFC this commit? Jung-uk Kim ___ freebsd-acpi@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-acpi To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"
Re: [PATCH] Naive implementation of AcpiExCmosSpaceHandler()
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2014-06-06 19:33:13 -0400, Adrian Chadd wrote: > Hi! > > Would you mind throwing this into a bugzilla report? > > https://bugs.freebsd.org/bugzilla/ > > That way it won't get lost? > > Let me know what number it is and I'll chase it down and get it > into -HEAD. ... Actually, it is a patch for upstream to review. https://bugs.acpica.org https://lists.acpica.org/mailman/listinfo https://github.com/acpica/acpica Jung-uk Kim -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQEcBAEBAgAGBQJTkldRAAoJEHyflib82/FGnoEH/A2t0nFfkIHSEPICxvuQKucB D1sG3oQjn4tScyL7Izy4mhGLev7b0zw0u8g1GbAkva8lrr/NSUOgBS5aS/o+LMLE 6gddnOGlpq5BZCBsddpSpKqSIahQarzDHlqhd4mhF9dox+D4XsZ8IfiVIteEjXyc K/UscdtBHc2SKLRWpbBzm3eS2SRB0R6fRoUkPcZ1MW6y0Np95zUwsa/Ok8vemwyP /X5u33Q2OdTSwlhQBE7hR3iszEebpvS0+cBUKcM6PFV8RZLlZXMOxdkTyx6o+nxq 5rHsoCZWOn9/yLYxs0NetoLZrm00/nq2LcMTBAE1qJZWfXxKmZ1BSAp7SKZ8zes= =ZRDm -END PGP SIGNATURE- ___ freebsd-acpi@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-acpi To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"
Re: Investigating failed suspend/resume T61
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 2014-05-28 18:14:34 -0400, Jung-uk Kim wrote:
> However, it had to be done from AcpiEvGpeInitialize() in
> sys/contrib/dev/acpica/components/events/evgpeinit.c, IMHO.
>
> ACPI_STATUS AcpiEvGpeInitialize ( void) { ... if
> (AcpiGbl_FADT.Gpe1BlockLength &&
> HERE!!! AcpiGbl_FADT.XGpe1Block.Address) { ...
Please see the attached patch (not tested). Probably, this is what
you really meant to test.
Jung-uk Kim
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (FreeBSD)
iQEcBAEBAgAGBQJThnPaAAoJEHyflib82/FGKbcIAIfNGtaEDNhEuGUTTr7wSgCE
DIAIt/QdTeICyOiR8t9r8SrOKrnrloPohKTqtujhkliiAN7bKbjodeN3+/50H7a9
Ura6075gCtds/6Im/hOiFMyclWBA88HR+lUpct3RJD9Ag70qcfEQloIiVI1pkm2U
X1YRRgS0liUbG4NKoZuAl2xPxyO+DS+jC7FKO/Ti4Bl4buM+R/lO0fvAj6ZZoRQ4
JnLGsOPMrmPLDfug6dZSCruG8rcetrh+0PYVn3En4ecZ8rzsY+IW5qR+57+8rcXX
Jh9JsWyS0eYiGP62yOKzdj+9GSH85MJJC0fvtOgYe42eA8UU3bf8GAD5Vynl+gU=
=4thP
-END PGP SIGNATURE-
Index: sys/contrib/dev/acpica/components/events/evgpeinit.c
===
--- sys/contrib/dev/acpica/components/events/evgpeinit.c (리비전 266821)
+++ sys/contrib/dev/acpica/components/events/evgpeinit.c (작업 사본)
@@ -128,12 +128,19 @@ AcpiEvGpeInitialize (
* If EITHER the register length OR the block address are zero, then that
* particular block is not supported.
*/
-if (AcpiGbl_FADT.Gpe0BlockLength &&
-AcpiGbl_FADT.XGpe0Block.Address)
+if ((AcpiGbl_FADT.Gpe0Block && AcpiGbl_FADT.Gpe0BlockLength) ||
+(AcpiGbl_FADT.XGpe0Block.Address && AcpiGbl_FADT.XGpe0Block.BitWidth))
{
/* GPE block 0 exists (has both length and address > 0) */
-RegisterCount0 = (UINT16) (AcpiGbl_FADT.Gpe0BlockLength / 2);
+if (AcpiGbl_FADT.XGpe0Block.Address && AcpiGbl_FADT.XGpe0Block.BitWidth)
+{
+RegisterCount0 = ACPI_DIV_8 (AcpiGbl_FADT.XGpe0Block.BitWidth) / 2;
+}
+else
+{
+RegisterCount0 = AcpiGbl_FADT.Gpe0BlockLength / 2;
+}
GpeNumberMax = (RegisterCount0 * ACPI_GPE_REGISTER_WIDTH) - 1;
/* Install GPE Block 0 */
@@ -149,12 +156,19 @@ AcpiEvGpeInitialize (
}
}
-if (AcpiGbl_FADT.Gpe1BlockLength &&
-AcpiGbl_FADT.XGpe1Block.Address)
+if ((AcpiGbl_FADT.Gpe1Block && AcpiGbl_FADT.Gpe1BlockLength) ||
+(AcpiGbl_FADT.XGpe1Block.Address && AcpiGbl_FADT.XGpe1Block.BitWidth))
{
/* GPE block 1 exists (has both length and address > 0) */
-RegisterCount1 = (UINT16) (AcpiGbl_FADT.Gpe1BlockLength / 2);
+if (AcpiGbl_FADT.XGpe1Block.Address && AcpiGbl_FADT.XGpe1Block.BitWidth)
+{
+RegisterCount1 = ACPI_DIV_8 (AcpiGbl_FADT.XGpe1Block.BitWidth) / 2;
+}
+else
+{
+RegisterCount1 = AcpiGbl_FADT.Gpe1BlockLength / 2;
+}
/* Check for GPE0/GPE1 overlap (if both banks exist) */
___
freebsd-acpi@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"
Re: Investigating failed suspend/resume T61
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2014-05-28 17:29:35 -0400, John Baldwin wrote: > Err, I think it enables GPE1 as otherwise ACPICA assumes GPE1 has a > length of zero (and is thus invalid)? BTW, ACPI 5.0a (page 121) says: "This is an optional field; if this register block is not supported, this field contains zero." Therefore, we must assume X_GPE1_BLK it is NOT supported. Jung-uk Kim -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (FreeBSD) iQEcBAEBAgAGBQJThmauAAoJEHyflib82/FG0rUIAJdLFd+Bd5KXF5nzSX9maVS2 71h9iM5oJE6WjLdMAt7nD2p1seiicVYkxm+jLU08EegkV9QH3506wt8KOXxtvIMG XNuLzTB7cukqYoMXfsrA2ojis4YDGADhAwuT6UpsJq8iblwiA4Ec9pvfli4l/RwU UObGkQIbKJ1BLspFHFClbXrqBqCp5Ou6s8Aga0AsqR4BIqgpnrtV+LQEmPIiUCRh W3PLu+/VHmBvTaU7YhUhmsN0BDC1CXhGwi6w614uHWB9GBym7xIuFjjREMoLPX2D cL9gidZBj0TAtPj2oe/geYRb3Ta47Migo/FAkkpp5hqd9/xrr9CImK9f37yzqzU= =Yxlz -END PGP SIGNATURE- ___ freebsd-acpi@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-acpi To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"
Re: Investigating failed suspend/resume T61
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 2014-05-28 18:14:34 -0400, Jung-uk Kim wrote:
> On 2014-05-28 17:29:35 -0400, John Baldwin wrote:
>> Err, I think it enables GPE1 as otherwise ACPICA assumes GPE1 has
>> a length of zero (and is thus invalid)? Perhaps _PTS wants to
>> frob something that uses GPE1 that this fixes?
>
> static void AcpiTbValidateFadt ( void) { ... UINT8
> Length; ... for (i = 0; i < ACPI_FADT_INFO_ENTRIES; i++) { ...
> Length = *ACPI_ADD_PTR (UINT8, &AcpiGbl_FADT,
> FadtInfoTable[i].Length); ...
>
> Note the Length is read from the internal FADT and it is NOT a
> pointer.
>
> ... if (Address64->Address && (ACPI_MUL_8 (Length) <=
> ACPI_UINT8_MAX) && (Address64->BitWidth != ACPI_MUL_8 (Length))) {
> ACPI_BIOS_WARNING ((AE_INFO, "32/64X length mismatch in FADT/%s:
> %u/%u", Name, ACPI_MUL_8 (Length), Address64->BitWidth)); + if
> (Length == 0) + { + Length = ACPI_DIV_8
> (Address64->BitWidth); + } } ... } }
>
> AFAICT, it does change anything in AcpiGbl_FADT. ...
^
not
Sorry for the typo.
Jung-uk Kim
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (FreeBSD)
iQEcBAEBAgAGBQJThmG3AAoJEHyflib82/FGlGEIAIZBOaLiQSpFT8ziuK8vPP7s
WwI69o7tYzso16pbBjtaCV7eSD2uku+inSqNigmnp+FwvZGr4wxTOQSYMLSht9kw
CkiEjZ2wN4xA5rTCfvZzHlUgnVk4M9DAXjILiZ5W6+aURo5xRwkFNjVVQXPh2JXn
/JwmP7yJrRyVcm3KGKTR1c3rqoBzps3RP9RSz7I2bPZwzRfBTTTgiuuAjDy3LdUf
ozz6zGkknTGg/tPSATZULPWrzhfVWjfzwsTO3MbzQwynXtjVa0nmAO0Ug0iBiB0g
9ls1TdH/JSwaMMG3/8QlIkMp95jD5aTtpT2x1I78iWbptEX5N4pJ7uQctsFn09o=
=j9xm
-END PGP SIGNATURE-
___
freebsd-acpi@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"
Re: Investigating failed suspend/resume T61
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 2014-05-28 17:29:35 -0400, John Baldwin wrote:
> Err, I think it enables GPE1 as otherwise ACPICA assumes GPE1 has a
> length of zero (and is thus invalid)? Perhaps _PTS wants to frob
> something that uses GPE1 that this fixes?
static void
AcpiTbValidateFadt (
void)
{
...
UINT8 Length;
...
for (i = 0; i < ACPI_FADT_INFO_ENTRIES; i++)
{
...
Length = *ACPI_ADD_PTR (UINT8,
&AcpiGbl_FADT, FadtInfoTable[i].Length);
...
Note the Length is read from the internal FADT and it is NOT a pointer.
...
if (Address64->Address &&
(ACPI_MUL_8 (Length) <= ACPI_UINT8_MAX) &&
(Address64->BitWidth != ACPI_MUL_8 (Length)))
{
ACPI_BIOS_WARNING ((AE_INFO,
"32/64X length mismatch in FADT/%s: %u/%u",
Name, ACPI_MUL_8 (Length), Address64->BitWidth));
+ if (Length == 0)
+ {
+ Length = ACPI_DIV_8 (Address64->BitWidth);
+ }
}
...
}
}
AFAICT, it does change anything in AcpiGbl_FADT. If you really wanted
to "patch" it, you had to do something like this:
+ if (Length == 0)
+ {
+ Length = ACPI_DIV_8 (Address64->BitWidth);
+ *ACPI_ADD_PTR (UINT8,
+ &AcpiGbl_FADT, FadtInfoTable[i].Length) = Length;
+ }
However, it had to be done from AcpiEvGpeInitialize() in
sys/contrib/dev/acpica/components/events/evgpeinit.c, IMHO.
ACPI_STATUS
AcpiEvGpeInitialize (
void)
{
...
if (AcpiGbl_FADT.Gpe1BlockLength &&
HERE!!!
AcpiGbl_FADT.XGpe1Block.Address)
{
...
What did I miss?
Jung-uk Kim
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (FreeBSD)
iQEcBAEBAgAGBQJThl/KAAoJEHyflib82/FGessH+gOcPzgbg8/kPbpkHl6y6n1n
1vMgky6TB1v5ul48YEtnHQybK0pFm/9UVaxOnJFEAKmDzVyr739xFnveht3g1otQ
LLM0vDh6dLNV2qlmLSVNQQm3Fsvu0NdF737dsSNyksi6vvKAjb7o45nn1UmkQmv/
lqNjSEaSuW8dLR9xuvvQvUUFgxGyGM3UuAk7tHOF7PQo/EwRvbkc2W0cOfRLPXqP
Se+B/8kggxSoV+yj/kHdoYm5wb/dsVfudkh7grKtm/C2iH/PqAhnYDLWEfbSZbpz
Vy3C+r4/uz4I3CaV7Txz13plbYqIJ1oo3sdUxUdLH+SfbaY16+adHJZFfagVyOU=
=n4SF
-END PGP SIGNATURE-
___
freebsd-acpi@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"
Re: Investigating failed suspend/resume T61
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2014-05-28 15:56:37 -0400, John Baldwin wrote: > On Wednesday, May 28, 2014 2:16:03 pm Jung-uk Kim wrote: >> On 2014-05-28 13:44:46 -0400, John Baldwin wrote: >>> On Wednesday, May 28, 2014 12:44:44 pm Jung-uk Kim wrote: >>>> On 2014-05-28 12:20:24 -0400, John Baldwin wrote: >>>>> On Wednesday, May 28, 2014 12:10:55 pm Sean Bruno wrote: >>>>>> On Wed, 2014-05-28 at 10:54 -0400, John Baldwin wrote: >>>>>>> On Wednesday, May 28, 2014 7:08:36 am Sean Bruno >>>>>>> wrote: >>>>>>>> On Tue, 2014-05-27 at 16:14 -0400, John Baldwin >>>>>>>> wrote: >>>>>>>>> On Tuesday, May 27, 2014 1:39:48 pm Sean Bruno >>>>>>>>> wrote: >>>>>>>>>> On Tue, 2014-05-27 at 11:32 -0400, John Baldwin >>>>>>>>>> wrote: >>>>>>>>>>> On Friday, May 23, 2014 12:14:58 pm Sean Bruno >>>>>>>>>>> wrote: >>>>>>>>>>>> Trying to figure out the failures on suspend >>>>>>>>>>>> resume for the T61 I have. I see a little >>>>>>>>>>>> acpi error at host startup, but I don't think >>>>>>>>>>>> its related. However, I'm not sure what it >>>>>>>>>>>> means. >>>>>>>>>>>> >>>>>>>>>>>> sean >>>>>>>>>>>> >>>>>>>>>>>> -- >>>>>>>>>>>> >>>>>>>>>>>> FreeBSD 11.0-CURRENT #1 r265820: Sat May 10 >>>>>>>>>>>> 15:13:37 PDT 2014 >>>>>>>>>>>> sbruno@bruno:/usr/obj/usr/src/sys/BRUNO >>>>>>>>>>>> amd64 FreeBSD clang version 3.4 >>>>>>>>>>>> (tags/RELEASE_34/final 197956) 20140216 VT: >>>>>>>>>>>> running with driver "vga". CPU: Intel(R) >>>>>>>>>>>> Core(TM)2 Duo CPU T7300 @ 2.00GHz >>>>>>>>>>>> (1995.04-MHz K8-class CPU) >>>>>>>>>>>> Origin="GenuineIntel" Id=0x6fa Family=0x6 >>>>>>>>>>>> Model=0xf Stepping=10 >>>>>>>>>>>> >>>>>>>>>>>> >>> > Features=0xbfebfbff >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>> >>> >> > Features2=0xe3bd >>>>>>>>>>>> AMD Features=0x20100800 AMD >>>>>>>>>>>> Features2=0x1 TSC: P-state invariant, >>>>>>>>>>>> performance statistics real memory = >>>>>>>>>>>> 2147483648 (2048 MB) avail memory = >>>>>>>>>>>> 2007138304 (1914 MB) Event timer "LAPIC" >>>>>>>>>>>> quality 400 ACPI APIC Table: >>>>>>>>>>> > FreeBSD/SMP: Multiprocessor System >>>>>>>>>>>> Detected: 2 CPUs FreeBSD/SMP: 1 package(s) x >>>>>>>>>>>> 2 core(s) cpu0 (BSP): APIC ID: 0 cpu1 (AP): >>>>>>>>>>>> APIC ID: 1 ACPI BIOS Warning (bug): 32/64X >>>>>>>>>>>> length mismatch in FADT/Gpe1Block: 0/32 >>>>>>>>>>>> (20130823/tbfadt-601) ACPI BIOS Warning >>>>>>>>>>>> (bug): Optional FADT field Gpe1Block has zero >>>>>>>>>>>> address or length: 0x102C/0x0 >>>>>>>>>>>> (20130823/tbfadt-630) >>>>>>>>>>> >>>>>>>>>>> It might be related as Gpe1Block describes a >>>>>>>>>>> register set that IIRC is used to enter sleep >>>>>>>>>>> states. Can you put your acpidump -t >>>>>>>>>>> somewhere? (No need for -d as this is in the >>>>>>>>>>> FADT, not the DSDT.) >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>>
Re: Investigating failed suspend/resume T61
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2014-05-28 13:44:46 -0400, John Baldwin wrote: > On Wednesday, May 28, 2014 12:44:44 pm Jung-uk Kim wrote: >> On 2014-05-28 12:20:24 -0400, John Baldwin wrote: >>> On Wednesday, May 28, 2014 12:10:55 pm Sean Bruno wrote: >>>> On Wed, 2014-05-28 at 10:54 -0400, John Baldwin wrote: >>>>> On Wednesday, May 28, 2014 7:08:36 am Sean Bruno wrote: >>>>>> On Tue, 2014-05-27 at 16:14 -0400, John Baldwin wrote: >>>>>>> On Tuesday, May 27, 2014 1:39:48 pm Sean Bruno wrote: >>>>>>>> On Tue, 2014-05-27 at 11:32 -0400, John Baldwin >>>>>>>> wrote: >>>>>>>>> On Friday, May 23, 2014 12:14:58 pm Sean Bruno >>>>>>>>> wrote: >>>>>>>>>> Trying to figure out the failures on suspend >>>>>>>>>> resume for the T61 I have. I see a little acpi >>>>>>>>>> error at host startup, but I don't think its >>>>>>>>>> related. However, I'm not sure what it means. >>>>>>>>>> >>>>>>>>>> sean >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> >>>>>>>>>> FreeBSD 11.0-CURRENT #1 r265820: Sat May 10 >>>>>>>>>> 15:13:37 PDT 2014 >>>>>>>>>> sbruno@bruno:/usr/obj/usr/src/sys/BRUNO amd64 >>>>>>>>>> FreeBSD clang version 3.4 (tags/RELEASE_34/final >>>>>>>>>> 197956) 20140216 VT: running with driver "vga". >>>>>>>>>> CPU: Intel(R) Core(TM)2 Duo CPU T7300 @ 2.00GHz >>>>>>>>>> (1995.04-MHz K8-class CPU) Origin="GenuineIntel" >>>>>>>>>> Id=0x6fa Family=0x6 Model=0xf Stepping=10 >>>>>>>>>> >>>>>>>>>> > Features=0xbfebfbff >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >> > Features2=0xe3bd >>>>>>>>>> AMD Features=0x20100800 AMD >>>>>>>>>> Features2=0x1 TSC: P-state invariant, >>>>>>>>>> performance statistics real memory = 2147483648 >>>>>>>>>> (2048 MB) avail memory = 2007138304 (1914 MB) >>>>>>>>>> Event timer "LAPIC" quality 400 ACPI APIC Table: >>>>>>>>>> FreeBSD/SMP: Multiprocessor >>>>>>>>>> System Detected: 2 CPUs FreeBSD/SMP: 1 package(s) >>>>>>>>>> x 2 core(s) cpu0 (BSP): APIC ID: 0 cpu1 (AP): >>>>>>>>>> APIC ID: 1 ACPI BIOS Warning (bug): 32/64X length >>>>>>>>>> mismatch in FADT/Gpe1Block: 0/32 >>>>>>>>>> (20130823/tbfadt-601) ACPI BIOS Warning (bug): >>>>>>>>>> Optional FADT field Gpe1Block has zero address or >>>>>>>>>> length: 0x102C/0x0 >>>>>>>>>> (20130823/tbfadt-630) >>>>>>>>> >>>>>>>>> It might be related as Gpe1Block describes a >>>>>>>>> register set that IIRC is used to enter sleep >>>>>>>>> states. Can you put your acpidump -t somewhere? >>>>>>>>> (No need for -d as this is in the FADT, not the >>>>>>>>> DSDT.) >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Here --> >>>>>>>> http://people.freebsd.org/~sbruno/T61_acpidump.txt >>>>>>> >>>>>>> Ah, so the warning is due to the fact that the 'FACP' >>>>>>> table has 'X_GPE1_BLOCK' but no 'GPE1_BLOCK'. (Note >>>>>>> how it has both 'GPE0_BLOCK' and 'X_GPE0_BLOCK' which >>>>>>> say the same thing.) Try this workaround to quiet the >>>>>>> warning. I've no idea if it will help at all with >>>>>>> suspend/resume. >>>>>>> >>>>>>> Index: >>>>>>> sys/contrib/dev/acpica/components/tables/tbfadt.c >>>>>>> === >>>
Re: Investigating failed suspend/resume T61
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 2014-05-28 12:20:24 -0400, John Baldwin wrote:
> On Wednesday, May 28, 2014 12:10:55 pm Sean Bruno wrote:
>> On Wed, 2014-05-28 at 10:54 -0400, John Baldwin wrote:
>>> On Wednesday, May 28, 2014 7:08:36 am Sean Bruno wrote:
>>>> On Tue, 2014-05-27 at 16:14 -0400, John Baldwin wrote:
>>>>> On Tuesday, May 27, 2014 1:39:48 pm Sean Bruno wrote:
>>>>>> On Tue, 2014-05-27 at 11:32 -0400, John Baldwin wrote:
>>>>>>> On Friday, May 23, 2014 12:14:58 pm Sean Bruno wrote:
>>>>>>>> Trying to figure out the failures on suspend resume
>>>>>>>> for the T61 I have. I see a little acpi error at host
>>>>>>>> startup, but I don't think its related. However, I'm
>>>>>>>> not sure what it means.
>>>>>>>>
>>>>>>>> sean
>>>>>>>>
>>>>>>>> --
>>>>>>>>
>>>>>>>> FreeBSD 11.0-CURRENT #1 r265820: Sat May 10 15:13:37
>>>>>>>> PDT 2014 sbruno@bruno:/usr/obj/usr/src/sys/BRUNO
>>>>>>>> amd64 FreeBSD clang version 3.4
>>>>>>>> (tags/RELEASE_34/final 197956) 20140216 VT: running
>>>>>>>> with driver "vga". CPU: Intel(R) Core(TM)2 Duo CPU
>>>>>>>> T7300 @ 2.00GHz (1995.04-MHz K8-class CPU)
>>>>>>>> Origin="GenuineIntel" Id=0x6fa Family=0x6
>>>>>>>> Model=0xf Stepping=10
>>>>>>>>
>>>>>>>> Features=0xbfebfbff
>>>>>>>>
>>>>>>>>
>>>>>>>>
Features2=0xe3bd
>>>>>>>> AMD Features=0x20100800 AMD
>>>>>>>> Features2=0x1 TSC: P-state invariant,
>>>>>>>> performance statistics real memory = 2147483648
>>>>>>>> (2048 MB) avail memory = 2007138304 (1914 MB) Event
>>>>>>>> timer "LAPIC" quality 400 ACPI APIC Table: >>>>>>> TP-7L > FreeBSD/SMP: Multiprocessor System
>>>>>>>> Detected: 2 CPUs FreeBSD/SMP: 1 package(s) x 2
>>>>>>>> core(s) cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID:
>>>>>>>> 1 ACPI BIOS Warning (bug): 32/64X length mismatch in
>>>>>>>> FADT/Gpe1Block: 0/32 (20130823/tbfadt-601) ACPI BIOS
>>>>>>>> Warning (bug): Optional FADT field Gpe1Block has zero
>>>>>>>> address or length: 0x102C/0x0
>>>>>>>> (20130823/tbfadt-630)
>>>>>>>
>>>>>>> It might be related as Gpe1Block describes a register
>>>>>>> set that IIRC is used to enter sleep states. Can you
>>>>>>> put your acpidump -t somewhere? (No need for -d as
>>>>>>> this is in the FADT, not the DSDT.)
>>>>>>>
>>>>>>
>>>>>>
>>>>>> Here -->
>>>>>> http://people.freebsd.org/~sbruno/T61_acpidump.txt
>>>>>
>>>>> Ah, so the warning is due to the fact that the 'FACP' table
>>>>> has 'X_GPE1_BLOCK' but no 'GPE1_BLOCK'. (Note how it has
>>>>> both 'GPE0_BLOCK' and 'X_GPE0_BLOCK' which say the same
>>>>> thing.) Try this workaround to quiet the warning. I've no
>>>>> idea if it will help at all with suspend/resume.
>>>>>
>>>>> Index: sys/contrib/dev/acpica/components/tables/tbfadt.c
>>>>> ===
>>>>>
>>>>>
- --- tbfadt.c (revision 266442)
>>>>> +++ tbfadt.c (working copy) @@ -601,6 +601,10 @@
>>>>> AcpiTbValidateFadt ( ACPI_BIOS_WARNING ((AE_INFO, "32/64X
>>>>> length mismatch in FADT/%s: %u/%u", Name, ACPI_MUL_8
>>>>> (Length), Address64->BitWidth)); +if (Length == 0) +
>>>>> { + Length = ACPI_DIV_8 (Address64->BitWidth); +} }
>>>>>
>>>>> if (FadtInfoTable[i].Type & ACPI_FADT_REQUIRED)
>>>>>
>>>>>
>>>>
>>>> One warning went away, one remains, not sure if its
>>>> meaningful or not.
>>>>
>>>> ACPI BIOS Warning (bug): 32/64X length misma
Re: ACPI issues with PC engines APU beta board
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2014-01-22 12:41:06 -0500, Larry Baird wrote: > On Wed, Jan 22, 2014 at 12:33:30PM -0500, Jung-uk Kim wrote: >> -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 >> >> On 2014-01-22 11:32:15 -0500, Larry Baird wrote: >>> I have a protoype board from PC Engines for their upcoming APU >>> board. The board runs fine under FreeBSD 8.4 release but fails >>> to boot using either FreeBSD 9.2 release or FreeBSD 10.0 >>> release. Verbose boot seems to indicate issue is with ACPI. I >>> am working with PC Engines to get FreeBSD up and running on >>> their board. Hopefully attached information is enough to >>> determine issue with BIOS. I'll then feed this information back >>> to PC Engines so they can provide the information to their BIOS >>> provider. >>> >>> Attached is a verbose dmesg from 9.2. In case it gets stripped >>> you can also find dmesg at: >>> ftp://ftp.gta.com/pub/apu/FreeBSD9.2/bootVerbose.txt >>> >>> Dmesg from booting 8.4 is at: >>> ftp://ftp.gta.com/pub/apu/FreeBSD8.4/dmesg.boot >>> >>> Dump of sysctl.hw.acpi from FreeBSD 8.4 is: >>> >>> hw.acpi.supported_sleep_state: S1 S2 S3 S4 S5 >>> hw.acpi.power_button_state: S5 hw.acpi.sleep_button_state: S1 >>> hw.acpi.lid_switch_state: NONE hw.acpi.standby_state: S1 >>> hw.acpi.suspend_state: S3 hw.acpi.sleep_delay: 1 >>> hw.acpi.s4bios: 0 hw.acpi.verbose: 0 hw.acpi.disable_on_reboot: >>> 0 hw.acpi.handle_reboot: 1 hw.acpi.reset_video: 0 >>> hw.acpi.cpu.cx_lowest: C1 >>> >>> acpidump -dt from from FreeBSD 8.4 is at: >>> ftp://ftp.gta.com/pub/apu/FreeBSD8.4/lab-pcengines-apu1b.asl >> >> Try setting "debug.acpi.disabled=sysres" in loader. > No effect. Please try setting "hw.pci.realloc_bars=1" in loader, then. Jung-uk Kim -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (FreeBSD) iQEcBAEBAgAGBQJS4FrcAAoJEHyflib82/FGnqgH/220WX2M9swzVyOAcypD1+oR hDHq/38ApTSMIp7pHrCRsvlr4xzpPEqCJlCg/riLEz6xVs7AbAPHA/Ql7AikIsE9 b0b4hlZKHjiK1GzYktI6j5lr/atVzcvv4bD9LSx0Saf1vmdFzABpOqPtrfQ4OdxE VmHVZ4TXqKAJ6qa8Pd32UMfvDoW8VH85wqPIjpsu2k9QQGKarKN9kU4DjDck95Cj LQR5tDGQHKdBRYKvzedSHNmHqaSjh0nc/H+5yqF4f+uvYwQ5FVaNPMJ7fBWKidFZ SEVqMWaCRKm1v6crB4cFyGlPxOpZIv9kJZfrWCcFyKtaHq0tVZtx0KQnmL4A4oE= =LWmj -END PGP SIGNATURE- ___ freebsd-acpi@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-acpi To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"
Re: P-state setting suddenly disappeared, what gives?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2013-11-14 17:41:44 -0500, Adrian Chadd wrote: > Hi all, > > I have this Lenovo T400 that I've been doing FreeBSD development on > for a while. > > It has a P8700 in it: > > CPU: Intel(R) Core(TM)2 Duo CPU P8700 @ 2.53GHz (2527.07-MHz > 686-class CPU) > > Now, up until yesterday, ACPI exported the required twiddles to > enter various different P-states. > > However, as of sometime yesterday, it stopped being able to do so. > > sysctl dev.cpu.0.freq returns nothing. Setting it to something > retuns "device not configured." The frequency list (ie, the P-state > list) is still fine. > > I had to load cpufreq.ko to get the enhanced speedstep stuff to > show up, but (a) it doesn't support this CPU (and it seems to have > stopped growing EST bits after Pentium M CPUs..) and (b) setting > the frequency using it versus P-state settings doesn't save as much > power. > > I'd like to try and debug why the heck this is. > > The laptop still works fine, things are just not as "nice" as they > once were. > > Any ideas? Any suggestions on where to start debugging this? SSDT tables for Intel processors are usually dynamic and often times additional tables are loaded per _OSC or _PDC. [1] Basically, we advertise our capabilities from sys/dev/acpica/acpi_cpu.c, depending on loaded device drivers. Unfortunately, some times it is too late and some SSDTs are not properly loaded. Also, warm booting from other OSes to FreeBSD may cause similar problems. To debug the problem, you need to dump DSDT and SSDTs and try to understand _OSC (or _PDC), _PCT and _PSS for your system. Jung-uk Kim 1. See http://docs.freebsd.org/cgi/mid.cgi?4B698DD8.4010404 for current implementation. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (FreeBSD) iQEcBAEBAgAGBQJShVknAAoJEHyflib82/FGzwkH/2M9EwyFJRL5Edo4QWstNw8r 9tDWKzzkRqCB3D0+QSvOTA+ZbOnnoTwQAfLyyWZEJcz3kWuN5KLqjix4zFzX3F// NGuhmsDDqa8OQ4wAL6ZL9RP+O1S6pc9j1W1Q7FG96G94trVjsVXRubvwosHca1YL SD2OK0UMxGPf9jqu9nSilh3j6Ry3w+LeQbg8aEjUPltwOQzPIxV34pwWzX0EeENG HkTeO82F5o8Gj0l55KZKl+qi64HAujbqFuZv6OdZxetrP61Z1SeqqkOQez++Z9oM kwlKF/xev2+Z3bJNChgV+FQtQ4eapBTSpAj1bvjEsGfSKCDaIlIftDhmFi80Sf0= =co85 -END PGP SIGNATURE- ___ freebsd-acpi@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-acpi To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"
Re: Problems with amd FX 8 core and freq scaling
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2013-11-13 18:21:37 -0500, Adrian Chadd wrote: > On 11 November 2013 13:47, Jung-uk Kim wrote: > >> Just in case, here I attached the uncommitted (and untested) >> patch. >> > > Would you mind describing everything that this patch does? The patch was written few years ago to fix crashes. However, I don't remember too much detail any more, sorry. Jung-uk Kim -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (FreeBSD) iQEcBAEBAgAGBQJShAy3AAoJEHyflib82/FGs6UH/0/1pwz/08hGRqq8WiTqDebI SrFaYD/JKMTLGyij+b+WoOrPpVPNN/+q+ebsKQ4kCUTctnQgnzUqnW4VfkKXBRe4 jSjA02Wu0EhkAweIe22WLnuURst5oL+0/5YF3DEPyCexQZyiMiY0bfCLKZuRibJ0 GHSUT9zfHPPMktwYhQMNxwrnQqQ0O7IxKirmsCksm/Vo7vwbIo8Q2lUJh3nfN5KR MikgAf7x1jdwfEhfqTrXOk1NISFLw1O3uQ0qQWf1tHBeUOGZ76nvUxE/MGaIL2iG RpHRyTySri6iXMXMBfdCYtMmdvMs3NFznk6+tNQ4bXPNS0OXboRQGbZjueiToIY= =sIFq -END PGP SIGNATURE- ___ freebsd-acpi@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-acpi To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"
Re: Problems with amd FX 8 core and freq scaling
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 2013-11-11 16:31:30 -0500, Jung-uk Kim wrote:
> On 2013-11-11 15:26:58 -0500, Adrian Chadd wrote:
>> On 11 November 2013 12:00, Jung-uk Kim wrote:
>>> -BEGIN PGP SIGNED MESSAGE- Hash: SHA1
>>>
>>> On 2013-11-11 13:16:47 -0500, Nicholas McKenzie wrote:
>>>> But wouldn't this just disable frequency scaling and the
>>>> whole point of powerd?
>>>
>>> No. acpi_throttle (and p4tcc) controls T-state. "Frequency
>>> scaling" should be done by changing P-state.
>
>> Right.
>
>> IIRC, T-state is just for emergency temperature throttling. It
>> shouldn't be used outside of that.
>
>
>>>>> There have been a number of reports of throttling causing
>>>>> crashes. This setting does not prevent powerd from
>>>>> adjusting your CPU's clock, it just disables some arcane
>>>>> feature which pre-dates the modern power management
>>>>> methods.
>
>> .. did anyone ever figure out why crashes would be caused by
>> T-state adjustment?
>
> My memory is vague but I think it was not able to reject a broken
> FADT or _PTC table, or something like that.
Just in case, here I attached the uncommitted (and untested) patch.
Jung-uk Kim
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (FreeBSD)
iQEcBAEBAgAGBQJSgVBgAAoJEHyflib82/FGACsIAJGDQGOYYO8dxvtQMw4BBnzl
BNbFkvalvHOzaSezJz+A4R0zeIMvkfJtu0Gb8qiTkxJF+REREFo6a7lmzC7hOMwa
7PzRRRG34rtmnnHJro3Wc5qQwc1zBbmyFgYEJ45AkmIc62mpp9f0sZyNA1+aSpau
2sY6H0dXktapc2pLR1uNyxfUlr1tRhoabceGSlGLYiB583FrMsvASkaTnuWQ2IfI
gytrJBKjMihu60KlwKauzUOVDrEuN3J/B1y7V/TrTXmcFmWgL9Wdw/gC7ToRdloT
JdF812Duj/xYvyoNEwkz1Rm0NT5r1ZTYqwMvkOPuMfK7IWX0O9UFO8VG+QnJXhU=
=/d/E
-END PGP SIGNATURE-
Index: sys/dev/acpica/acpi_throttle.c
===
--- sys/dev/acpica/acpi_throttle.c (revision 258019)
+++ sys/dev/acpica/acpi_throttle.c (working copy)
@@ -54,14 +54,24 @@ __FBSDID("$FreeBSD$");
* absolute cpufreq drivers. We support the ACPI 2.0 specification.
*/
+struct acpi_tx {
+ uint32_t percent;
+ uint32_t power;
+ uint32_t trans_lat;
+ uint32_t ctrl_val;
+ uint32_t sts_val;
+};
+
struct acpi_throttle_softc {
device_t cpu_dev;
ACPI_HANDLE cpu_handle;
uint32_t cpu_p_blk; /* ACPI P_BLK location */
uint32_t cpu_p_blk_len; /* P_BLK length (must be 6). */
+ uint32_t cpu_p_mask; /* P_BLK mask for clock value */
+ uint32_t cpu_tx_count; /* Total number of throttle states. */
+ struct acpi_tx *cpu_tx_states; /* ACPI throttle states */
struct resource *cpu_p_cnt; /* Throttling control register */
- int cpu_p_type; /* Resource type for cpu_p_cnt. */
- uint32_t cpu_thr_state; /* Current throttle setting. */
+ struct resource *cpu_p_sts; /* Throttling status register */
};
#define THR_GET_REG(reg) \
@@ -75,10 +85,6 @@ struct acpi_throttle_softc {
* Speeds are stored in counts, from 1 to CPU_MAX_SPEED, and
* reported to the user in hundredths of a percent.
*/
-#define CPU_MAX_SPEED (1 << cpu_duty_width)
-#define CPU_SPEED_PERCENT(x) ((1 * (x)) / CPU_MAX_SPEED)
-#define CPU_SPEED_PRINTABLE(x) (CPU_SPEED_PERCENT(x) / 10), \
-(CPU_SPEED_PERCENT(x) % 10)
#define CPU_P_CNT_THT_EN (1<<4)
#define CPU_QUIRK_NO_THROTTLE (1<<1) /* Throttling is not usable. */
@@ -89,7 +95,6 @@ struct acpi_throttle_softc {
static uint32_t cpu_duty_offset; /* Offset in P_CNT of throttle val. */
static uint32_t cpu_duty_width; /* Bit width of throttle value. */
-static int thr_rid; /* Driver-wide resource id. */
static int thr_quirks; /* Indicate any hardware bugs. */
static void acpi_throttle_identify(driver_t *driver, device_t parent);
@@ -127,6 +132,8 @@ static devclass_t acpi_throttle_devclass;
DRIVER_MODULE(acpi_throttle, cpu, acpi_throttle_driver, acpi_throttle_devclass,
0, 0);
+static MALLOC_DEFINE(M_ACPITHR, "acpi_throttle", "ACPI Throttling states");
+
static void
acpi_throttle_identify(driver_t *driver, device_t parent)
{
@@ -133,6 +140,9 @@ acpi_throttle_identify(driver_t *driver, device_t
ACPI_BUFFER buf;
ACPI_HANDLE handle;
ACPI_OBJECT *obj;
+ ACPI_IO_ADDRESS addr;
+ ACPI_STATUS status;
+ UINT32 len;
/* Make sure we're not being doubly invoked. */
if (device_find_child(parent, "acpi_throttle", -1))
@@ -155,12 +165,16 @@ acpi_throttle_identify(driver_t *driver, device_t
if (ACPI_FAILURE(AcpiEvaluateObject(handle, NULL, NULL, &buf)))
return;
obj = (ACPI_OBJECT *)buf.Pointer;
- if ((obj->Processor.PblkAddress && obj->Processor.PblkLength >= 4) ||
- ACPI_SUCCESS(AcpiEvaluateObject(handle, "_PTC", NULL, NULL))) {
- if (BUS_ADD_CHILD(parent, 0, "acpi_throttle", -1) == NULL)
- devi
Re: Problems with amd FX 8 core and freq scaling
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 2013-11-11 15:26:58 -0500, Adrian Chadd wrote:
> On 11 November 2013 12:00, Jung-uk Kim wrote:
>> -BEGIN PGP SIGNED MESSAGE- Hash: SHA1
>>
>> On 2013-11-11 13:16:47 -0500, Nicholas McKenzie wrote:
>>> But wouldn't this just disable frequency scaling and the whole
>>> point of powerd?
>>
>> No. acpi_throttle (and p4tcc) controls T-state. "Frequency
>> scaling" should be done by changing P-state.
>
> Right.
>
> IIRC, T-state is just for emergency temperature throttling. It
> shouldn't be used outside of that.
>
>
>>>> There have been a number of reports of throttling causing
>>>> crashes. This setting does not prevent powerd from adjusting
>>>> your CPU's clock, it just disables some arcane feature which
>>>> pre-dates the modern power management methods.
>
> .. did anyone ever figure out why crashes would be caused by
> T-state adjustment?
My memory is vague but I think it was not able to reject a broken FADT
or _PTC table, or something like that.
>> I rewrote acpi_throttle.c at some point to fix the problem but
>> never committed it because nobody was really interested in
>> testing the patch. Also, it is really an arcane and archaic
>> feature:
>>
>> http://software.intel.com/en-us/blogs/2013/10/15/c-states-p-states-where-the-heck-are-those-t-states
>>
>>
>>
Now I think we should disable the feature by default because it is
>> causing too much hassle for us (attached). Any objection?
>
> No, I think we should correctly identify which particular features
> are required for which particular CPUs and enable/disable it based
> on that.
>
> So, if it's relevant for P4 era hardware, let's default to having
> it on for that class hardware.
>
> If it's not relevant for core and core 2 (and later) hardware,
> then let's default to leaving it off for that.
If you can maintain p4tcc for Intel processors, I am okay with that.
However, I still want to disable acpi_throttle by default. In fact,
I've never seen any non-Intel processor and/or motherboard with
correct BIOS to support T-state change.
> So, how about we come up with a table of CPUs and what particular
> power save technologies we should be using, then start
> implementing that?
Please see p4tcc.c. It already has a quirk table based on CPUID. You
just have to maintain it properly.
> I'm reading the SDM bits on the adaptive frequency stuff (turbo
> boost, etc) and I'll see about writing up some data gathering knobs
> for the kernel.
Cool.
BTW, please don't forget AMD users, i.e., check the BKDGs.
http://developer.amd.com/resources/documentation-articles/developer-guides-manuals/
> People still spin up FreeBSD on P4 (and earlier) class hardware.
> I'd rather we get it right versus just flipping crap on and off
> based on what 'current' hardware expects. I watched people do this
> with the RTC code. It's ridiculous.
Please see the attached patch, i.e., I reverted p4tcc-specific changes.
Jung-uk Kim
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (FreeBSD)
iQEcBAEBAgAGBQJSgUyyAAoJEHyflib82/FGfLoH/2jejB55Eqtj134Z71bi75MA
YUCZ2z5r2PoDN5PUsJeHqyv5EyEWteYlAxLKr/mvV5rbaIk1Wlg0+6c4U7rH99Qj
+QpkS1GFL4XQFlKM8pFJ55VxQAYmUVwGCRGJxtxl0z6J6GvCIByKopqV3ywy04eG
LcxjML2Kka0FU5UmFKqjy/2j9jBBClEYfynSeVqpjc+REK970oZFMjblQqtLSNsf
GKhVwuFwaQYyZZylBTyEZh5fD7346jtA5G/mtSqjKJN2dY6nI5hIqqSWpXulLOEC
N16jqUWswO8hE8ZpgVeFSAmkznP4ITHsSjuxQgU4pyTdnF1DiOmizA7Snjekyvs=
=S1SR
-END PGP SIGNATURE-
Index: sys/dev/acpica/acpi_throttle.c
===
--- sys/dev/acpica/acpi_throttle.c (revision 258002)
+++ sys/dev/acpica/acpi_throttle.c (working copy)
@@ -167,7 +167,7 @@ static int
acpi_throttle_probe(device_t dev)
{
- if (resource_disabled("acpi_throttle", 0))
+ if (!resource_enabled("acpi_throttle", 0))
return (ENXIO);
/*
Index: sys/kern/subr_hints.c
===
--- sys/kern/subr_hints.c (revision 258002)
+++ sys/kern/subr_hints.c (working copy)
@@ -449,15 +449,29 @@ resource_find_dev(int *anchor, const char *name, i
}
/*
- * Check to see if a device is disabled via a disabled hint.
+ * Check to see if a device is disabled or enabled via a hint.
*/
-int
-resource_disabled(const char *name, int unit)
+static __inline int
+resource_find_hint(const char *name, int unit, const char *hint)
{
int error, value;
- error = resource_int_value(name, unit, "disabled", &value);
+ error = resource_int_value(name, unit, hint, &value);
if (error)
return (0);
return (value);
}
+
+int
+re
Fwd: Re: Problems with amd FX 8 core and freq scaling
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 2013-11-11 13:16:47 -0500, Nicholas McKenzie wrote:
> But wouldn't this just disable frequency scaling and the whole
> point of powerd?
No. acpi_throttle (and p4tcc) controls T-state. "Frequency scaling"
should be done by changing P-state.
> On Mon, Nov 11, 2013 at 1:46 AM, Stefan Esser
> wrote:
>>
>> Am 10.11.2013 22:46, schrieb Nicholas Stewart McKenzie:
>>> My computer crashes if I enable powerd. I can't get cpu freq
>>> scaling to work with my cpu:(P.S. I sent this to both drivers
>>> and amd64 mailing list...
>>
>> Hi,
>>
>> you may want to try booting with the following line added to
>> /boot/loader.conf (or entered at the boot menu prompt after
>> breaking out of automatic boot):
>>
>> hint.acpi_throttle.0.disabled="1"
>>
>> There have been a number of reports of throttling causing
>> crashes. This setting does not prevent powerd from adjusting
>> your CPU's clock, it just disables some arcane feature which
>> pre-dates the modern power management methods.
I rewrote acpi_throttle.c at some point to fix the problem but never
committed it because nobody was really interested in testing the
patch. Also, it is really an arcane and archaic feature:
http://software.intel.com/en-us/blogs/2013/10/15/c-states-p-states-where-the-heck-are-those-t-states
Now I think we should disable the feature by default because it is
causing too much hassle for us (attached). Any objection?
Jung-uk Kim
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (FreeBSD)
iQEcBAEBAgAGBQJSgTdPAAoJEHyflib82/FGZaEIAJPt2/qPu7CxFAHBwizG+o+Y
Mmn0rqXREynXT83ds5cD998cO44GHFGhSaDYZ6wuL6CXoSE2bzTo5aAjVq/vY6io
4ItmvZPVNKK/UxeTK+ccDeuMKBXHBmOoUUUADGRy1d9S+GGtie0DVSpWZhEvSFrY
l/y1Dt3yd53qjlV96GcKqGYO6EyzlDq1tlO7jog28x8oDfz6W6KyXRL3evpqn/Mb
Y1B3anULsxbOMPN1hXcgBIA11SOdCCIe5zifldeAn1CCq3hMVxmIyH04dpVq9eBp
p7QpA+4KDLGwoXMYDL1dlL8kK0bCIWUB5FIFcJrBfcPYhv0FduX736NzufRvncc=
=ZSMa
-END PGP SIGNATURE-
Index: sys/dev/acpica/acpi_throttle.c
===
--- sys/dev/acpica/acpi_throttle.c (revision 258002)
+++ sys/dev/acpica/acpi_throttle.c (working copy)
@@ -167,7 +167,7 @@ static int
acpi_throttle_probe(device_t dev)
{
- if (resource_disabled("acpi_throttle", 0))
+ if (!resource_enabled("acpi_throttle", 0))
return (ENXIO);
/*
@@ -177,7 +177,7 @@ acpi_throttle_probe(device_t dev)
* we disable acpi_throttle when p4tcc is also present.
*/
if (device_find_child(device_get_parent(dev), "p4tcc", -1) &&
- !resource_disabled("p4tcc", 0))
+ resource_ensabled("p4tcc", 0))
return (ENXIO);
device_set_desc(dev, "ACPI CPU Throttling");
Index: sys/kern/subr_hints.c
===
--- sys/kern/subr_hints.c (revision 258002)
+++ sys/kern/subr_hints.c (working copy)
@@ -449,15 +449,29 @@ resource_find_dev(int *anchor, const char *name, i
}
/*
- * Check to see if a device is disabled via a disabled hint.
+ * Check to see if a device is disabled or enabled via a hint.
*/
-int
-resource_disabled(const char *name, int unit)
+static __inline int
+resource_find_hint(const char *name, int unit, const char *hint)
{
int error, value;
- error = resource_int_value(name, unit, "disabled", &value);
+ error = resource_int_value(name, unit, hint, &value);
if (error)
return (0);
return (value);
}
+
+int
+resource_disabled(const char *name, int unit)
+{
+
+ return (resource_find_hint(name, unit, "disabled"));
+}
+
+int
+resource_enabled(const char *name, int unit)
+{
+
+ return (resource_find_hint(name, unit, "enabled"));
+}
Index: sys/sys/bus.h
===
--- sys/sys/bus.h (revision 258002)
+++ sys/sys/bus.h (working copy)
@@ -503,6 +503,7 @@ int resource_long_value(const char *name, int unit
int resource_string_value(const char *name, int unit, const char *resname,
const char **result);
int resource_disabled(const char *name, int unit);
+int resource_enabled(const char *name, int unit);
int resource_find_match(int *anchor, const char **name, int *unit,
const char *resname, const char *value);
int resource_find_dev(int *anchor, const char *name, int *unit,
Index: sys/x86/cpufreq/p4tcc.c
===
--- sys/x86/cpufreq/p4tcc.c (revision 258002)
+++ sys/x86/cpufreq/p4tcc.c (working copy)
@@ -142,7 +142,7 @@ static int
p4tcc_probe(device_t dev)
{
- if (resource_disabled("p4tcc", 0))
+ if (!resource_enabled("p4tcc", 0))
return (ENXIO);
device_set_desc(dev, "CPU Frequency Thermal Control");
___
freebsd-acpi@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"
Re: suspend/resume on Lenovo X1 (regression from reports on wiki)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2013-09-05 20:24:46 -0400, Adrian Chadd wrote: > Whoa whoa. > > I'm confused. Well, a bit. How is it up to syscons to fix the > backlight configuration, which seems to be a large part of the > problem here? No, it has nothing to do with syscons(4). acpi_video(4) does. However, it does not work with i915kms.ko because some piece of code is not implemented for FreeBSD if I understand it correctly. > Or what else is going on here with restoring the system state? It worked with DRM1 because automatic VT-switching (aka sysctl hw.syscons.sc_no_suspend_vtswitch) indirectly saves/restores GPU states via X11 driver, which is no longer possible with KMS. > I'm worried that we'll have the same problem with newcons, with or > without KMS. Why would KMS get involved if I'm in console mode > doing 80x60 text? :) If KMS is used for newcons backend, I am sure text mode won't be implemented. Also, KMS will "naturally" handle suspend/resume as it is a proper newbus driver, unlike syscons. At least, that's the idea. Jung-uk Kim -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.21 (FreeBSD) iQEcBAEBAgAGBQJSKSuvAAoJECXpabHZMqHOA6kIAMLLYNSniDonBSs5QzLvT6aM iISSshjhyykNPCTwZBS5d5LCMAJXuQ7OF7FIYYI7bgrKFX0hzNCAARDJE52/PgQA S1D4ra0slsKm62ezdiOuJhP4C/Hwqihv8/jMK9KmbBSNAyydZ+pPVXHd/JKaCd/U J+g72slzyAm/GYOe8kRb7JGUQsiDyDUbVOOoZZlarqxSEl0kvZFE7rIWBxuD0DGN iGkVB3e0ybIlVNPvjh2CsukBnD2TUYR1ssXFn7zp1Mh9qnQIfoTnQoSDkjDVV1b6 wi2Y1L3cu1kgfG0dCx6CNuH/K3/g0SXA55D8o+NrmLPAQYHWy/TGVm3eKQe30fg= =CY1F -END PGP SIGNATURE- ___ freebsd-acpi@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-acpi To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"
Re: suspend/resume on Lenovo X1 (regression from reports on wiki)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2013-09-05 04:24:58 -0400, Bengt Ahlgren wrote: > "Ganael LAPLANCHE" writes: > >> On Fri, 30 Aug 2013 11:53:22 -0400, John Baldwin wrote >> >>> I just removed VESA from my kernel on an X220 and it now >>> suspends and resumes great in X. I don't notice any slowdown, >>> but I'm using a very simple tiling window manager (i3wm). >> >> Great, I can confirm that suspend/resume also works on my X220 >> with this trick ! >> >> I had once opened a PR for that problem and I had managed to >> track the change that, at that time, broke suspend/resume : >> >> http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/174504 >> >> I don't know how it relates to VESA (the change does not seem to >> be related to VESA), but it might help ? > > I believe this (the PR) is a completely different issue, since you > write "resume make the computer hang". The nooptions VESA fixed > wedging of Intel/KMS graphics _after_ resume. There have been many > other changes since r231797 (15 feb 2012). Correct. r231797 had an issue but it was quickly fixed, I think, and it was completely unrelated to VESA. > But nice that it works for you too! Unfortunately, many people think that no video == hang because they cannot see anything on their screen/panel. Moreover, I realized that more users are now complaining about suspend/resume problems with DRM/KMS, which is not directly related to ACPI. - From lots of responses I gathered from users and developers yesterday, I can definitely say that i915kms.ko does not cooperatively work with syscons(4) and acpi_video(4). Basically, it was not a priority at the time of porting according to the author. I am quite sure radeonkms.ko has similar problems. FYI... Jung-uk Kim * PS: https://wiki.freebsd.org/SuspendResume needs more love, I guess. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.21 (FreeBSD) iQEcBAEBAgAGBQJSKMadAAoJECXpabHZMqHOvpMH/0RVq4KZCTDZqsxOibrIY9/9 INNEZXsVWP+Y8+BQacXP3x45eUOGVKa2IGiDo/O7Oediqh/DIhWa8pqonzJ474qY UadV+SQTjQE1EDUcjWmKnAY4OT0dHiN6eAIUv5o+dnFOxb6HupQ2hTGziReQoupS QE9YgwUVU5yOlGZXFbhq2RHvqT2Bi52dHC1qP2waVOlghNY7PIbYMTwQ4X6S4fGC Fjgjvx4tUU4EhjWuaK8mH0t/gCsUjpRico7YmYVVb2N5hu9SrojGPsIgGLaD1Aqi 4Nkmd59Asu+NBR0A22c7UAcoRpP2aJ65q/MU8CdRp/FOTE+W2LLlsXy2JIiKCBk= =Pf+z -END PGP SIGNATURE- ___ freebsd-acpi@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-acpi To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"
Re: suspend/resume on Lenovo X1 (regression from reports on wiki)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2013-09-05 16:04:56 -0400, Bengt Ahlgren wrote: > Jung-uk Kim writes: > >> On 2013-09-04 18:47:47 -0400, Jung-uk Kim wrote: >>> On 2013-09-04 18:39:07 -0400, Bengt Ahlgren wrote: >>>> The value of hw.acpi.video.lcd0.brightness changes when the >>>> screen brightness keys (Fn+Home/End) are pressed, but >>>> nothing happens with the screen. Same goes for changing the >>>> value with sysctl. After a fresh boot it works with one >>>> issue. The screen brightness level seems to lag behind one >>>> keypress. Without acpi_video, screen brightness changes >>>> without the lag. >>> >>>> hw.acpi.video.lcd0.active is always stuck at 0 - can't >>>> change with sysctl (regardless if the screen is on after a >>>> fresh boot, or black after a text console suspend/resume): >>> >>>> [root@bit ~]# sysctl hw.acpi.video.lcd0.active=1 >>>> hw.acpi.video.lcd0.active: 0 -> 0 >>> >>>> Again, for my old X40 with non-KMS Xorg intel driver has >>>> (curiously, the screen blinks when issuing this sysctl >>>> command): >>> >>>> [bengta@P142 ~]$ sysctl hw.acpi.video >>>> hw.acpi.video.lcd0.active: 1 hw.acpi.video.crt0.active: 0 >>> >>> Then, KMS probably breaks acpi_video(4), too. :-( >> >> kib let me know that there is a way to make it work but it was >> not well-integrated to i915kms.ko. If you are interested in >> fixing it, dev/drm2/i915/intel_opregion.c is the source and you >> can download the specification from here: >> >> https://01.org/linuxgraphics/sites/default/files/documentation/acpi_igd_opregion_spec.pdf > >> > Hmm, scanning that spec, I wonder whether the opregion > functionality is better placed together with acpi_video, and then > i915kms makes calls to that instead? Traditionally, platform-specific code goes to dev/acpi_support. So, dev/acpi_support/acpi_intel.c may be created to cater its needs, if it is absolutely necessary. > Hmm, again, perhaps the intel platform needs opregion support to > work properly also without the kms driver. Could be anexplanation > for the backlight issues. Yes and yes, I think. However, many developers are tired of dealing with syscons ugliness and now the Foundation is sponsoring ray@ to replace syscons with newcons+KMS if my understanding is correct. I am not sure how it will be layered at the end, though. > (Just speculation so far... I have no idea if/how this relates to > or interacts with options VESA) Apparently, they interact badly. :-( Jung-uk Kim -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.21 (FreeBSD) iQEcBAEBAgAGBQJSKOpXAAoJECXpabHZMqHOSnIIANS/Kt043RI7fFLNYVeWvpH0 zQ8C3wTi66aIW9B5bvYcXcJXcE1yazfegbtAHT6i0Hf4/BrvoMkN3umHIRYMbMv9 ei7WoFDLRIuyGzqgMy7CP3t9byYZolRBuyIt+zELsNU/5zCkgSP3di40TK+oLJ+3 NXhALsLZA37B1S3TYaiLy+U4BylfC3iNhFDlDRrikuYvAym/s5o/Ro0Ea8dyUw4i CtWDEomCIwjzOuythAl1wlXYeMtZZp+6Fj2Pemhh9COzFXgHiTfhfVySRVt0tBAs 6FKmQnc30ra2clU1o5JJuzwlOsgGH+aztvrdjc4VGr/wGpdmKW6FrNlpcku1VkQ= =i0JD -END PGP SIGNATURE- ___ freebsd-acpi@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-acpi To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"
Re: suspend/resume on Lenovo X1 (regression from reports on wiki)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2013-09-04 18:47:47 -0400, Jung-uk Kim wrote: > On 2013-09-04 18:39:07 -0400, Bengt Ahlgren wrote: >> The value of hw.acpi.video.lcd0.brightness changes when the >> screen brightness keys (Fn+Home/End) are pressed, but nothing >> happens with the screen. Same goes for changing the value with >> sysctl. After a fresh boot it works with one issue. The screen >> brightness level seems to lag behind one keypress. Without >> acpi_video, screen brightness changes without the lag. > >> hw.acpi.video.lcd0.active is always stuck at 0 - can't change >> with sysctl (regardless if the screen is on after a fresh boot, >> or black after a text console suspend/resume): > >> [root@bit ~]# sysctl hw.acpi.video.lcd0.active=1 >> hw.acpi.video.lcd0.active: 0 -> 0 > >> Again, for my old X40 with non-KMS Xorg intel driver has >> (curiously, the screen blinks when issuing this sysctl command): > >> [bengta@P142 ~]$ sysctl hw.acpi.video hw.acpi.video.lcd0.active: >> 1 hw.acpi.video.crt0.active: 0 > > Then, KMS probably breaks acpi_video(4), too. :-( kib let me know that there is a way to make it work but it was not well-integrated to i915kms.ko. If you are interested in fixing it, dev/drm2/i915/intel_opregion.c is the source and you can download the specification from here: https://01.org/linuxgraphics/sites/default/files/documentation/acpi_igd_opregion_spec.pdf Jung-uk Kim -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.21 (FreeBSD) iQEcBAEBAgAGBQJSJ8rwAAoJECXpabHZMqHOz3cIAIH5qAXbfWZrWgwJWYAyL9UI z0f/LC5ufqlpgnyvFAHZO75oDebKiDq8skGWDFDhEj8vjp8JIydZSM89EK5wj0zB eCAVwquzcasduGXQZSGyN2tPUqwCm3Fuw3Bsj2Fhwgy3Y0TA9Vsz2KGTH4qCuqWU 7W97FXpLmIOpMBh/LcWCE96hY8u0HxZmzFhjMn5MlJ7z07zEc58YRpieZ3MqACCx ml3dp56RVUQhXXZzrc5Vj+Oxgmti13Xrat7YrzVmpqSRzDtOLNaoqvk4sMz1Crh4 aXq1de1+7Hc+g2oroN3mqDcb5RXknqZ7Aq7wbiOCeQwOzK7vrs3khFWq9luWG9E= =nWlO -END PGP SIGNATURE- ___ freebsd-acpi@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-acpi To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"
Re: suspend/resume on Lenovo X1 (regression from reports on wiki)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2013-09-04 18:39:07 -0400, Bengt Ahlgren wrote: > Jung-uk Kim writes: > >> On 2013-09-04 15:14:32 -0400, Bengt Ahlgren wrote: >>> Jung-uk Kim writes: >>> >>>> On 2013-09-04 09:29:35 -0400, John Baldwin wrote: >>>>> On Tuesday, September 03, 2013 6:58:55 pm Jung-uk Kim >>>>> wrote: >>>>>> On 2013-09-03 16:47:47 -0400, John Baldwin wrote: >>>>>>> Even with that hacked so I force vgapm0 and dpms0 to >>>>>>> attach, I still can't resume in console mode, ... >>>>>> >>>>>> What happens? Does it panic, hang, or just no >>>>>> backlight? >>>>> >>>>> Just no backlight. It resumes fine and if I do it in >>>>> multiuser I can ssh in, etc. It's just the backlight that >>>>> doesn't resume. I was hopeful dpms.ko would fix that, but >>>>> it didn't. :( >>>> >>>> Ah, that's a well-known problem and we cannot fix it without >>>> help of machine-specific code, e.g., drm1/drm2. Actually, >>>> both acpi_video and dpms try to restore video settings but >>>> nothing worked for Intel GPUs + LVDS + LCD panel AFAIK. >>>> >>>>> I think i915drm has code to specifically turn on the >>>>> backlight as I get some weird error message in the kernel >>>>> console about a timeout trying to turn the panel off during >>>>> suspend when I'm in X. >>>> So, I guess it has an ordering issue. If my memory serves, >>>> drm1 was okay with vesa, however. I *think* it accidentally >>>> worked because of automatic VT-switching, which is still >>>> broken for KMS. >>> >>> Yes, perhaps, but there is also the sysctl hw.acpi.reset_video >>> which I have enabled on my older hardware (TP X40 running >>> 8.3-REL and an old Xorg server) for it to work properly. (I >>> however have some faint memory that reset_video might a no-op >>> these days, or?) >> >> No, I didn't remove it. However, I strongly discourage it. In >> fact, the same functionality exists in vesa.c and it is safer. >> >>> In this old mail regarding reset_video, there is a thought that >>> it could be good with "more" reinitialisation: >>> >>> http://lists.freebsd.org/pipermail/freebsd-acpi/2006-July/002959.html >> >> >>> vesa.c >>> >> does pretty much the same thing. FYI, vbetool does "more" but it >> does not really do more "reinitialisation". >> >> % grep ^MAINTAINER sysutils/vbetool/Makefile MAINTAINER= >> j...@freebsd.org >> >> :-) > > Great! Is vesa.c = options VESA = vesa.ko? Yes. >>> I however have one datapoint that I think contradicts John's >>> thought. This is on a X201 with stable/9 and no options VESA. >>> I first just booted up and stayed in text console, suspended >>> and resumed. No backlight, of course, and also no content on >>> the LCD, it is completely black. >> >> Panel may be completely off. >> >>> Then, I started Xorg with KMS. Still no backlight, but you can >>> see that the LCD is driven with the desired content, which is >>> one step forward. Finally, I suspended and resumed, but no >>> difference, the backlight is still off. >> >> I believe i915kms explicitly turns on LVDS/LCD panel. I guess >> it doesn't change brightness, though. >> >>> Xorg/KMS didn't manage to turn the backlight on, so the text >>> console suspend/resume cycle managed to persistently turn the >>> backlight off. >> >> Can you change the brightness via hotkeys or acpi_video? > > The value of hw.acpi.video.lcd0.brightness changes when the screen > brightness keys (Fn+Home/End) are pressed, but nothing happens with > the screen. Same goes for changing the value with sysctl. After a > fresh boot it works with one issue. The screen brightness level > seems to lag behind one keypress. Without acpi_video, screen > brightness changes without the lag. > > hw.acpi.video.lcd0.active is always stuck at 0 - can't change with > sysctl (regardless if the screen is on after a fresh boot, or > black after a text console suspend/resume): > > [root@bit ~]# sysctl hw.acpi.video.lcd0.active=1 > hw.acpi.video.lcd0.active: 0 -> 0 > > Again, for my old X40 with non-KMS Xorg intel driver has >
Re: suspend/resume on Lenovo X1 (regression from reports on wiki)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2013-09-04 15:14:32 -0400, Bengt Ahlgren wrote: > Jung-uk Kim writes: > >> On 2013-09-04 09:29:35 -0400, John Baldwin wrote: >>> On Tuesday, September 03, 2013 6:58:55 pm Jung-uk Kim wrote: >>>> On 2013-09-03 16:47:47 -0400, John Baldwin wrote: >>>>> Even with that hacked so I force vgapm0 and dpms0 to >>>>> attach, I still can't resume in console mode, ... >>>> >>>> What happens? Does it panic, hang, or just no backlight? >>> >>> Just no backlight. It resumes fine and if I do it in multiuser >>> I can ssh in, etc. It's just the backlight that doesn't >>> resume. I was hopeful dpms.ko would fix that, but it didn't. >>> :( >> >> Ah, that's a well-known problem and we cannot fix it without help >> of machine-specific code, e.g., drm1/drm2. Actually, both >> acpi_video and dpms try to restore video settings but nothing >> worked for Intel GPUs + LVDS + LCD panel AFAIK. >> >>> I think i915drm has code to specifically turn on the backlight >>> as I get some weird error message in the kernel console about >>> a timeout trying to turn the panel off during suspend when I'm >>> in X. >> So, I guess it has an ordering issue. If my memory serves, drm1 >> was okay with vesa, however. I *think* it accidentally worked >> because of automatic VT-switching, which is still broken for >> KMS. > > Yes, perhaps, but there is also the sysctl hw.acpi.reset_video > which I have enabled on my older hardware (TP X40 running 8.3-REL > and an old Xorg server) for it to work properly. (I however have > some faint memory that reset_video might a no-op these days, or?) No, I didn't remove it. However, I strongly discourage it. In fact, the same functionality exists in vesa.c and it is safer. > In this old mail regarding reset_video, there is a thought that it > could be good with "more" reinitialisation: > > http://lists.freebsd.org/pipermail/freebsd-acpi/2006-July/002959.html vesa.c > does pretty much the same thing. FYI, vbetool does "more" but it does not really do more "reinitialisation". % grep ^MAINTAINER sysutils/vbetool/Makefile MAINTAINER= j...@freebsd.org :-) > I however have one datapoint that I think contradicts John's > thought. This is on a X201 with stable/9 and no options VESA. I > first just booted up and stayed in text console, suspended and > resumed. No backlight, of course, and also no content on the LCD, > it is completely black. Panel may be completely off. > Then, I started Xorg with KMS. Still no backlight, but you can see > that the LCD is driven with the desired content, which is one step > forward. Finally, I suspended and resumed, but no difference, the > backlight is still off. I believe i915kms explicitly turns on LVDS/LCD panel. I guess it doesn't change brightness, though. > Xorg/KMS didn't manage to turn the backlight on, so the text > console suspend/resume cycle managed to persistently turn the > backlight off. Can you change the brightness via hotkeys or acpi_video? > One more thing, the kernel logs this at resume directly after the > devices are powered on (transition to D0), but I have no idea > whether it is relevant: > > Sep 2 19:57:21 bit kernel: error: [drm:pid1904:intel_lvds_enable] > *ERROR* timed out waiting for panel to power off Yes, it looks relevant. Jung-uk Kim -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.21 (FreeBSD) iQEcBAEBAgAGBQJSJ5HRAAoJECXpabHZMqHOZWQIAMHMrSWRw55HslMhQBpdbiI6 lT/iKNGUsHu4um9o8ULJMuuq2aKsSPxygz62a+XokefTbMEBIxQPFfcXAqvvGq2Y 6CvLjimTzfPO8axvvLRLEbVXDKcnHboabW5YxwJ6NreXwiWID+Noifc3EiEs5knj /Y0la3PP9ZWJu71DinGeyNLMoIeNdRC/E+o45P9uDTy3uZh7jBbIIwVdzAUEho+7 dN9xx88FkgYvnaNVJIf2sGmcMbMo0PJHB/9RNnz5AxNtmgVzrlEJaMMwKr1rnRu5 J5mUyuLt27/hGjSamqWaTMA/jS8gYJeF1Gyq7NWb2AvIsWHe68DY2a0MVZe1Oz0= =9xfZ -END PGP SIGNATURE- ___ freebsd-acpi@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-acpi To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"
Re: suspend/resume on Lenovo X1 (regression from reports on wiki)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2013-09-04 09:29:35 -0400, John Baldwin wrote: > On Tuesday, September 03, 2013 6:58:55 pm Jung-uk Kim wrote: >> On 2013-09-03 16:47:47 -0400, John Baldwin wrote: >>> Even with that hacked so I force vgapm0 and dpms0 to attach, I >>> still can't resume in console mode, ... >> >> What happens? Does it panic, hang, or just no backlight? > > Just no backlight. It resumes fine and if I do it in multiuser I > can ssh in, etc. It's just the backlight that doesn't resume. I > was hopeful dpms.ko would fix that, but it didn't. :( Ah, that's a well-known problem and we cannot fix it without help of machine-specific code, e.g., drm1/drm2. Actually, both acpi_video and dpms try to restore video settings but nothing worked for Intel GPUs + LVDS + LCD panel AFAIK. > I think i915drm has code to specifically turn on the backlight as > I get some weird error message in the kernel console about a > timeout trying to turn the panel off during suspend when I'm in X. So, I guess it has an ordering issue. If my memory serves, drm1 was okay with vesa, however. I *think* it accidentally worked because of automatic VT-switching, which is still broken for KMS. Jung-uk Kim -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.21 (FreeBSD) iQEcBAEBAgAGBQJSJ2VUAAoJECXpabHZMqHOJtgIAIagXbUGDBGR6cdu1EncP8bU eN+03coO4KBsCuFesNkOBF8GgCsoGf+n+IrUjGnazuyK9UTi5flLMieg3TpIkGrL YxOTTo6hfMswII8c5B67ZqPjvY/EmhgQdCQ34WsUGptDvUnqq23u3ounOiQY75iu FXJqQf5s1X6M5a5bzgvfWZd8yhJhUoYsrQftFOpiZBx1Xyb6hrfCRUJquQklx1Y8 zFDVYm6zr34Aan/lHOWTjAI2ZWBFeiu6BswWdFy2BCbKUUh5b9tToBikfsBRWmSn isgnm4y8NNDlz/wY42eoXvGFonJLH6+lR7sasxQayIZU7bkfrLlgs9SBex1vh4g= =dj+e -END PGP SIGNATURE- ___ freebsd-acpi@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-acpi To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"
Re: suspend/resume on Lenovo X1 (regression from reports on wiki)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2013-09-03 16:47:47 -0400, John Baldwin wrote: > On Tuesday, September 03, 2013 4:12:01 pm Jung-uk Kim wrote: >> On 2013-09-03 12:28:30 -0400, John Baldwin wrote: >>> On Sunday, September 01, 2013 3:51:47 pm Adrian Chadd wrote: >>>> (cc jkim) >>>> >>>> Hi! Would you mind taking a look at the -acpi list posts >>>> with this subject? It looks like a lot of the video >>>> suspend/resume issues on these thinkpads boil down to the >>>> VESA driver code. If it's disabled, (at least) x11 resume >>>> works. >>>> >>>> Would you be able to help us track down what's going on? >>>> >>>> Thanks! >>> >>> Most likely vga_suspend()/vga_resume() in sys/isa/vga_isa.c is >>> calling vidd_save_state() and vidd_load_state() which in the >>> VESA case map to the _save_state() and _load_state() methods >>> in sys/dev/fb/vesa.c. >> >> Unfortunately, I don't really know where it actually fails >> because I do not have *any* Intel GPUs to test. If vesa.c is >> really causing trouble, vesa_bios_post() in vesa_load_state() may >> be the culprit, however. > > I can try narrowing it down. Please do. >>> These methods look fairly sane to me, so it's probably either >>> a BIOS bug, or the fact that KMS is bypassing the BIOS, so when >>> KMS is active we should perhaps disable the VESA BIOS. >> >> AFAIK, KMS does not play nice with syscons(4) ATM, e.g., syscons >> does automatic VT switching and it may need to be turned off. >> Again, it is just my guess. > > Well, I don't have to do that, just having no VESA in the kernel > results in resume working fine in X. It seems that the i915drm > driver is doing something to explicitly enable the backlight on the > LCD btw. Normally, I expect a device tree like this to do properly suspend/resume with *drm1*: nexus0 acpi0 pcib0 pci0 hostb0 pcib1 pci1 vgapci0 vgapm0 dpms0 drm0 ... isab0 isa0 sc0 vga0 ... Not sure about i915kms.ko. >>> However, one thing that might help is that this is being called >>> at a "random" time rather than when vgapci0 is being suspended >>> and resumed. Actually, it looks like jkim fixed this via the >>> vgapm driver, except I have no vgapm0 device on my laptop. >> >> If you don't have vgapm0, its BIOS is not setting >> PCIB_BCR_VGA_ENABLE bit to its bridge. Often times, that means >> it is "legacy free" stuff. >> >>> I wonder if it's supposed to be device_get_unit() instead of >>> device_get_flags() in the vgapm identify routine? >> >> No. With multiple GPUs, it is (was?) the only way to find the >> "boot display" because unit number is not always 0. Although >> dumbbell added vga_pci_is_boot_display() in current, this >> interface should be kept for 9.x. > > Hmm, so there is magic to set this I guess? Ah, I see it now in > vga_pci.c. That does seem gross compared to an ivar or some such. > :) And you said the almost exact same thing but okayed at the time. :-) > In my case btw, x86bios_match_device() doesn't work because the > BIOS ROM has a PCI device ID of 0x0106 while the device itself is > 0x0126. It's a bug. > Even with that hacked so I force vgapm0 and dpms0 to attach, I > still can't resume in console mode, and resume in X refuses to > wakeup with VESA in the kernel (hitting the power button doesn't > make it wakeup). Please try to make syscons resume first. Jung-uk Kim -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.21 (FreeBSD) iQEcBAEBAgAGBQJSJmgdAAoJECXpabHZMqHOh6kH/RpRVeXz3n8eb72PMfZ1eQDy 2LBn/NCpxbRAHhNkwclLqCorQp6CDAEM1iO4IJMgUG4BrRYcrGUybM7kHDGn5Oy3 7qLkXmu1TmBGwFndHMZ8VaqLsUV2mgKG1DLgCCEp2NG3szOuSgg1KwBaZuT1OUhm TtJIWyuuwWld+DAaBaJJqCTJun6s3rpddXIEKj/2R+f4q99cjLt5I5qel+goArE+ yym4VrkY0S1Fn3Vj5+Nv8WMXlTgknIymsEg7fNJ9RDBGDPZ11l5DLztLjj+UfvIL K6L3+AMNJ58HRA/PibPIGNgI0WXUDJ/KSNN0A44RIItiYwTxJSh482PkghlrLE4= =jHx2 -END PGP SIGNATURE- ___ freebsd-acpi@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-acpi To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"
Re: suspend/resume on Lenovo X1 (regression from reports on wiki)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2013-09-03 12:28:30 -0400, John Baldwin wrote: > On Sunday, September 01, 2013 3:51:47 pm Adrian Chadd wrote: >> (cc jkim) >> >> Hi! Would you mind taking a look at the -acpi list posts with >> this subject? It looks like a lot of the video suspend/resume >> issues on these thinkpads boil down to the VESA driver code. If >> it's disabled, (at least) x11 resume works. >> >> Would you be able to help us track down what's going on? >> >> Thanks! > > Most likely vga_suspend()/vga_resume() in sys/isa/vga_isa.c is > calling vidd_save_state() and vidd_load_state() which in the VESA > case map to the _save_state() and _load_state() methods in > sys/dev/fb/vesa.c. Unfortunately, I don't really know where it actually fails because I do not have *any* Intel GPUs to test. If vesa.c is really causing trouble, vesa_bios_post() in vesa_load_state() may be the culprit, however. > These methods look fairly sane to me, so it's probably either a > BIOS bug, or the fact that KMS is bypassing the BIOS, so when KMS > is active we should perhaps disable the VESA BIOS. AFAIK, KMS does not play nice with syscons(4) ATM, e.g., syscons does automatic VT switching and it may need to be turned off. Again, it is just my guess. > I'd argue that we should be it is a BIOS bug regardless. +1 > However, one thing that might help is that this is being called at > a "random" time rather than when vgapci0 is being suspended and > resumed. Actually, it looks like jkim fixed this via the vgapm > driver, except I have no vgapm0 device on my laptop. If you don't have vgapm0, its BIOS is not setting PCIB_BCR_VGA_ENABLE bit to its bridge. Often times, that means it is "legacy free" stuff. > I wonder if it's supposed to be device_get_unit() instead of > device_get_flags() in the vgapm identify routine? No. With multiple GPUs, it is (was?) the only way to find the "boot display" because unit number is not always 0. Although dumbbell added vga_pci_is_boot_display() in current, this interface should be kept for 9.x. Jung-uk Kim -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.21 (FreeBSD) iQEcBAEBAgAGBQJSJkKRAAoJECXpabHZMqHOKLwIAKExzuj82Ak05a7KLzrMmqzI +W0jaoRVCWykCGBpBv4CkejiI5+sliZZcJyNVkC73HOxZuW/VMPb70JqJg83WtHH PdiZ0C/MX5zAlkErNYBiZPT9QwbinzUzbEPGRjjHSO+b3GiUSbE3OGQSBsRCEAHQ JI+4N9UFLssswZoYDeeRuD6AE24di2LGmU+OK01FKd8AvnkSI6MD3F3bBr6o1u6+ bJXMyANxG13JMbnn6QfVG02QSDUqTbG/VuQVuVQJ1ZgFjMPHGFeTEfApxa88TAR2 i5WVCGShpQLmwheQVw+yPiEPi0lLPSCiUj/gRjyvrtducZ1zHJ3f4n/kAVeIUls= =H2G/ -END PGP SIGNATURE- ___ freebsd-acpi@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-acpi To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"
Re: AMT Activation ACPI warnings
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2013-08-20 15:42:12 -0400, Robert Moore wrote: > It appears to be a vendor thing. However, still in direct violation > of the ACPI spec. I believe you're correct. FYI, Linux people have "Optimus" driver and you may find some info from their work: http://bumblebee-project.org/ Especially, this looks interesting regarding _DSM encoding: https://github.com/Bumblebee-Project/bbswitch Jung-uk Kim >> -Original Message- From: Sean Bruno >> [mailto:sean_br...@yahoo.com] Sent: Tuesday, August 20, 2013 >> 12:33 PM To: Moore, Robert Cc: freebsd-acpi@freebsd.org Subject: >> RE: AMT Activation ACPI warnings >> >> On Tue, 2013-08-20 at 19:20 +, Moore, Robert wrote: >>> We have seen at least one video vendor that uses a Buffer >>> object instead of the ACPI-required package object as the 4th >>> _DSM argument. >>> >>> >> >> The T520 has a Nvidia thingy in it. Is this something we need to >> deal with in the BSD ACPI implementation or is this a vendor >> thing? >> >> Sean > ___ > freebsd-acpi@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-acpi To > unsubscribe, send any mail to > "freebsd-acpi-unsubscr...@freebsd.org" > > -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.21 (FreeBSD) iQEcBAEBAgAGBQJSE9Q3AAoJECXpabHZMqHOsrwIAL5pIGgtv+XchpKDCENNuEUz nu9bFMltpDvZUoi/7ly9vkernIRg87XDIDJ5JkpdnVdwREsLZztbOC6aV0F1P1x4 GBEjns3CMKaTxRFgoHjXXgke0LcEunsawvN4bfYQ/WikV+hW6ZoKe2h7pC91rWP6 nK9X9ZYCmYfoMMPJbiF6ZcDhMyWA4zRKQPkKx7EA5XbkzbjMuy++DxqF9lCmQQ4y sZJtVpmlMowCFvcm2WUn6iIFVhvJZT40BKCOXFcUa8TqPtR5cV0Xg9H46kZE9tKt w5/jMbEvgwxoRLg/678tZ5qoi/Wd5MH2UKyLDHd+sxK3w4Yt56agJtI4aRWyiYw= =05PR -END PGP SIGNATURE- ___ freebsd-acpi@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-acpi To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"
Re: ACPI locking bugs?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2013-03-01 02:52:12 -0500, Hans Petter Selasky wrote: > The problem is not locking or locking order, but that the locking > wait for signals. You know when you have a thread, you kan kill it > using a signal. I think at shutdown all threads and processes gets > a KILL signal, and that confuses ACPICA if it is about to grab a > mutex. Hmm... That's an interesting thought. It can happen if a thread gets killed while holding a ACPI mutex/semaphore. However, I am not sure how to fix that situation. With or without PCATCH, it can happen anyway. :-( Jung-uk Kim -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (FreeBSD) iQEcBAEBAgAGBQJRMRv4AAoJECXpabHZMqHOG/EH/3JBUZrkTpybpD6IfdtK5zHP qsTz4YQ0tX5JQUs2mWVdg24fINJ8pRMTKll5WpwHA6qB9lgzVyMFWTNZKwJ/dbLs HY9O1qkYem5a9H7rqU5E8Z1tKUeVlzyQFt7aTuIRbeHAYNseDi1qWZfesNHXk8yD zqSqnMNv0+9a39ct8BLoRBTNa3jaRMrlqf7Ks1skph4e6kQExtoEG5e+rjq39Oiv HZiJbMqcVos+xhDc921NOGgQtHH++aLkhMvimrOhPAnTD/7iNU4uFuSQ5nxeQoDS G6vwJJqMDeHdBdZzW398RIUbJNHQcUJTiLT1U7VQx2QIXhUKNMuKIREQJQwI8rY= =4qjW -END PGP SIGNATURE- ___ freebsd-acpi@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-acpi To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"
Re: ACPI locking bugs?
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 2013-02-27 09:54:53 -0500, Andriy Gapon wrote:
> on 27/02/2013 15:53 Hans Petter Selasky said the following:
>> Hi,
>>
>> What is the reason for using cv_wait_sig() and cv_timedwait_sig()
>> instead of cv_wait() and cv_timedwait() inside of
>> AcpiOsWaitSemaphore(). What signals are supposed to be catched
>> here?
>>
>> switch (Timeout) { case ACPI_DO_NOT_WAIT: if (!ACPISEM_AVAIL(as,
>> Units)) status = AE_TIME; break; case ACPI_WAIT_FOREVER: while
>> (!ACPISEM_AVAIL(as, Units)) { as->as_waiters++; error =
>> cv_wait_sig(&as->as_cv, &as->as_lock); as->as_waiters--; if
>> (error == EINTR || as->as_reset) { status = AE_ERROR; break; } }
>> break; default: tmo = timeout2hz(Timeout); while
>> (!ACPISEM_AVAIL(as, Units)) { prevtick = ticks;
>> as->as_waiters++; error = cv_timedwait_sig(&as->as_cv,
>> &as->as_lock, tmo); as->as_waiters--; if (error == EINTR ||
>> as->as_reset) { status = AE_ERROR; break; } if (ACPISEM_AVAIL(as,
>> Units)) break; slptick = ticks - prevtick; if (slptick >= tmo ||
>> slptick < 0) { status = AE_TIME; break; } tmo -= slptick; } }
When something is miserably waiting forever to grab a mutex/semaphore,
I wanted to be able to kill the misbehaving application, e.g., 'sysctl
- -a' from /etc/rc.d/initrandom. Often times, it is caused by buggy DSDTs.
>> I've observed an issue twice on my MacBookPro that some ACPI
>> locking fails during shutdown on 9-stable and then the power-off
>> won't complete. I've been unable to capture the full dmesg,
>> because syslogd is killed at the moment this happens. There are
>> two ACPI error printouts about failed locking.
I suspect there's a bug in DSDT.
>> I see that in the case of ACPI_WAIT_FOREVER, it appears to be
>> incorrect to catch signals, because sometimes the return argument
>> is not checked for lock operations:
>>
>> ./components/utilities/utosi.c:(void) AcpiOsAcquireMutex
>> (AcpiGbl_OsiMutex, ACPI_WAIT_FOREVER);
>> ./components/utilities/utosi.c:(void) AcpiOsAcquireMutex
>> (AcpiGbl_OsiMutex, ACPI_WAIT_FOREVER);
>> ./components/utilities/utosi.c:(void) AcpiOsAcquireMutex
>> (AcpiGbl_OsiMutex, ACPI_WAIT_FOREVER);
It should be fixed in ACPICA. FYI, here is a patch to address the
problem:
https://github.com/otcshare/acpica/pull/5
IMHO, using ACPI_WAIT_FOREVER is really foot-shooting. In fact, I
believe it should be removed from ACPI specification altogether.
>> Any comments?
>
> kib drew my attention to this issue some time ago and I also pinged
> jkim about it. I completely agree with you that the signal handling
> should be removed. Are you willing to make the change or would you
> prefer me doing it?
Although I don't 100% agree with you, I decided to be more practical.
Please try the attached patch. It is also available from here:
http://people.freebsd.org/~jkim/OsdSynch.diff
I don't think it will fix anything, though.
Jung-uk Kim
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (FreeBSD)
iQEcBAEBAgAGBQJRMRagAAoJECXpabHZMqHO+S8H/RnYNxLlLKM2u3s/VdRKXL1I
+WLgfdUpQoWU8RZvb9Kf7QzpiOsmEkEnUIiwYRkEos7YNUSObt8ivWsuxQx/Sxat
nzRl160HOHf9azgz9hlOfmWl1PLK12gMh/wX6E4WvYJLNQed5OXXlkqq9X4DSJ/Q
CVzxcLcKZYkoMFg1wvQcB1nSP4uGHkdtGQc0qB9WWNt4Gmb5T3wfLiy6T3j2YN3x
gchMhvJVTbbGTb5K1eZyahdacXpW3Ost2z/q/mB1eAjUwnsjF0Q95MzGInvIq3n6
wHizY8RHNDWfAyQMPAyqYFIPdbFjDHX6NFHQIIQw3ewn8fKylMi2npls7a9y51k=
=y21z
-END PGP SIGNATURE-
Index: sys/dev/acpica/Osd/OsdSynch.c
=======
--- sys/dev/acpica/Osd/OsdSynch.c (revision 247571)
+++ sys/dev/acpica/Osd/OsdSynch.c (working copy)
@@ -1,7 +1,7 @@
/*-
* Copyright (c) 2000 Michael Smith
* Copyright (c) 2000 BSDi
- * Copyright (c) 2007-2009 Jung-uk Kim
+ * Copyright (c) 2007-2013 Jung-uk Kim
* All rights reserved.
*
* Redistribution and use in source and binary forms, with or without
@@ -45,6 +45,19 @@ __FBSDID("$FreeBSD$");
#define _COMPONENT ACPI_OS_SERVICES
ACPI_MODULE_NAME("SYNCH")
+/*
+ * Allow the user to tune the maximum seconds to destroy mutex and semaphore.
+ */
+static int acpi_wait_destroy = 10;
+TUNABLE_INT("debug.acpi.sync_wait_destroy", &acpi_wait_destroy);
+
+/*
+ * Allow the user to tune the maximum seconds for ACPI_WAIT_FOREVER.
+ * Note it must be larger than 65 seconds.
+ */
+static int acpi_wait_forever = 120;
+TUNABLE_INT("debug.acpi.sync_wait_forever", &acpi_wait_forever);
+
static MALLOC_DEFINE(M_ACPISEM, "acpisem", "ACPI semaphore");
/*
@@ -54,7 +67,15 @@ static int
timeout2hz(UINT16 Timeout)
{
struct timeval tv;
+ int tmo;
+ if (Timeou
Re: ACPI locking bugs?
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 2013-02-27 08:53:43 -0500, Hans Petter Selasky wrote:
> Hi,
>
> What is the reason for using cv_wait_sig() and cv_timedwait_sig()
> instead of cv_wait() and cv_timedwait() inside of
> AcpiOsWaitSemaphore(). What signals are supposed to be catched
> here?
>
> switch (Timeout) { case ACPI_DO_NOT_WAIT: if (!ACPISEM_AVAIL(as,
> Units)) status = AE_TIME; break; case ACPI_WAIT_FOREVER: while
> (!ACPISEM_AVAIL(as, Units)) { as->as_waiters++; error =
> cv_wait_sig(&as->as_cv, &as->as_lock); as->as_waiters--; if (error
> == EINTR || as->as_reset) { status = AE_ERROR; break; } } break;
> default: tmo = timeout2hz(Timeout); while (!ACPISEM_AVAIL(as,
> Units)) { prevtick = ticks; as->as_waiters++; error =
> cv_timedwait_sig(&as->as_cv, &as->as_lock, tmo); as->as_waiters--;
> if (error == EINTR || as->as_reset) { status = AE_ERROR; break; }
> if (ACPISEM_AVAIL(as, Units)) break; slptick = ticks - prevtick; if
> (slptick >= tmo || slptick < 0) { status = AE_TIME; break; } tmo -=
> slptick; } }
>
> I've observed an issue twice on my MacBookPro that some ACPI
> locking fails during shutdown on 9-stable and then the power-off
> won't complete. I've been unable to capture the full dmesg, because
> syslogd is killed at the moment this happens. There are two ACPI
> error printouts about failed locking.
>
> I see that in the case of ACPI_WAIT_FOREVER, it appears to be
> incorrect to catch signals, because sometimes the return argument
> is not checked for lock operations:
>
> ./components/utilities/utosi.c:(void) AcpiOsAcquireMutex
> (AcpiGbl_OsiMutex, ACPI_WAIT_FOREVER);
> ./components/utilities/utosi.c:(void) AcpiOsAcquireMutex
> (AcpiGbl_OsiMutex, ACPI_WAIT_FOREVER);
> ./components/utilities/utosi.c:(void) AcpiOsAcquireMutex
> (AcpiGbl_OsiMutex, ACPI_WAIT_FOREVER);
>
> Any comments?
>
> Reference: sys/dev/acpica/Osd/OsdSynch.c:AcpiOsWaitSemaphore
I don't exactly remember why it was written like that, sorry.
Probably it was to work around broken mutex uses in ACPICA at the time.
FYI, many ACPICA patches are contributed by Linux developers.
Unfortunately, the Linux OS-dependent code does not implement the
ACPICA OSL API fully and omits some corner cases. [1]
For example, ACPICA mutex is implemented via semaphore:
http://lxr.linux.no/#linux+v3.8/include/acpi/platform/aclinux.h#L51
http://lxr.linux.no/#linux+v3.8/include/acpi/actypes.h#L239
And the semaphore does not support unit > 1 and ACPI_WAIT_FOREVER:
http://lxr.linux.no/#linux+v3.8/drivers/acpi/osl.c#L1227
So, a lot of locking related ACPICA patches ignored these corner
cases. Another problem is that we are very serious about locking
orders but ACPICA doesn't really care much because Linux and others
don't care, really.
Another example is the ACPICA "cache" allocator. It is actually
modeled after Linux's slab allocator, i.e., kmem_cache_*():
http://lxr.linux.no/#linux+v3.8/drivers/acpi/osl.c#L1636
Unfortunately, it doesn't really fit into our closest KPI, i.e.,
zone(9). [2]
We always tried our best to *fully* implement OSL but it is not an
easy task. :-(
Jung-uk Kim
1. For the official ACPICA OS-dependent API, please see "ACPI
Component Architecture User Guide and Programmer Reference". You can
get it from here:
https://www.acpica.org/documentation/
2. There were some patches but I am not really comfortable with any
of these patches yet.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (FreeBSD)
iQEcBAEBAgAGBQJRLl5MAAoJECXpabHZMqHOyi0IAMbzAggbm+XRlVeSFaEtZpvc
6VyceBmTh/OBgO8rdUEXbWuY/CpyQixYBlKIowDa+vJrzhAbA1louywWRvLXlfCc
sbw6yGsX8gMbucU648duTDTePw80JxMLs/Rl7aSXm4Rq+wVNRlnBzs/pOrLjdhfU
0ChK+atphQED9DKNfa7aYAlkANaQ6pDgI03E8Te8Bu5zeflaaSpj2rE7VLlXH/kK
XBbO+83Tsy7/gBdWqdTXtVP2FQQvg39M932ZeD0qFaefd25R9yVr6UppqIF4BtIO
dq9yavmZbkmkM9bstWPdu6D8pV9UlsbyAk6dseXNwpiL1adkacAsigwcXoSa6mE=
=o9HQ
-END PGP SIGNATURE-
___
freebsd-acpi@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"
Re: uma for acpi object cache
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2013-01-26 03:30:27 -0500, Andriy Gapon wrote: > on 25/01/2013 10:38 Andriy Gapon said the following: >> on 24/01/2013 22:33 Jung-uk Kim said the following: >>> On 2013-01-24 13:49:07 -0500, Andriy Gapon wrote: >>>> on 24/01/2013 20:29 Jung-uk Kim said the following: >>>>> When utcache.c works, it works fairly well, actually. :-) >>> >>>> Well, my primary motivation for the patch is all the reports >>>> about mysterious panics that seem to involve the cache: >>>> http://thread.gmane.org/gmane.os.freebsd.devel.acpi/7562 >>>> http://thread.gmane.org/gmane.os.freebsd.devel.acpi/7613 >>>> http://thread.gmane.org/gmane.os.freebsd.devel.acpi/7077 >>> >>>> There were a few more reports with the same theme. I hoped >>>> that using uma(9) instead of hand-rolled code would lead to >>>> better diagnostic and debugging cabilities. >>> >>> Hmm... I am not really sure local cache is to blame here. If >>> you really want to prove your theory, I think a simple >>> modification to utcache.c should do: >>> >>> Cache->LinkOffset = 8; Cache->ListName = CacheName; >>> Cache->ObjectSize = ObjectSize; -Cache->MaxDepth = >>> MaxDepth; +Cache->MaxDepth = 0; >>> >>> *ReturnCache = Cache; return (AE_OK); >>> >>> This should effectively kill object caching. >> >> That's a very simple trick, I wonder why I didn't think about it >> :-) Now I need to wait until one of the reporters resurfaces. > > And just to clarify - I didn't and don't suspect the cache code > itself. I suspect some code that uses the cache (directly or > indirectly) - something like double-free or use-after-free, etc. I haven't tried it for ages but ACPI_DBG_TRACK_ALLOCATIONS was meant to track such problems. Try adding it in acfreebsd.h. Jung-uk Kim -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (FreeBSD) iQEcBAEBAgAGBQJRBsY6AAoJECXpabHZMqHO/sYH/0T/Imtxw70IwN5Ri7qP2C0G +zkZeUosV8hUI8xmXOdQMtyYhBXQprAoewXvAAnx0iCTLYtjNDt0lMGvoyyMDqOW bwupzYE+6GhaTDDc+8bfSxxMbDXgXqFuIqkohBnZPAQ7GdfLNwY2KHwGlA6T+o/s XailQ+sq9zN4VJ6SDoNAvpi1+O9FsO1GJBfnIihdY/S8b99n2ffpOO2XcAIIPwCE huxWnZ/GYVPmoVuvEKyc7CzzsGxRZfdQpJ5e7oPvwM5JAG7GEmc1VzRDPBtCFBWL VO3sBH3ObKX2+H0LhU9tskCVsmuzD0U+/ygF3P8NRkuLP7Y/yQiAWIoZeEr1saI= =05h0 -END PGP SIGNATURE- ___ freebsd-acpi@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-acpi To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"
Re: uma for acpi object cache
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2013-01-24 13:49:07 -0500, Andriy Gapon wrote: > on 24/01/2013 20:29 Jung-uk Kim said the following: >> On 2013-01-24 04:41:08 -0500, Andriy Gapon wrote: >>> on 24/01/2013 02:54 Jung-uk Kim said the following: I think >>> that I have a much better patch for all potential ACPI object >>> cache problems :-) >>> http://people.freebsd.org/~avg/acpi-uma-cache.diff >> >>> What do you think? >> >> We have to fix this bug because local cache is always used for >> userland applications, e.g., iasl. > > Could you please clarify what problem/bug is fixed by that patch? I > looked hard but couldn't spot any difference besides moving the > link pointer from offset 8 to offset 0. If I am not completely mistaken, this is what's happening: https://github.com/otcshare/acpica/pull/3 Please see ACPI_OBJECT_COMMON_HEADER macro change in the commit I mentioned the pull request. Before the commit: UINT8 Descriptor; UINT8 Type; UINT16 ReferenceCount; union acpi_operand_object *NextObject; UINT8 Flags; After the commit: union acpi_operand_object *NextObject; UINT8 DescriptorType; UINT8 Type; UINT16 ReferenceCount; UINT8 Flags; It may not look obvious but LinkOffset was used to keep offset of NextObject (and it was only "safe" for certain compilers & platforms). Alas, it is completely bogus now because the pointer became the first element of any object. Although it was the right decision, the author forgot to change the LinkOffset with this commit, I guess. Now, modifying DescriptorType, Type, ReferenceCount, or Flags silently corrupts the linked list. Similarly, modifying any of these before setting the pointer gets silently clobbered. For example, ACPI_SET_DESCRIPTOR_TYPE() in AcpiOsReleaseObject() is effectively no-op because it's overwritten later. Does it make sense to you? >> BTW, I tried something like that long ago. In fact, the first >> attempt goes all the way back to this patch (warning: it's naive, >> broken, and overly complicated): >> >> http://people.freebsd.org/~jkim/acpica/OsdCache.diff >> >> I have more up-to-date and correct patch to use UMA but I'm still >> not 100% convinced whether we want to do it or not. > > Hmm, your patch looks a bit more complicated than mine. What is all > that extra stuff that you have there? The main issue was AcpiOsPurgeCache(). For example, we didn't have anything like Linux's kmem_cache_shrink() at the time: http://www.kernel.org/doc/htmldocs/kernel-api/API-kmem-cache-shrink.html It seems you implemented that with zone_drain() but it wasn't available until this commit: http://svnweb.freebsd.org/base?view=revision&revision=166213 Also, I had to make sure the cache is empty before we do uma_zdestroy(), so on and so forth. >> When utcache.c works, it works fairly well, actually. :-) > > Well, my primary motivation for the patch is all the reports about > mysterious panics that seem to involve the cache: > http://thread.gmane.org/gmane.os.freebsd.devel.acpi/7562 > http://thread.gmane.org/gmane.os.freebsd.devel.acpi/7613 > http://thread.gmane.org/gmane.os.freebsd.devel.acpi/7077 > > There were a few more reports with the same theme. I hoped that > using uma(9) instead of hand-rolled code would lead to better > diagnostic and debugging cabilities. Hmm... I am not really sure local cache is to blame here. If you really want to prove your theory, I think a simple modification to utcache.c should do: Cache->LinkOffset = 8; Cache->ListName = CacheName; Cache->ObjectSize = ObjectSize; - -Cache->MaxDepth = MaxDepth; +Cache->MaxDepth = 0; *ReturnCache = Cache; return (AE_OK); This should effectively kill object caching. Jung-uk Kim -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (FreeBSD) iQEcBAEBAgAGBQJRAZquAAoJECXpabHZMqHOE9EIANaY52hh9wpflBCsISJHHmS0 MTtrEiLeC+SqUd8Z+WN0QCLkg9xitryuoyDEK+bMKfn5p5zjJQEL4OyEHSuN37I3 j06UU8gcti6Q8nv5f0EjgT/RR9WR8/AJfIta6neaiX+5cZxARpj86avD+hf8Mv71 7LiiDtbDIzkwf4bXM0kkhs5+UPCqlkCzZUHzMNQ8CZsmtIy8vfw3wagpYfX0nMhN YjdZkADo2f46lgZw409VBOxfwewrzrhYWeCG3ETPBM0YCYRsmU47dWNlnWFkqIQY OZT4BIu0sHtGYzCwamWKBDCSklpzGgYqk2V4eRZcm8b/BLCnS712GkqZfNYsei0= =ObAy -END PGP SIGNATURE- ___ freebsd-acpi@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-acpi To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"
Re: acpi patches in gnats that are rotting
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2012-07-02 12:22:28 -0400, Sean Bruno wrote: > http://www.freebsd.org/cgi/query-pr.cgi?pr=121504 This is no longer relevant after r214390: http://svnweb.freebsd.org/base?view=revision&revision=214390 > http://www.freebsd.org/cgi/query-pr.cgi?pr=135349 If my memory serves, I objected it at the time. I don't really remember exactly why, though. I *think* my objection was something along the line of "not safe without mem range check and header validation". Jung-uk Kim -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk/xzu8ACgkQmlay1b9qnVPyPQCgv/fXkWZFmRc0og9YzOjFQBdL 9woAoJnP/vzFfPmEoYqpjaLoWu/w0SZM =4qEc -END PGP SIGNATURE- ___ freebsd-acpi@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-acpi To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"
Re: [CFT] SMP/i386 suspend/resume
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2012-05-15 03:30:02 -0400, Peter Jeremy wrote: > I wrote: >>> Thank you for that. Since I was in the process of upgrading my >>> netbook (Acer Aspire One AOA-110 - Atom N270), I rolled your >>> RELENG_8 patch on top of r235229. >>> >>> Unfortunately, the result hasn't been a complete success. > > On 2012-May-13 22:53:28 +0900, Mitsuru IWASAKI > wrote: >> I think graphic driver (or pic?) has some problems on resume and >> they are out of scope of my patches. HEAD and RELENG_9 have >> better support on interrupt re-enabling than RELENG_8 I think. >> Could you try them? And for ps/2 mouse, kernel option >> PSM_HOOKRESUME and PSM_RESETAFTERSUSPEND would be useful. > > I've tried stable/9 r235399 with your patches as well as > PSM_HOOKRESUME and PSM_RESETAFTERSUSPEND and suspend/resume now > works (for the first time) from VTY. FYI, you don't need the kernel options. You just have to add the following line to /boot/loader.conf: hint.psm.0.flags="0x6000" It is much easier for us to debug the issue. Please revert the kernel options and give us the following results. 1. Test psm and moused without the above hint. 2. Test psm and moused with "hint.psm.0.flags="0x2000". 3. Test psm and moused with "hint.psm.0.flags="0x6000". 4. Verbose dmesg output (for the touch pad model strings). > I haven't tried suspending directly from X but expect that is > still broken. I believe you have Intel graphics, right? Then, you need kib's KMS patchset to make it happen. http://wiki.freebsd.org/Intel_GPU Jung-uk Kim -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk+yjIEACgkQmlay1b9qnVPogACgj+HUK/lYje8MBvca1oUI6A82 gJMAoKkDSb/KW/CEZ8+Hw7RAUGDIOw8t =IFVX -END PGP SIGNATURE- ___ freebsd-acpi@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-acpi To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"
Re: [CFT] SMP/i386 suspend/resume
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2012-05-14 00:16:17 -0400, Mitsuru IWASAKI wrote: > Hi, > >>>> Reporting from an Acer Centrino Duo, running CURRENT r235266. >>>> The machine has an nvidia card (Ge7300go). The acpi_video and >>>> nvidia modules are there. >>>> >>>> I did test it a few times with X running (plain twm) and >>>> worked just fine. Setting hw.acpi.lid_switch_state=S3 allowed >>>> me to use the close-the-lid-to-sleep functionality. >>>> >>>> The problem comes when I suspend the machine in the console. >>>> The machine resumes fine (I can ping and ssh it) but the >>>> screen remains black. I set hw.acpi.reset_video to 0 or 1 but >>>> no go. If I'm in a console but X is running, after the resume >>>> I can CTRL+ALT+F9 and get my video back; then I can return to >>>> the console. If I don't have X running, I don't know how to >>>> get my console back. >>> >>> I think this is graphic driver problem. nvidia's driver seems >>> to have correct suspend/resume method. >>> http://www.nvidia.com/object/freebsd_archive.html >>> >>> Have you try it? >> >> Yes, it is running the propietary driver. Everything was done >> with it loaded. Do you want me to try without the nvidia binary >> driver? First of all, thank you very much for your work! I wanted to do it for very long time but I had no time to actually implement it. :-) > Yes, if it doesn't bother you. Hmmm, it doesn't seem related with > my SMP/i386 sleep patches. I know for sure it is not related to your patches. In fact, we cannot resume most NVIDIA controllers without NVIDIA kernel driver + binary X.org driver + VT switching hack (i.e., hw.syscons.sc_no_suspend_vtswitch=0, which is default). Also, there is ACPI_PM option for ports/x11/nvidia-driver but it doesn't help much because it doesn't seem to save/restore GPU registers by itself (off by default). Very few NVIDIA controllers can be reset with BIOS POST or saved/restored with VBE functions. Many Intel controllers have similar issues and they need kib's KMS driver. Usually, ATI/AMD controllers have no problem when (relatively recent) vesa.ko is compiled into kernel or loaded as module as they have complete VBE save/restore functions. Similarly, any video controllers with correct save/restore functions should work with vesa.ko. > Could you try also Uni-processer kernel (w/o SMP and apic from > config file) without my patches? > >> OTOH, IIRC the console only test (without X) without acpi_video >> lead to freeze. No crash dump. The machine has no serial or fwire >> ports :( > > We can improve video initialization on another opportunity. Linux > have many video hacks while we have only hw.acpi.reset_video ;) FYI, we don't need hw.acpi.reset_video any more (and it is even harmful). It is done from vesa.ko now. > http://www.kernel.org/doc/Documentation/power/video.txt I believe > there are some solutions for you in this document, then we can > implement them in our source if found. Most of these Linux hacks are completely obsolete since KMS. I really don't want to reiterate Linux mistakes again. Jung-uk Kim -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk+xRvcACgkQmlay1b9qnVP1NwCfVPMz1YhvUcyyhWkQjs4JZdgd B0gAoKuv4ST+N7FInyfaMwMYuFe4AfNx =jk3/ -END PGP SIGNATURE- ___ freebsd-acpi@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-acpi To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"
Re: Suspend/resume on Macbooks: partial diagnosis
On Sunday 26 February 2012 04:33 pm, Eric McCorkle wrote: > A while ago, I tried to diagnose the reason why suspend/resume > doesn't work on my macbook (9.0-STABLE, 13' unibody macbook pro, > 5,5, I think). I got a partial answer, but then got busy and never > finished. The recent KDE update apparently triggers a suspend, so > I had incentive to look at it again, and also to report my previous > findings, in case someone else has information or can fix it. Can you please show us more detail, e.g., "devinfo -rv", "pciconf -lv", verbose dmesg, etc? > Here's what I have: > > The USB system sometimes fails to come back up, but this seems to > be a more general issue not specific to the hardware. The firewire > system would also sometimes trigger a kernel panic, but that was > almost a year ago on 9-CURRENT, and firewire was causing other > issues, so I disabled it and haven't used it since. These are very common issues, unfortunately. :-( > The VGA system fails to come back up, reporting "vga0: failed to > reload state". I traced this error using extra logging messages to > the BIOS POST call, at which point the x86emu system emulates the > bios. From looking at the error message, disassembly of the BIOS > code, and the memory map I am almost certain I know why. I'd meant > to confirm it 100%, but I got busy. Actually, the error message has nothing to do with BIOS POST call. Do you have NVIDIA GPU on it? > The root problem seems to be bad BIOS code that accesses the stack > one word above the region allocated by the BIOS memory map (the map > allocates 0x1000-0x1fff, the code dereferences 0x2000, or something > similar). This is *technically* an error, but it does not cause a > problem during boot, because there is always good memory at that > address. The BIOS emulation system, however, seems to only > allocate the regions described by the memory map, and thus treats > it as an error (as a strictly-conforming BIOS implementation > would). > > A quick-and-dirty fix might be to add an extra page above the stack > region. I'm not sure what a more "legitimate" fix might be, since > it's the BIOS code and not FreeBSD that's causing the problem. > I'll probably take a closer look in the near future. x86bios virtualizes real-mode memory and invalid memory access immedidately halts the emulator. In other words, it shouldn't happen. ;-) Jung-uk Kim ___ freebsd-acpi@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-acpi To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"
Re: Suspend and resume on Dell E6520
On Thursday 24 November 2011 01:33 am, Sebastian Chmielewski wrote: > On Wed, 23 Nov 2011 20:50:58 -0500 > > Jung-uk Kim wrote: > > Usually, we cannot resume console on NVIDIA graphics, which often > > times lack or has incomplete VBE save/restore state function. > > I had kldunload nvidia in rc.suspend. Isn't that enough? No, it doesn't (can't) save/restore GPU state. In fact, nvidia.ko may help when you are suspending from X11. At least in theory, it should be able to save/restore GPU state correctly. However, a NVIDIA engineer once told me that the code path wasn't tested well because he couldn't find a right laptop to test at the time. It was long ago, though. Jung-uk Kim ___ freebsd-acpi@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-acpi To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"
Re: Suspend and resume on Dell E6520
On Monday 24 October 2011 12:47 pm, Sebastian Chmielewski wrote: > Hi, > I've reported two bugs related to suspend and resume on Dell E6520 > (misc/161715 and misc/161713). > First is that system goes to sleep only when key sequence like > 'Ctrl-C' is pressed after command 'zzz'. > Second is that this system cannot resume from suspend. Nothing is > shown on attached firewire console and removing (or not loading at > all at boot time) nvidia.ko didn't help. I've booted kernel without > additional modules (I've most of drivers compiled as modules) but > it didn't help. > > What is needed to debug this issues? [snip] > vgapci0@pci0:1:0:0: class=0x03 card=0x04941028 > chip=0x105610de rev=0xa1 hdr=0x00 vendor = 'NVIDIA Corporation' > class = display > subclass = VGA [snip] Usually, we cannot resume console on NVIDIA graphics, which often times lack or has incomplete VBE save/restore state function. Jung-uk Kim ___ freebsd-acpi@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-acpi To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"
Re: regression in power management since r216674 (kern/162578)
[Forwarding thread regarding kern/162578]
On Tuesday 22 November 2011 03:05 pm, John Baldwin wrote:
> [ Adding jkim@, could probably resend this thread to acpi@. ]
>
> On Tuesday, November 22, 2011 2:52:26 pm kron wrote:
> > On 2011/11/22 14:58, John Baldwin wrote:
> > > On Tuesday, November 22, 2011 5:05:40 am kron wrote:
> > >> Hi John,
> > >>
> > >> I dare to write directly to you because this seems to be
> > >> related to your commit r216674.
> > >>
> > >> I tried to open this on -stable a week ago ("9.0-RC2:
> > >> regression in power management on VIA Samuel 2") but didn't
> > >> attract an attention. In the meanwhile I created kern/162578
> > >> and after some bisecting came to a conclusion that my power
> > >> management issue was caused by r216674. In summary:
> > >>
> > >> With r216673, sysctl shows:
> > >> dev.cpu.0.%desc: ACPI CPU
> > >> dev.cpu.0.%driver: cpu
> > >> dev.cpu.0.%location: handle=\_PR_.CPU0
> > >> dev.cpu.0.%pnpinfo: _HID=none _UID=0
> > >> dev.cpu.0.%parent: acpi0
> > >> dev.cpu.0.freq: 532
> > >> *dev.cpu.0.freq_levels:* 532/-1 266/-1
> > >> *dev.cpu.0.cx_supported:* C1/0 C2/90 C3/900
> > >> dev.cpu.0.cx_lowest: C2
> > >> I can set dev.cpu.0.cx_lowest and run powerd, too.
> > >>
> > >> With r216674:
> > >> dev.cpu.0.%desc: ACPI CPU
> > >> dev.cpu.0.%driver: cpu
> > >> dev.cpu.0.%location: handle=\_PR_.CPU0
> > >> dev.cpu.0.%pnpinfo: _HID=none _UID=0
> > >> dev.cpu.0.%parent: acpi0
> > >> dev.cpu.0.cx_supported: C1/0
> > >> dev.cpu.0.cx_lowest: C1
> > >> dev.cpu.0.cx_usage: 100.00% last 208us
> > >> The C2 and C3 states and frequency levels are away and
> > >> powerd fails to start:
> > >> powerd: lookup freq: No such file or directory
> > >>
> > >> I tried to study acpi.c but it's a totally new area to me
> > >> - I'm 15 years away from C and have zero experience with
> > >> HW, kernels or so. I have a spare machine affected by this
> > >> and I'm willing to work on this issue. I'm going to find
> > >> some help at -users@ but before that, can you give me any
> > >> advice or tip, please?
> > >
> > > Sure, perhaps acpi_cpu() is failing to attach. Can you get
> > > verbose dmesg from before and after the change?
> >
> > Thank you very much!
> >
> > Both dmesgs attached. The difference between r216673
> > and r216674 is as follows:
> >
> > -Calibrating TSC clock ... TSC clock: 532647138 Hz
> > +Calibrating TSC clock ... TSC clock: 532648183 Hz
> >
> > -ACPI timer: 0/4 0/5 0/4 0/5 0/4 0/5 0/4 0/5 0/4 0/4 -> 0
> > -Timecounter "ACPI-safe" frequency 3579545 Hz quality 850
> > -acpi_timer0: <24-bit timer at 3.579545MHz> port 0x4008-0x400b on
> > acpi0 +acpi_timer0: couldn't allocate resource (port 0x4008)
> >
> > -acpi_throttle0: P_CNT from P_BLK 0x4010
> > +acpi_throttle0: failed to attach P_CNT
> > +device_attach: acpi_throttle0 attach returned 6
>
> So this is the issue, and it seems what happens is that your BIOS
> assigns the resources for this range to the pcib0 device when we
> expect them to be assigned as a system resource (if at all):
>
> pcib0: port
> 0xcf8-0xcff,0x4000-0x407f,0x4080-0x40ff,0x5000-0x500f,0x6000-0x607f
> on acpi0
>
> You could try hacking your ASL to not list the 0x4000-0x407f range
> for now, but the real fix is probably to make resources attached to
> Host-PCI bridge devices be treated as if they were system resources
> and put into the ACPI system resource rman instead. That requires
> a fair bit of work however.
___
freebsd-acpi@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"
Re: (Missing) power states of an Atom N455-based netbook
On Wednesday 13 July 2011 10:32 am, Vitaly Magerya wrote: > Taku YAMAMOTO wrote: > > Ah, the line in the acpi_cpu_mwait function should be read as: > > > > cpu_monitor(state, 0, 0); > > > > Vitaly, could you test the jkim's patch again with the above line > > modified? I fixed that bug in the later patches, e.g., http://people.freebsd.org/~jkim/acpi_cx_native.diff However, it doesn't work yet. Please see below. > Sure. With the above change it hangs during the boot. > > Here are the last two lines before the hang with verbose boot: > > acpi_acad0: acline initialization start > acpi_battery0: battery initialization start It is a known problem and the above patch hangs, too. :-( Actually, I abandoned the patches and I am thinking about rewriting it from scratch, e.g., refactoring MI/MD support code (dev/acpica/acpi_cpu.c -> machine/machdep.c & acpica/acpi_machdep.c). Unfortunately, I don't have much time nor hardware to test, so it won't happen any time soon. Sorry. If anyone wants to pick it up from here, please feel free. Jung-uk Kim ___ freebsd-acpi@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-acpi To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"
Re: (Missing) power states of an Atom N455-based netbook
On Thursday 30 June 2011 03:49 pm, Vitaly Magerya wrote: > Andriy Gapon wrote: > > on 28/06/2011 22:37 Vitaly Magerya said the following: > >> Is there some simple way of sending fake advertisement? Or will > >> that lead to disaster? > > > > It doesn't make sense without actual support. > > And maybe (just maybe) it won't change much anyway. > > I see. Should I hold my breath for this code? :-) I have written a very rough patch and it is available from here: http://people.freebsd.org/~jkim/acpi_cst.diff It compiles but wasn't tested at all, i.e., I have no hardware. Please be careful. Jung-uk Kim ___ freebsd-acpi@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-acpi To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"
Re: (Missing) power states of an Atom N455-based netbook
On Tuesday 28 June 2011 05:26 pm, Andriy Gapon wrote: > on 28/06/2011 22:14 Jung-uk Kim said the following: > > On Tuesday 28 June 2011 07:28 am, Andriy Gapon wrote: > >> I think that part (but not all) of the differences between > >> FreeBSD and Linux can be explained by the fact that FreeBSD > >> currently doesn't advertise itself as featuring > >> ACPI_CAP_SMP_C1_NATIVE and ACPI_CAP_SMP_C3_NATIVE. I am not > >> sure what it would take to actually support these features. I > >> think that Linux does support (or at least advertise support) > >> for these features. > > > > Yes, Linux supports this Intel-specific feature. I think it > > shouldn't be too hard for us, however. We just have to add > > support for Intel-specific _CST FFH (Functional Fixed Hardware) > > in > > sys/dev/acpica/acpi_cpu.c. You can find more information from > > "Intel Processor Vendor-Specific ACPI" (order number 302223-005) > > on Intel website. Also, arch/x86/kernel/acpi/cstate.c of Linux > > source may help. I believe Linux actually supports all > > Intel-specific FFHs, BTW. > > Once upon a time there was a patch proposed for FreeBSD: > http://thread.gmane.org/gmane.os.freebsd.current/127860/focus=6372 > Unfortunately I have never really evaluated it. Hmm, interesting patch. I think he is in the right direction. Thanks for sharing, Jung-uk Kim ___ freebsd-acpi@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-acpi To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"
Re: (Missing) power states of an Atom N455-based netbook
On Tuesday 28 June 2011 05:18 pm, Andriy Gapon wrote: > on 29/06/2011 00:13 Jung-uk Kim said the following: > > On Tuesday 28 June 2011 03:37 pm, Vitaly Magerya wrote: > >>> I think that part (but not all) of the differences between > >>> FreeBSD and Linux can be explained by the fact that FreeBSD > >>> currently doesn't advertise itself as featuring > >>> ACPI_CAP_SMP_C1_NATIVE and ACPI_CAP_SMP_C3_NATIVE. I am not > >>> sure what it would take to actually support these features. I > >>> think that Linux does support (or at least advertise support) > >>> for these features. > >> > >> Is there some simple way of sending fake advertisement? Or will > >> that lead to disaster? > > > > Actually, ACPI_CAP_SMP_C1_NATIVE is kinda supported but without > > hints from ACPI _CST FFH. It sits in machdep.c as > > cpu_idle_mwait(). So, I think you can advertise them. The > > easist way is this (not tested): > > But don't we currently ignore FFH-type C state definitions? Correct. > I am not sure that mwait that we use (its parameters) would be the > same as the system would expect us to use unless we actually parse > FFH data. Even for C1 sate. It is unfortunate but you're correct. We don't have correct support code yet. > Also I am not sure if that would give much gain/difference. Just for the sake of testing your theory, nothing more, nothing less. Jung-uk Kim ___ freebsd-acpi@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-acpi To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"
Re: (Missing) power states of an Atom N455-based netbook
On Tuesday 28 June 2011 03:37 pm, Vitaly Magerya wrote:
> > I think that part (but not all) of the differences between
> > FreeBSD and Linux can be explained by the fact that FreeBSD
> > currently doesn't advertise itself as featuring
> > ACPI_CAP_SMP_C1_NATIVE and ACPI_CAP_SMP_C3_NATIVE. I am not sure
> > what it would take to actually support these features. I think
> > that Linux does support (or at least advertise support) for these
> > features.
>
> Is there some simple way of sending fake advertisement? Or will
> that lead to disaster?
Actually, ACPI_CAP_SMP_C1_NATIVE is kinda supported but without hints
from ACPI _CST FFH. It sits in machdep.c as cpu_idle_mwait(). So,
I think you can advertise them. The easist way is this (not tested):
Index: sys/dev/acpica/acpi_cpu.c
===
--- sys/dev/acpica/acpi_cpu.c (revision 223651)
+++ sys/dev/acpica/acpi_cpu.c (working copy)
@@ -339,6 +339,10 @@ acpi_cpu_attach(device_t dev)
* SMP control where each CPU can have different settings.
*/
sc->cpu_features = ACPI_CAP_SMP_SAME | ACPI_CAP_SMP_SAME_C3;
+#if defined(__amd64__) || defined(__i386__)
+if ((cpu_feature2 & CPUID2_MON) != 0)
+ sc->cpu_features |= ACPI_CAP_SMP_C1_NATIVE;
+#endif
if (devclass_get_drivers(acpi_cpu_devclass, &drivers, &drv_count) == 0) {
for (i = 0; i < drv_count; i++) {
if (ACPI_GET_FEATURES(drivers[i], &features) == 0)
ACPI_CAP_SMP_C3_NATIVE is also kinda supported without hints from
the GAS.
Jung-uk Kim
___
freebsd-acpi@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"
Re: (Missing) power states of an Atom N455-based netbook
On Tuesday 28 June 2011 07:28 am, Andriy Gapon wrote: > I think that part (but not all) of the differences between FreeBSD > and Linux can be explained by the fact that FreeBSD currently > doesn't advertise itself as featuring ACPI_CAP_SMP_C1_NATIVE and > ACPI_CAP_SMP_C3_NATIVE. I am not sure what it would take to > actually support these features. I think that Linux does support > (or at least advertise support) for these features. Yes, Linux supports this Intel-specific feature. I think it shouldn't be too hard for us, however. We just have to add support for Intel-specific _CST FFH (Functional Fixed Hardware) in sys/dev/acpica/acpi_cpu.c. You can find more information from "Intel Processor Vendor-Specific ACPI" (order number 302223-005) on Intel website. Also, arch/x86/kernel/acpi/cstate.c of Linux source may help. I believe Linux actually supports all Intel-specific FFHs, BTW. Jung-uk Kim ___ freebsd-acpi@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-acpi To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"
Re: [PATCH] Move scsuspend()/scresume() forward to EVENTHANDLERs
On Tuesday 19 April 2011 05:27 pm, Brandon Gooch wrote: > On Tue, Apr 19, 2011 at 4:02 PM, Jung-uk Kim wrote: > > On Tuesday 19 April 2011 04:55 pm, Brandon Gooch wrote: > >> On Tue, Apr 19, 2011 at 3:24 PM, Jung-uk Kim > > > > wrote: > >> > On Tuesday 19 April 2011 04:02 pm, Warner Losh wrote: > >> >> Having chased boogiemen in this area before, I think this > >> >> patch makes good sense even though it breaks the device model > >> >> a little. However, the hardware in question really is special > >> >> on x86... > >> >> > >> >> Warner > >> > > >> > Actually I was working on a similar patch and it should be > >> > ready soon. > >> > > >> > Jung-uk Kim > >> > >> You have a willing (if not completely capable) tester here, so I > >> always look forward to your patches. > >> > > :-) > > > > http://people.freebsd.org/~jkim/syscons.diff > > > > Also attached here. > > Cool, building now... > > I noticed you didn't grab the Giant lock, which shouldn't be needed > since Ed's work, correct? Actually the real reason is locking is completely missing in syscons(4) since we abandoned spltty(). Grabbing Giant here makes no difference because of that reason. :-( > >> As the situation has greatly improved, I hesitate to even say > >> this, but...I wish the USB stack could be made to be > >> suspend/resume resilient. It's really the only problem child in > >> my laptop. Fortunately, it's easy enough to build the USB stack > >> as modules and unload/reload them. > > > > I tried to do something about it but new USB stack is completely > > out of my expertise, unfortunately. :-( > > > > Jung-uk Kim > > I understand, and again, I know it seems like I always bring it up > to you whenever I get the chance -- because I do. Sorry :| That's okay, I'm used to it. ;-) > I should bug someone else (Hans or Andrew Thompson), or maybe the > PC-BSD guys might get interested in fixing this eventually -- after > GEM, KMS, etc... ;) Yeah, maybe... Jung-uk Kim ___ freebsd-acpi@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-acpi To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"
Re: [PATCH] Move scsuspend()/scresume() forward to EVENTHANDLERs
On Tuesday 19 April 2011 04:55 pm, Brandon Gooch wrote:
> On Tue, Apr 19, 2011 at 3:24 PM, Jung-uk Kim
wrote:
> > On Tuesday 19 April 2011 04:02 pm, Warner Losh wrote:
> >> Having chased boogiemen in this area before, I think this patch
> >> makes good sense even though it breaks the device model a
> >> little. However, the hardware in question really is special on
> >> x86...
> >>
> >> Warner
> >
> > Actually I was working on a similar patch and it should be ready
> > soon.
> >
> > Jung-uk Kim
>
> You have a willing (if not completely capable) tester here, so I
> always look forward to your patches.
:-)
http://people.freebsd.org/~jkim/syscons.diff
Also attached here.
> As the situation has greatly improved, I hesitate to even say this,
> but...I wish the USB stack could be made to be suspend/resume
> resilient. It's really the only problem child in my laptop.
> Fortunately, it's easy enough to build the USB stack as modules and
> unload/reload them.
I tried to do something about it but new USB stack is completely out
of my expertise, unfortunately. :-(
Jung-uk Kim
Index: sys/isa/syscons_isa.c
===
--- sys/isa/syscons_isa.c (revision 220864)
+++ sys/isa/syscons_isa.c (working copy)
@@ -69,18 +69,7 @@ __FBSDID("$FreeBSD$");
static devclass_t sc_devclass;
static sc_softc_t main_softc;
-#ifdef SC_NO_SUSPEND_VTYSWITCH
-static int sc_no_suspend_vtswitch = 1;
-#else
-static int sc_no_suspend_vtswitch = 0;
-#endif
-static int sc_cur_scr;
-TUNABLE_INT("hw.syscons.sc_no_suspend_vtswitch", &sc_no_suspend_vtswitch);
-SYSCTL_DECL(_hw_syscons);
-SYSCTL_INT(_hw_syscons, OID_AUTO, sc_no_suspend_vtswitch, CTLFLAG_RW,
-&sc_no_suspend_vtswitch, 0, "Disable VT switch before suspend.");
-
static void
scidentify(driver_t *driver, device_t parent)
{
@@ -108,53 +97,6 @@ scattach(device_t dev)
SC_AUTODETECT_KBD));
}
-static int
-scsuspend(device_t dev)
-{
- int retry = 10;
- sc_softc_t *sc;
-
- sc = &main_softc;
-
- if (sc->cur_scp == NULL)
- return (0);
-
- if (sc->suspend_in_progress == 0) {
- sc_cur_scr = sc->cur_scp->index;
- if (!sc_no_suspend_vtswitch && sc_cur_scr != 0)
- do {
- sc_switch_scr(sc, 0);
- if (!sc->switch_in_progress)
- break;
- pause("scsuspend", hz);
- } while (retry--);
- }
- sc->suspend_in_progress++;
-
- return (0);
-}
-
-static int
-scresume(device_t dev)
-{
- sc_softc_t *sc;
-
- sc = &main_softc;
-
- if (sc->cur_scp == NULL)
- return (0);
-
- sc->suspend_in_progress--;
- if (sc->suspend_in_progress == 0) {
- if (!sc_no_suspend_vtswitch && sc_cur_scr != 0)
- sc_switch_scr(sc, sc_cur_scr);
- else
- mark_all(sc->cur_scp);
- }
-
- return (0);
-}
-
int
sc_max_unit(void)
{
@@ -300,8 +242,6 @@ static device_method_t sc_methods[] = {
DEVMETHOD(device_identify, scidentify),
DEVMETHOD(device_probe, scprobe),
DEVMETHOD(device_attach,scattach),
- DEVMETHOD(device_suspend, scsuspend),
- DEVMETHOD(device_resume,scresume),
{ 0, 0 }
};
@@ -312,70 +252,3 @@ static driver_t sc_driver = {
};
DRIVER_MODULE(sc, isa, sc_driver, sc_devclass, 0, 0);
-
-static devclass_t scpm_devclass;
-
-static void
-scpm_identify(driver_t *driver, device_t parent)
-{
-
- device_add_child(parent, "scpm", 0);
-}
-
-static int
-scpm_probe(device_t dev)
-{
-
- device_set_desc(dev, SC_DRIVER_NAME " suspend/resume");
- device_quiet(dev);
-
- return (BUS_PROBE_DEFAULT);
-}
-
-static int
-scpm_attach(device_t dev)
-{
-
- bus_generic_probe(dev);
- bus_generic_attach(dev);
-
- return (0);
-}
-
-static int
-scpm_suspend(device_t dev)
-{
- int error;
-
- error = bus_generic_suspend(dev);
- if (error != 0)
- return (error);
-
- return (scsuspend(dev));
-}
-
-static int
-scpm_resume(device_t dev)
-{
-
- scresume(dev);
-
- return (bus_generic_resume(dev));
-}
-
-static device_method_t scpm_methods[] = {
- DEVMETHOD(device_identify, scpm_identify),
- DEVMETHOD(device_probe, scpm_probe),
- DEVMETHOD(device_attach,scpm_attach),
- DEVMETHOD(device_suspend, scpm_suspend),
- DEVMETHOD(device_resume,scpm_resume),
- { 0, 0 }
-};
-
-static drive
Re: [PATCH] Move scsuspend()/scresume() forward to EVENTHANDLERs
On Tuesday 19 April 2011 04:02 pm, Warner Losh wrote: > Having chased boogiemen in this area before, I think this patch > makes good sense even though it breaks the device model a little. > However, the hardware in question really is special on x86... Actually I was working on a similar patch and it should be ready soon. Jung-uk Kim > Warner > > On Apr 19, 2011, at 12:48 PM, Brandon Gooch wrote: > > On Tue, Apr 19, 2011 at 10:46 AM, Taku YAMAMOTO wrote: > >> On Wed, 20 Apr 2011 00:31:33 +0900 > >> > >> Taku YAMAMOTO wrote: > >>> A patch is attached. > >> > >> Mailman ate it ;) > >> Here it is. > >> > >> -- > >> -|-__ YAMAMOTO, Taku > >> > >> | __ < > >> > >> - A chicken is an egg's way of producing more eggs. - > > > > Throughout testing, I've seen zero regressions. In fact, an issue > > that existed prior to this patch involving minor screen > > corruption (dirty VGA buffers) is gone (Intel Mobile 965 > > Express). > > > > Thank you so much guys! > > > > -Brandon > > ___ > > freebsd-acpi@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-acpi > > To unsubscribe, send any mail to > > "freebsd-acpi-unsubscr...@freebsd.org" > > ___ > freebsd-acpi@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-acpi > To unsubscribe, send any mail to > "freebsd-acpi-unsubscr...@freebsd.org" ___ freebsd-acpi@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-acpi To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"
Re: Panic after update kernel
On Wednesday 16 March 2011 07:49 pm, Moore, Robert wrote: > The latest version of acpica released today (20110316) should fix > this issue for you. Cool! I just committed it on HEAD now. Please try it and let us know. Thanks! Jung-uk Kim > Bob > > >-Original Message----- > >From: Jung-uk Kim [mailto:j...@freebsd.org] > >Sent: Wednesday, March 16, 2011 3:22 PM > >To: Andriy Gapon > >Cc: Ilya A. Arhipov; Moore, Robert; freebsd-acpi@freebsd.org > >Subject: Re: Panic after update kernel > > > >On Wednesday 16 March 2011 11:12 am, Andriy Gapon wrote: > >> on 16/03/2011 16:18 Ilya A. Arhipov said the following: > >> > 2011/3/16 Andriy Gapon >> > <mailto:a...@freebsd.org>> > >> > > >> > on 16/03/2011 10:52 Ilya A. Archipov said the following: > >> > > and see: > >> > > http://imm.io/4nzZ > >> > > > >> > > what information still needs to provide? > >> > > >> > 'bt' command output please (a screenshot is fine). > >> > > >> > -- > >> > Andriy Gapon > >> > > >> > > >> > boot: > >> > http://imm.io/4nTZ > >> > bt: > >> > http://imm.io/4nTS <-first > >> > http://imm.io/4nUd <-last > >> > >> So the panic is that we acquire a regular (non-spin) mutex in an > >> interrupt context. Not sure if this is a FreeBSD issue > >> (implementation of ACPI semaphore) or some ACPICA issue (e.g. > >> doing something wrong in an interrupt handler). > >> > >> Jung-uk, Robert, can you please take a look? > > > >_GL_ creates a semaphore and this semaphore is exclusively used in > >interrupt context. Also, it is always used to wait forever if it > >cannot acquire the necessary global lock. This is really bad for > > us because a semaphore requires a lock object to prevent sleeping > > forever without being waken up. Only workaround I can think of > > is to turn AcpiOsWaitSemaphore() & AcpiOsSignalSemaphore() into > > tsleep(9) & wakeup(9) because that's exactly what it wants to do, > > it seems. > > > >JK > > ___ > freebsd-acpi@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-acpi > To unsubscribe, send any mail to > "freebsd-acpi-unsubscr...@freebsd.org" ___ freebsd-acpi@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-acpi To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"
Re: Panic after update kernel
On Wednesday 16 March 2011 11:12 am, Andriy Gapon wrote: > on 16/03/2011 16:18 Ilya A. Arhipov said the following: > > 2011/3/16 Andriy Gapon mailto:a...@freebsd.org>> > > > > on 16/03/2011 10:52 Ilya A. Archipov said the following: > > > and see: > > > http://imm.io/4nzZ > > > > > > what information still needs to provide? > > > > 'bt' command output please (a screenshot is fine). > > > > -- > > Andriy Gapon > > > > > > boot: > > http://imm.io/4nTZ > > bt: > > http://imm.io/4nTS <-first > > http://imm.io/4nUd <-last > > So the panic is that we acquire a regular (non-spin) mutex in an > interrupt context. Not sure if this is a FreeBSD issue > (implementation of ACPI semaphore) or some ACPICA issue (e.g. doing > something wrong in an interrupt handler). > > Jung-uk, Robert, can you please take a look? _GL_ creates a semaphore and this semaphore is exclusively used in interrupt context. Also, it is always used to wait forever if it cannot acquire the necessary global lock. This is really bad for us because a semaphore requires a lock object to prevent sleeping forever without being waken up. Only workaround I can think of is to turn AcpiOsWaitSemaphore() & AcpiOsSignalSemaphore() into tsleep(9) & wakeup(9) because that's exactly what it wants to do, it seems. JK ___ freebsd-acpi@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-acpi To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"
Re: acpi(ca) mfc for 8.2
On Wednesday 17 November 2010 05:48 pm, Jung-uk Kim wrote: > On Wednesday 17 November 2010 05:41 pm, Jung-uk Kim wrote: > > On Wednesday 17 November 2010 05:04 pm, Alexandre "Sunny" > > Kovalenko > > > > wrote: > > > On Wed, 2010-11-17 at 20:43 +0200, Andriy Gapon wrote: > > > > I want to do MFC of ACPICA imports to stable/8 before 8.2 > > > > release. This would obviously include commits that fix > > > > mismerges or remove obsolete code. Plus some other small > > > > enhancements/fixes in our ACPI code. > > > > > > > > This is what I currently have: > > > > svn status: http://people.freebsd.org/~avg/acpi-stable-8.txt > > > > svn diff: http://people.freebsd.org/~avg/acpi-stable-8.diff > > > > svn log ...:http://people.freebsd.org/~avg/acpi-stable-8.log > > > > > > > > Please note that the svn diff above can not be used with > > > > patch(1), because of some svn peculiarities related to files > > > > in vendor area. > > > > Here's a plain diff that should be more useful: > > > > http://people.freebsd.org/~avg/acpi-stable-8.plain.diff > > > > > > > > I will appreciate any testing and reviews. > > > > Mobile users who track stable/8 would be the primary > > > > candidates, I guess :-) Thanks a lot! > > > > > > On my system: > > > > > > FreeBSD RabbitsDen.RabbitsLawn.verizon.net 8.1-STABLE FreeBSD > > > 8.1-STABLE #0 r215086: Wed Nov 10 11:07:30 EST 2010 > > > r...@rabbitsden.rabbitslawn.verizon.net:/usr/obj/usr/src/sys/TP > > >X6 0 i386 > > > > > > running on ThinkPad X60, I get proliferation of > > > > > > "acpi_tz0: error fetching current temperature -- AE_NOT_FOUND" > > > > > > messages after applying the patch. > > > > > > Verbose dmesg from "before" and "after" cold boots are > > > available at: > > > > > > http://members.verizon.net/~akovalenko/ACPI/dmesg.before.bz2 > > > http://members.verizon.net/~akovalenko/ACPI/dmesg.after.bz2 > > > > > > respectively. > > > > > > Now, on this machine tz0 is not a real thermal zone but some > > > kind of implement to initiate system shutdown for some case I > > > never had enough time or inclination to track through ASL. Real > > > thermal zone is tz1. > > > > > > hw.acpi.thermal.min_runtime: 0 > > > hw.acpi.thermal.polling_rate: 10 > > > hw.acpi.thermal.user_override: 1 > > > hw.acpi.thermal.tz0.temperature: 45.0C > > > hw.acpi.thermal.tz0.active: -1 > > > hw.acpi.thermal.tz0.passive_cooling: 0 > > > hw.acpi.thermal.tz0.thermal_flags: 0 > > > hw.acpi.thermal.tz0._PSV: -1 > > > hw.acpi.thermal.tz0._HOT: -1 > > > hw.acpi.thermal.tz0._CRT: 127.0C > > > hw.acpi.thermal.tz0._ACx: -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 > > > hw.acpi.thermal.tz0._TC1: -1 > > > hw.acpi.thermal.tz0._TC2: -1 > > > hw.acpi.thermal.tz0._TSP: -1 > > > hw.acpi.thermal.tz1.temperature: 43.0C > > > hw.acpi.thermal.tz1.active: -1 > > > hw.acpi.thermal.tz1.passive_cooling: 1 > > > hw.acpi.thermal.tz1.thermal_flags: 0 > > > hw.acpi.thermal.tz1._PSV: 75.0C > > > hw.acpi.thermal.tz1._HOT: -1 > > > hw.acpi.thermal.tz1._CRT: 97.0C > > > hw.acpi.thermal.tz1._ACx: -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 > > > hw.acpi.thermal.tz1._TC1: 5 > > > hw.acpi.thermal.tz1._TC2: 4 > > > hw.acpi.thermal.tz1._TSP: 600 > > > > > > If I can provide any additional information or test any > > > patches, please, let me know. > > > > Ouch... Can you please try the attached patch? > > Please ignore this patch. I need little bit more thinking. I think I know what's going on. Andriy, it seems this change is missing from your patchset (maybe more): http://svn.freebsd.org/viewvc/base/head/sys/contrib/dev/acpica/utilities/utglobal.c?r1=210976&r2=213806 Jung-uk Kim ___ freebsd-acpi@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-acpi To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"
Re: acpi(ca) mfc for 8.2
On Wednesday 17 November 2010 05:41 pm, Jung-uk Kim wrote: > On Wednesday 17 November 2010 05:04 pm, Alexandre "Sunny" Kovalenko > > wrote: > > On Wed, 2010-11-17 at 20:43 +0200, Andriy Gapon wrote: > > > I want to do MFC of ACPICA imports to stable/8 before 8.2 > > > release. This would obviously include commits that fix > > > mismerges or remove obsolete code. Plus some other small > > > enhancements/fixes in our ACPI code. > > > > > > This is what I currently have: > > > svn status: http://people.freebsd.org/~avg/acpi-stable-8.txt > > > svn diff: http://people.freebsd.org/~avg/acpi-stable-8.diff > > > svn log ...: http://people.freebsd.org/~avg/acpi-stable-8.log > > > > > > Please note that the svn diff above can not be used with > > > patch(1), because of some svn peculiarities related to files in > > > vendor area. > > > Here's a plain diff that should be more useful: > > > http://people.freebsd.org/~avg/acpi-stable-8.plain.diff > > > > > > I will appreciate any testing and reviews. > > > Mobile users who track stable/8 would be the primary > > > candidates, I guess :-) Thanks a lot! > > > > On my system: > > > > FreeBSD RabbitsDen.RabbitsLawn.verizon.net 8.1-STABLE FreeBSD > > 8.1-STABLE #0 r215086: Wed Nov 10 11:07:30 EST 2010 > > r...@rabbitsden.rabbitslawn.verizon.net:/usr/obj/usr/src/sys/TPX6 > >0 i386 > > > > running on ThinkPad X60, I get proliferation of > > > > "acpi_tz0: error fetching current temperature -- AE_NOT_FOUND" > > > > messages after applying the patch. > > > > Verbose dmesg from "before" and "after" cold boots are available > > at: > > > > http://members.verizon.net/~akovalenko/ACPI/dmesg.before.bz2 > > http://members.verizon.net/~akovalenko/ACPI/dmesg.after.bz2 > > > > respectively. > > > > Now, on this machine tz0 is not a real thermal zone but some kind > > of implement to initiate system shutdown for some case I never > > had enough time or inclination to track through ASL. Real thermal > > zone is tz1. > > > > hw.acpi.thermal.min_runtime: 0 > > hw.acpi.thermal.polling_rate: 10 > > hw.acpi.thermal.user_override: 1 > > hw.acpi.thermal.tz0.temperature: 45.0C > > hw.acpi.thermal.tz0.active: -1 > > hw.acpi.thermal.tz0.passive_cooling: 0 > > hw.acpi.thermal.tz0.thermal_flags: 0 > > hw.acpi.thermal.tz0._PSV: -1 > > hw.acpi.thermal.tz0._HOT: -1 > > hw.acpi.thermal.tz0._CRT: 127.0C > > hw.acpi.thermal.tz0._ACx: -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 > > hw.acpi.thermal.tz0._TC1: -1 > > hw.acpi.thermal.tz0._TC2: -1 > > hw.acpi.thermal.tz0._TSP: -1 > > hw.acpi.thermal.tz1.temperature: 43.0C > > hw.acpi.thermal.tz1.active: -1 > > hw.acpi.thermal.tz1.passive_cooling: 1 > > hw.acpi.thermal.tz1.thermal_flags: 0 > > hw.acpi.thermal.tz1._PSV: 75.0C > > hw.acpi.thermal.tz1._HOT: -1 > > hw.acpi.thermal.tz1._CRT: 97.0C > > hw.acpi.thermal.tz1._ACx: -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 > > hw.acpi.thermal.tz1._TC1: 5 > > hw.acpi.thermal.tz1._TC2: 4 > > hw.acpi.thermal.tz1._TSP: 600 > > > > If I can provide any additional information or test any patches, > > please, let me know. > > Ouch... Can you please try the attached patch? Please ignore this patch. I need little bit more thinking. Sorry, Jung-uk Kim ___ freebsd-acpi@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-acpi To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"
Re: acpi(ca) mfc for 8.2
On Wednesday 17 November 2010 05:04 pm, Alexandre "Sunny" Kovalenko
wrote:
> On Wed, 2010-11-17 at 20:43 +0200, Andriy Gapon wrote:
> > I want to do MFC of ACPICA imports to stable/8 before 8.2
> > release. This would obviously include commits that fix mismerges
> > or remove obsolete code. Plus some other small enhancements/fixes
> > in our ACPI code.
> >
> > This is what I currently have:
> > svn status: http://people.freebsd.org/~avg/acpi-stable-8.txt
> > svn diff: http://people.freebsd.org/~avg/acpi-stable-8.diff
> > svn log ...:http://people.freebsd.org/~avg/acpi-stable-8.log
> >
> > Please note that the svn diff above can not be used with
> > patch(1), because of some svn peculiarities related to files in
> > vendor area.
> > Here's a plain diff that should be more useful:
> > http://people.freebsd.org/~avg/acpi-stable-8.plain.diff
> >
> > I will appreciate any testing and reviews.
> > Mobile users who track stable/8 would be the primary candidates,
> > I guess :-) Thanks a lot!
>
> On my system:
>
> FreeBSD RabbitsDen.RabbitsLawn.verizon.net 8.1-STABLE FreeBSD
> 8.1-STABLE #0 r215086: Wed Nov 10 11:07:30 EST 2010
> r...@rabbitsden.rabbitslawn.verizon.net:/usr/obj/usr/src/sys/TPX60
> i386
>
> running on ThinkPad X60, I get proliferation of
>
> "acpi_tz0: error fetching current temperature -- AE_NOT_FOUND"
>
> messages after applying the patch.
>
> Verbose dmesg from "before" and "after" cold boots are available
> at:
>
> http://members.verizon.net/~akovalenko/ACPI/dmesg.before.bz2
> http://members.verizon.net/~akovalenko/ACPI/dmesg.after.bz2
>
> respectively.
>
> Now, on this machine tz0 is not a real thermal zone but some kind
> of implement to initiate system shutdown for some case I never had
> enough time or inclination to track through ASL. Real thermal zone
> is tz1.
>
> hw.acpi.thermal.min_runtime: 0
> hw.acpi.thermal.polling_rate: 10
> hw.acpi.thermal.user_override: 1
> hw.acpi.thermal.tz0.temperature: 45.0C
> hw.acpi.thermal.tz0.active: -1
> hw.acpi.thermal.tz0.passive_cooling: 0
> hw.acpi.thermal.tz0.thermal_flags: 0
> hw.acpi.thermal.tz0._PSV: -1
> hw.acpi.thermal.tz0._HOT: -1
> hw.acpi.thermal.tz0._CRT: 127.0C
> hw.acpi.thermal.tz0._ACx: -1 -1 -1 -1 -1 -1 -1 -1 -1 -1
> hw.acpi.thermal.tz0._TC1: -1
> hw.acpi.thermal.tz0._TC2: -1
> hw.acpi.thermal.tz0._TSP: -1
> hw.acpi.thermal.tz1.temperature: 43.0C
> hw.acpi.thermal.tz1.active: -1
> hw.acpi.thermal.tz1.passive_cooling: 1
> hw.acpi.thermal.tz1.thermal_flags: 0
> hw.acpi.thermal.tz1._PSV: 75.0C
> hw.acpi.thermal.tz1._HOT: -1
> hw.acpi.thermal.tz1._CRT: 97.0C
> hw.acpi.thermal.tz1._ACx: -1 -1 -1 -1 -1 -1 -1 -1 -1 -1
> hw.acpi.thermal.tz1._TC1: 5
> hw.acpi.thermal.tz1._TC2: 4
> hw.acpi.thermal.tz1._TSP: 600
>
> If I can provide any additional information or test any patches,
> please, let me know.
Ouch... Can you please try the attached patch?
Thanks,
Jung-uk Kim
Index: sys/dev/acpica/acpi_thermal.c
===
--- sys/dev/acpica/acpi_thermal.c (revision 215429)
+++ sys/dev/acpica/acpi_thermal.c (working copy)
@@ -181,14 +181,16 @@ static intacpi_tz_cooling_unit =
-1;
static int
acpi_tz_probe(device_t dev)
{
-intresult;
+ char *name;
-if (acpi_get_type(dev) == ACPI_TYPE_THERMAL && !acpi_disabled("thermal")) {
- device_set_desc(dev, "Thermal Zone");
- result = -10;
-} else
- result = ENXIO;
-return (result);
+ if (!acpi_disabled("thermal")) {
+ name = acpi_name(acpi_get_handle(dev));
+ if (name != NULL && strcmp(name, "\\_TZ_") == 0) {
+ device_set_desc(dev, "Thermal Zone");
+ return (-10);
+ }
+ }
+ return (ENXIO);
}
static int
___
freebsd-acpi@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"
Re: amd64 resume, vesa and vbe
On Tuesday 16 November 2010 08:36 am, Bruce Cran wrote: > Hi, > > I've been trying to figure out how to get my laptop working with > suspend/resume - the backlight wasn't coming back on. I eventually > got a working configuration by suspending from X11 with the nvidia > driver running - it has an rm_power_management call that seems to > knows what to do. In the process I found that the "int 0x10" call > in amd64/acpica/acpi_wakecode.S causes the machine to reboot > because POSTing doesn't bring the video chip back - from reading > some Linux documentation is appears the VBE state needs restored > too before video will work on this particular laptop. > > It looks like the vesa driver does the POST and state restore in > vesa_load_state (but it doesn't appear to get any suspend/resume > events), while the dpms driver appears to handle suspend/resume but > doesn't work with my laptop - it hangs on resume if > hw.acpi.reset_video isn't set, but reboots if it is set. Has > anyone done any work getting the POST/restore sequence working in > either of the drivers? You should not use hw.acpi.reset_video if you loaded vesa.ko. However, "vesa doesn't appear to get any suspend/resume events" concerns me. Can you please show me "devinfo -v" output? Also, please do "dd if=/dev/mem of=video.dat skip=0xc bs=1 count=64k" and send me video.dat. Thanks, Jung-uk Kim ___ freebsd-acpi@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-acpi To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"
Re: fixup for missing C1 in _CST
On Friday 12 November 2010 01:42 am, Andriy Gapon wrote: > on 12/11/2010 03:48 Jung-uk Kim said the following: > > On Thursday 11 November 2010 05:37 pm, Jung-uk Kim wrote: > >> On Thursday 11 November 2010 12:20 pm, Andriy Gapon wrote: > >>> Dear fellow FreeBSD ACPI hackers, > >>> what is your opinion about the following patch? > >>> > >>> The idea is to add a C1 state to available states if a bugggy > >>> BIOS supplies us with _CST that has states with C2, C3, etc > >>> types, but no state with C1 type. > >> > >> Can you please try the attached patch instead? > > > > It seems C1 state became mandatory years ago. Please ignore the > > previous patches and try this instead. > > The patch looks OK to me. Committed as r215188. Thanks! Jung-uk Kim ___ freebsd-acpi@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-acpi To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"
Re: fixup for missing C1 in _CST
On Thursday 11 November 2010 05:37 pm, Jung-uk Kim wrote:
> On Thursday 11 November 2010 12:20 pm, Andriy Gapon wrote:
> > Dear fellow FreeBSD ACPI hackers,
> > what is your opinion about the following patch?
> >
> > The idea is to add a C1 state to available states if a bugggy
> > BIOS supplies us with _CST that has states with C2, C3, etc
> > types, but no state with C1 type.
>
> Can you please try the attached patch instead?
It seems C1 state became mandatory years ago. Please ignore the
previous patches and try this instead.
Thanks!
Jung-uk Kim
Index: sys/dev/acpica/acpi_cpu.c
===
--- sys/dev/acpica/acpi_cpu.c (revision 215135)
+++ sys/dev/acpica/acpi_cpu.c (working copy)
@@ -668,9 +668,19 @@ acpi_cpu_cx_cst(struct acpi_cpu_softc *sc)
count = MAX_CX_STATES;
}
-/* Set up all valid states. */
+sc->cpu_non_c3 = 0;
sc->cpu_cx_count = 0;
cx_ptr = sc->cpu_cx_states;
+
+/*
+ * C1 has been required since just after ACPI 1.0.
+ * Reserve the first slot for it.
+ */
+cx_ptr->type = ACPI_STATE_C0;
+cx_ptr++;
+sc->cpu_cx_count++;
+
+/* Set up all valid states. */
for (i = 0; i < count; i++) {
pkg = &top->Package.Elements[i + 1];
if (!ACPI_PKG_VALID(pkg, 4) ||
@@ -685,9 +695,14 @@ acpi_cpu_cx_cst(struct acpi_cpu_softc *sc)
/* Validate the state to see if we should use it. */
switch (cx_ptr->type) {
case ACPI_STATE_C1:
- sc->cpu_non_c3 = i;
- cx_ptr++;
- sc->cpu_cx_count++;
+ if (sc->cpu_cx_states[0].type == ACPI_STATE_C0) {
+ /* This is the first C1 state. Use the reserved slot. */
+ sc->cpu_cx_states[0] = *cx_ptr;
+ } else {
+ sc->cpu_non_c3 = i;
+ cx_ptr++;
+ sc->cpu_cx_count++;
+ }
continue;
case ACPI_STATE_C2:
sc->cpu_non_c3 = i;
@@ -726,6 +741,13 @@ acpi_cpu_cx_cst(struct acpi_cpu_softc *sc)
}
AcpiOsFree(buf.Pointer);
+/* If C1 state was not found, we need one now. */
+cx_ptr = sc->cpu_cx_states;
+if (cx_ptr->type == ACPI_STATE_C0) {
+ cx_ptr->type = ACPI_STATE_C1;
+ cx_ptr->trans_lat = 0;
+}
+
return (0);
}
___
freebsd-acpi@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"
Re: fixup for missing C1 in _CST
On Thursday 11 November 2010 12:20 pm, Andriy Gapon wrote:
> Dear fellow FreeBSD ACPI hackers,
> what is your opinion about the following patch?
>
> The idea is to add a C1 state to available states if a bugggy BIOS
> supplies us with _CST that has states with C2, C3, etc types, but
> no state with C1 type.
Can you please try the attached patch instead?
Thanks,
Jung-uk Kim
Index: sys/dev/acpica/acpi_cpu.c
===
--- sys/dev/acpica/acpi_cpu.c (revision 215135)
+++ sys/dev/acpica/acpi_cpu.c (working copy)
@@ -635,12 +635,13 @@ acpi_cpu_generic_cx_probe(struct acpi_cpu_softc *s
static int
acpi_cpu_cx_cst(struct acpi_cpu_softc *sc)
{
+static const struct acpi_cx def_c1 = { .type = ACPI_STATE_C1 };
struct acpi_cx *cx_ptr;
ACPI_STATUS status;
ACPI_BUFFER buf;
ACPI_OBJECT*top;
ACPI_OBJECT*pkg;
-uint32_tcount;
+uint32_tcount, power, trans_lat, type;
int i;
ACPI_FUNCTION_TRACE((char *)(uintptr_t)__func__);
@@ -671,23 +672,29 @@ acpi_cpu_cx_cst(struct acpi_cpu_softc *sc)
/* Set up all valid states. */
sc->cpu_cx_count = 0;
cx_ptr = sc->cpu_cx_states;
+*cx_ptr = def_c1;
+sc->cpu_non_c3 = 0;
+if ((AcpiGbl_FADT.Flags & ACPI_FADT_C1_SUPPORTED) != 0)
+ sc->cpu_cx_count++;
+cx_ptr++;
for (i = 0; i < count; i++) {
pkg = &top->Package.Elements[i + 1];
if (!ACPI_PKG_VALID(pkg, 4) ||
- acpi_PkgInt32(pkg, 1, &cx_ptr->type) != 0 ||
- acpi_PkgInt32(pkg, 2, &cx_ptr->trans_lat) != 0 ||
- acpi_PkgInt32(pkg, 3, &cx_ptr->power) != 0) {
+ acpi_PkgInt32(pkg, 1, &type) != 0 ||
+ acpi_PkgInt32(pkg, 2, &trans_lat) != 0 ||
+ acpi_PkgInt32(pkg, 3, &power) != 0) {
device_printf(sc->cpu_dev, "skipping invalid Cx state package\n");
continue;
}
/* Validate the state to see if we should use it. */
- switch (cx_ptr->type) {
+ switch (type) {
case ACPI_STATE_C1:
- sc->cpu_non_c3 = i;
- cx_ptr++;
- sc->cpu_cx_count++;
+ sc->cpu_cx_states[0].trans_lat = trans_lat;
+ sc->cpu_cx_states[0].power = power;
+ if ((AcpiGbl_FADT.Flags & ACPI_FADT_C1_SUPPORTED) == 0)
+ sc->cpu_cx_count++;
continue;
case ACPI_STATE_C2:
sc->cpu_non_c3 = i;
@@ -716,6 +723,9 @@ acpi_cpu_cx_cst(struct acpi_cpu_softc *sc)
&cx_ptr->p_lvlx, RF_SHAREABLE);
if (cx_ptr->p_lvlx) {
sc->cpu_rid++;
+ cx_ptr->type = type;
+ cx_ptr->trans_lat = trans_lat;
+ cx_ptr->power = power;
ACPI_DEBUG_PRINT((ACPI_DB_INFO,
"acpi_cpu%d: Got C%d - %d latency\n",
device_get_unit(sc->cpu_dev), cx_ptr->type,
___
freebsd-acpi@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"
Re: MacBookPro 5,1
On Friday 05 November 2010 04:14 pm, Jung-uk Kim wrote:
> On Tuesday 12 October 2010 06:09 am, Hans Petter Selasky wrote:
> > Hi,
> >
> > My MacBookPro 5,1 does not boot using -current because memory
> > inside the ACPI kernel module is used after free.
> >
> > The following patch temporily mitigates the problem:
> >
> > /usr/src/sys/dev/acpica/Osd/OsdMemory.c
> >
> > void
> > AcpiOsFree(void *Memory)
> > {
> > + if (cold == 0)
> > free(Memory, M_ACPICA);
> > }
> >
> > Is there any way to debug this from user-land?
>
> FYI, this problem should be fixed in r214848.
And r214849. I forgot to change one line. :-(
Sorry,
Jung-uk Kim
___
freebsd-acpi@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"
Re: MacBookPro 5,1
On Tuesday 12 October 2010 06:09 am, Hans Petter Selasky wrote:
> Hi,
>
> My MacBookPro 5,1 does not boot using -current because memory
> inside the ACPI kernel module is used after free.
>
> The following patch temporily mitigates the problem:
>
> /usr/src/sys/dev/acpica/Osd/OsdMemory.c
>
> void
> AcpiOsFree(void *Memory)
> {
> + if (cold == 0)
> free(Memory, M_ACPICA);
> }
>
> Is there any way to debug this from user-land?
FYI, this problem should be fixed in r214848.
While I am here, I'd like to give many thanks to hps for trying out
patches, to avg for the great in-depth analysis and initial patch, to
ACPICA developers for continuous support and invaluable comments!
Thank you, all folks!
Jung-uk Kim
___
freebsd-acpi@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"
Re: MacBookPro 5,1
On Wednesday 03 November 2010 04:25 pm, Jung-uk Kim wrote: > Note I had to adjust resource length to prevent reading/writing > beyond buffer size. It should work okay for > acpi_pci_link_srs_from_links() case, I believe. It's a hack > anyway. ;-) I realized two MPASS() checks were removed accidentally. They are still valid, so they won't be removed in the actual commit if it works and everyone agrees. Jung-uk Kim ___ freebsd-acpi@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-acpi To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"
Re: MacBookPro 5,1
On Wednesday 03 November 2010 01:51 pm, Jung-uk Kim wrote: > On Wednesday 03 November 2010 12:47 pm, John Baldwin wrote: > > On Wednesday, November 03, 2010 12:25:37 pm Jung-uk Kim wrote: > > > On Wednesday 03 November 2010 08:28 am, John Baldwin wrote: > > > > On Tuesday, November 02, 2010 6:32:12 pm Jung-uk Kim wrote: > > > > > On Tuesday 02 November 2010 05:26 pm, John Baldwin wrote: > > > > > > On Tuesday, November 02, 2010 4:50:18 pm Jung-uk Kim wrote: > > > > > > > On Tuesday 02 November 2010 04:24 pm, John Baldwin wrote: > > > > > > > > On Tuesday, November 02, 2010 4:14:05 pm Jung-uk Kim > > wrote: > > > > > > > > > On Tuesday 02 November 2010 03:41 pm, John Baldwin > > wrote: > > > > > > > > > > On Tuesday, November 02, 2010 3:29:01 pm Jung-uk > > > > > > > > > > Kim > > > > > > wrote: > > > > > > > > > > > On Tuesday 02 November 2010 11:29 am, Andriy > > > > > > > > > > > Gapon > > > > > > wrote: > > > > > > > > > > > > on 29/10/2010 08:51 Andriy Gapon said the > > following: > > > > > > > > > > > > > I guess that a general problem here is that > > > > > > > > > > > > > it is incorrect to merely use memcpy/bcopy > > > > > > > > > > > > > to create a copy of a resource if the > > > > > > > > > > > > > resource has ACPI_RESOURCE_SOURCE field in > > > > > > > > > > > > > it. > > > > > > > > > > > > > > > > > > > > > > > > Hans, > > > > > > > > > > > > > > > > > > > > > > > > could you please test the following patch? > > > > > > > > > > > > > > > > > > > > > > > > diff --git a/sys/dev/acpica/acpi_pci_link.c > > > > > > > > > > > > b/sys/dev/acpica/acpi_pci_link.c index > > > > > > > > > > > > dcf101d..e842635 100644 --- > > > > > > > > > > > > a/sys/dev/acpica/acpi_pci_link.c +++ > > > > > > > > > > > > b/sys/dev/acpica/acpi_pci_link.c > > > > > > > > > > > > @@ -767,6 +767,8 @@ > > > > > > > > > > > > acpi_pci_link_srs_from_crs link->l_irq; > > > > > > > > > > > > else > > > > > > > > > > > > > > > > > > > > > > > > resptr->Data.ExtendedIrq.Interrupts[0] = > > > > > > > > > > > > 0; > > > > > > > > > > > > + > > > > > > > > > > > > memset(&resptr->Data.ExtendedIrq.Resource > > > > > > > > > > > >So urce , 0, + > > > > > > > > > > > > sizeof(ACPI_RESOURCE_SOURCE)); link++; > > > > > > > > > > > > i++; > > > > > > > > > > > > break; > > > > > > > > > > > > > > > > > > > > > > Hmm... Very interesting. Can you please try > > > > > > > > > > > this, too? > > > > > > > > > > > > > > > > > > > > Linux doesn't set the resource source bits up at > > > > > > > > > > all when doing _SRS, so I'd rather just do that. > > > > > > > > > > I think what I'd prefer is that we not use the > > > > > > > > > > prs_template, perhaps just save the type of the > > > > > > > > > > resource and build a new resource object from > > > > > > > > > > scratch where the resource is zero'd, the > > > > > > > > > > appropriate bits are set and then that resource > > > > > > > > > > is appended to the buffer being built. > > > > > > > > > > > > > > > > > > "Linux doesn't do it" is wrong if I am reading the
Re: MacBookPro 5,1
On Wednesday 03 November 2010 12:47 pm, John Baldwin wrote: > On Wednesday, November 03, 2010 12:25:37 pm Jung-uk Kim wrote: > > On Wednesday 03 November 2010 08:28 am, John Baldwin wrote: > > > On Tuesday, November 02, 2010 6:32:12 pm Jung-uk Kim wrote: > > > > On Tuesday 02 November 2010 05:26 pm, John Baldwin wrote: > > > > > On Tuesday, November 02, 2010 4:50:18 pm Jung-uk Kim wrote: > > > > > > On Tuesday 02 November 2010 04:24 pm, John Baldwin wrote: > > > > > > > On Tuesday, November 02, 2010 4:14:05 pm Jung-uk Kim wrote: > > > > > > > > On Tuesday 02 November 2010 03:41 pm, John Baldwin wrote: > > > > > > > > > On Tuesday, November 02, 2010 3:29:01 pm Jung-uk > > > > > > > > > Kim > > > > wrote: > > > > > > > > > > On Tuesday 02 November 2010 11:29 am, Andriy > > > > > > > > > > Gapon > > > > wrote: > > > > > > > > > > > on 29/10/2010 08:51 Andriy Gapon said the following: > > > > > > > > > > > > I guess that a general problem here is that > > > > > > > > > > > > it is incorrect to merely use memcpy/bcopy to > > > > > > > > > > > > create a copy of a resource if the resource > > > > > > > > > > > > has ACPI_RESOURCE_SOURCE field in it. > > > > > > > > > > > > > > > > > > > > > > Hans, > > > > > > > > > > > > > > > > > > > > > > could you please test the following patch? > > > > > > > > > > > > > > > > > > > > > > diff --git a/sys/dev/acpica/acpi_pci_link.c > > > > > > > > > > > b/sys/dev/acpica/acpi_pci_link.c index > > > > > > > > > > > dcf101d..e842635 100644 --- > > > > > > > > > > > a/sys/dev/acpica/acpi_pci_link.c +++ > > > > > > > > > > > b/sys/dev/acpica/acpi_pci_link.c > > > > > > > > > > > @@ -767,6 +767,8 @@ acpi_pci_link_srs_from_crs > > > > > > > > > > > link->l_irq; > > > > > > > > > > > else > > > > > > > > > > > > > > > > > > > > > > resptr->Data.ExtendedIrq.Interrupts[0] = > > > > > > > > > > > 0; > > > > > > > > > > > + > > > > > > > > > > > memset(&resptr->Data.ExtendedIrq.ResourceSo > > > > > > > > > > >urce , 0, + > > > > > > > > > > >sizeof(ACPI_RESOURCE_SOURCE)); > > > > > > > > > > > link++; > > > > > > > > > > > i++; > > > > > > > > > > > break; > > > > > > > > > > > > > > > > > > > > Hmm... Very interesting. Can you please try > > > > > > > > > > this, too? > > > > > > > > > > > > > > > > > > Linux doesn't set the resource source bits up at > > > > > > > > > all when doing _SRS, so I'd rather just do that. I > > > > > > > > > think what I'd prefer is that we not use the > > > > > > > > > prs_template, perhaps just save the type of the > > > > > > > > > resource and build a new resource object from > > > > > > > > > scratch where the resource is zero'd, the > > > > > > > > > appropriate bits are set and then that resource is > > > > > > > > > appended to the buffer being built. > > > > > > > > > > > > > > > > "Linux doesn't do it" is wrong if I am reading the > > > > > > > > spec. correctly, i.e., _CRS, _PRS and _SRS must have > > > > > > > > the same format and size. > > > > > > > > > > > > > > Umm, but we aren't setting up the raw bits for _SRS. > > > > > > > We are creating a list of ACPI_RESOURCE objects that >
Re: MacBookPro 5,1
On Wednesday 03 November 2010 08:28 am, John Baldwin wrote: > On Tuesday, November 02, 2010 6:32:12 pm Jung-uk Kim wrote: > > On Tuesday 02 November 2010 05:26 pm, John Baldwin wrote: > > > On Tuesday, November 02, 2010 4:50:18 pm Jung-uk Kim wrote: > > > > On Tuesday 02 November 2010 04:24 pm, John Baldwin wrote: > > > > > On Tuesday, November 02, 2010 4:14:05 pm Jung-uk Kim wrote: > > > > > > On Tuesday 02 November 2010 03:41 pm, John Baldwin wrote: > > > > > > > On Tuesday, November 02, 2010 3:29:01 pm Jung-uk Kim wrote: > > > > > > > > On Tuesday 02 November 2010 11:29 am, Andriy Gapon wrote: > > > > > > > > > on 29/10/2010 08:51 Andriy Gapon said the following: > > > > > > > > > > I guess that a general problem here is that it is > > > > > > > > > > incorrect to merely use memcpy/bcopy to create a > > > > > > > > > > copy of a resource if the resource has > > > > > > > > > > ACPI_RESOURCE_SOURCE field in it. > > > > > > > > > > > > > > > > > > Hans, > > > > > > > > > > > > > > > > > > could you please test the following patch? > > > > > > > > > > > > > > > > > > diff --git a/sys/dev/acpica/acpi_pci_link.c > > > > > > > > > b/sys/dev/acpica/acpi_pci_link.c index > > > > > > > > > dcf101d..e842635 100644 --- > > > > > > > > > a/sys/dev/acpica/acpi_pci_link.c +++ > > > > > > > > > b/sys/dev/acpica/acpi_pci_link.c > > > > > > > > > @@ -767,6 +767,8 @@ acpi_pci_link_srs_from_crs > > > > > > > > > link->l_irq; > > > > > > > > > else > > > > > > > > > > > > > > > > > > resptr->Data.ExtendedIrq.Interrupts[0] = 0; > > > > > > > > > + > > > > > > > > > memset(&resptr->Data.ExtendedIrq.ResourceSource > > > > > > > > >, 0, + sizeof(ACPI_RESOURCE_SOURCE)); > > > > > > > > > link++; > > > > > > > > > i++; > > > > > > > > > break; > > > > > > > > > > > > > > > > Hmm... Very interesting. Can you please try this, > > > > > > > > too? > > > > > > > > > > > > > > Linux doesn't set the resource source bits up at all > > > > > > > when doing _SRS, so I'd rather just do that. I think > > > > > > > what I'd prefer is that we not use the prs_template, > > > > > > > perhaps just save the type of the resource and build a > > > > > > > new resource object from scratch where the resource is > > > > > > > zero'd, the appropriate bits are set and then that > > > > > > > resource is appended to the buffer being built. > > > > > > > > > > > > "Linux doesn't do it" is wrong if I am reading the spec. > > > > > > correctly, i.e., _CRS, _PRS and _SRS must have the same > > > > > > format and size. > > > > > > > > > > Umm, but we aren't setting up the raw bits for _SRS. We > > > > > are creating a list of ACPI_RESOURCE objects that ACPICA > > > > > then encodes into a buffer to send to _SRS. > > > > > > > > Yes, I understand. However, ACPICA is expecting the same > > > > size of buffer *including* the optional parts if I am reading > > > > the code right. Besides, I don't think there is any harm in > > > > doing the right thing. ;-) > > > > > > To be clear, I am suggesting to take an ACPI_RESOURCE object, > > > bzero it, then set the type and the IRQ and that's it. Leave > > > the ResourceSource bits as zero. The size will still be set > > > based on the actual type (or if needed we can use the cached > > > size from the template copy we save from _PRS). The point > > > would be to start from a zero structure instead of from a copy > > > of what we got from _PRS. > > > > It may work if we don't use l_prs_template. > > Well, we still need much of the info from the _PRS resource (the > type, etc.), but I think we should not blindly use the template > directly when building the buffer for _SRS. Actually, I think we should get the information directly from _CRS as ACPI spec. is suggesting. Jung-uk Kim ___ freebsd-acpi@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-acpi To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"
Re: MacBookPro 5,1
On Tuesday 02 November 2010 05:50 pm, Andriy Gapon wrote: > on 02/11/2010 22:50 Jung-uk Kim said the following: > > Yes, I understand. However, ACPICA is expecting the same size of > > buffer *including* the optional parts if I am reading the code > > right. > > Hmm, where is ACPICA doing that? If you scrub ResourceSource, then: AcpiSetCurrentResources() -> AcpiRsSetSrsMethodData() -> AcpiRsCreateAmlResources() -> AcpiRsGetAmlLength() -> AcpiRsStructOptionLength() will return 0 and size of new buffer may be smaller than what we got from _CRS. I may have read it wrong, though. :-/ > I didn't see any connection between what *ACPICA* can return to OS > in _CRS/_PRS and what OS can pass in _SRS. > > > Besides, I don't think there is any harm in doing the right > > thing. ;-) > > I don't think that this is any "righter" than zero-ing out resource > source description string. BIOS/firmware can't possibly use that > for anything meaningful, IMO. I didn't say it is ever useful. My point was it may not work for some BIOS but I am not sure, that's all. Jung-uk Kim ___ freebsd-acpi@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-acpi To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"
Re: MacBookPro 5,1
On Tuesday 02 November 2010 05:26 pm, John Baldwin wrote: > On Tuesday, November 02, 2010 4:50:18 pm Jung-uk Kim wrote: > > On Tuesday 02 November 2010 04:24 pm, John Baldwin wrote: > > > On Tuesday, November 02, 2010 4:14:05 pm Jung-uk Kim wrote: > > > > On Tuesday 02 November 2010 03:41 pm, John Baldwin wrote: > > > > > On Tuesday, November 02, 2010 3:29:01 pm Jung-uk Kim wrote: > > > > > > On Tuesday 02 November 2010 11:29 am, Andriy Gapon wrote: > > > > > > > on 29/10/2010 08:51 Andriy Gapon said the following: > > > > > > > > I guess that a general problem here is that it is > > > > > > > > incorrect to merely use memcpy/bcopy to create a copy > > > > > > > > of a resource if the resource has > > > > > > > > ACPI_RESOURCE_SOURCE field in it. > > > > > > > > > > > > > > Hans, > > > > > > > > > > > > > > could you please test the following patch? > > > > > > > > > > > > > > diff --git a/sys/dev/acpica/acpi_pci_link.c > > > > > > > b/sys/dev/acpica/acpi_pci_link.c index dcf101d..e842635 > > > > > > > 100644 --- a/sys/dev/acpica/acpi_pci_link.c > > > > > > > +++ b/sys/dev/acpica/acpi_pci_link.c > > > > > > > @@ -767,6 +767,8 @@ acpi_pci_link_srs_from_crs > > > > > > > link->l_irq; > > > > > > > else > > > > > > > resptr->Data.ExtendedIrq.Interrupts[0] > > > > > > > = 0; > > > > > > > + > > > > > > > memset(&resptr->Data.ExtendedIrq.ResourceSource, 0, > > > > > > > + sizeof(ACPI_RESOURCE_SOURCE)); > > > > > > > link++; > > > > > > > i++; > > > > > > > break; > > > > > > > > > > > > Hmm... Very interesting. Can you please try this, too? > > > > > > > > > > Linux doesn't set the resource source bits up at all when > > > > > doing _SRS, so I'd rather just do that. I think what I'd > > > > > prefer is that we not use the prs_template, perhaps just > > > > > save the type of the resource and build a new resource > > > > > object from scratch where the resource is zero'd, the > > > > > appropriate bits are set and then that resource is appended > > > > > to the buffer being built. > > > > > > > > "Linux doesn't do it" is wrong if I am reading the spec. > > > > correctly, i.e., _CRS, _PRS and _SRS must have the same > > > > format and size. > > > > > > Umm, but we aren't setting up the raw bits for _SRS. We are > > > creating a list of ACPI_RESOURCE objects that ACPICA then > > > encodes into a buffer to send to _SRS. > > > > Yes, I understand. However, ACPICA is expecting the same size of > > buffer *including* the optional parts if I am reading the code > > right. Besides, I don't think there is any harm in doing the > > right thing. ;-) > > To be clear, I am suggesting to take an ACPI_RESOURCE object, bzero > it, then set the type and the IRQ and that's it. Leave the > ResourceSource bits as zero. The size will still be set based on > the actual type (or if needed we can use the cached size from the > template copy we save from _PRS). The point would be to start from > a zero structure instead of from a copy of what we got from _PRS. It may work if we don't use l_prs_template. Jung-uk Kim ___ freebsd-acpi@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-acpi To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"
Re: MacBookPro 5,1
On Tuesday 02 November 2010 04:24 pm, John Baldwin wrote: > On Tuesday, November 02, 2010 4:14:05 pm Jung-uk Kim wrote: > > On Tuesday 02 November 2010 03:41 pm, John Baldwin wrote: > > > On Tuesday, November 02, 2010 3:29:01 pm Jung-uk Kim wrote: > > > > On Tuesday 02 November 2010 11:29 am, Andriy Gapon wrote: > > > > > on 29/10/2010 08:51 Andriy Gapon said the following: > > > > > > I guess that a general problem here is that it is > > > > > > incorrect to merely use memcpy/bcopy to create a copy of > > > > > > a resource if the resource has ACPI_RESOURCE_SOURCE field > > > > > > in it. > > > > > > > > > > Hans, > > > > > > > > > > could you please test the following patch? > > > > > > > > > > diff --git a/sys/dev/acpica/acpi_pci_link.c > > > > > b/sys/dev/acpica/acpi_pci_link.c index dcf101d..e842635 > > > > > 100644 --- a/sys/dev/acpica/acpi_pci_link.c > > > > > +++ b/sys/dev/acpica/acpi_pci_link.c > > > > > @@ -767,6 +767,8 @@ acpi_pci_link_srs_from_crs > > > > > link->l_irq; > > > > > else > > > > > resptr->Data.ExtendedIrq.Interrupts[0] > > > > > = 0; > > > > > + > > > > > memset(&resptr->Data.ExtendedIrq.ResourceSource, 0, > > > > > + sizeof(ACPI_RESOURCE_SOURCE)); > > > > > link++; > > > > > i++; > > > > > break; > > > > > > > > Hmm... Very interesting. Can you please try this, too? > > > > > > Linux doesn't set the resource source bits up at all when doing > > > _SRS, so I'd rather just do that. I think what I'd prefer is > > > that we not use the prs_template, perhaps just save the type of > > > the resource and build a new resource object from scratch where > > > the resource is zero'd, the appropriate bits are set and then > > > that resource is appended to the buffer being built. > > > > "Linux doesn't do it" is wrong if I am reading the spec. > > correctly, i.e., _CRS, _PRS and _SRS must have the same format > > and size. > > Umm, but we aren't setting up the raw bits for _SRS. We are > creating a list of ACPI_RESOURCE objects that ACPICA then encodes > into a buffer to send to _SRS. Yes, I understand. However, ACPICA is expecting the same size of buffer *including* the optional parts if I am reading the code right. Besides, I don't think there is any harm in doing the right thing. ;-) Jung-uk Kim ___ freebsd-acpi@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-acpi To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"
Re: MacBookPro 5,1
On Tuesday 02 November 2010 03:41 pm, John Baldwin wrote: > On Tuesday, November 02, 2010 3:29:01 pm Jung-uk Kim wrote: > > On Tuesday 02 November 2010 11:29 am, Andriy Gapon wrote: > > > on 29/10/2010 08:51 Andriy Gapon said the following: > > > > I guess that a general problem here is that it is incorrect > > > > to merely use memcpy/bcopy to create a copy of a resource if > > > > the resource has ACPI_RESOURCE_SOURCE field in it. > > > > > > Hans, > > > > > > could you please test the following patch? > > > > > > diff --git a/sys/dev/acpica/acpi_pci_link.c > > > b/sys/dev/acpica/acpi_pci_link.c index dcf101d..e842635 100644 > > > --- a/sys/dev/acpica/acpi_pci_link.c > > > +++ b/sys/dev/acpica/acpi_pci_link.c > > > @@ -767,6 +767,8 @@ acpi_pci_link_srs_from_crs > > > link->l_irq; > > > else > > > resptr->Data.ExtendedIrq.Interrupts[0] = 0; > > > + memset(&resptr->Data.ExtendedIrq.ResourceSource, 0, > > > + sizeof(ACPI_RESOURCE_SOURCE)); > > > link++; > > > i++; > > > break; > > > > Hmm... Very interesting. Can you please try this, too? > > Linux doesn't set the resource source bits up at all when doing > _SRS, so I'd rather just do that. I think what I'd prefer is that > we not use the prs_template, perhaps just save the type of the > resource and build a new resource object from scratch where the > resource is zero'd, the appropriate bits are set and then that > resource is appended to the buffer being built. "Linux doesn't do it" is wrong if I am reading the spec. correctly, i.e., _CRS, _PRS and _SRS must have the same format and size. Jung-uk Kim ___ freebsd-acpi@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-acpi To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"
Re: MacBookPro 5,1
On Tuesday 02 November 2010 11:29 am, Andriy Gapon wrote:
> on 29/10/2010 08:51 Andriy Gapon said the following:
> > I guess that a general problem here is that it is incorrect to
> > merely use memcpy/bcopy to create a copy of a resource if the
> > resource has ACPI_RESOURCE_SOURCE field in it.
>
> Hans,
>
> could you please test the following patch?
>
> diff --git a/sys/dev/acpica/acpi_pci_link.c
> b/sys/dev/acpica/acpi_pci_link.c index dcf101d..e842635 100644
> --- a/sys/dev/acpica/acpi_pci_link.c
> +++ b/sys/dev/acpica/acpi_pci_link.c
> @@ -767,6 +767,8 @@ acpi_pci_link_srs_from_crs
> link->l_irq;
> else
> resptr->Data.ExtendedIrq.Interrupts[0] = 0;
> + memset(&resptr->Data.ExtendedIrq.ResourceSource, 0,
> + sizeof(ACPI_RESOURCE_SOURCE));
> link++;
> i++;
> break;
Hmm... Very interesting. Can you please try this, too?
Thanks,
Jung-uk Kim
--- sys/dev/acpica/acpi_pci_link.c 2010-03-05 15:07:53.0 -0500
+++ sys/dev/acpica/acpi_pci_link.c 2010-11-02 14:57:50.0 -0400
@@ -268,6 +268,7 @@
static ACPI_STATUS
link_add_prs(ACPI_RESOURCE *res, void *context)
{
+ ACPI_RESOURCE_EXTENDED_IRQ *ext;
struct link_res_request *req;
struct link *link;
UINT8 *irqs = NULL;
@@ -323,6 +324,13 @@
*/
bcopy(res, &link->l_prs_template, sizeof(ACPI_RESOURCE));
if (is_ext_irq) {
+ ext = &link->l_prs_template.Data.ExtendedIrq;
+ ext->ResourceSource.StringPtr = malloc(
+ ext->ResourceSource.StringLength + 1,
+ M_PCI_LINK, M_WAITOK);
+ strncpy(ext->ResourceSource.StringPtr,
+ res->Data.ExtendedIrq.ResourceSource.StringPtr,
+ ext->ResourceSource.StringLength + 1);
link->l_num_irqs =
res->Data.ExtendedIrq.InterruptCount;
ext_irqs = res->Data.ExtendedIrq.Interrupts;
@@ -422,9 +430,10 @@
static int
acpi_pci_link_attach(device_t dev)
{
- struct acpi_pci_link_softc *sc;
struct link_count_request creq;
struct link_res_request rreq;
+ ACPI_RESOURCE_EXTENDED_IRQ *ext;
+ struct acpi_pci_link_softc *sc;
ACPI_STATUS status;
int i;
@@ -540,9 +549,15 @@
return (0);
fail:
ACPI_SERIAL_END(pci_link);
- for (i = 0; i < sc->pl_num_links; i++)
+ for (i = 0; i < sc->pl_num_links; i++) {
+ if (sc->pl_links[i].l_prs_template.Type ==
+ ACPI_RESOURCE_TYPE_EXTENDED_IRQ) {
+ ext = &sc->pl_links[i].l_prs_template.Data.ExtendedIrq;
+ free(ext->ResourceSource.StringPtr, M_PCI_LINK);
+ }
if (sc->pl_links[i].l_irqs != NULL)
free(sc->pl_links[i].l_irqs, M_PCI_LINK);
+ }
free(sc->pl_links, M_PCI_LINK);
return (ENXIO);
}
___
freebsd-acpi@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"
Re: est CPU support
On Monday 01 November 2010 01:22 pm, Joerg Traeger wrote: > On Monday 01 November 2010, Andriy Gapon wrote: > > on 01/11/2010 15:13 Andriy Gapon said the following: > > > on 01/11/2010 14:41 Joerg Traeger said the following: > > >> On Monday 01 November 2010, Andriy Gapon wrote: > > >>> on 01/11/2010 14:25 Joerg Traeger said the following: > > >>>> On Monday 01 November 2010, Andriy Gapon wrote: > > >>>>> on 01/11/2010 11:52 Joerg Traeger said the following: > > >>>>>> Hi, > > >>>>>> > > >>>>>> I have got several mainboards with CPUs which appear not > > >>>>>> to be supportet by est. An error exists: > > >>>>>> > > >>>>>> (examle of somewhat older Intel DG45FC with DualCore E5200 > > >>>>>> and latest BIOS) > > >>>>>> > > >>>>>> est0: on cpu0 > > >>>>>> est: CPU supports Enhanced Speedstep, but is not > > >>>>>> recognized. est: cpu_vendor GenuineIntel, msr > > >>>>>> 61a4c1f06004c1f device_attach: est0 attach returned 6 > > >>>>>> <-- > > >>>>> > > >>>>> Do you have ACPI enabled? > > >>>> > > >>>> Yes, sure it is enabled. > > >>> > > >>> Can you upload your acpidump -dt output somewhere and provide > > >>> a link? > > >> > > >> You can read the output here: > > >> http://xoasis.de/DG45FC_E5200_acpidump.txt > > > > > > Your BIOS doesn't provide _PSS method for processor objects, so > > > est won't work in general ACPI mode. > > > > Hmm, it seems that I missed code in your DSDT for dynamically > > loading SSDT. Could you please provide a link to your boot dmesg? > > Sure. You find dmesg here: http://xoasis.de/DG45FC_dmesg.txt > ACPI Warning: 32/64X FACS address mismatch in FADT - 0xCBE61F40/0x 0CBE67E40, using 32 (20100331/tbfadt-586) Grrr... I bet this board has a Windows XP sticker on it? ;-) > ACPI: Overriding _OS definition with "Windows 2001.1" \_OS does not do anything for modern BIOSes such as yours, i.e., it is only useful for up to MS Win2K-ish BIOS, only because MS mandated it from XP AFAIK. By default, \_OSI is used and it will match "Windows 2001.1" just fine. Although the DSDT has listed many other non-Windows OSes in the table, they are just place holders AFAICT. Jung-uk Kim ___ freebsd-acpi@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-acpi To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"
Re: VirtualBox: Compile problems with ACPICA 20101013
On Saturday 23 October 2010 03:28 am, Bernhard Froehlich wrote: > On Tue, 19 Oct 2010 11:31:00 -0400, Jung-uk Kim > > wrote: > > On Tuesday 19 October 2010 08:52 am, Bernhard Froehlich wrote: > >> On Mon, 18 Oct 2010 13:33:26 -0400, Jung-uk Kim > >> > >> > >> wrote: > >> > On Monday 18 October 2010 05:44 am, Bernhard Froehlich wrote: > >> >> Hi guys! > >> >> > >> >> VirtualBox has a compile problem with latest acpica. I've > >> >> talked to the VirtualBox developers and they think it's an > >> >> acpica problem which should be fixed upstream. Can we somehow > >> >> file a bugreport or create a patch to fix that in acpica? > >> > > >> > Excerpt rom ACPI 4.0a: > >> > > >> > --- > >> > Each Compatible Device ID must be either: > >> > > >> > o A valid HID value (a 32-bit compressed EISA type ID or a > >> > string such as "ACPI0004"). > >> > o A string that uses a bus-specific nomenclature. For > >> > example, _CID can be used to specify the PCI ID. > >> > --- > >> > > >> > Since it is not a valid HID value, you can only say it may be > >> > a bus-specific nomenclature at best. However, it looks like > >> > an ISA device to me and probably it is just a bogus ID. In > >> > fact, I googled a bit and it only exists on some Intel Mac > >> > models, it seems. You can just remove the entire _CID unless > >> > it is absolutely necessary, which is very unlikely. :-) > >> > >> It very much looks like a regression. Right beyond that > >> sentences they have a few examples in the ACPI 4.0a spec on page > >> 201 that won't pass that check. I haven't looked at all the code > >> so probably it's done somewhere completely different but if it > >> is checked with that code then it will complain. > >> > >> ACPI 4.0a spec on page 201: > >> --- > >> o A valid HID value (a 32-bit compressed EISA type ID or a > >> string such as "ACPI0004"). > >> o A string that uses a bus-specific nomenclature. For example, > >> _CID can be used to specify the PCI ID. > >> > >> "PCI\CC_ccss" > >> "PCI\CC_ccsspp" > >> "PCI\VEN_&DEV_&SUBSYS_&REV_rr" > >> > >> --- > >> > >> Now with a deeper look at the commit from acpica [1] especially > >> the second half. Before there was only an alphanumeric check for > >> _HID but with that change it was put into a new function > >> AnCheckId() that is called for both _HID and _CID and now wants > >> both to be alphanumeric. That looks correct for _HID but it's > >> too strict for _CID which is a string. Somewhere i've seen > >> string is defined as a null-terminated ASCII string and no word > >> about alphanumeric. > >> > >> [1] > >> http://git.moblin.org/cgit.cgi/acpica/commit/?id=b66fd716e0b9b53 > >>89e > > > > Yes, I am aware of the issue. My point was _CID may be pointless > > for *VirtualBox* and it can be removed. > > I am just trying to figure out who is wrong and try to fix it there > if possible. Understood. > So do you agree that this is a acpica regression? Yes, I do. I was told Intel would going to look into it. > Vbox guys say that removing it is not a good idea because it will > "break things" but I don't know what it is used for so I cannot test > it. It *may* break Mac OS X guest. However, I don't believe it would rely on _CID. On top of that, Mac OS X is not a supported guest OS and it is illegal, AFAIK. So, I don't think it would matter. ;-) Jung-uk Kim ___ freebsd-acpi@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-acpi To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"
Re: VirtualBox: Compile problems with ACPICA 20101013
On Tuesday 19 October 2010 08:52 am, Bernhard Froehlich wrote: > On Mon, 18 Oct 2010 13:33:26 -0400, Jung-uk Kim > > wrote: > > On Monday 18 October 2010 05:44 am, Bernhard Froehlich wrote: > >> Hi guys! > >> > >> VirtualBox has a compile problem with latest acpica. I've talked > >> to the VirtualBox developers and they think it's an acpica > >> problem which should be fixed upstream. Can we somehow file a > >> bugreport or create a patch to fix that in acpica? > > > > Excerpt rom ACPI 4.0a: > > > > --- > > Each Compatible Device ID must be either: > > > > o A valid HID value (a 32-bit compressed EISA type ID or a string > > such as "ACPI0004"). > > o A string that uses a bus-specific nomenclature. For example, > > _CID can be used to specify the PCI ID. > > --- > > > > Since it is not a valid HID value, you can only say it may be a > > bus-specific nomenclature at best. However, it looks like an ISA > > device to me and probably it is just a bogus ID. In fact, I > > googled a bit and it only exists on some Intel Mac models, it > > seems. You can just remove the entire _CID unless it is > > absolutely necessary, which is very unlikely. :-) > > It very much looks like a regression. Right beyond that sentences > they have a few examples in the ACPI 4.0a spec on page 201 that > won't pass that check. I haven't looked at all the code so probably > it's done somewhere completely different but if it is checked with > that code then it will complain. > > ACPI 4.0a spec on page 201: > --- > o A valid HID value (a 32-bit compressed EISA type ID or a string > such as "ACPI0004"). > o A string that uses a bus-specific nomenclature. For example, > _CID can be used to specify the PCI ID. > > "PCI\CC_ccss" > "PCI\CC_ccsspp" > "PCI\VEN_&DEV_&SUBSYS_&REV_rr" > > --- > > Now with a deeper look at the commit from acpica [1] especially the > second half. Before there was only an alphanumeric check for _HID > but with that change it was put into a new function AnCheckId() > that is called for both _HID and _CID and now wants both to be > alphanumeric. That looks correct for _HID but it's too strict for > _CID which is a string. Somewhere i've seen string is defined as a > null-terminated ASCII string and no word about alphanumeric. > > [1] > http://git.moblin.org/cgit.cgi/acpica/commit/?id=b66fd716e0b9b5389e Yes, I am aware of the issue. My point was _CID may be pointless for *VirtualBox* and it can be removed. Jung-uk Kim ___ freebsd-acpi@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-acpi To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"
Re: VirtualBox: Compile problems with ACPICA 20101013
On Monday 18 October 2010 05:44 am, Bernhard Froehlich wrote: > Hi guys! > > VirtualBox has a compile problem with latest acpica. I've talked to > the VirtualBox developers and they think it's an acpica problem > which should be fixed upstream. Can we somehow file a bugreport or > create a patch to fix that in acpica? Excerpt rom ACPI 4.0a: --- Each Compatible Device ID must be either: o A valid HID value (a 32-bit compressed EISA type ID or a string such as "ACPI0004"). o A string that uses a bus-specific nomenclature. For example, _CID can be used to specify the PCI ID. --- Since it is not a valid HID value, you can only say it may be a bus-specific nomenclature at best. However, it looks like an ISA device to me and probably it is just a bogus ID. In fact, I googled a bit and it only exists on some Intel Mac models, it seems. You can just remove the entire _CID unless it is absolutely necessary, which is very unlikely. :-) Jung-uk Kim > Compile error: > kBuild: iasl DevicesR3 - > /usr/ports/emulators/virtualbox-ose/work/VirtualBox-3.2.10_OSE/src/ >VBox/Devices/PC/vbox.dsl > /usr/ports/emulators/virtualbox-ose/work/VirtualBox-3.2.10_OSE/src/ >VBox/Devices/PC/vbox.dsl 736: Name (_CID, > "smc-napa") > Error4001 - > String must be entirely > alphanumeric ^ (smc-napa) > > ASL Input: > /usr/ports/emulators/virtualbox-ose/work/VirtualBox-3.2.10_OSE/src/ >VBox/Devices/PC/vbox.dsl - 1305 lines, 46193 bytes, 288 keywords > Compilation complete. 1 Errors, 0 Warnings, 0 Remarks, 404 > Optimizations > > > I have found the commit that introduces this additional checks: > http://git.moblin.org/cgit.cgi/acpica/commit/?id=b66fd716e0b9b5389e >544c58df189c817f316c3b > > and here is the dsl file from virtualbox: > http://www.virtualbox.org/browser/trunk/src/VBox/Devices/PC/vbox.ds >l#L781 > > > Thanks! ___ freebsd-acpi@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-acpi To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"
Re: MacBookPro 5,1
On Tuesday 12 October 2010 06:09 am, Hans Petter Selasky wrote:
> Hi,
>
> My MacBookPro 5,1 does not boot using -current because memory
> inside the ACPI kernel module is used after free.
>
> The following patch temporily mitigates the problem:
>
> /usr/src/sys/dev/acpica/Osd/OsdMemory.c
>
> void
> AcpiOsFree(void *Memory)
> {
> + if (cold == 0)
> free(Memory, M_ACPICA);
> }
>
> Is there any way to debug this from user-land?
acpidb(8). However, it is quite broken ATM. :-(
Alternatively, you may use acpiexec from ACPICA:
fetch http://www.acpica.org/download/acpica-unix-20101013.tar.gz
tar xpf acpica-unix-20101013.tar.gz
cd acpica-unix-20101013/tools/acpiexec
gmake
./acpiexec
Actually you need to extract ACPI tables from your BIOS (or UEFI in
your case) to use with acpiexec. acpidump(8) gives you what you want
BUT you cannot use it with acpiexec directly. You need to dump/extract
tables using Linux pmtools:
fetch
http://ftp.kernel.org/pub/linux/kernel/people/lenb/acpi/utils/pmtools-20100825.tar.bz2
fetch http://people.freebsd.org/~jkim/pmtools-20100825.diff
tar xpf pmtools-20100825.tar.bz2
cd pmtools
patch < ../pmtools-20100825.diff
gmake
sudo acpidump/acpidump -o ACPI.dat
acpixtract/acpixtract -a ACPI.dat
Note the pmtools patch is really a hack but it should work. ;-)
Good luck,
Jung-uk Kim
* PS: If anyone has enough free time, please fix acpidb.
___
freebsd-acpi@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"
Re: acpi0: Could not initialise SystemMemory handler: AE_NOT_EXIST
On Tuesday 21 September 2010 04:51 pm, Andriy Gapon wrote: > on 21/09/2010 23:29 Daniel Bilik said the following: > > On Tue, 21 Sep 2010 17:38:10 +0300 > > > > Andriy Gapon wrote: > >> To be precise, would you be able to test the following patch? > >> ... > > > > I have to report a success story... The patch made 8-stable to > > correctly attach acpi and recognize every piece of hardware in > > this mini-beast (except Broadcom wireless). There are couple of > > warnings though... > > > > ACPI Warning for \\_SB_.PCI0.PCIB._PRT: Return Package has no > > elements (empty) (20100331/nspredef-572) > > > > atrtc0: Warning: Couldn't map I/O. > > Perhaps mav would want to dig this one further. > > > ... and our familiar... > > > > RTC BIOS diagnostic error > > 96 > > > > Full dmesg is here: > > > > http://neosystem.cz/freebsd/hp_mini_5102-dmesg.txt > > > > I don't know possible implications of removing those status > > checks from acpi.c but most important effect for me is that I'm > > now able to put FreeBSD on this machine and actually use it. :) > > > > Thank you very much, Andriy. > > All the credit belongs to Robert Moore of Intel/acpica.org. > Glad that we could resolve the problem and thank you very much for > the debugging an testing! Please commit. You may add "Reviewed by: jkim" if you want. Please make a note in the commit log that this code is redundant since ACPICA 20040427. Thanks! Jung-uk Kim ___ freebsd-acpi@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-acpi To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"
Re: acpi shows wrong battery state (fwd)
On Friday 03 September 2010 03:07 pm, Jung-uk Kim wrote: > On Friday 03 September 2010 02:31 am, Andriy Gapon wrote: > > on 03/09/2010 06:01 Ian Smith said the following: > > > But that's really an aside from the real issue you identify > > > below, and perhaps also some TZ value/s being 'absurd' .. > > > > Let's try to not mix these things together just yet. > > acpi_hp/acpi_wmi problems should not affect acpi_ec in any way. > > (the converse could be true, but let's not go there yet...) > > Uh... If I am reading acpi_wmi.c correctly, it installs its own > version of EC handler and EC is directly read/written via > ACPI_EC_READ() and ACPI_EC_WRITE() from there. Apparently, it just > bypasses EC serialization and "affects" EC. Am I reading it wrong? Please ignore what I just said. It is not attached properly, so it doesn't affect EC at all. Doh... Sorry for the noise. Jung-uk Kim ___ freebsd-acpi@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-acpi To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"
Re: acpi shows wrong battery state (fwd)
On Friday 03 September 2010 02:31 am, Andriy Gapon wrote: > on 03/09/2010 06:01 Ian Smith said the following: > > But that's really an aside from the real issue you identify > > below, and perhaps also some TZ value/s being 'absurd' .. > > Let's try to not mix these things together just yet. > acpi_hp/acpi_wmi problems should not affect acpi_ec in any way. > (the converse could be true, but let's not go there yet...) Uh... If I am reading acpi_wmi.c correctly, it installs its own version of EC handler and EC is directly read/written via ACPI_EC_READ() and ACPI_EC_WRITE() from there. Apparently, it just bypasses EC serialization and "affects" EC. Am I reading it wrong? BTW, it is kinda messy way to handle EC. :-( Jung-uk Kim ___ freebsd-acpi@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-acpi To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"
Re: acpi shows wrong battery state (fwd)
On Friday 03 September 2010 01:32 am, Ian Smith wrote: > http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/acpi-debu >g.html === > 11.16.5.1 _OS dependencies > > Some AML assumes the world consists of various Windows versions. > You can tell FreeBSD to claim it is any OS to see if this fixes > problems you may have. An easy way to override this is to set > hw.acpi.osname="Windows 2001" in /boot/loader.conf or other similar > strings you find in the ASL. === > > It may be worth trying setting hw.acpi.osname to "Linux", or to one > of the others mentioned in your ASL. You'll see a number of > conditional tests on 'OSYS' in there; I don't know just what they > do, but it can't hurt to experiment. > > Try 'Windows 2001' also; there are some tests in the > EmbeddedControl section mentioning an RFLG and VIST .. clearly the > latter refers to Vista, but Windows 2001 zeroes RFLG, otherwise > set. (just guessing!) hw.acpi.osname is for \_OS and it does NOT influence \_OSI at all. They have totally different semantics although MS is advocating \_OSI is some sort of improved version of \_OS, unfortunately. Some BIOSes use both \_OS and \_OSI (e.g., \_OS for old Windows and \_OSI for newer Windows). Because of this problem, ACPICA just matches any known Windows OSIs for maximum compatibility. :-( FYI, in the latest ACPICA in CURRENT, we can install or remove OSIs from OS but the FreeBSD part is yet to be implemented. Jung-uk Kim ___ freebsd-acpi@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-acpi To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"
Re: acpi shows wrong battery state (fwd)
On Thursday 02 September 2010 11:01 pm, Ian Smith wrote: > But that's really an aside from the real issue you identify below, > and perhaps also some TZ value/s being 'absurd' .. This commit may help in some cases: http://svn.freebsd.org/viewvc/base?view=revision&revision=210313 Jung-uk Kim ___ freebsd-acpi@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-acpi To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"
Re: acpi shows wrong battery state (fwd)
On Thursday 02 September 2010 06:02 pm, kuba wrote:
> > Take a look at these tunables:
> > debug.acpi.ec.timeout: 750
> > debug.acpi.ec.polled: 0
> > debug.acpi.ec.burst: 0
> >
> > Perhaps increasing timeout would help?
>
> Increasing timeout didn't help at all :(
> Is there a chance that in the future release 8.2 this problem will
> be fixed? I don't have any idea left how to force acpi to show
> proper battery state, and I need this information to work with my
> laptop, so I think that the best option is to remove or leave
> unused freebsd for some time :/ and use only linux.
As few people already have said, your EC is not responding and that's
the root cause. However, 8.0 also didn't work according to your
dmesg output. You said "battery indicator" is not working from 8.1
in another e-mail. If I understand it correctly, that's some sort of
LED on the laptop, right? Did "acpiconf -i batt" ever work with 8.0?
I doubt it, though.
Another problem is acpi_wmi(4) is not attaching because it cannot
match the device, which is defined wrong in the AML:
Name (_HID, "pnp0c14")
It should never be lower cases although it seems we have a workaround
for *some* models in sys/dev/acpi_support/acpi_wmi.c:
201: static char *wmi_ids[] = {"PNP0C14", "PNP0c14", NULL};
Also, your acpidump output shows typical BIOS stupidity, i.e., it
tries to detect installed MS Windows version and responds
differently. We have updated ACPICA in 8.1 and it matches Vista's
OSI now. That's probably the reason why the battery indicator
stopped working.
To recap:
1. Add "pnp0c14" in sys/dev/acpi_support/acpi_wmi.c like this:
static char *wmi_ids[] = {"PNP0C14", "PNP0c14", "pnp0c14", NULL};
Recompile, install, and reboot.
2. If #1 does not help, remove the following three lines from
sys/contrib/dev/acpica/utilities/uteval.c, which were added in 8.1:
149: {"Windows 2006.1", ACPI_OSI_WINSRV_2008}, ...
150: {"Windows 2006 SP1", ACPI_OSI_WIN_VISTA_SP1}, ...
151: {"Windows 2009",ACPI_OSI_WIN_7}, ...
Recompile, install, and reboot.
3. If #2 still does not help, you should complain to HP.
Good luck.
Jung-uk Kim
___
freebsd-acpi@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"
