|
Bugzilla – Full Text Bug Listing |
| Summary: | acpidump segmentation fault (only on i386-pae with a lot memory?) | ||
|---|---|---|---|
| Product: | [openSUSE] openSUSE 11.1 | Reporter: | andrea florio <andrea> |
| Component: | Basesystem | Assignee: | Thomas Renninger <trenn> |
| Status: | RESOLVED WORKSFORME | QA Contact: | E-mail List <qa-bugs> |
| Severity: | Normal | ||
| Priority: | P3 - Medium | CC: | rommie |
| Version: | Final | ||
| Target Milestone: | --- | ||
| Hardware: | i386 | ||
| OS: | Other | ||
| Whiteboard: | |||
| Found By: | --- | Services Priority: | |
| Business Priority: | Blocker: | --- | |
| Marketing QA Status: | --- | IT Deployment: | --- |
| Attachments: |
/var/log/boot.msg log file
Only dump RSDT if XSDT must not be used or is not available or if --rsdt param is provided my /proc/iomem |
||
|
Description
andrea florio
2009-04-21 10:29:25 UTC
nobody care? I have the same crash every time I run acpidump. gdb says: (gdb) r Starting program: /usr/sbin/acpidump [Thread debugging using libthread_db enabled] Program received signal SIGSEGV, Segmentation fault. 0xb7ed8fb7 in memcmp () from /lib/libc.so.6 (gdb) bt #0 0xb7ed8fb7 in memcmp () from /lib/libc.so.6 #1 0x08048c63 in acpi_map_table (where=3488600120, sig=0x8049e3a "RSDT") at acpidump.c:108 #2 0x080496dd in main (argc=Cannot access memory at address 0x4 ) at acpidump.c:304 There's no need to reboot. acpidump crashes when started in console (sudoed). similar output here: (gdb) r /usr/sbin/acpidump Starting program: /usr/sbin/acpidump /usr/sbin/acpidump (no debugging symbols found) (no debugging symbols found) [Thread debugging using libthread_db enabled] Program received signal SIGSEGV, Segmentation fault. 0xb7ecdfb7 in memcmp () from /lib/libc.so.6 (gdb) Assigning to pmtools maintainer. I expect this system does not provide an RSDT table, only an XSDT one.
It also seem to have a random/invalid pointer to a RSDT table.
We know that older Microsoft OSes did use RSDT table, even they shouldn't.
At least Vista seem to make use of XSDT more spec conform. What Microsoft OSes are supported by this machine?
The address pointing to RSDT: 0x3488600120 is probably invalid but mmap does not return an error and when trying to access it, acpidump segfaults.
Some ideas:
- provide a --rsdt param. Only dump RSDT if no XSDT gets dumped or --rsdt
param is explicitly provided -> will attach patch.
- check against e820 table, whether the tables all lie in reserved ACPI data
regions -> a lot to do. It could be checked through /proc/iomem:
cffc0000-cffcdfff : ACPI Tables
cffce000-cffeffff : ACPI Non-volatile Storage
All tables must lie in these regions.
There already is --skip option, but I do not understand it. Trying out a bit with it I always get an empty dump with --skip 1 -t ANY_TABLE or a full dump with only --skip 1. IMO this param can be reverted.
Alexey, what do you think?
Can you try acpidump from pmtools package provided here, please:
ftp.suse.com/pub/people/trenn/acpidump
It now should work without any param (Also try -a param). If you add --rsdt param you should get the same segfault?
Created attachment 292990 [details]
Only dump RSDT if XSDT must not be used or is not available or if --rsdt param is provided
Please attach acpidump -a of your tests.
I suppose 3488600120 is decimal which is 0xCFEFD038. It is valid 32bit value though I understand nothing in acpi and can't say is it valid for acpi. acpidump with -a failed with message "Unknown option!". The same is for --rsdt. --skip 1, --skip 2, --skip -t ANY_TABLE segfaults. I have 4 gigabytes RAM and use PAE: Linux pc6 2.6.27.21-0.1-pae #1 SMP 2009-03-31 14:50:44 +0200 i686 i686 i386 GNU/Linux May it cause acpidump crash? Created attachment 293024 [details]
my /proc/iomem
Installed pmtools from the ftp. It is still segfaults. But now --rsdt option is valid and it segfaults too. -a is invalid. > I have 4 gigabytes RAM and use PAE
Hmm, maybe this is related to -pae/i386 + 4 or more GB of memory...
Do you both have a -pae kernel running?
Maybe mem=1G helps?
Guessing..., you may want to give it a try, but someone else with more memory knowledge should have a look at this. Maybe this even is not acpidump related.
i don't know what is happened but now it segfault no more... Oo only official updates... anubis@suse-laptop:~> rpm -qf /usr/sbin/acpidump pmtools-20071116-44.3 anubis@suse-laptop:~> rpm -qi pmtools Name : pmtools Relocations: (not relocatable) Version : 20071116 Vendor: openSUSE Release : 44.3 Build Date: mer 03 dic 2008 06:57:02 CET Install Date: mar 09 dic 2008 23:11:48 CET Build Host: build15 Group : Development/Tools/Other Source RPM: pmtools-20071116-44.3.src.rpm Size : 1138062 License: GPL v2 or later Signature : RSA/8, mer 03 dic 2008 06:57:13 CET, Key ID b88b2fd43dbdc284 Packager : http://bugs.opensuse.org URL : http://acpica.org/downloads Summary : ACPI Debugging Tools Description : This is a set of tools to display your BIOS ACPI tables. Distribution: openSUSE 11.1 anyway i have 32bit kernel pae 4GB ram Tried mem=1G but it crashed anyway. I tried to reproduce this here on a i386 and 4GB machine without success. Not sure how to go on, I could imagine this bug is hard to resolve, especially remotely. It even looks like a HW/BIOS related issue. Acpidump generally works. I keep the bug open for a while, please update it if you find out more (e.g. an easy way to reproduce, a BIOS/boot option that helps, etc). Hmmm. It is strange but acpidump turned to work. Two weeks earlier it won't but version of acpidump from OpenSUSE 11.0 bootable CD worked well. The bootable CD contains default (not pae) kernel (which is older then my current version) and predefined boot configuration. I suppose the problem could be caused by kernel (I think it have been updated) or conflict with some other application that is fixed now. Unfortunately, Yast update logs are missed and I can not surely say that packages have been updated since acpidump fixed. Anyway, it works for me now. exactly same thing happen to me (comment #11) Due to last comments and this potentially was an underlying problem we might never find out what caused it and as the bug is rather old -> resolved, eh say "works for me". |