RE: Output ACPI info via sysfs

Brown, Len
2006-05-15T22:22:18Z

I see.
the /dev/mem reader tickles some hardware wrong in some cases.

>The other vendor's hardware _sometimes_ has bad data in the XSDT if
>you've got more than 1G of ram, and I've now got workarounds in my
>parser for it -- but the kernel doesn't have those, and it works just
>fine. Dunno why this is happening, but the BIOS guys at that
>vendor are looking into it. Just FWIW, acpidump has the same
>failure as the code I've got (both were hacked up from the kernel code)
> -- on my 4G box it tries to read 4026571728 bytes at 0x2b858abbd0 ,
which is
>clearly bogus.

sure looks like a wrap-around or a sign bug, being so close to 4GB.

Is this still true for acpidump in the latest pmtools here?:
http://ftp.kernel.org/pub/linux/kernel/people/lenb/acpi/utils/

Bob,
the latest, 20051111, is indeed based on the ACPICA headers.

>But when the kernel is parsing the tables, it's getting the right data.
>I really have no idea what's happening on that hardware. I suspect a
>bus analyzer is needed to tell for sure what's going on.

I can't explain why the kernel works and the latest acpidump doesn't,
but I'm willing to help fix the latest acpidump so it does.

>...
>I still don't think it's the best idea -- poking around
>in /dev/mem is ugly and bug-prone. Doing this probe in userland means
>we've got two sets of code to parse the same thing, which pretty much
>always leads to bug fixes that fail to be applied to both sets of code.
>So that means I've essentially got to track changes to what the kernel
>parsing code (or some library-ized version of pmtools) in order to get
>bug fixes. This is a maintenance nightmare!

On the grand scale of nigthmares, this is not a big one.
This code nearly never changes. Also, the user-land utility
can work even when the kernel is broken.

I don't really see a case to bloat the kernel here.
Perhaps all the user-space parser needs it a reliable
physical address for the MADT?

-Len