A user reports: On my new Dell laptop I'm getting multiple complaints each time the battery monitor thread runs. Here's some gdb output from poking around: (kgdb) bt #0 0xc06a8dca in Debugger (msg=0x1b <Address 0x1b out of bounds>) at machine/atomic.h:263 #1 0xc0452527 in AcpiUtAllocate (Size=1, Component=128, Module=0xc06eb11e "", Line=166) at ../../../contrib/dev/acpica/utalloc.c:458 #2 0xc044611a in AcpiExStoreBufferToBuffer (SourceDesc=0x80, TargetDesc=0x1) at ../../../contrib/dev/acpica/exstorob.c:166 #3 0xc0446081 in AcpiExStoreObjectToObject (SourceDesc=0xa6, DestDesc=0xc2d386c0, NewDesc=0xcdcc09e8, WalkState=0x80) at ../../../contrib/dev/acpica/exstoren.c:348 #4 0xc0445d92 in AcpiExStoreObjectToIndex (SourceDesc=0xc2d384c0, IndexDesc=0x80, WalkState=0x1b) at ../../../contrib/dev/acpica/exstore.c:372 #5 0xc0445d0a in AcpiExStore (SourceDesc=0xa6, DestDesc=0x20, WalkState=0x80) at ../../../contrib/dev/acpica/exstore.c:243 #6 0xc0443b75 in AcpiExOpcode_1A_1T_1R (WalkState=0xa6) at ../../../contrib/dev/acpica/exoparg1.c:494 #7 0xc043c00d in AcpiDsExecEndOp (WalkState=0xc16ba400) at ../../../contrib/dev/acpica/dswexec.c:517 #8 0xc044c6f6 in AcpiPsParseLoop (WalkState=0xc16ba400) at ../../../contrib/dev/acpica/psparse.c:976 #9 0xc044cb1c in AcpiPsParseAml (WalkState=0xc16ba400) at ../../../contrib/dev/acpica/psparse.c:1258 #10 0xc044d80d in AcpiPsxExecute (MethodNode=0xc16b6e60, Params=0x0, ReturnObjDesc=0xcdcc0be8) at ../../../contrib/dev/acpica/psxface.c:288 #11 0xc0448dcf in AcpiNsExecuteControlMethod (MethodNode=0xc16b6e60, Params=0x1b, ReturnObjDesc=0x1b) at ../../../contrib/dev/acpica/nseval.c:527 #12 0xc0448d26 in AcpiNsEvaluateByHandle (Handle=0xc16b6e60, Params=0x1b, ReturnObject=0xc16b6e60) at ../../../contrib/dev/acpica/nseval.c:409 #13 0xc0448b9e in AcpiNsEvaluateRelative (Handle=0xc16b6e60, Pathname=0x1b <Address 0x1b out of bounds>, Params=0x1b, ReturnObject=0x1b) at ../../../contrib/dev/acpica/nseval.c:225 #14 0xc044aaa0 in AcpiEvaluateObject (Handle=0xc16b6f00, Pathname=0xc06ee623 "_BIF", ExternalParams=0x0, ReturnBuffer=0xcdcc0cb4) at ../../../contrib/dev/acpica/nsxfeval.c:357 #15 0xc045de26 in acpi_cmbat_get_bif (context=0xc16bd680) at ../../../dev/acpica/acpi_cmbat.c:250 This reports the warning "UtAllocate: Attempt to allocate zero bytes". Here is the section of ASL for _BIF: Name (BIFP, Package (0x0D) {}) Method (BIF, 1, NotSerialized) { SX10 () SX30 (0x01) SX30 (Arg0) SX11 () Store (SX42 (), Index (BIFP, 0x00)) Store (SX42 (), Index (BIFP, 0x01)) Store (SX42 (), Index (BIFP, 0x02)) Store (SX42 (), Index (BIFP, 0x03)) Store (SX42 (), Index (BIFP, 0x04)) Store (SX42 (), Index (BIFP, 0x05)) Store (SX42 (), Index (BIFP, 0x06)) Store (SX42 (), Index (BIFP, 0x07)) Store (SX42 (), Index (BIFP, 0x08)) Store (SX45 (), Index (BIFP, 0x09)) Store (SX45 (), Index (BIFP, 0x0A)) Store (SX45 (), Index (BIFP, 0x0B)) Store (SX45 (), Index (BIFP, 0x0C)) SX12 () Return (BIFP) } Name (SXX0, Buffer (0x0100) {}) Name (SXX1, Buffer (0x08) {}) CreateWordField (SXX1, 0x00, SXX2) CreateWordField (SXX1, 0x04, SXX3) Method (SX10, 0, NotSerialized) { Acquire (SMIX, 0xFFFF) Store (0x00, SXX2) } Method (SX30, 1, NotSerialized) { Store (SXX2, Local0) Increment (Local0) If (LNot (LGreater (Local0, SizeOf (SXX0)))) { CreateByteField (SXX0, SXX2, SX20) Store (Arg0, SX20) Store (Local0, SXX2) } } Method (SX31, 1, NotSerialized) { Store (SXX2, Local0) Add (Local0, 0x02, Local0) If (LNot (LGreater (Local0, SizeOf (SXX0)))) { CreateWordField (SXX0, SXX2, SX21) Store (Arg0, SX21) Store (Local0, SXX2) } } Method (SX32, 1, NotSerialized) { Store (SXX2, Local0) Add (Local0, 0x04, Local0) If (LNot (LGreater (Local0, SizeOf (SXX0)))) { CreateDWordField (SXX0, SXX2, SX22) Store (Arg0, SX22) Store (Local0, SXX2) } } Method (SX33, 2, NotSerialized) { If (LLess (Arg1, SizeOf (Arg0))) { CreateByteField (Arg0, Arg1, SX20) SX30 (SX20) } } Method (SX34, 2, NotSerialized) { Store (0x00, Local0) While (LLess (Local0, Arg1)) { SX33 (Arg0, Local0) Increment (Local0) } } Method (SXX6, 2, NotSerialized) { Store (Arg1, \_SB.SMIA) Store (Arg0, \_SB.SMIC) Store (\_SB.SMIC, Local0) While (LNot (LEqual (Local0, 0x00))) { Store (\_SB.SMIC, Local0) } Return (\_SB.SMIA) } Method (SXX5, 2, NotSerialized) { If (LLess (Arg1, SizeOf (Arg0))) { CreateByteField (Arg0, Arg1, SX20) SXX6 (0x7C, SX20) } } Method (SXX4, 0, NotSerialized) { SXX6 (0x7B, 0x00) Store (0x00, Local0) While (LLess (Local0, SXX2)) { SXX5 (SXX0, Local0) Increment (Local0) } } Method (SXX8, 2, NotSerialized) { If (LLess (Arg1, SizeOf (Arg0))) { CreateByteField (Arg0, Arg1, SX20) Store (SXX6 (0x7D, 0x00), SX20) } } Method (SXX7, 0, NotSerialized) { Store (0x00, Local0) While (LLess (Local0, SXX3)) { Add (SXX2, Local0, Local1) SXX8 (SXX0, Local1) Increment (Local0) } } Method (SX11, 0, NotSerialized) { SXX4 () Store (SXX6 (0x79, 0x00), SXX3) Add (SXX2, SXX3, Local0) If (LLess (SizeOf (SXX0), Local0)) { Store (SizeOf (SXX0), Local0) Subtract (Local0, SXX2, Local0) Store (Local0, SXX3) } SXX7 () } Method (SX40, 0, NotSerialized) { Store (SXX2, Local0) Increment (Local0) If (LNot (LGreater (Local0, SizeOf (SXX0)))) { CreateByteField (SXX0, SXX2, SX20) Store (Local0, SXX2) Return (SX20) } Return (0x00) } Method (SX41, 0, NotSerialized) { Store (SXX2, Local0) Add (Local0, 0x02, Local0) If (LNot (LGreater (Local0, SizeOf (SXX0)))) { CreateWordField (SXX0, SXX2, SX21) Store (Local0, SXX2) Return (SX21) } Return (0x00) } Method (SX42, 0, NotSerialized) { Store (SXX2, Local0) Add (Local0, 0x04, Local0) If (LNot (LGreater (Local0, SizeOf (SXX0)))) { CreateDWordField (SXX0, SXX2, SX22) Store (Local0, SXX2) Return (SX22) } Return (0x00) } Method (SX43, 2, NotSerialized) { If (LLess (Arg1, SizeOf (Arg0))) { CreateByteField (Arg0, Arg1, SX20) Store (SX40 (), SX20) } } Method (SX44, 2, NotSerialized) { Store (0x00, Local0) While (LLess (Local0, Arg1)) { SX43 (Arg0, Local0) Increment (Local0) } } Method (SX45, 0, NotSerialized) { Store (SX40 (), Local0) Name (SX23, Buffer (Local0) {}) SX44 (SX23, Local0) Return (SX23) } Method (SX12, 0, NotSerialized) { Release (SMIX) } Unfortunately, the AML seems obfuscated. The problem appears to be in SX45 but I'm not sure. Let me know what other info you'd like. This is with ACPI-CA 1203.
This test case looks rather big! And I cannot find out code that can reproduce that warning on my T21. Would you please add some Store ("xxxx", Debug) that will help you narrow down the problem.
Created attachment 1747 [details] a proposal patch I don't think store zero-length buffer to zero-length buffer need allocate memroy.
Thanks for the patch. It silences the users' warning messages but doesn't address the underlying problem. I found this web page with a patch that does fix their problems. Is there any way you can fix ACPI-CA so this DSDT patch is not needed? It appears that the ASL is passing by value when it should be passing by reference. http://sandcat.nl/~stijn/freebsd/dell.php
Created attachment 1760 [details] DSDT patch for passing by reference
The following test case cannot reporoduce the problem you may have. Could you please describe the error casued by passing argument by value. Name (SXX0, Buffer(6) {1,2,3,4,5,6}) Method (SXX5, 2, NotSerialized) { Store("sizeof arg0", Debug) Store(sizeof(Arg0), Debug) /* Store("sizeof refof arg0",Debug) Store(sizeof(refof(Arg0)),Debug) */ If (LLESS(Arg1, sizeof(Arg0))) { CreateByteField(Arg0, Arg1, SX20) store("store sx20", Debug) Store(SX20, Debug) } } Method (_STA, 0, NotSerialized) { Store ("1111111" ,Debug) Name (SX23, Buffer(0) {}) Store ("2222222", Debug) Store (SX24, SX23) /* Store ("sizeof SXX0", Debug) Store (sizeof(SXX0), Debug) */ Store ("sizeof refof SXX0", Debug) Store (sizeof(refof(SXX0)), Debug) Store ("SXX5", Debug) SXX5 (SXX0, 2) } The result is: [ACPI Debug] String: 1111111 [ACPI Debug] String: 2222222 [ACPI Debug] String: sizeof refof SXX0 [ACPI Debug] Integer: 0000000000000006 [ACPI Debug] String: SXX5 [ACPI Debug] String: sizeof arg0 [ACPI Debug] Integer: 0000000000000006 [ACPI Debug] String: store sx20 [ACPI Debug] Integer: 0000000000000003
If you use the ASL patch I have attached that adds RefOf/DerefOf (credit Mark Santcroos), the problems are fixed. You can also revert dsmthdat.c back to what it was pre-0619 and that also fixes the problem. The issue is, ACPI-CA is still not getting its argument-passing right after moving away from "always copy" semantics. For now, I will be reverting dsmthdat.c with the following patch.
Created attachment 1772 [details] Full ASL for the problem system Please look at this full ASL rather than the snippet I gave you.
Here is a diff to revert dsmthdat.c. Please test and see if this also fixes the problem. http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/contrib/dev/acpica/dsmthdat.c.diff?r1=text&tr1=1.1.1.20&r2=text&tr2=1.1.1.18
Sorry, the above diff is backwards. I'll attach the correct diff.
Created attachment 1773 [details] Revert changes to copy semantics in dsmthdat.c
That patch is introduced for solving bug 1444 "ACPI-1120: *** Error: Method execution failed ... AE_AML_BUFFER_LIMIT on Compaq X1005EA". So it cannot be reverted. Would you please take a look at bug 1766. Is that issue you want to solve. BTW, I'm still unable to reproudce "UTAllocate 0 length warnings". Would you please provide me with test case. --Luming
Created attachment 1783 [details] Dell ASL that causes problem. I see the 0 length allocation stuff. I used to see the same errors that are fixed on the Compaq, but those have disappeared. Reverting things per this patch fixes my problem and doesn't cause a recurrance AND gives me good battery. I'd reconfirm that the laptop in question really was fixed by this patch, or if it merely looked that way.
Just added an attachment that's my dell's ASL. I used to see the same sort of error that the Compaq is having, and they went away at some point. Reverting things, per this patch, fixes my battery woes and the warnings (w/o them my battery status is foobar'd) are also gone. Since I had a similar experience to the Compaq laptop in the deep, dark recesses of time, I'd suggest reverting it and letting that compaq owner re-complain. I strongly suspect that something else was to blame and that the change to dsmthdat.c just papered over the problem for a while. But I'm biased; I have a dell, and have many friends who have dells that are getting bit by this problem.
Note that this bug is being worked on by Luming Yu in bug 1766
The work around given in Bug 1766 appears to restore my battery functions. And eliminate the warnings. Woo Hoo! Much less dramatic than the huge backout.