Bug 1330174 - test suite fails on s390x
Summary: test suite fails on s390x
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:
Keywords:
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)

(edit)
Clone Of:
(edit)
Last Closed: 2016-05-07 11:40:22 UTC


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

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 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.