[opensuse] test fails in swing due to incorrect rendering on 16bpp framebuffers
openQA test in scenario opensuse-Tumbleweed-DVD-x86_64-toolkits@64bit fails in
Current Java versions apparently no longer render correctly when the framebuffer only has 16bpp.
As is, the current test is pointless. Possible changes:
- disable the swing test completely
- run the test (also) on machine-type @64bit_virtio, which uses a 32bpp screen depth
- detect 16bpp and disable the swing test
Test suite description¶
Maintainer: email@example.com Test GUI Toolkits
Fails since (at least) Build 20190226
Last good: 20190105 (or more recent)
- DONE: @waitfor gh#os-autoinst/os-autoinst#1169 deployed to o3, then check if QEMUVGA=cirrus can be removed from default, remove from machines afterwards
- @waitfor gh#os-autoinst/os-autoinst#1169 deployed to osd, then check if QEMUVGA=cirrus can be removed from default, remove from machines afterwards -> #55445
- remove all jobs against "64bit_std" from Development Tumbleweed after we decided to keep the new default -> #55448
- remove the machine definition "64bit_std" from o3 -> #55448
- either remove or move all jobs against "64bit_qxl" -> #55448
- DONE: crosscheck extra_tests_on_gnome for https://bugzilla.opensuse.org/show_bug.cgi?id=1122176 in steam -> bug was declared WONTFIX, latest test on std is fine in steam: https://openqa.opensuse.org/tests/1005327#step/steam/27
Always latest result in this scenario: latest
#1 Updated by okurz over 2 years ago
- Subject changed from test fails in swing to [functional][u] test fails in swing due to incorrect rendering on 16bpp framebuffers
hm, we just changed the kernel boot parameters for virtio with #51614 , maybe it is about time to change the default graphics adapter away from cirrus? Shouldn't be hard to test using the test parameter
QEMUVGA. I do not have enough experience which vga adapter would be a better choice as a sane default – or is it virtio itself? Not sure about that.
Also see #43778#note-12
#2 Updated by okurz over 2 years ago
- Status changed from New to In Progress
- Assignee set to okurz
Maybe I can explore the options:
openqa_clone_job_o3 --skip-chained-deps 963993 _GROUP=0 TEST=okurz_poo53339_std QEMUVGA=std BUILD=okurz_poo53339 openqa_clone_job_o3 --skip-chained-deps 963993 _GROUP=0 TEST=okurz_poo53339_cirrus QEMUVGA=cirrus BUILD=okurz_poo53339 openqa_clone_job_o3 --skip-chained-deps 963993 _GROUP=0 TEST=okurz_poo53339_qxl QEMUVGA=qxl BUILD=okurz_poo53339 openqa_clone_job_o3 --skip-chained-deps 963993 _GROUP=0 TEST=okurz_poo53339_virtio QEMUVGA=virtio BUILD=okurz_poo53339 openqa_clone_job_o3 --skip-chained-deps 964045 _GROUP=0 TEST=okurz_poo53339_std QEMUVGA=std BUILD=okurz_poo53339 openqa_clone_job_o3 --skip-chained-deps 964045 _GROUP=0 TEST=okurz_poo53339_cirrus QEMUVGA=cirrus BUILD=okurz_poo53339 openqa_clone_job_o3 --skip-chained-deps 964045 _GROUP=0 TEST=okurz_poo53339_qxl QEMUVGA=qxl BUILD=okurz_poo53339 openqa_clone_job_o3 --skip-chained-deps 964045 _GROUP=0 TEST=okurz_poo53339_virtio QEMUVGA=virtio BUILD=okurz_poo53339
Created job #964242: opensuse-Tumbleweed-DVD-x86_64-Build20190619-kde@64bit -> https://openqa.opensuse.org/t964242 ok (std) 1:45h
Created job #964243: opensuse-Tumbleweed-DVD-x86_64-Build20190619-kde@64bit -> https://openqa.opensuse.org/t964243 failed to switch consoles (cirrus), retriggered -> https://openqa.opensuse.org/tests/964569
Created job #964244: opensuse-Tumbleweed-DVD-x86_64-Build20190619-kde@64bit -> https://openqa.opensuse.org/t964244 ok (qxl) 1:45h
Created job #964245: opensuse-Tumbleweed-DVD-x86_64-Build20190619-kde@64bit -> https://openqa.opensuse.org/t964245 failed in https://openqa.opensuse.org/tests/964245#step/user_gui_login/8 (virtio), retriggered -> https://openqa.opensuse.org/tests/964570
Created job #964246: opensuse-Tumbleweed-DVD-x86_64-Build20190619-toolkits@64bit -> https://openqa.opensuse.org/t964246 failed to switch consoles (std), retriggered -> https://openqa.opensuse.org/tests/964571
Created job #964247: opensuse-Tumbleweed-DVD-x86_64-Build20190619-toolkits@64bit -> https://openqa.opensuse.org/t964247 failed in swing as expected (cirrus) 0:24h
Created job #964248: opensuse-Tumbleweed-DVD-x86_64-Build20190619-toolkits@64bit -> https://openqa.opensuse.org/t964248 failed to switch consoles (qxl), retriggered -> https://openqa.opensuse.org/tests/964572
Created job #964249: opensuse-Tumbleweed-DVD-x86_64-Build20190619-toolkits@64bit -> https://openqa.opensuse.org/t964249 failed to switch consoles (virtio), retriggered -> https://openqa.opensuse.org/tests/964573
EDIT: The result is horribly unstable and confusing though, updated above
Also scheduled one more, trying out if I can override the
video= parameter to check out 32bpp:
openqa_clone_job_o3 --skip-chained-deps 964045 _GROUP=0 TEST=okurz_poo53339_boot32bpp_qxl QEMUVGA=qxl BUILD=okurz_poo53339 EXTRABOOTPARAMS_BOOT_LOCAL=video=1024x768
Created job #964574: opensuse-Tumbleweed-DVD-x86_64-Build20190619-toolkits@64bit -> https://openqa.opensuse.org/t964574
#8 Updated by okurz over 2 years ago
- Status changed from In Progress to Feedback
So I will propose to switch the default QEMUVGA to "std", or actually just trust qemu's default and not overwrite it in os-autoinst, "std" in this case still. I will also add specific test cases within "openSUSE Tumbleweed" for "cirrus" and "qxl" as we already have "virtio" and "std" would be the new default for "64bit". DimStar gave his ok for adding the new variants. Added two machine variants "cirrus" and "qxl" to machines on o3, and four scenarios "gnome@64bit_cirrus", "gnome@64bit_qxl", "kde@64bit_cirrus", "gnome@64bit_qxl" to Development: openSUSE Tumbleweed.
https://github.com/os-autoinst/os-autoinst/pull/1169 for the proposal to revert to the qemu defaults.
However, we can still do some upfront testing so I scheduled some more tests for Tumbleweed tests on the special, specific machine "64bit_std" which explicitly sets the "std" graphics adapter. Scheduled many scenarios in Development Tumbleweed.
- create_hdd_gnome ok
- create_hdd_textmode ok
- desktopapps-gnome ok (as unstable as "64bit" variant)
- extra_tests_on_gnome ok (unstable in gnucash and exiv2 but no failures in steam, so good)
- extra_tests_in_textmode ok (fails in dstat, sssd, libgpiod, same as "64bit" variant)
- kde ok
- minimalx ok
- qemu ok
- textmode ok
- update_13.1-gnome ok
- virtualization ok
- yast2_gui ok (fails in yast2_firewall on boo#1114673 as cirrus)
- yast2_ncurses ok (fails same as cirrus)
- kde-live_installation ok
- zdup-Leap-42.3-kde needs asset, @waitfor new builds fails reproducibly to switch ttys in https://openqa.opensuse.org/tests/972173#step/setup_zdup/4, also in the post_fail_hook. I wonder if this is because of the X server actually running on a different tty? I doubt that because the post_fail_hook should try tty5 which should really be free. The serial port output showed the scheduler in kernel to be a "blocked task". Trying with
openqa-clone-job --skip-chained-deps --within-instance https://openqa.opensuse.org 972173 TEST=zdup-Leap-42.3-kde_4G_timeout_scale_3 QEMURAM=4096 TIMEOUT_SCALE=3to give the machine more head-room: Created job #972175: opensuse-Tumbleweed-DVD-x86_64-Build20190630-zdup-Leap-42.3-kde@64bit_std -> https://openqa.opensuse.org/t972175 , in interactive mode I connected, GUI was not reactive, over VNC at least the machine reacted on "ctrl-alt-del" and rebooted, retriggered as https://openqa.opensuse.org/tests/972176
- gnome-live quite unstable, compare to "update_Leap_15.1_gnome"
- extra_tests_in_kde missing asset of generation job, added to schedule
- extra_tests_in_xfce same as kde variant
- gnome fails reproducibly in "xorg_vt" showing "Xwayland" instead of plain "X"
- -> need to foresee this in tests, seems like "std" causes the system to automatically select wayland instead of X, asked "DimStar" in IRC, answer: We should accept that wayland is detected as default and rely on that. That has an impact on "create_hdd_gnome-wayland" and downstream jobs
- first created https://github.com/os-autoinst/os-autoinst-needles-opensuse/pull/565 and https://github.com/os-autoinst/os-autoinst-distri-opensuse/pull/7769 to generalize xorg_vt
- I hardcoded "QEMUVGA=cirrus" on the x86_64 machines which are not "bare-metal" and only when QEMUVGA is not set already, see https://openqa.suse.de/admin/machines . I did the same on https://openqa.opensuse.org/admin/machines to be on the safe side for now (https://openqa.opensuse.org/tests/966421#step/xorg_vt/3 shows that the explicit "cirrus" is fine as well whereas https://openqa.opensuse.org/tests/966446#step/xorg_vt/4 shows that "qxl" fails the same for now as "std" as "wayland" was not expected there)
- toolkit fails showing a correct image but apparently no needle matches this, need to compare with cirrus case -> created https://bugzilla.opensuse.org/show_bug.cgi?id=1139927 and an according workaround needle "tk-ui-toolkit-tk-boo1139927-no_text_string_shown-20190701", retriggered as https://openqa.opensuse.org/tests/972161 -> ok
- update_Leap_15.1_gnome very unstable, xorg_vt (as above) but also oomath, ooffice, firefox, needs further investigation! -> xorg_vt solved with https://github.com/os-autoinst/os-autoinst-distri-opensuse/pull/7769 and new needle
- update_Leap_42.3_kde incomplete, needs base image, created, retriggered -> https://openqa.opensuse.org/tests/972172 ok
#10 Updated by okurz over 2 years ago
#12 Updated by okurz over 2 years ago
- Description updated (diff)
- DONE: @waitfor gh#os-autoinst/os-autoinst-distri-opensuse#7769 , then
- DONE: Add gnome@64bit_cirrus for Tumbleweed
- DONE: Add kde@64bit_cirrus for Tumbleweed
Also I added "gnome@64bit_std" and "kde@64bit_std" to be explicit however I plan to remove these soon again after we actually switched the 64bit machines to "std" instead.
Asked DimStar which TW snapshot would be good to test against std and we agreed that 20190702 should be good. I removed
QEMUVGA=cirrus from all machine definitions on o3 except "64bit_cirrus".
I installed the new version of os-autoinst on openqaworker1, rebooted and will check how jobs run there as well.
#14 Updated by okurz over 2 years ago
openqa-clone-job --skip-chained-deps --within-instance https://openqa.opensuse.org 972404 QEMUVGA=
Created job #973125: opensuse-Tumbleweed-DVD-x86_64-Build20190701-toolkits@64bit -> https://openqa.opensuse.org/t973125
however that job failed in https://openqa.opensuse.org/tests/973125#step/prepare_test_data/1 as the kernel command line still has "video=1024x768-16" from the generated qcow2 image. I deleted the according jobs again. Better to wait for a fresh new snapshot with properly created images as cloning including the parent is not easily possible as clone-job does not pass parameters to the parent.
#18 Updated by okurz over 2 years ago
- Description updated (diff)
- Status changed from Feedback to Resolved
default graphics adapter in os-autoinst has been changed to "std", the
QEMUVGA=cirrus machine variant on o3 has already been removed, special tickets have been created for followup on o3 and osd.