I have a hp notebook that needs acpi_serialize to acpi functions work properly. Well , everything work fine on 2.6.20 but now after try 2.6.21-rc3 , my system locks during boot when i pass acpi_serialize option. The last three lines before the lock are: ACPI: Interpreter Enabled ACPI: (Supports S0 S3 S4 S5) ACPI: Using IOAPIC for interrupt routing. so the system locks [ i waited five minutes just to be sure ]...
Created attachment 10697 [details] acpidump output
i have exactly the same problem here. Kernel stops during boot right after those same messages. I attached the acpidump output that can help to trace the problem.
Does acpi_serialize still deadlock on linux-2.6.3-rc3-git6 or later? Please include information on why you are using the option in the first place. What bad things happened in 2.6.20 when you did not use acpi_serialize?
i will test in git and post results. In old kernel i had a lot of : A lot of Jan 6 00:43:49 localhost kernel: ACPI Error (psargs-0355): [PBST] Namespace lookup failure, AE_NOT_FOUND Jan 6 00:43:49 localhost kernel: ACPI Error (psparse-0537): Method parse/execution failed [\_SB_.PCI0.LPCB.BAT1._BST] (Node c1910770), AE_NOT_FOUND Jan 6 00:43:49 localhost kernel: ACPI Exception (acpi_battery-0207): AE_NOT_FOUND, Evaluating _BST [20060707] Jan 6 00:44:19 localhost kernel: ACPI Error (psargs-0355): [PBST] Namespace lookup failure, AE_NOT_FOUND Jan 6 00:44:19 localhost kernel: ACPI Error (psparse-0537): Method parse/execution failed [\_SB_.PCI0.LPCB.BAT1._BST] (Node c1910770), AE_NOT_FOUND Jan 6 00:44:19 localhost kernel: ACPI Exception (acpi_battery-0207): AE_NOT_FOUND, Evaluating _BST [20060707] Jan 6 00:44:49 localhost kernel: ACPI Error (psargs-0355): [PBST] Namespace lookup failure, AE_NOT_FOUND Jan 6 00:44:49 localhost kernel: ACPI Error (psparse-0537): Method parse/execution failed [\_SB_.PCI0.LPCB.BAT1._BST] (Node c1910770), AE_NOT_FOUND Jan 6 00:44:49 localhost kernel: ACPI Exception (acpi_battery-0207): AE_NOT_FOUND, Evaluating _BST [20060707] this way , power management did not work. Suspend did not work , and a lot of related problems. acpi_serialize fixed that.
I`ve just tested in 2.6.21-rc3-git7 and still lock :/
any chance you can bisect to see where the hang starts? In particular, can you see if it starts with this commit? 1ba753acb372c2955a4843302e92e49ce82e2fea Author: Bob Moore <robert.moore@intel.com> 2007-02-02 11:48:20 Committer: Len Brown <len.brown@intel.com> 2007-02-02 21:14:24 Parent: 95befdb398e0112ede80529f6770644ecfa5a82e (ACPICA: Create tbfadt.c to hold all FADT-related functions) Child: 765ec20180fb70b4ee9d730167b2a0b76879f791 (ACPICA: Delete stale FADT functions outside tbfadt.c.) Branches: origin, master Follows: v2.6.20-rc7 Precedes: v2.6.21-rc1
how can i do this ? I download 2.6.20rc7 and do what ? i could boot perfectly in 2.6.20 with acpi_serialize so i think that is not the problem.
Well , tonight i will try 2.6.21-rc1-git1..7. A doubt , sould i apply the git 2.6.21-rc1-gitXX patch over 2.6.20.2 ? Are they cummulative or i must apply one by one ?
> Follows: v2.6.20-rc7 I'm sorry this line was mis-leading, it also follows 2.6.20. > Precedes: v2.6.21-rc1 Since git keeps track of patch dependencies, and later patches are on top of this one it is simplest to get a git tree, and roll the history back to the exact place that the patch occurred. git bisect start git bisect good v2.6.20 git-bisect bad v2.6.21-rc1 git checkout -b expect-bad 1ba753acb372c2955a4843302e92e49ce82e2fea if good: bit bisect good if bad: git bisect bad git checkout -b expect-good 95befdb398e0112ede80529f6770644ecfa5a82e if good: git bisect good if bad: git bisects bad git visualize The guess here, of course, is that "expect-bad" is bad, and "expect-good" is good. However, if this guess is wrong, you'll be able to continue to use git bisect to look elswhere using bisect's choice of suspects.
sorry , but i have never used git before. How can i get the kernel from repository to start use those commands you sent me ?
grab an RPM for git for your distro if it isn't installed already. or get a git archive tar file: http://kernel.org/pub/software/scm/git/ If you want to track the very latest version of git, use that to get it: git clone git://git.kernel.org/pub/scm/git/git.git Get the current copy of Linus' kernel tree: git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git Initial git tutorial lives here: http://www.kernel.org/pub/software/scm/git/docs/tutorial.html
can not test : %cd /TMP/bisect/ %cd linux-2.6/ %git bisect start %git bisect good v2.6.20 %git-bisect bad v2.6.21-rc1 Bisecting: 1614 revisions left to test after this [574009c1a895aeeb85eaab29c235d75852b09eb8] Merge branch 'upstream' of git://ftp$ %git checkout -b expect-bad 1ba753acb372c2955a4843302e92e49ce82e2fea %make menuconfig %make ... LD .tmp_vmlinux1 drivers/built-in.o(.text+0x2e3b0): In function `acpi_tb_parse_fadt': : undefined reference to `acpi_tb_install_table' drivers/built-in.o(.text+0x2e3c8): In function `acpi_tb_parse_fadt': : undefined reference to `acpi_tb_install_table' make: *** [.tmp_vmlinux1] Error 1 %
rats! Sorry I lead you on a wild-goose chase to a commit that doesn't even build -- buy hey, now you know how to use git and do a bisect:-) I've reproduced the "acpi_serialize" hang on my t41, so I should be able to work on it here.
Created attachment 10774 [details] 2.6.21-rc3 patch to revert ACPICA acpi_serialize changes Please test this patch with "acpi_serialize"
well , it is working great now , ooops , not great 'cause you told me acpi_serialize is just a workaround :), let`s say that the workaround is working great :D . Thanks.
heh, yeah, we're back to where we started. we still need to go figure out why it is necessary to manually use "acpi_serialize" on this box in the first place.
if there is anything else i can do to help in this , just ask :)
patch in comment #14 shipped in linux-2.6.21-rc4-git7 so this regression vs 2.6.20 should be gone, and this bug is closed. yes, it is also a bug that booting with acpi_serialize has been necessary to boot your system -- no matter what release. Please open a new bug for that issue.
Hi, this problem has appeared again in 2.6.22. I can not boot my machine with acpi_serialize again. Systel Locks here: ACPI: INTERPRETER ENABLED ACPI: (SUPPORT S0 S3 S4 S5) ACPI: USING IOAPIC FOR INTERRUPT ROUTING SO IT STOPS HERE.
your machine booted properly with 2.6.21 and acpi_serialize, but fails to boot with 2.6.22 and acpi_serialize? Any chance you can bisect where it broke? Please point me to the bug report showing why acpi_serialize is necessary on this machine.
Same problem that Comment #4 power management , suspend ... I am on dial up so i think it wont be possible use git :/ Last kernel i tried was 2.6.21.5 and it worked fine.
Salatiel -- are you having this problem again also?
Sorry the delay , i was downloading 2.6.22 ... Yeah, same problem here. My machine also locks. I have opened a bug about my machine need acpi_serialize today as soon as i saw this post :). Everything was working great with 2.6.21 that i do not even try to update to 2.6.22.
any news on this ?
Was _BST the only method failing? If so, you might want to disassemble the DSDT, patch the _BST declaration to make it serialized, then override the DSDT. Might provide another data point. -Method (_BST, 0, NotSerialized) +Method (_BST, 0, Serialized)
? :)
Please try compiling the ACPICA code with the ACPI_MUTEX_DEBUG flag defined. Actually, just the utilities/utmutex.c file will suffice. Then, see if any error messages are produced before the system hangs. Thanks.
I do not know if i did right , i just add a line #define ACPI_MUTEX_DEBUG TRUE well , the strange part is that after that the system does not lock anymore. But i really got a lot of errors in the point where it should lock. Executed 1 _INI methods requiring 0 _STA executions (examined 63 objects) ACPI: Interpreter enabled ACPI: (supports S0 S3 S4 S5) ACPI: Using IOAPIC for interrupt routing * IT USED TO LOCK HERE* ACPI Error (utmutex-0231): Mutex [ACPI_MTX_Interpreter] already acquired by this thread [DFD27A70] [20070126] ACPI Error (exutils-0096): Could not acquire AML Interpreter mutex [20070126] ACPI Error (utmutex-0306): Mutex [0] is not acquired, cannot release [20070126] ACPI Error (exutils-0156): Could not release AML Interpreter mutex [20070126] ACPI Error (utmutex-0231): Mutex [ACPI_MTX_Interpreter] already acquired by this thread [DFD27A70] [20070126] ACPI Error (exutils-0096): Could not acquire AML Interpreter mutex [20070126] ACPI Error (utmutex-0306): Mutex [0] is not acquired, cannot release [20070126] ACPI Error (exutils-0156): Could not release AML Interpreter mutex [20070126] ACPI Error (utmutex-0231): Mutex [ACPI_MTX_Interpreter] already acquired by this thread [DFD27A70] [20070126] ACPI Error (exutils-0096): Could not acquire AML Interpreter mutex [20070126] ACPI Error (utmutex-0306): Mutex [0] is not acquired, cannot release [20070126] ACPI Error (exutils-0156): Could not release AML Interpreter mutex [20070126] ACPI Error (utmutex-0231): Mutex [ACPI_MTX_Interpreter] already acquired by this thread [DFD27A70] [20070126] ACPI Error (exutils-0096): Could not acquire AML Interpreter mutex [20070126] ACPI Error (utmutex-0306): Mutex [0] is not acquired, cannot release [20070126] ACPI Error (exutils-0156): Could not release AML Interpreter mutex [20070126] ACPI: PCI Root Bridge [PCI0] (0000:00) PCI: Probing PCI hardware (bus 00) ...
Thanks. I have solved the problem. Patch forthcoming. Bob
Created attachment 12890 [details] serialized bug fix Please try this patch
It worked :) thanks.
isn`t this patch already commited, is it ? I tried the kernel 2.6.22.9 and it still locks.
Len Brown handles the actual Linux patches. I don't know if it has made it into the kernel yet.
update bug status to resolved.
hrm, so it seems that... 2.6.20: okay -- baseline for this report 2.6.21: okay -- .21-rc regression fixed by patch in comment #14 2.6.22: broken -- needs patch in comment #30 2.6.23: broken -- needs patch in comment #30 2.6.24: broken -- needs patch in comment #30 added patch in comment #30 to acpi test tree Bob, how did we break this in 2.6.22? -- we didn't update ACPICA between 2.6.21 and 2.6.22, they're both 20070126.
Not sure, depends on when the changes below were integrated into Linux. Problem was introduced here: 12 September 2006. Summary of changes for version 20060912: Enhanced the implementation of the "serialized mode" of the interpreter (enabled via the AcpiGbl_AllMethodsSerialized flag.) When this mode is specified, instead of creating a serialization semaphore per control method, the interpreter lock is simply no longer released before a blocking operation during control method execution. This effectively makes the AML Interpreter single-threaded. The overhead of a semaphore per-method is eliminated. Problem was solved here: 19 September 2007. Summary of changes for version 20070919: Fixed a problem where the use of the AcpiGbl_AllMethodsSerialized flag (acpi_serialized option on Linux) could cause some systems to hang during initialization. (Bob Moore) BZ 8171
patch in comment #30 shipped in linux-2.6.24-rc7-git5 closed.