Most recent kernel where this bug did not occur: 2.6.21.5 Distribution: Ubuntu/Slackware Hardware Environment: HP Pavillion dv8230us Software Environment: Problem Description: With out acpi_serialize option , my machine does not function properly. A lot of battery problems with: rror (dswload-0774): [PBST] Namespace lookup failure, AE_ALREADY_EXISTS ACPI Exception (psloop-0225): AE_ALREADY_EXISTS, During name lookup/catalog [20070126] ACPI Error (psparse-0537): Method parse/execution failed [\_SB_.PCI0.LPCB.BAT1._BST] (Node dfd1b770), AE_ALREADY_EXISTS ACPI: Marking method _BST as Serialized ACPI Exception (battery-0206): AE_ALREADY_EXISTS, Evaluating _BST [20070126] ACPI Error (psargs-0355): [PBST] Namespace lookup failure, AE_NOT_FOUND ACPI Error (psparse-0537): Method parse/execution failed [\_SB_.PCI0.LPCB.BAT1._BST] (Node dfd1b770), AE_NOT_FOUND ACPI Exception (battery-0206): AE_NOT_FOUND, Evaluating _BST [20070126]
In 2.6.21, When you do not use "acpi_serialize", you get the errors above and battery status doesn't work etc. But when you boot with "acpi_serialize", all these warnings go away and your battery works properly? Is there a previous release of Linux where you did not need acpi_serialize, or have you always needed it for every release tested? Please attach the output from acpidump
Created attachment 12142 [details] acpidump data acpidump data
Yes. With acpi_serialize all errors go away and everything works great. Actually with out acpi_serialize i have a lot of problems with battery status and i can not suspend/resume [S3] my machine either. i bought this notebook in december and i always needed this parameter , actually it was someone on linux-acpi maillist that told me to use that option to see if my machine.
if my machine worked :) i forgot to finish the sentence ;p
It looks like acpi_serialize is doing the job it was intended to do, and nothing more needs to be done. I am closing this bug report.
Well , now i do not understand. Len Brown told me that acpi_serialize is just a workaround not a realfix. btw, acpi_serialize locks my machine in 2.6.22.xx kernels. I already report a bug on this too.
acpi_serialize is a workaround for bad BIOS ASL code. You said: >Yes. With acpi_serialize all errors go away and everything works great. So, now I do not understand.
:) You are right , with acpi_serialize everything works OK, what i said i did not understand it is why Len told me to open a Bug about this if telling that acpi_serialize is just a workaround and some real fix should be done. :) Anyway , thanks :) Now i have just to wait some fix for acpi_serialize locking the system in > 2.6.21 Bug 8171 and maybe duplicated in 8454. I will stay in 2.6.21 for a while...
If a user needs to add a boot parameter to convince Linux/ACPI to work properly with the BIOS that shipped from the vendor, when that same BIOS does not confuse Windows, then it is a Linux/ACPI bug. It may be that we choose to deal with the compatibility issue by looking up the DMI for the machine and enabling acpi_serialize automatically, or maybe we need to do something more clever -- but the system should work "out of the box" on Linux, and it is a bug if it does not.
well, i agree. Mainly `cause acpi_serialize now locks the system on kernel > 2.6.21. This way i can not upgrade until this bug is "fixed" or Bug 8171 [acpi_serialize locking system] be fixed :) Thank you guys
We tried to be clever about detecting the error and marking the method as serialized on the fly: ACPI: Marking method _BST as Serialized But, this is not a clean solution as errors can still appear, at least until the method becomes idle and marked serialized.
Robert can you check if the following ought to be acceptable? There is a error message printed still.. but it works great after that. http://bugzilla.kernel.org/attachment.cgi?id=12814&action=view
I don't think it is a good idea to set status to AE_OK in this case, because the control method did in fact abort prematurely with an exception. If the caller is expecting data from the method, it will be bogus even though an AE_OK was returned. Once we set the method to SERIALIZED, however, it should work fine from then on. I had a thought that we might just automatically mark all _BST methods as serialized because this seems to be a recurring problem across a large number of machines.
If there is no way there can be a bad outcome of marking _BST methods as serializedby default, it can be a good idea. Would cut the number of bug reports from people that would spot and exception in dmesg. Somehow my system was acting up only on AC events, but it doesn't get stuck after the "Marking _BST serialized..." anymore as it used to. Hence the hackich status = AE_OK. I'm using current ubuntu-gutsy.git
Or, another possibility would be to mark the method serialized and restart it. We're still thinking about the whole thing. Take a look at Bug 8171, I have posted a patch that fixes problems with the acpi_serialized flag. You might be running into that.
I've been following that bug report too, and it does hang with acpi_serialized. On the other side, I don't know what commit fixed the exception on AC events. Maybe this one: http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-gutsy.git;a=commit;h=426ea6c8aadc921e499f490bb457086945b42a0d and then this quick fix on the previous http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-gutsy.git;a=commit;h=b478b18f0842c250dc7ff33da531ba8f83975bad Also, do you think I can link your patch from Bug 8171 to an Ubuntu developer for inclusion in gutsy? I mean.. You haven't commit yet to git, did you?
It's been released in ACPICA version 20070919.
mark bug as fixed per comment# 17, please reopen if it doens't work.
ACPICA 20070919 shipped in Linux 2.6.26-rc1 please re-open if that release or later does not work properly. closed.