On 06/04/2015 01:34 PM, Roy Franz wrote:
On Wed, Jun 3, 2015 at 5:53 PM, Al Stone al.stone@linaro.org wrote:
On 05/15/2015 12:50 PM, Roy Franz wrote:
Don't try to read the RSDP structure or RSDT/XSDT tables from memory with the -c option. These are now provided as files in /sysfs, and this allows acpidump to function when /dev/mem is not available, which will be the case for Aarch64 servers.
Signed-off-by: Roy Franz roy.franz@linaro.org
Graeme - all this is tested with your patch, which looks good. It takes care of what acpidump needs from sysfs.
Al - this fixes acpidump. Are there other utilities that I need to look at within acpica-tools?
This produces almost the same output with/without the "-c" option, with the /sysfs files being used with "-c", with the following differences:
- Table address are 0x0 with -c, since we don't get them from the sysfs files
- the tables are listed in a different order.
I have verified with strace that no /dev/mem accesses are made with "-c".
An issue that this patch doesn't address, is what should be the default, and what should be done if /dev/mem is missing, or there but not readable.
So, I stepped back and rethought the problem a bit. Based on that, I decided to use the patch that follows instead. Basically, this new patch removes any use of /dev/mem from the arm64 version of acpidump; if it's not in /sys, the ACPI table cannot be read. Any attempts to use /dev/mem via other parameters will fail as being unsupported (e.g., trying to retrieve a table by address). This only affects arm64, too, so it should be more palatable upstream, but could be used on other Linux architectures if so desired.
This version is now in the Debian sid and Fedora rawhide packages (version is 20150515-2 for both, and f21, f22 packages are in the testing queue). I've also sent a copy upstream to see what they do with it :).
So I think this takes care of the issue on arm64. It does leave the status quo for x86, right? That is likely 'good enough', since the bits missing on x86 with the "-c" option were not that interesting, so I think this is fine. Given that acpica-tools upstream is opaque, they have the problem statement, 2 solutions, so in a future release the problem may be addresses :)
Roy
Right. This *only* touches arm64; everything else remains exactly the same as before.
BTW, packaging source for Debain is also at:
https://github.com/ahs3/acpica-tools
if you need it.