|
Bugzilla – Full Text Bug Listing |
| Summary: | Bad character in ACPI Name - Interpreter disabled | ||
|---|---|---|---|
| Product: | [openSUSE] SUSE Linux 10.1 | Reporter: | Rihards Olups <richlv> |
| Component: | Kernel | Assignee: | Thomas Renninger <trenn> |
| Status: | RESOLVED DUPLICATE | QA Contact: | E-mail List <qa-bugs> |
| Severity: | Major | ||
| Priority: | P5 - None | ||
| Version: | Alpha 4 | ||
| Target Milestone: | --- | ||
| Hardware: | x86-64 | ||
| OS: | SUSE Other | ||
| Whiteboard: | |||
| Found By: | Other | Services Priority: | |
| Business Priority: | Blocker: | --- | |
| Marketing QA Status: | --- | IT Deployment: | --- |
| Attachments: |
dmesg output after bootup
acpidmp output fixed and compiled DSDT |
||
|
Description
Rihards Olups
2006-01-04 10:51:17 UTC
Created attachment 61941 [details]
dmesg output after bootup
currently computer is booted up with noapic flag, but i hope this doesn't obscure the problem
see bug 141202 for hwinfo output Before going on, you should look out for a BIOS update for this machine. If it is the newest or the problem is still not fixed please try: Does acpidmp >/tmp/acpidmp give you some sane output (Some binary stuff)? If yes please attach the file. If not could you try: acpidump --addr 0x000000003ffb0000 --length 0x5000 >/tmp/acpidump unfortunately machine is at a remote location right now and the best i can get is ssh access - so i can not verify bios version (computer was bought only a week ago, so chances are high it is the latest). acpidmp produced attached output Created attachment 62525 [details]
acpidmp output
The error is a switched byte in the middle of the ACPI byte code. Playing a bit with acpidmp and iasl compiler it came out that the error appears while trying to parse the ACPI bytecode. The error is located at offset 14b0 in the acpidmp. Modifing the byte 14b0 (0x03): 14a0: 99 99 99 14 09 41 50 50 43 00 a4 0a 00 08 50 53 .....APPC.....PS 14b0: 03 43 0a 0a 5b 82 46 0b 4f 4d 53 43 08 5f 48 49 .C..[.F.OMSC._HI To 0x53 and also changing the text from . to S on the right side: 14a0: 99 99 99 14 09 41 50 50 43 00 a4 0a 00 08 50 53 .....APPC.....PS 14b0: 53 43 0a 0a 5b 82 46 0b 4f 4d 53 43 08 5f 48 49 SC..[.F.OMSC._HI makes the DSDT dissasmble and even recompile without any errors. This is clearly a BIOS bug and cannot be workarounded. I wonder how this can happen? Does M$ Windows run on this machine? It might be waranty issue? Hmm, strange is that the checksum fits to the broken DSDT... However you should get the ACPI system up by overriding the DSDT with my fixed one: Follow the instruction on: http://powersave.sourceforge.net/DSDT.html#DSDT. You only need the point 15.2.8 and use the DSDT.aml file I will attach. If that works and the ACPI errors disappear, please also try to boot without noapic. BTW: Looking for a new BIOS is really worth it, even M$ Windows should have it's problems with that BIOS and I expect that gets fixed with the next BIOS release. Created attachment 62639 [details]
fixed and compiled DSDT
1) Please copy file to /etc/DSDT.aml.
2) Modify the variable ACPI_DSDT to ACPI_DSDT="/etc/DSDT.aml" in
/etc/sysconfig/kernel
3) run mkinitrd (there should be a line ACPI DSDT found and added
or similar)
4) reboot and see whether early ACPI errors dissappear
5) If not, please attach dmesg again. If yes, try w/o noapic
boot option
"Does M$ Windows run on this machine?" no, never has been installed. according to this page : http://www.asrock.com/support/Download/dl_939S56-M.htm#bios latest bios version is 1.40 dmidecode returns : BIOS Information Vendor: American Megatrends Inc. Version: P1.40 so i will try reporting this to asrock. as i can not get to the machine currently, i will try your workaround if there is no bios fix when i get to it eventually. thanks a lot for your help. BIOS bug... Here is someone else with this switched byte... maybe we don't have a BIOS bug, or M$ is workarounding it somehow... *** This bug has been marked as a duplicate of 147621 *** |