From: glen martin <lists@locutory.org>
To: linux-acpi@vger.kernel.org
Subject: FIXED: no /proc/acpi, trying to dump dsdt to a file
Date: Wed, 29 Mar 2006 18:47:19 -0800 [thread overview]
Message-ID: <442B46B7.2040407@locutory.org> (raw)
Or at least, I'm past my pain, thanks to a lot of help from Robert and Len.
To recap:
The DSDT in my BIOS was very broken, such that ACPI didn't load up
properly. This meant I was having trouble reading the data from my BIOS
using /proc/acpi/dsdt.
To fix this, I applied this patch to the kernel (which was 2.6.15):
https://bugzilla.novell.com/show_bug.cgi?id=147621#c22
Rebuild, reboot, and I could get at the dsdt data at /proc/acpi/dsdt.
Then iasl couldn't handle the extracted data, because it failed error
checking in the same way the kernel had. Patch it like this:
<snip>
--- namespace/nssearch.c.~1~ 2006-03-29 18:22:16.000000000 -0800
+++ namespace/nssearch.c 2006-03-29 12:11:22.000000000 -0800
@@ -403,7 +403,7 @@
{
ACPI_ERROR ((AE_INFO, "Bad character in ACPI Name: %X",
TargetName));
- return_ACPI_STATUS (AE_BAD_CHARACTER);
+// return_ACPI_STATUS (AE_BAD_CHARACTER);
}
/* Try to find the name in the namespace level specified by the
caller */
</p>
This allowed iasl to function on the extracted dsdt data.
There remained some errors in the extracted dsdt that I'm still looking at.
In a side conversation, though, I had another look at a supposedly
working cleaned-up version of the DSDT for my machine that I downloaded
from http://acpi.sourceforge.net/dsdt/view.php. I'd tried to assemble
it using iasl on Linux, which segfaulted on this file. This was why I
started down this path of extracting my existing DSDT. But Robert had
the idea to try it using the Windows binary iasl, and it assembled fine
there. I was able to take that binary and load it into my kernel using
the initramfs dsdt patch here:
http://gaugusch.at/kernel.shtml.
I wasn't already using an initramfs, so not knowing how, on a lark I
constructed a bogus one:
mkdir temp
cp /path/to/my_dsdt.asl temp/DSDT.asl // this filename matters
cd temp
find . | cpio --quiet -o -H newc | gzip -9 > ../minirt.gz
cd ..
rm -r temp
This initramfs is likely bogus, but it worked anyway for this purpose.
Just add it to your grub.conf in an initrd line.
The reward? Now my onboad LAN interface is working, so I can retire the
add-on board I installed to get by with. Not that geeks like me need a
reward.
Hope this recap helps someone. And thanks once again to Robert and Len
for their help.
glen
next reply other threads:[~2006-03-30 2:47 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-03-30 2:47 glen martin [this message]
-- strict thread matches above, loose matches on Subject: below --
2006-03-30 3:29 FIXED: no /proc/acpi, trying to dump dsdt to a file Yu, Luming
2006-03-30 7:11 ` glen martin
2006-03-30 7:15 Yu, Luming
2006-03-30 7:47 ` glen martin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=442B46B7.2040407@locutory.org \
--to=lists@locutory.org \
--cc=linux-acpi@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.