Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 1330174 - test suite fails on s390x
Summary: test suite fails on s390x
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: qemu
Version: 24
Hardware: s390x
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Fedora Virtualization Maintainers
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks: ZedoraTracker PPCTracker
TreeView+ depends on / blocked
 
Reported: 2016-04-25 14:16 UTC by Dan Horák
Modified: 2016-05-07 11:40 UTC (History)
12 users (show)

Fixed In Version: qemu-2.6.0-0.2.rc4.fc24
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2016-05-07 11:40:22 UTC
Type: Bug
Embargoed:

Attachments (Terms of Use)
SSDT.dsl (17.31 KB, text/x-csrc)
2016-04-28 12:51 UTC, Laurent Vivier 		no flags Details
View All

Description Dan Horák 2016-04-25 14:16:03 UTC 
The test suite gets stuck and build is killed on s390x - see http://s390.koji.fedoraproject.org/koji/taskinfo?taskID=2191093 for more details

...
TEST: tests/hd-geo-test... (pid=54301)
  /i386/hd-geo/ide/none:                                               OK
  /i386/hd-geo/ide/drive/cd_0:                                         OK
  /i386/hd-geo/ide/drive/mbr/blank:                                    OK
  /i386/hd-geo/ide/drive/mbr/lba:                                      OK
  /i386/hd-geo/ide/drive/mbr/chs:                                      OK
  /i386/hd-geo/ide/drive/user/chs:                                     OK
  /i386/hd-geo/ide/drive/user/chst:                                    OK
  /i386/hd-geo/ide/device/mbr/blank:                                   OK
  /i386/hd-geo/ide/device/mbr/lba:                                     OK
  /i386/hd-geo/ide/device/mbr/chs:                                     OK
  /i386/hd-geo/ide/device/user/chs:                                    OK
  /i386/hd-geo/ide/device/user/chst:                                   OK
PASS: tests/hd-geo-test
TEST: tests/boot-order-test... (pid=54349)
  /i386/boot-order/pc:                                                 OK
PASS: tests/boot-order-test
TEST: tests/bios-tables-test... (pid=54383)
  /i386/acpi/piix4/tcg:                                                **
ERROR:tests/bios-tables-test.c:493:load_expected_aml: assertion failed: (g_file_test(aml_file, G_FILE_TEST_EXISTS))
FAIL
GTester: last random seed: R02Sef8ef7ed96861c7774c48e38953bb4cb
(pid=54389)
  /i386/acpi/piix4/tcg/bridge:                                         
EXCEPTION: Timeout(86400) expired for command:
 # bash --login -c /usr/bin/rpmbuild -bb --target s390x --nodeps  /builddir/build/SPECS/qemu.spec 



Version-Release number of selected component (if applicable):
qemu-2.6.0-0.1.rc3.fc24
Comment 1 Dan Horák 2016-04-27 09:59:23 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
Comment 2 Laurent Vivier 2016-04-27 20:24:07 UTC 
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)?
Comment 3 Marcel Apfelbaum 2016-04-27 23:37:25 UTC 
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
Comment 4 Laurent Vivier 2016-04-28 12:51:12 UTC 
Created attachment 1151851 [details]
SSDT.dsl
Comment 5 Laurent Vivier 2016-04-28 13:08:30 UTC 
(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
Comment 6 Marcel Apfelbaum 2016-04-28 13:53:58 UTC 
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
Comment 7 Laurent Vivier 2016-04-28 15:10:44 UTC 
(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.
Comment 8 Igor Mammedov 2016-04-28 16:10:40 UTC 
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.
Comment 9 Laurent Vivier 2016-04-28 16:57:07 UTC 
(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)
Comment 10 Igor Mammedov 2016-04-29 08:20:46 UTC 
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
Comment 11 Igor Mammedov 2016-04-30 12:09:26 UTC 
Here is fix:
http://patchwork.ozlabs.org/patch/616730/
Comment 12 Fedora Update System 2016-05-02 23:00:56 UTC 
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
Comment 13 Fedora Update System 2016-05-03 11:23:03 UTC 
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
Comment 14 Fedora Update System 2016-05-07 11:40:16 UTC 
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.
Note You need to log in before you can comment on or make changes to this bug.