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 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 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", , , +
>> , 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, +
>> , 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", , ,
+ , 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,
+ , 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,
_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,
+_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, );
+ 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 directly.
.It Fl h
Displays a summ
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
Index: usr.sbin/acpi/acpiconf/acpiconf.c
==
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 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 <a...@icyb.net.ua> 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: 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: [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: [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 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=0xbfebfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE
Features2=0xe3bdSSE3,DTES64,MON,DS_CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM
AMD Features=0x20100800SYSCALL,NX,LM AMD
Features2=0x1LAHF TSC: P-state invariant,
performance statistics real memory = 2147483648
(2048 MB) avail memory = 2007138304 (1914 MB) Event
timer LAPIC quality 400 ACPI APIC Table: LENOVO
TP-7LFreeBSD/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 mismatch in
FADT/Gpe1Block: 0/32 (20130823/tbfadt-601)
Yes, I didn't remove that warning, I just fixed it to use the
64-bit length when the 32-bit length was zero when that warning
fires. Does this seem to have made any difference with
anything on the laptop? (E.g. it might possibly affect
hotkeys, etc.)
Believe it or not, but I just suspend/resumed on the thing,
TWICE. Once from the xfce menu - suspend and once from
Fn-moonsymbolsuspendsleepthing on the F4 key.
Good grief. Thanks John.
Humm. I wonder if we can get the Intel guys to accept the patch
upstream?
Yes, ACPICA guys are very open to patches. Actually there are several
ways to report bugs and/or submit patches.
Bug reports:
https://bugs.acpica.org
Developer ML:
https://lists.acpica.org/mailman/listinfo/devel
Source repository:
https://github.com/acpica/acpica
However, I'm afraid the following commit may have nullified your patch.
https://github.com/acpica/acpica/commit/8149df49
Jung-uk Kim
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (FreeBSD)
iQEcBAEBAgAGBQJThhJ8AAoJEHyflib82/FGrPsH/iohXslK+ZSWBWXpHmlE5ONQ
bpRjFbAvfeKwSn33YaVgk/1g06/+UhPcpErEwLF0yp9/CC54v40/LXJUKs2DTYRV
5A2gK02xTJ9vJCQiqJXanZhdFBfITPf9eKAM2idIfgCwGlvKH/Vw3DFZbdVHDphJ
ma4nWYFWureASD3QvRoZ4xjmjWZoY0jfw/h+xRk49Ja5/bzFTu9Mx0AbkVTtg/50
jta4pzbaiv6Sv3lsTvYU+VTc9vOyLqnPl6JSeavM8Bit3AThb8e8Atg7ZLxb6WGb
YAdei45YvsplGTTl+vjzOWFpXdxNATv2yjwBNzudG1+rjiCEayd+96CyMURH+tk=
=ylP0
-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 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=0xbfebfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE
Features2=0xe3bdSSE3,DTES64,MON,DS_CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM
AMD Features=0x20100800SYSCALL,NX,LM AMD
Features2=0x1LAHF TSC: P-state invariant,
performance statistics real memory = 2147483648
(2048 MB) avail memory = 2007138304 (1914 MB)
Event timer LAPIC quality 400 ACPI APIC Table:
LENOVO TP-7LFreeBSD/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 mismatch in
FADT/Gpe1Block: 0/32 (20130823/tbfadt-601)
Yes, I didn't remove that warning, I just fixed it to use
the 64-bit length when the 32-bit length was zero when that
warning fires. Does this seem to have made any difference
with anything on the laptop? (E.g. it might possibly
affect hotkeys, etc.)
Believe it or not, but I just suspend/resumed on the thing,
TWICE. Once from the xfce menu - suspend and once from
Fn-moonsymbolsuspendsleepthing on the F4 key.
Good grief. Thanks John.
Humm. I wonder if we can get the Intel guys to accept the
patch upstream?
Yes, ACPICA guys are very open to patches. Actually there are
several ways to report bugs and/or submit patches.
Bug reports: https://bugs.acpica.org
Developer ML: https://lists.acpica.org/mailman/listinfo/devel
Source repository: https://github.com/acpica/acpica
However, I'm afraid the following commit may have nullified your
patch.
https://github.com/acpica/acpica/commit/8149df49
It looks to only be adjusting the preference for the Address
portion. It still uses the length field from FADT and doesn't use
the length from the GAS.
Okay.
BTW, I just read your patch carefully but I failed to understand how
shutting up a warning can fix any problem at all. Did you mean to
patch internal table?
Jung-uk Kim
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (FreeBSD)
iQEcBAEBAgAGBQJThifjAAoJEHyflib82/FGNsEIAI2/4zlCl4J448VDzRPlzp7i
jsHVt9KB7NUNin3Wie20PwxHxLhWcxd4LsMXUuC5vQUO7d8i06AMImsJ4O56u1ZO
muGu/tuH9RfmH7xBeJ/9Lu7FOSUhEPd4qIQwl0hD1P5OTmigdJDQ9W0Xw4l87VuH
EuHWM0DiXywAvZTKgPdc4REZHzO2PnVco7qm/HpJqcxksrmOMbWuPjlimnR4KSQT
JFf6Gp3+xtFgP3Mpcqfyn3Xi8hO8DEkVBOQVkAh9u3Rki1AZuBjPwkWop0ykTjT7
KL5UAv7Tx/4W04tbqzsE3lmvCdU5EcNjhSlFEmKA5oyOoNdyf7NNAz3fmMMkU2I
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)? 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:
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: 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: 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 j...@freebsd.org 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
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 s...@freebsd.org
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: 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 j...@freebsd.org 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
+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
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 j...@freebsd.org 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-05 04:24:58 -0400, Bengt Ahlgren wrote: Ganael LAPLANCHE ganael.laplan...@martymac.org 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-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-04 15:14:32 -0400, Bengt Ahlgren wrote: Jung-uk Kim j...@freebsd.org 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 18:39:07 -0400, Bengt Ahlgren wrote: Jung-uk Kim j...@freebsd.org writes: On 2013-09-04 15:14:32 -0400, Bengt Ahlgren wrote: Jung-uk Kim j...@freebsd.org 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 (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. :-( Jung-uk Kim Jumping to another thing. The Xorg intel/KMS driver does not present a backlight property using RandR (older non-KMS intel driver did): [bengta@bit ~]$ xbacklight No outputs have backlight property Bengt 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) iQEcBAEBAgAGBQJSJ7iTAAoJECXpabHZMqHOX0kH/Ag+vuvrx3YKyeYHKiGwlOKR eOp8s4m9EJgdPFy2Tw5u9xQsLiQ1JBgT10kZ+PDXaqFGEPGlVROrfc/lsoUVx6u3 ArOGaG1+NO1dTHurfrysRl/k35fcnY3p8+KrYmzbia6BNWC/3DmtnHItaWn+nOs2 PFJfCBWjjljVpZa+TNRBR2H5QMGOFnOGA9kDgZQe3QJY0JGZOMTuXizWatEYWo5q 7hLZsyvEsIQNSbmofE7KO5JNekllQ/F5A9RLilXRPnJBaJm1to2BT89Nf8JgiIxm 18jk17XXkRWYmAkM+8aYrxUoR9SIK/jn3hxL4iNZRma
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-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: 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 j...@freebsd.org
+ * Copyright (c) 2007-2013 Jung-uk Kim j...@freebsd.org
* 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 (Timeout == ACPI_WAIT_FOREVER) {
+ tmo = acpi_wait_forever * hz;
+ KASSERT(tmo 0 acpi_wait_forever UINT16_MAX / 1000,
+ (invalid timeout %d, tmo));
+ return (tmo);
+ }
+
tv.tv_sec = (time_t)(Timeout / 1000);
tv.tv_usec = (suseconds_t)(Timeout % 1000) * 1000;
@@ -106,6 +127,7 @@ ACPI_STATUS
AcpiOsDeleteSemaphore(ACPI_SEMAPHORE Handle)
{
struct acpi_sema *as = (struct acpi_sema *)Handle;
+ int retry;
ACPI_FUNCTION_TRACE((char *)(uintptr_t
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: 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: [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 iwas...@jp.freebsd.org 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 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: ACPI Host-PCI bridge 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 Thursday 30 June 2011 03:49 pm, Vitaly Magerya wrote: Andriy Gapon a...@freebsd.org 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 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: (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: [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 j...@freebsd.org
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 driver_t scpm_driver = {
- scpm,
- scpm_methods,
- 0
-};
-
-DRIVER_MODULE(scpm, vgapm, scpm_driver, scpm_devclass, 0, 0);
Index: sys/dev/syscons/syscons.c
===
--- sys/dev/syscons/syscons.c (revision 220864)
+++ sys/dev
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 j...@freebsd.org wrote: On Tuesday 19 April 2011 04:55 pm, Brandon Gooch wrote: On Tue, Apr 19, 2011 at 3:24 PM, Jung-uk Kim j...@freebsd.org 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: 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: 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 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 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 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 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. I would be fine with that, but that does not work if _CRS doesn't work (the acpi_pci_link_srs_from_links() case). For that case, we must use the template, of course. In fact, my patch is more useful for this particular case. :-) Are we allowed to modify the buffer ACPICA gives us from _CRS and then pass that back to _SRS? I believe so. If we go with that route, we don't have to worry about ResourceSource.StringPtr or acpi_AppendBufferResource() copying stale pointers. 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
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.
I would be fine with that, but that does not work if _CRS doesn't
work (the acpi_pci_link_srs_from_links() case).
For that case, we must use the template, of course. In fact, my
patch is more useful for this particular case. :-)
Are we allowed to modify the buffer ACPICA gives us from _CRS and
then pass that back to _SRS?
I believe so. If we go with that route, we don't have to worry
about ResourceSource.StringPtr or acpi_AppendBufferResource()
copying stale pointers.
Please see the attached patch. It seems working fine. :-)
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. ;-)
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-03 16:09:40.0 -0400
@@ -268,6 +268,7 @@ link_add_crs(ACPI_RESOURCE *res, void *c
static ACPI_STATUS
link_add_prs(ACPI_RESOURCE *res, void *context)
{
+ ACPI_RESOURCE *tmp
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 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 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: 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 j...@freebsd.org wrote: On Tuesday 19 October 2010 08:52 am, Bernhard Froehlich wrote: On Mon, 18 Oct 2010 13:33:26 -0400, Jung-uk Kim j...@freebsd.org 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 j...@freebsd.org 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 a...@icyb.net.ua 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 96clock_battery,memory_size,invalid_time 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
