Bug 1728
Summary: | UtAllocate 0 length warnings | ||
---|---|---|---|
Product: | ACPI | Reporter: | Nate Lawson (nate) |
Component: | ACPICA-Core | Assignee: | Robert Moore (Robert.Moore) |
Status: | CLOSED CODE_FIX | ||
Severity: | low | CC: | acpi-bugzilla |
Priority: | P2 | ||
Hardware: | i386 | ||
OS: | Linux | ||
Kernel Version: | 2.6.0 | Subsystem: | |
Regression: | --- | Bisected commit-id: | |
Bug Depends on: | 1766 | ||
Bug Blocks: | |||
Attachments: |
a proposal patch
DSDT patch for passing by reference Full ASL for the problem system Revert changes to copy semantics in dsmthdat.c Dell ASL that causes problem. |
Description
Nate Lawson
2003-12-22 17:19:28 UTC
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. |