Bug 1330174
| Summary: | test suite fails on s390x | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Dan Horák <dan> | ||||
| Component: | qemu | Assignee: | Fedora Virtualization Maintainers <virt-maint> | ||||
| Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||
| Severity: | unspecified | Docs Contact: | |||||
| Priority: | unspecified | ||||||
| Version: | 24 | CC: | amit.shah, berrange, cfergeau, crobinso, dwmw2, imammedo, itamar, lvivier, marcel, pbonzini, rjones, virt-maint | ||||
| Target Milestone: | --- | ||||||
| Target Release: | --- | ||||||
| Hardware: | s390x | ||||||
| OS: | Unspecified | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | qemu-2.6.0-0.2.rc4.fc24 | Doc Type: | Bug Fix | ||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2016-05-07 11:40:22 UTC | Type: | Bug | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Embargoed: | |||||||
| Bug Depends On: | |||||||
| Bug Blocks: | 467765, 1071880 | ||||||
| Attachments: |
|
||||||
|
Description
Dan Horák
2016-04-25 14:16:03 UTC
probably a bug endian related problem somewhere, because ppc64 suffers from the same problem, eg. in http://ppc.koji.fedoraproject.org/koji/taskinfo?taskID=3323757 To be able to reproduce this error, I've needed to install: acpica-tools
Without this package, this code path is not used (configure doesn't detect "iasl").
The error appears because:
g_file_test("tests/acpi-test-data/pc/SSDT", G_FILE_TEST_EXISTS)
returns 0. This file does not exist. On a x86 host, it doesn't try to open this file.
Marcel, as you have written this code, do you know why it wants to open this file (and why it can't)?
In reply to Laurent Vivier from comment #2) > To be able to reproduce this error, I've needed to install: acpica-tools > > Without this package, this code path is not used (configure doesn't detect > "iasl"). > > The error appears because: > > g_file_test("tests/acpi-test-data/pc/SSDT", G_FILE_TEST_EXISTS) > > returns 0. This file does not exist. On a x86 host, it doesn't try to open > this file. > > Marcel, as you have written this code, do you know why it wants to open this > file (and why it can't)? Hi Laurent, This file was part of the acpi tests, it was an "expected" file which was compared with the current SSDT table received from the guest. At some point the file was removed (see commit: caf50c7166a6ed96c462ab5db4b495e1234e4cc6) because, as far as I understand, all the SSDT code appears to be moved to DSDT. When loading a Fedora guest I could see no SSDT table in /sys/firmware/acpi/tables. The question is: why on a s390x host QEMU still generates the SSDT table and on x86 host it doesn't? Can you please attach the SSDT file from the guest to the BZ so I can have a look? Since the file is binary you can run: cp /sys/firmware/acpi/tables/SSDT . iasl SSDT and attach the SSDT.dsl file. Thanks, Marcel Created attachment 1151851 [details]
SSDT.dsl
(In reply to Marcel Apfelbaum from comment #3) > At some point the file was removed (see commit: > caf50c7166a6ed96c462ab5db4b495e1234e4cc6) > because, as far as I understand, all the SSDT code appears to be moved to > DSDT. The test is broken since this commit. Before, the test passes with some warnings: $ QTEST_QEMU_BINARY=x86_64-softmmu/qemu-system-x86_64 gtester -k --verbose -m=quick tests/bios-tables-test TEST: tests/bios-tables-test... (pid=25294) /x86_64/acpi/piix4/tcg: Warning! iasl couldn't parse the expected aml Warning! iasl couldn't parse the expected aml Warning! iasl couldn't parse the expected aml Warning! iasl couldn't parse the expected aml OK /x86_64/acpi/piix4/tcg/bridge: Warning! iasl couldn't parse the expected aml Warning! iasl couldn't parse the expected aml Warning! iasl couldn't parse the expected aml Warning! iasl couldn't parse the expected aml OK /x86_64/acpi/q35/tcg: Warning! iasl couldn't parse the expected aml Warning! iasl couldn't parse the expected aml Warning! iasl couldn't parse the expected aml Warning! iasl couldn't parse the expected aml Warning! iasl couldn't parse the expected aml OK /x86_64/acpi/q35/tcg/bridge: Warning! iasl couldn't parse the expected aml Warning! iasl couldn't parse the expected aml Warning! iasl couldn't parse the expected aml Warning! iasl couldn't parse the expected aml Warning! iasl couldn't parse the expected aml OK PASS: tests/bios-tables-test Hi Igor, Can you please advise on this BZ? Why do you think QEMU generates the SSDT table on s390x hosts? If 2.6 is not out yet we still have a chance to fix this. Thanks, Marcel (In reply to Marcel Apfelbaum from comment #6) > Hi Igor, > > Can you please advise on this BZ? Why do you think QEMU generates > the SSDT table on s390x hosts? If 2.6 is not out yet we still have > a chance to fix this. FYI, I've tested this on ppc64 host and ppc64le host. It doesn't fail on ppc64le (it doesn't try to access SSDT). So it really looks like an endianness problem. Attached table looks like the OLD SSDT from 2.5 which doesn't exists in 2.6 anymore, is there any chance that tests executes old binary? Short of that, I'd start qemu under gdb and put breakpoint on build_header(), that should help to trace where from SSDT generation is triggered. (In reply to Igor Mammedov from comment #8) > Attached table looks like the OLD SSDT from 2.5 which doesn't exists in 2.6 > anymore, is there any chance that tests executes old binary? I've checked: I'm actually using 2.6.0-rc3. 8d0d9b9 Update version for v2.6.0-rc3 release > Short of that, I'd start qemu under gdb and put breakpoint on build_header(), > that should help to trace where from SSDT generation is triggered. It seems SSDT is not generated: Breakpoint 1, build_header (linker=0x10bf66d0, table_data=0x10bf6670, h=0x12e5f430, sig=0x1041a7c0 "DSDT", len=5587, rev=1 '\001', oem_id=0x0, oem_table_id=0x0) Breakpoint 1, build_header (linker=0x10bf66d0, table_data=0x10bf6670, h=0x12e60a03, sig=0x1041a900 "FACP", len=116, rev=1 '\001', oem_id=0x0, oem_table_id=0x0) Breakpoint 1, build_header (linker=0x10bf66d0, table_data=0x10bf6670, h=0x12e60a77, sig=0x1041a908 "APIC", len=120, rev=1 '\001', oem_id=0x0, oem_table_id=0x0) Breakpoint 1, build_header (linker=0x10bf66d0, table_data=0x10bf6670, h=0x12e60aef, sig=0x1041a140 "HPET", len=56, rev=1 '\001', oem_id=0x0, oem_table_id=0x0) Breakpoint 1, build_header (linker=0x10bf66d0, table_data=0x10bf6670, h=0x12e60b27, sig=0x104901f8 "RSDT", len=48, rev=1 '\001', oem_id=0x0, oem_table_id=0x0) Breakpoint 1, build_header (linker=0x12e410f0, table_data=0x12e41b90, h=0x3fff9835e1b0, sig=0x1041a7c0 "DSDT", len=5587, rev=1 '\001', oem_id=0x0, oem_table_id=0x0) Breakpoint 1, build_header (linker=0x12e410f0, table_data=0x12e41b90, h=0x3fff9835f783, sig=0x1041a900 "FACP", len=116, rev=1 '\001', oem_id=0x0, oem_table_id=0x0) Breakpoint 1, build_header (linker=0x12e410f0, table_data=0x12e41b90, h=0x3fff9835f7f7, sig=0x1041a908 "APIC", len=120, rev=1 '\001', oem_id=0x0, oem_table_id=0x0) Breakpoint 1, build_header (linker=0x12e410f0, table_data=0x12e41b90, h=0x3fff9835f86f, sig=0x1041a140 "HPET", len=56, rev=1 '\001', oem_id=0x0, oem_table_id=0x0) Breakpoint 1, build_header (linker=0x12e410f0, table_data=0x12e41b90, h=0x3fff9835f8a7, sig=0x104901f8 "RSDT", len=48, rev=1 '\001', oem_id=0x0, oem_table_id=0x0) Looks like test issue, If you could give me access to a system where I could use debug it, I could try to find out what's wrong. You've done it manually but anyway here is patch one could use to see what expected files the test fails to open: https://github.com/imammedo/qemu/commit/075cc7e467e865f58bba5fa3844a8b9cf3735cef Here is fix: http://patchwork.ozlabs.org/patch/616730/ qemu-2.6.0-0.2.rc4.fc24 has been submitted as an update to Fedora 24. https://bodhi.fedoraproject.org/updates/FEDORA-2016-afc25f920f qemu-2.6.0-0.2.rc4.fc24 has been pushed to the Fedora 24 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2016-afc25f920f qemu-2.6.0-0.2.rc4.fc24 has been pushed to the Fedora 24 stable repository. If problems still persist, please make note of it in this bug report. |