Most recent kernel where this bug did not occur: N/A Distribution: Debian stable, testing, unstable Hardware Environment: Acer Aspire 5050-4570 (Turion64 MK-38) Software Environment: Problem Description: All three stock kernels I've tried and one I've compiled give the following error on boot, and then halt: ACPI Exception (processor_core-0781): AE_NOT_FOUND, Processor Device is not present [20070126] The 2.6.18(-5) kernel from Debian stable is the only one that will boot in single-user mode; after the above message, it pauses on the following message for several seconds and outputs what looks like a stack dump (goes by too quickly for me to see it, and isn't in any of the system logs or dmesg): Getting cpuindex for acpiid 0x01 Steps to reproduce: Install Debian on an Acer Aspire 5050-4570
please boot the system with "acpi=off" and get the output from acpidump, and attach it to this bug report. Please see if you can boot in ACPI mode with "maxcpus=1" if you can, please attach the output from dmesg -s64000
Created attachment 12584 [details] acpidump with acpi=off, 2.6.22 kernel
maxpcpus=1 makes no difference. Apparently the 2.6.18 kernel will boot in normal mode, but hangs when it loads acpi services (non-kernel-level): the system continues to take keyboard input, but ^C has no effect.
(In reply to comment #3) > maxpcpus=1 makes no difference. Sorry, typo. > Apparently the 2.6.18 kernel will boot in normal mode, but hangs when it > loads > acpi services (non-kernel-level): the system continues to take keyboard > input, > but ^C has no effect. >
Does a kernel built with CONFIG_ACPI_PROCESSOR=n boot in ACPI mode?
Yes. Btw, apparently the message for the 2.6.18 kernel has acpiid 0x1, not 0x01.
Well, when I say it boots, I mean it gets past the kernel-level acpi stuff loading, but the acpi daemon still hangs in the 2.6.22 kernel; the 2.6.18 kernel behaves more nicely.
Sorry, I mean the system gets that far normally with the 2.6.18 kernel--with the ACPI daemon hanging. The kernel I'm compiling is 2.6.22.
With self-compiled 2.6.22.5, I have some new-found control to test things. This is what I've found: The processor module still loads and gives the AE_NOT_FOUND error. The ac module, otoh, freezes the system when an attempt is made to load it.
2.6.22.6 kernel has the same behaviour. Also, the battery module loads, but reports no battery, and no battery info shows up in /proc. This appears to be a hot topic on the Ubuntu forums: http://ubuntuforums.org/showthread.php?t=532567
The thermal module also freezes the system. In summary, ac and thermal both freeze the system on loading, the prcoessor module throws AE_NOT_FOUND but loads, and the battery module loads and does not work. This behaviour seems consistent for 2.6.22 kernels on this machine, including 2.6.22.6, and a quick search shows I'm not alone in these problems on this hardware. I also upgraded my BIOS a few hours ago, but it didn't change any of the behaviour. Should this bug remain as NEEDINFO? I'll be happy to provide any further information needed.
Will you please upload the acpidump and dmesg with boot option acpi=off apic=debug after BIOS is updated? It is better to upload the .config file. Thanks.
Created attachment 12778 [details] dmesg with acpi=off apic=debug
Created attachment 12779 [details] acpidump with acpi=off apic=debug
Created attachment 12780 [details] 2.6.22.6 kernel .config The modules which crash the system have been disabled so that other ACPI can be enabled with other ACPI features working.
I can confirm this same problem on an Aspire 5050-4697, my dmesg and acpidump are virtually the same, and indeed building without processor, ac and battery gets the system to boot. I had to add noapic and nolapic additionally to the kernel command line to be alble to use the RTL-8931 ethernet NIC, I guess due to IRQs? PCMCIA supported WiFi NICs don't work either (PCMCIA seems to be disabled when using the other arguments). At any rate, the same behavior as the original report is present without any comman line arguments.
Thanks for the info. Will you please test it using the latest stable kernel? Please enable ACPI processor /battery in the kernel configuration.(CONFIG_ACPI_PROCESSOR=y . not m). Please get the dmesg using serial port and upload the dmesg. (acpi is on) Thanks.
Please boot with idle=poll and report if that helps. If it does, then this hang is related to going into an ACPI C-state. Ignore the "processor device is not present" message -- per bug 8570 it is probably unrelated to the functional issue here.
2.6.23.1 kernel with and without idle=poll reacts the same as previously reported.
*** Bug 9088 has been marked as a duplicate of this bug. ***
"Processor device is not present" message does indeed seem to be unrelated. I'm afraid I can't add anything more of much use without being asked for it. So is there any more information I can provide, or are we just going to say the kernel's current acpi code is hopelessly broken (for Acer users?)?
I have an Acer Aspire 3050 and I have a similar problem.
2.6.24-rc3 does not crash as reported for previous versions. Battery usage information, however, is not available from the kernel.
(In reply to comment #23) > 2.6.24-rc3 does not crash as reported for previous versions. > > Battery usage information, however, is not available from the kernel. > OK, veryfied in my laptop too. ACPI error messages (and some not error) in dmesg are: ACPI: EC: acpi_ec_wait timeout, status = 255, expect_event = 2 ACPI: EC: input buffer is not empty, aborting transaction ACPI Exception (evregion-0420): AE_TIME, Returned by Handler for [EmbeddedControl] [20070126] ACPI Exception (dswexec-0462): AE_TIME, While resolving operands for [OpcodeName unavailable] [20070126] ACPI Error (psparse-0537): Method parse/execution failed [\_TZ_.THRM._TMP] (Node ffff81003b83e2e0), AE_TIME ACPI: Battery Slot [BAT1] (battery absent) ACPI: EC: acpi_ec_wait timeout, status = 255, expect_event = 2 ACPI: EC: input buffer is not empty, aborting transaction ACPI Exception (evregion-0420): AE_TIME, Returned by Handler for [EmbeddedControl] [20070126] ACPI Exception (dswexec-0462): AE_TIME, While resolving operands for [OpcodeName unavailable] [20070126] ACPI Error (psparse-0537): Method parse/execution failed [\_SB_.ACAD._PSR] (Node ffff81003b83cf60), AE_TIME ACPI Exception (ac-0131): AE_TIME, Error reading AC Adapter state [20070126] input: Power Button (FF) as /class/input/input2 ACPI: Power Button (FF) [PWRF] input: Power Button (CM) as /class/input/input3 ACPI: Power Button (CM) [PWRB] input: Lid Switch as /class/input/input4 ACPI: EC: acpi_ec_wait timeout, status = 255, expect_event = 2 ACPI: EC: input buffer is not empty, aborting transaction ACPI Exception (evregion-0420): AE_TIME, Returned by Handler for [EmbeddedControl] [20070126] ACPI Exception (dswexec-0462): AE_TIME, While resolving operands for [OpcodeName unavailable] [20070126] ACPI Error (psparse-0537): Method parse/execution failed [\_SB_.LID_._LID] (Node ffff81003b83e260), AE_TIME ACPI: Lid Switch [LID] input: Sleep Button (CM) as /class/input/input5 ACPI: Sleep Button (CM) [SLPB] Hernan
Any ideas? I have the same problem on my laptop.
I have an Acer Aspire 5050-3785 bios 3309 and I have a similar problem. I tried 2.6.24-rc3 and battery monitor not work too.
I do something that solved my problem. I change the version of bios to 3303 and now is ok.
Could you release more information? Which ACER Aspire model do you have? Where did you find the bios? (ACER has different products, services, etcetera for different regions of the world) Is this an upgrade or a downgrade? (Which was your previous Bios?) If downgrade, have you notice problems with other things under Linux or Vista? Thanks Hernan
I get similar messages. Also, resume from s2ram no longer works with 2.6.24-rc3. ACPI Error (psargs-0355): [\_SB_.PHSR] Namespace lookup failure, AE_NOT_FOUND ACPI Error (psparse-0537): Method parse/execution failed [\_SB_.PCI0.LPC0.EC0_._REG] (Node ffff81002f82d810), AE_NOT_FOUND Initializing Device/Processor/Thermal objects by executing _INI methods:<4>ACPI: System BIOS is requesting _OSI(Linux)
_REG method of EC0 uses absent \_SB_.PHSR method. There are seem to be 2 methods with the same name -- \_SB_.PCI0.LPC0.PHSR just above the EC0 declaration and \_SB_.WMID.PHSR, which is used quite a lot through the DSDT. You could try to modify your DSDT to call the second method instead of absent one, and see if it helps.
Could you give me any guidance on how to do that? Messing with my DSDT scares me, since I basically have no clue what I'm doing.
Ok, let's try easy things first -- please check if you have latest BIOS, and if not install it from here... ftp://ftp.work.acer-euro.com/notebook/aspire_5050/bios/3309.zip
If you don't mind,I will be testing too (I hope I will learn some new stuff) dmidecode -s bios-version returns v1.3309 Hernan
I also have 3309.
do `cat /proc/acpi/dsdt > DSDT.dat` disasm: 'iasl -d DSDT.dat' you should see DSDT.dsl. edit DSDT.dsl line 3906 "Store (\_SB.PHSR (0x0D, 0x00), TJ85)" to look "Store (\_SB.WMID.PHSR (0x0D, 0x00), TJ85)". "WMID." inserted. 'iasl -tc DSDT.dsl' to compile DSDT back. Unselect Device Drivers->Generic Driver Options->Select only drivers... Select Power Management->ACPI->Custom DSDT Put DSDT.hex into Custom DSDT location field. Copy file DSDT.hex into drivers/acpi do make/make install/...
Yes, works Great in my Acer 5050-3785 Bios 3309, very thanks Alexey Starikovskiy you are linux man. Battery detected full work.
Works great here too. I now have battery usage info for the first time, thanks! I'm still having issues with s2ram, but I guess it's unrelated?
OK. same report here. Way to go! The compilation produced some 11 errors (the errors were there before the change made). The report follows. Nevertheless, the battery and ac status are working! Hernan Intel ACPI Component Architecture ASL Optimizing Compiler version 20061109 [Sep 21 2007] Copyright (C) 2000 - 2006 Intel Corporation Supports ACPI Specification Revision 3.0a DSDT.dsl 90: Field (PLPT, DWordAcc, Lock, Preserve) Error 4026 - ^ Access width is greater than region size DSDT.dsl 92: P378, 8 Error 4027 - ^ Access width of Field Unit extends beyond region limit DSDT.dsl 132: Method (_WAK, 1, NotSerialized) Warning 1079 - ^ Reserved method must return a value (_WAK) DSDT.dsl 5341: Name (_T_0, 0x00) Error 4081 - Use of reserved word ^ (_T_0) DSDT.dsl 5384: Name (_T_0, 0x00) Error 4081 - Use of reserved word ^ (_T_0) DSDT.dsl 5422: Name (_T_0, 0x00) Error 4081 - Use of reserved word ^ (_T_0) DSDT.dsl 5507: Method (Z00I, 2, NotSerialized) Warning 1086 - ^ Not all control paths return a value (Z00I) DSDT.dsl 5572: Method (Z00O, 2, NotSerialized) Warning 1086 - ^ Not all control paths return a value (Z00O) DSDT.dsl 5613: Name (_T_0, 0x00) Error 4081 - Use of reserved word ^ (_T_0) DSDT.dsl 5827: Name (_T_0, 0x00) Error 4081 - Use of reserved word ^ (_T_0) DSDT.dsl 6045: Method (WMBD, 3, NotSerialized) Warning 1086 - ^ Not all control paths return a value (WMBD) DSDT.dsl 6049: Name (_T_0, 0x00) Error 4081 - Use of reserved word ^ (_T_0) DSDT.dsl 6121: Name (_T_0, 0x00) Error 4081 - Use of reserved word ^ (_T_0) DSDT.dsl 6239: Name (_T_0, 0x00) Error 4081 - Use of reserved word ^ (_T_0) DSDT.dsl 6284: Name (_T_0, 0x00) Error 4081 - Use of reserved word ^ (_T_0) ASL Input: DSDT.dsl - 6505 lines, 234500 bytes, 2703 keywords Compilation complete. 11 Errors, 4 Warnings, 0 Remarks, 953 Optimizations
ok, i will try help you Field (PLPT, DWordAcc, Lock, Preserve) change--> Field (PLPT, ByteAcc, Lock, Preserve) ------------- Method (_WAK, 1, NotSerialized) put --> Return(Package(0x02){0x00, 0x00}) ------------- Name (_T_0, 0x00) all "_T_0" must be changed to T_0 anyway i will send my DSDT fixed for your e-mail Thanks again Alexey Starikovskiy
I had those same errors too, actually. Could you post the fixed DSDT as an attachment to this bug too, so everyone has access to it?
Thanks to all the people involved. Alexey's fix works like a charm. Moises' debuging works equally well. Moises, why don't you post the fixed DSDT at the repository? http://acpi.sourceforge.net/dsdt/
For comment #23 and #24, it seems that the problem is similar to bug 9399. Jonathan and Hernan, is the problem fixed? Alexey, could you have a look at this problem please?
Yes, the problem is fixed. "_T_0" changed to T_0 gets rid of all but one of the errors. Field (PLPT, DWordAcc, Lock, Preserve) change--> Field (PLPT, ByteAcc, Lock, Preserve) erases the remaining one. The Return() instruction fixes one warning. An the remaining warnings are fixed in Moises' DSDT The problem has been present in other ACERs. There is DSDT.dsl in the repository for ACER Aspire 5050-3785 bios 3910 with the same problem when compiling (not fixed) So far, the only odd thing is that, when charging the battery, is always saying it has 2min more of charging, which of course is not true. (Under debian Etch, and genome)
*** Bug 9175 has been marked as a duplicate of this bug. ***
Created attachment 14046 [details] DSDT fixed by Moises Marangoni We cannot add the fixed DSDT.dsl to the repository, so it is here. Credits to: Alexey Starikovskiy and Moises Marangoni. Useful on ACER Aspire 5050-4570/4697/3785 Bios 3309
Folks, Can anybody confirm that the battery status works properly on Windows using BIOS 3309? Bob, Can you take a look at why Alexey's PHSR modification was necessary and ponder if perhaps there is a Windows bug compatibility workaround we can add to ACPICA? Certainly asking people to modify their BIOS is not a scalable solution, and WILL_NOT_FIX is probably not okay either if Windows somehow works with this apparently broken BIOS. Note that if it isn't viable to enable a workaround always, one possibility is to DMI this machine and invoke a platform-specific workaround.
Note also that this is WMI code: Scope (\_SB) { Device (WMID) { Name (_HID, "PNP0C14") ... Method (PHSR, 2, NotSerialized) { Acquire (\_SB.PCI0.LPC0.PSMX, 0xFFFF) Store (0x91, \_SB.PCI0.LPC0.BCMD) Store (Arg0, \_SB.PCI0.LPC0.DID) Store (Arg1, \_SB.PCI0.LPC0.INF) Store (Zero, \_SB.PCI0.LPC0.SMIC) Store (\_SB.PCI0.LPC0.DID, Local0) Release (\_SB.PCI0.LPC0.PSMX) Return (Local0) } So there is a possibility that the WMI implementation interacts with this DSDT to patch things up.
(In reply to comment #46) > Folks, > Can anybody confirm that the battery status works properly > on Windows using BIOS 3309? The battery status and everything else (as far as I can see) works under Vista (ACER ships the 4697 with Vista, there is a Windows XT in a hidden partition but have never booted it, only windows-acer know what could result from it). One odd thing is that in ACER's ftp repository they offer the 3303 and the 3309 bios for Windows XP only, for Vista they only offer the 3303.
Len, Bob: From our reverse engineering efforts - the Acer WMI implementation does indeed offer the possibility to read the battery via ACPI-WMI, but at least from an acer_acpi/ acer-wmi perspective, I've never bothered to implement the code to handle this, since I've always considered it redundant. Now, I can always tack this into acer-wmi, but should this really be necessary?
Although, I'm not sure that WMI is the answer here - yes, we can also read the battery, and yes, our PHSR() method is properly defined. Perhaps the problem boils down to Windows vs ACPICA's handling of the: External (\_SB_.PHSR, MethodObj) // 2 Arguments On ACPICA, we fail on this; because, quite clearly, it doesn't exist. Is Windows trying to be clever and matching that instead to the first PHSR() method it can find in \_SB in the DSDT, rather than just failing? Would doing something like that for External's in ACPICA also solve the problem?
There are some odd things about this DSDT, and I am beginning to suspect the disassembler. I found one disassembler bug for sure (with current compiler, v 20071219): OperationRegion (\DEBG, SystemIO, 0x1080, 0x01) Field (\DEBG, ByteAcc, NoLock, Preserve) { DBGP, 8 } This gets disassembled as: OperationRegion (\DEBG, SystemIO, 0x1080, 0x01) Field (\DEBG, { 0x01 DBGP, 8 } Does anyone know where I can get the phoenix disassembler (ad.exe)? I've lost my copy.
After a couple tweaks, output from the MS compiler: dsdt.dsl(3913): warning: \_SB.PHSR does not exist or not in accessible scope asl(DSDT.aml): Image Size=27921, Image Checksum=0x90 Notice, just a warning.
No luck on finding ad.exe so far - seems to have pretty much vanished off the internet. Perhaps, far simpler, if a method is declared in External(), but is never defined, then if it's called, Windows just ignores it and carries on, rather than failing the whole method? I suppose a simple test for that would be if someone could just comment out/ remove this line completely in the DSDT: Store (\_SB.PHSR (0x0D, 0x00), TJ85) And then see what happens.
Gee, there's something that bothers me about facing a major issue like an unresolved external and just deciding to ignore it. Another issue is that the disassembler is just making a "guess" to emit an external in these cases. There is no AML opcode for External. So, we really have no way of knowing exactly why we can't find the name.
Created attachment 14130 [details] Phoenix (ad.exe) disassembled DSDT Bob, Well, after a few hours, I've actually found AD.exe after a lot of searching and a bit of luck. I've stashed a copy you can grab here: http://files.strangeworlds.co.uk/AD.EXE Attached is the output from disassembling the DSDT for this laptop (based on Jonathan's submitted acpidump).
Thanks for finding ad.exe. It cannot find \_SB.PHSR either, so maybe it's not a disassembler problem after all. We have a utility to execute AML code under windows, it would be interesting to analyze the behavior with a small subset of the code, with one unresolved symbol.
Alternatively, you might try changing Store (\_SB.PHSR (0x0D, 0x00), TJ85) to Store (\_SB.WMID.PHSR (0x0D, 0x00), TJ85)
Bob, (I don't have the laptop in question). However, Alexey already got the users with this hardware to try that (look back a few comments in the bug).
Yes, missed that. If WMID.PHSR doesn't help, try \_SB_.PCI0.LPC0.PHSR
Windows does not ignore unresolved symbols: We ran this method under windows and it fails. External (\_SB.ABBU.TEMP) Method(m019) { Store(\_SB.ABBU.TEMP, Local0) Return ("OK?") } ====== Executing M019 ====== M019 returns Failure!
I don't think this test is quite fair - what if we go back to my earlier hypothesis that Windows is trying to be smart here, and actually tries to resolve the symbol with the first closest match it can find (e.g. "Can't find \_SB.PHSR, so lets see what the first PHSR() I can find is")? The following example (it will probably need tweaking for your test suite) is closer to what we really have (except perhaps the 'External', which doesn't exist on the AD.exe decompiled DSDT). External (\_SB_.PHSR, MethodObj) Scope (\_SB) Device (EC0) { Method (PHSR, 2, NotSerialized) { /* Do something */ } Method (test, 0, NotSerialized) { \_SB.PHSR(1, 2) } }
Actually, slight correction, we're looking at: External (\_SB_.PHSR, MethodObj) Scope (\_SB) { Device (PCI0) { Method (PHSR, 2, NotSerialized) { /* Do something */ } Device (EC0) { Method (test, 0, NotSerialized) { \_SB.PHSR(1, 2) } } } }
I agree, that will be next. And the method named "test" should be _REG in case there is some special handling for the very important _REG methods.
Bob, Have you been able to test the discussed AML code on Windows yet?
At least I as a user not familiar at all with Windows (actually, my machine came with Vista 32bits) need a guide on what to do and how to undo it (I do not want to void the guarranty), otherwise I cannot help.
Hernan, (In reply to comment #65) > At least I as a user not familiar at all with Windows (actually, my machine > came with Vista 32bits) need a guide on what to do and how to undo it At the moment, there's not a lot you can do to help right now - the aim here is to try and work out what the Windows ACPI interpreter is doing here, and then copy that in Linux, to avoid using custom DSDTs for this laptop (since Windows does not break on the 3050/ 5050 DSDT, although it looks like it should). So we're waiting on Bob Moore to test a similar example to the broken EC of the DSDT on Windows using Intel's ACPI tests, to see how Windows is actually handling it. Hopefully, after that, a real fix can be developed for this problem.
Lin Ming is investigating this issue and attempting to determine the exact windows behavior.
Does this fix work for Acer Bios 3315 ? I just updated to 3315 and have no indicator about battery in Gutsy. Thanks, Philippe
Reply-To: aksenovsu@nskes.ru do `cat /proc/acpi/dsdt > DSDT.dat` disasm: 'iasl -d DSDT.dat' you should see DSDT.dsl. edit DSDT.dsl line 3906 "Store (\_SB.PHSR (0x0D, 0x00), TJ85)" to look "Store (\_SB.WMID.PHSR (0x0D, 0x00), TJ85)". "WMID." inserted. 'iasl -tc DSDT.dsl' to compile DSDT back. Unselect Device Drivers->Generic Driver Options->Select only drivers... Select Power Management->ACPI->Custom DSDT Put DSDT.hex into Custom DSDT location field. Copy file DSDT.hex into drivers/acpi do make/make install/... It worked for me! But i have another one problem!!! I upgrade memory and now I have 2x1Gb in my Aspire 5050. When i leave only 1Gb the battery status works and if there is both 2Gb of memmory it doesn't work!!! I suppose it can be fixed by editing DSDT but I don't know how! Please help me!
*** Bug 9988 has been marked as a duplicate of this bug. ***
(In reply to comment #70) > *** Bug 9988 has been marked as a duplicate of this bug. *** > My first question has not been answered clearly, but as I have the same warning and error after compilation, I assume the Bios 3315 has the same problem than 3309. But, I really don't see where I can do these actions : *Unselect Device Drivers->Generic Driver Options->Select only drivers... *Select Power Management->ACPI->Custom DSDT2 problems : On Gnome, I have System/Administration/Restricted Driver ... where I cannot "Select only drivers.." Then, on Power Management, I don't see ANYTHING about ACPI. If somebody can help, or if I missed something, please tell me. Philippe
> But, I really don't see where I can do these actions : > *Unselect Device Drivers->Generic Driver Options->Select only drivers... > *Select Power Management->ACPI->Custom DSDT2 problems : > On Gnome, I have System/Administration/Restricted Driver ... where I cannot > "Select only drivers.." > Then, on Power Management, I don't see ANYTHING about ACPI. > If somebody can help, or if I missed something, please tell me. The actions refer to the configuration process for compiling a new kernel. First you dowload a new kernel from linux-kernel, the first good enough was 2.6.24-rc3 (a pre-release) but there a newer kernels ofcourse. (Notice this is not the kernel distributed with ubuntu. So... forget going through distribution packages and much less desktop options. Fix is at kernel level.) Next you set up the desired kernel configuration, with make config or make xconfig or make menuconfig (recommended xconfig) The instructions posted indicate options you have to set in the configuration. I hope it helps. Good luck. Hernan
Thanks, Not sure I will be able to do it but I will try when I will have time. Philippe
One question : does it mean the problem comes from the kernel and it should be fixed or that I need to do this for each new kernel ?
This is a bug in the ACPI interpreter in the kernel - editing the DSDT is only a workaround until the guys at Intel figure out how this DSDT works on Windows, and can then apply that to the ACPI interpreter. (Bob - any updates from either you or Lin Ming on this bug?)
Works on Acer 5050 (5053Wxmi) with latest Acer Bios 3315. I did not apply the corrections in comments 39 but Battery is visible by the kernel now. I dont know if this could be better with those ones applied. I am using 2.6.24.3 by the way. Thanks for help, Philippe
*** Bug 9792 has been marked as a duplicate of this bug. ***
With 2.6.24 and the custom DSDT, the battery is visible by the kernel, but the status (i.e., percent charged) only updates if the battery/AC state changes (e.g., from AC power to battery power, or vice-versa).
Yesterday I found that bug and noticed, that 3315 BIOS is present now. After I'd installed it my life became a complete mess - laptop is not booting at all (until some change in BIOS settings takes place, i.e. change boot order). After downgrade to 3309 - it's the same behavior as posted here, except: 1) I'm able to boot with acpi_osi=Linux (no acpi=off) with 2.6.25-rc5 2) I'm not able to boot 2.6.25-rc6 except acpi=off 3) Windows works perfectly here After looking to some bugs opened by me I've found that before I was using 3303 (as I remember I have upgraded it to 3309, but probably downgraded for some reasons :-) I'm using 5050-5052 Aspire
add myself to cc
It seems that the 3315 BIOS does not work at all with Hardy 8.04. acpi=off works but no network functional. Many other error message as PNPBIOS error : dev_node_info = unexpected status 0x37. I think that flashing back to 3303 seems to be a reasonable advice as this 3315 BIOS does not fix anything ! Am I true ? Philippe (Acer aSPIRE 5053 WXMI)
Reply-To: jopa@mytechsolutions.com same problem here debian 4.0 R3 amd64 hangs with no battery on first reboot after install.
I was able to get battery status back on 2.6.24 and 2.6.25 kernels by upgrading to the latest version of hal and associated libraries and utilities (acpi alone wasn't enough). Laptop still doesn't suspend and wake from suspend consistently on 2.6.25 kernels.
Any progress on this bug? The status is need info. What would the info needed be? My system used to work tolerably well on Ubuntu 7.8 but when I upgraded to 8.1 I have to use acpi=off and noapic. With these flags there is a problem with pci I guess and my wireless card does not work.
I have one Acer Aspire 3050 and the same trouble here with the battery meter. As the BIOS downgrade seems to be the only solution I don't have done yet. I wish to ask you if this related downgrade (3315/3309 --> 3303) is safe, because on the 3309 release notes is some information about corrected problems related to temperature issues (hot, hot hot!). And if this downgrade create another issues like high temperatures, Wireless and Ethernet conflict, etc...? Thanks
(In reply to comment #85) > I have one Acer Aspire 3050 and the same trouble here with the battery meter. > As the BIOS downgrade seems to be the only solution I don't have done yet. > I wish to ask you if this related downgrade (3315/3309 --> 3303) is safe? Hi BaldUFO, I did not do the downgrade to 3303. I am staying with Gutsy for the moment. Only Acer can answer your questions I think. My friend has another Acer 5050, with 3309, but no way to boot Hardy or even Gutsy ! As about temperature, with 3315, I did not notice a change but if they say it, this should be true. ;-) Philippe
Hi Philippe, I think I had some success last night. The battery meter is working and the wireless was not messed. I researched and tried some mix of information and worked like a charm, even with the speedstep for my Semprom (after inserting the proper modules) Here are my changes (after exporting the DSDT from Acer 3050-1371): OperationRegion (PLPT, SystemIO, 0×0378, 0×01) to OperationRegion (PLPT, SystemIO, 0×0378, 0×04) <--- changed form 0*01 to 0*04 Changed all occurencies _T_0 to TTT0 (all of them) Store (\_SB.PHSR (0x0D, 0x00), TJ85) to Store (\_SB.WMID.PHSR (0x0D, 0x00), TJ85) <--- added WMID Recompiled (0 errors and some warnings) the DSDT, inserted dstd.hex on kernel source tree (2.2.26) Edited .config CONFIG_STANDALONE=n CONFIG_ACPI_CUSTOM_DSDT=y CONFIG_ACPI_CUSTOM_DSDT_FILE="/usr/src/linux/dsdt.hex" (please verify your path and attention for the fact that was the .hex and for direct kernel insertion) make bzImage, copied to /boot/vmlinuz and ran lilo (as my modules are the same I do not remake them) It worked here. Detects ac on/off, charge and aprox. remaining time. I think the 3050 and the 5050 are, with some minus changes, the same hardware and you can try.) For the BIOS, the change on the temperature was stated on 3309. I'm using 3315. Thanks to all who posted the information for this procedure. I just joined them from different sources.
Errr.. Sorry. The Kernel I'm using is 2.6.26 and not 2.2.26. My bad.
Could you attach the entire updated DSDT?
Created attachment 16945 [details] DSDT Acer Aspire 3050-1371 Corrected(?) .dsl DSDT for Acer Aspire 3050-1377
Created attachment 16946 [details] DSDT Acer Aspire 3050-1371 (hex) Corrected(?).hex DSDT for Acer Aspire 3050-1377
Worked for you Jonathan? I tried just suspend to ram and was ok. The lid close and goes to stanby ok. Returns to standby when keyboard is pressed. Boot without ac and goes ok. Terminal don't show any anomaly. KDE starts and the battery meter is shinning on the bar. Right click and I have on demand, performance and powersave to chose (and works!). Lock and suspend ok. Suspend ok. Acpi options are all (depends on your modules) fully enabled. I tried messing with hal but stopped just in time to recover Slack =] Now is fine tune the saving times to maximize the battery. For the first time I am (almost) fully enjoying this machine. Runs pretty decent. By the way, any one knows if phoenix can "open" the access to some bios configurations, like disable onboard adapters, set hd parms, etc...? Thanks
It seems a duplicate of bug 10237. Would you please have a try the patch at bug 10237 comment #49?
BaldUFO: My computer's been working mostly fine (except for some overheating issues I've hacked to avoid with some powersaved scripts), with battery readout etc since I used the recommended DSDT changes here and upgraded hald and libs. However, a complete corrected DSDT is useful. Lin Ming: Correction, bug 10237 appears to be a duplicate of this bug, and not vice versa. I'll try to test the patch some time within the next month if I have time; I'm currently very busy.
Will you please try the debug patch in http://bugzilla.kernel.org/show_bug.cgi?id=10237#c54?
Hibernate (resume to disk) fails miserably. Can be my settings. As far as I had observed, the temperature stay normal and the speedstep goes ok. The battery meter are correct. Compiled the last stable kernel with oldconfig loaded from Slack 12.1 kernel 2.6.24.5-huge (not smp). Barebones 2.6.26 and changes only to specific needs (processor, swap location...), but will not fail if the settings are the Slackware's defaults. No leds light for network. No function keys exept brightness, lock synaptics and turn off the screen. Sound are ok. Usb ok. Dvd ok. Ethernet ok. Do't looked at modem and pcmcia. Wireles goes ok with both mad and ndis. Sorry guys, I saw the 3050 on the thread and confess: do not read all the way. I hope at least people with this class (3050-1371) can now focus more on work. Thats it. Thanks for all.
I had the same problem with my aspire 5051 (5050 series). (My bug here: http://bugzilla.kernel.org/show_bug.cgi?id=10237 ) But I have TL-60 x2 prcessor (stock was TK-36) and bios 3315 is the only one that worked with this cpu. I also deassembled the DSDT from 3315 and changed the missing object to (\_SB.PCI0.LPC0.PHSR (0x0D, 0x00), TJ85). I chose this to WMID because all other calls in this function are to \_SB.PCI0.LPC0.PHSR no to \_SB.WMID.PHSR. I worked with this corrected DSDT table for about 3 months and 2.6.24 though 2.6.27-rc1 and have no problems with it. But I had to recompile the kernel every time. With the patch from ykzhao here http://bugzilla.kernel.org/show_bug.cgi?id=10237#c54 everything is fine again. I got no responce from acer about the missing object in the DSDT but vista, xp work fine with this bios. Also I patched the current FC8 kernerl 2.6.25.11-60 with the patch and it is ok. Hibernate to RAM/DISK works also with the patched kernel. Battery and LID are fine too. Can you confirm this for you notebooks?
Hi, BaldUFO Do you mean that the patch in comment #95 can't make your laptop work well? Right? Will you please double check whether the system can work well after using the corrected DSDT? It will be great if you can attach the output of acpidump ,dmesg. Thanks.
@ BaldUFO The bioses from acer website about 3050 und 5050 series (available ftp://ftp.work.acer-euro.com/notebook/aspire_3050/bios/ and ftp://ftp.work.acer-euro.com/notebook/aspire_5050/bios/) are identical (sha1sum). This means that since the patch form ykzhao works for me (5051) it should also work for you. Did you tried 2.6.27-rc1 (with default settigns, not the one from slackware and without your own adjustments)? Results?
Actually the solution I was trying was based on absolute despair and panic. With the modifications on DSDT I was able to have some acpi functions, but every time I rebooted the system, the wireless goes off. After my last post, I tried downgrading the bios to 3303 with no success. So I downgraded to 3309 and the situation was the same. Revisiting the posts again, I downloaded the dsdt fixed by Mr. Marangoni and now I have some wmi (acer_wmi) functions and can wake the atheros by "echoing" the lazy card after reboot. The card function well on first start, but if for some reason I need to reboot, is like the card was turned off. Mr. ykzhao, the dsdt posted by Mr. Marangoni is the same one? If yes, almost all functions are ok, except minor issues like some function keys and the wireless led. Now the battery are correctly identified as bat0 instead of bat1 with the dstd I posted here. The battery meter are correct with and without ac. The speedstep function perfectly ondemand or selecting performance, conservative or powersave. I can't downgrade to 3303, as I receive warnings about different or missing blocks on the bios image, so I'm using 3309 and everything is working fine. Mr. Covington, I was looking closely your problem, as I have the intention to buy one dualcore some time in the future and had no response for acer too... I'll try the 27-rc1 with stock defaults. Mr. ykzhao, can you please point me to the right directions for the patch? In order to use the patch I need to use the corrected dsdt or just the patched kernel? And if I need to use some dsdt, is the one posted by Mr. Marangoni? Thanks and really appreciate your hard work.
Created attachment 17068 [details] Corrected DSDT table from bios 3315. Line # 3907 Store (\_SB.PCI0.LPC0.PHSR (0x0D, 0x00), TJ85) This is another modified dsdt table. It is from bios 3315 and I modified the missing object from line 3907 to Store (\_SB.PCI0.LPC0.PHSR (0x0D, 0x00), TJ85). I've been using this before the patch from ykzhao and everything was fine. The difference between this one and the other tables in this threat is this missing object. In the other versions the object was substituted with Store (\_SB.WMID.PHSR (0x0D, 0x00), TJ85). In my case it is Store (\_SB.PCI0.LPC0.PHSR (0x0D, 0x00), TJ85) because all calls in the functin are to \_SB.PCI0.LPC0.PHSR not to \_SB.WMID.PHSR. Give it a try.
@ BaldUFO I tried it this way: 1. Download opensuse11.0 live image and burn in to usb stick. 2. or use KDE live from here (based on opensuse11.0 - i preffer this one): http://home.kde.org/~binner/kde-four-live/ use this artikle http://klik.atekon.de/wiki/index.php/CustomizeSUSELive to make the iso boot from the usb. The good part is that the opensuse kernel has the patch to load custom DSDT files from the initrd. so once you've made the bootable usb stick you can only substitute the initrd and try the new dsdt table. No need to recompile the whole kernel. And the live image has all setting set to "default"
Hi, BaldUFO The dsdt posted by by Mr. Marangoni is correct. It should fix the problem of your laptop. When the patch in comment #95 is used, only the patched kernel is enough.(Custom DSDT is not required.) Thanks.
10237 is a duplicate of this bug and reporter confirmed that patch at comment #95 works well. BaldUFO, Would you please help to test the patch at comment #95?
Created attachment 17138 [details] Dmesg after the patch
Hi Mr. Ming, Applied the patch to the latest stable kernel (2.6.26.2) and everything is working fine. The battery meter is working like it should, counting the charge and the time remaining with and without AC. The speedsptep is ok, suspend to RAM is ok and the fan are ok too. Sound, video, USB and DVD are also working without trouble. Suspend to disk is failing, but I suspect its just a question of little space on the swap. I can start without the AC and the laptop don't halt and have some WMI functions enabled. It seems the laptop is working a bit cooler (lower temperatures), and the fan is smooth than with the applied DSDT. Can be just the low resources I'm using now, but I'll keep a look at the temperatures with some more stress on the machine. Except for the warnings from dmesg, stated by Mr. Ykzhao as harmless (and in fact they are); the laptop is fully operational. My sincere thanks for all of you. ps: I'm attaching the dmesg with the patched ec.c.
Thanks for the test. Close this bug. Patch available at http://bugzilla.kernel.org/show_bug.cgi?id=10237#c54
does that patch work for acer 5050 4697 to?
It only circumvents the missing object in the DSDT table in bioses > 3309.
so it means that if my 5050 4697 has that bios (and indded mine has bios 3309) it will fix a result like the one on comment 106?
yes
Ok as I’m quite new to Linux it took me a while to figure out how to apply the patch, but I did. Problem is I didn’t get the results stated on comment 106, instead I got this: 1. Battery is working fine 2. if I unplug the AC power (for the first time) I get a warning saying that I have only 3 minutes of power and to plug the AC, even though I have (and is shown!) 83% of battery power; Then If I plug and unplug the AC power it takes like 18 seconds to the make the switch visible... is that normal??? 3. Can’t suspend to ram; if I try, a message pops up saying “suspend to ram is not supported on your machine…” , also that if I know that my machine is supposed to support suspend to ram I should over ride a setting (would that be safe? I thought it would be supported after the patch) and it also says to go to en.opensuse.org for more info. Well I’m running debian etch rev 3, so it kind of freaked me because I don’t know that is an opensuse message doing on my system. 4. DVD drive has power but doesn’t work, I mean I put a disk in but nothing happened. 5. USB is almost like the DVD, I plug my flash but it doesn’t appear on the desktop. If I go to the device manager I see the flash is connected. 6. Lid button works (it tries to suspend to ram). 7. Power button bring up a menu to choose from: log out, restart or shut down (I bet that good new, right?) look as I said before I’m quite new to Linux so I don’t know what is it that I’m doing wrong, I’m compiling kernel 2.6.26.2, question is am I doing it right??? If someone could help me and would like to, I spend a lot of time online so I’ll leave here my msn address (I hope it's not forbidden): phreddythezauberer666@live.com Oh by the way I have an ACER ASPIRE 5050 4697
can you post the dmesg form the patched kernel? I can remember that I had such an opensuse message in kpowersave on my fedora. But it was part of the code not ported correctly(nothing to worry about). For me it sounds like debian problems not kernel related but I cannot conclude this without the dmesg.
Created attachment 17176 [details] Acer 5050 4697 cpu info
Created attachment 17177 [details] Dmesg from patched kernel 2.6.26.2
Created attachment 17178 [details] lspci output
ok there are the dmsg form the patch kerlen 2.6.26.2 the output of lspci (just in case)and the /proc/cpuinfo (just in case too). I want to make clear that i'm running Debian Etch 4.0 rev.3 and that i use the Gnome desktop. Here is something interesting: in my previous comment i said that if i unplug the Ac power i get a low energy warning(comment 113, point 2), well if the battery is 100% charged nothing happends, anyway i still think thats a little weird. About that suspention to ram, here is the complet message i get: " Suspend to ram is not supported on your machine. If you know that it should work , you might override this detection with setting SUSPEND2RAM_FORCED=yes in /etc/powersave/sleep. See http://en.opensuse.org/S2ram for more information. Thanks! " excuse me for creating so many attachemets :P
your dmesg says that you've inserted another DSTD table in the kernel and applied the patch. Your ACPI supports only S0 S3 S5. Can you recompile the kernel only with the patch, without the dsdt table?
Another DSTD table??? I never touched that configuration When I compiled the kernel. You know what... I’ll reinstall The whole system and see what happens because at first I installed Defiant just to play around a little and see what Linux was like. Now I have more confidences to reinstall it by myself I'll let you know the result.
line #90 from the dmesg says: ACPI: Core revision 20080321. and this is a new dsdt recompiled with iasl v.20080321. It cannot happen by itself ;)
"ACPI: Core revision 20080321." means kernel now uses ACPICA release 20080321. It does not mean that dsdt is recompiled ...
I didn't know that, sorry. My kernel says: ACPI: Core revision 20070126 and it is FC9 2.6.25.14-108.fc9.i686. Maybe the vanilla/fedora kernel team has forgotten to apply the updates???
i checked it and fedora hasn't still pulled the 20080321 patch.
Created attachment 17279 [details] dmesg from patched 2.6.26.2, with suspend and resume Everything works, though I still have overheating issues and some ACPI warnings. And I think I had bluetooth functionality (with acer_acpi) and don't anymore (with the new acer_wmi).
Created attachment 17280 [details] dmesg from patched 2.6.26.2 compiled with custom DSDT With custom DSDT, battery/etc information doesn't work at first, but otherwise things look okay.
Jonathan, acer-wmi functionality is an unrelated issue to this bug. If you're still having acer-wmi issues, please open a separate bug and CC: me on it.
How can this be merged upstream? I put it 3 times for discussion on the linux-acpi list. But it seems noone is interested in this. PLease help.
*** Bug 10237 has been marked as a duplicate of this bug. ***
shipped in linux-2.6.28-rc1 closed commit 20edd74fcf9ad02c19efba0c13670a7b6b045099 Author: Zhao Yakui <yakui.zhao@intel.com> Date: Fri Oct 17 02:02:44 2008 -0400 ACPI: Ignore AE_NOT_FOUND error of EC _REG method and continue to initialize EC
I am not sure if this will help but this problem goes away when I flash my bios to ver. 1.3303. It did not work with ver 1.3309. The changes they mentioned between version 3303 and 3309 are as foll: ; ; Date : 2007/04/17 ; QCI Ver.: 1.3309 ; EC Ver. : 0.24 ; VGA BIOS: zr3_qdi.tst ; AMD CPU code: r1.37 (agesa 2.08.03) ; 1. Add thermal offset to solve thermal problem. 2. Fix the wrong CPU speed on CMOS setup Utility.(postspd.asm) ;+------------------------------------------------------------------------ ; ; Date : 2007/04/04 ; QCI Ver.: 1.3308 ; EC Ver. : 0.24 ; VGA BIOS: zr3_qdi.tst ; AMD CPU code: r1.37 (agesa 2.08.03) ; 1. Enable ATAPI information item on CMOS setup Utility. ;+------------------------------------------------------------------------ ; ; Date : 2007/04/04 ; QCI Ver.: 1.3307 ; EC Ver. : 0.24 ; VGA BIOS: zr3_qdi.tst ; AMD CPU code: r1.37 (agesa 2.08.03) ; 1. Update EC v.024 2. Update CPU kernel to 2.08.03 cpu\*.* block\*.* 3. Add thermal table for TK53 CPU. amdthrmo.asm tj58cpu.asm svr32.asm ec.asi qci_comm.asi ;+------------------------------------------------------------------------ ; ; Date : 2007/01/23 ; QCI Ver.: 1.3303 ; EC Ver. : 0.23 ; VGA BIOS: zr3_qdi.tst ; AMD CPU code: r1.37 (agesa 2.6.11) ; 1. Add Bison CCD. 2. Fix WinDiag test failed. (impcode.asm, sb_por.inc, usbpost.inc)
I think the problem is in 1.3304 (the TJ85 object) but we can't do anything about it. And no bios before 3315 works with turion x2 processors because of thermal problems. Anyway the patch is already included in the kernel.
Created attachment 26466 [details] Zipped Bios with fixed DSDT table This is the original bios v.3315 with a fixed DSDT table (for those of you who still have this aspire 5050). The sha256 checksum of the unzipped bios is c6a8573d144d0e5bf42e87b396d6a8a98e0041b3e2c57a14018e874f44fff43e. I've recompiled the fixed dsdt with the microsoft asl 2.0.2b compiler because windows doesn't like the output from intel's iasl (at least these acers 5050 don't like it). I've tested it with windows xp and 7 and everything is fine. Linux also works fine. Actually linux also works with the dsdt recompiled with iasl but in this case none of the windows versions couldn't last more than 10 secs before the BSOD. I've done this because I didn't like the error message about the faulty bios with the patch posted here. This patch really did a great job but the real problem was the buggy dsdt table not the acpi in linux. Now this patch is obsolete for this bug. The credits should go also to those who helped me recreate the bios. And the wanring: I'm not responsilbe for any demages caused by the use of this "modified" bios. I've tested it on 2 machines and it works fine. Use it on your own risk!