I'm bringing the Mono build up to date in the meta-mono layer and ran into a problem with my testing. I generally target QEMU, e.g. qemux86, build a core-image-sato based Mono test image and run up with 'runqemu qemux86' It's a remote build system so I am SSH'd in with VNC port forwarding and I view the QEMU box running with a TightVNC client. This has worked well for a long time, and still works fine with the current krogoth branch. I have just built against master though and am seeing screen corruption. ref: https://postimg.org/image/xjcdybdul When I'm back in the office later this week I'll double check whether I see screen corruption when running on the local desktop as opposed to when I'm SSH tunnelled to it. ... Build details are: Build Configuration: BB_VERSION = "1.35.0" BUILD_SYS = "x86_64-linux" NATIVELSBSTRING = "universal" TARGET_SYS = "i586-poky-linux" MACHINE = "qemux86" DISTRO = "poky" DISTRO_VERSION = "2.3+snapshot-20170828" TUNE_FEATURES = "m32 i586" TARGET_FPU = "" meta meta-poky meta-yocto-bsp = "master:51cc0b07a14277c71a3b6184575fe30ab489c717" meta-oe = "master:ac2a6d2b5d69937577effcb8bb2149651bac0176" meta-mono = "master:1d0d803fe100bc616ef61487387b97509db8c663" ... QEMU command line is: .../poky.master/build$ runqemu qemux86 runqemu - INFO - Running MACHINE=qemux86 bitbake -e... runqemu - INFO - Continuing with the following parameters: KERNEL: [tmp/deploy/images/qemux86/bzImage--4.12.7+git0+edb42d4805_d09f2ce584-r0-qemux86-20170825182334.bin] MACHINE: [qemux86] FSTYPE: [ext4] ROOTFS: [tmp/deploy/images/qemux86/core-image-mono-qemux86-20170825210648.rootfs.ext4] CONFFILE: [/mnt/sdb2/data_drive/monotest/poky.master/build/tmp/deploy/images/qemux86/core-image-mono-qemux86-20170825210648.qemuboot.conf] runqemu - INFO - Using preconfigured tap device tap0 runqemu - INFO - If this is not intended, touch /tmp/qemu-tap-locks/tap0.skip to make runqemu skip tap0. runqemu - INFO - Network configuration: 192.168.7.2::192.168.7.1:255.255.255.0 runqemu - INFO - Running tmp/work/x86_64-linux/qemu-helper-native/1.0-r1/recipe-sysroot-native/usr/bin//qemu-system-i386 -device virtio-net-pci,netdev=net0,mac=52:54:00:12:34:02 -netdev tap,id=net0,ifname=tap0,script=no,downscript=no -drive file=tmp/deploy/images/qemux86/core-image-mono-qemux86-20170825210648.rootfs.ext4,if=virtio,format=raw -vga vmware -show-cursor -usb -device usb-tablet -device virtio-rng-pci -cpu pentium2 -m 256 -serial mon:vc -serial null -kernel tmp/deploy/images/qemux86/bzImage--4.12.7+git0+edb42d4805_d09f2ce584-r0-qemux86-20170825182334.bin -append 'root=/dev/vda rw highres=off mem=256M ip=192.168.7.2::192.168.7.1:255.255.255.0 vga=0 uvesafb.mode_option=640x480-32 oprofile.timer=1 uvesafb.task_timeout=-1 '
Created attachment 3954 [details] Image showing corruption
Do you see it locally? Any idea if/when this last worked? We need to narrow down the cause if we can...
Back in the office today 1) Running qemu locally works fine. Display is as expected 2) Running with Xvnc locally and TightVNC on my client I get the same corruption as I show above. This is with the same checkout as above. I'll build and test with Pyro and feed back to you Cheer, Alex
Works with the latest pyro Build - Build Configuration: BB_VERSION = "1.34.0" BUILD_SYS = "x86_64-linux" NATIVELSBSTRING = "universal" TARGET_SYS = "i586-poky-linux" MACHINE = "qemux86" DISTRO = "poky" DISTRO_VERSION = "2.3.1" TUNE_FEATURES = "m32 i586" TARGET_FPU = "" meta meta-poky meta-yocto-bsp = "pyro:5fd01704b96f045d7857af0db86b3487ac66b52f" meta-oe = "pyro:5e82995148a2844c6f483ae5ddd1438d87ea9fb7" meta-mono = "master:10168e59ff2247edc600275706bdbf6306dc8161" QEMU - ajlennon@ajlennon-GA-78LMT-USB3:/mnt/sdb2/data_drive/monotest/poky.pyro/build$ runqemu qemux86 runqemu - INFO - Assuming MACHINE = qemux86 runqemu - INFO - Running MACHINE=qemux86 bitbake -e... runqemu - INFO - MACHINE: qemux86 runqemu - INFO - DEPLOY_DIR_IMAGE: /mnt/sdb2/data_drive/monotest/poky.pyro/build/tmp/deploy/images/qemux86 runqemu - INFO - Running ls -t /mnt/sdb2/data_drive/monotest/poky.pyro/build/tmp/deploy/images/qemux86/*.qemuboot.conf... runqemu - INFO - CONFFILE: /mnt/sdb2/data_drive/monotest/poky.pyro/build/tmp/deploy/images/qemux86/core-image-mono-qemux86-20170830201818.qemuboot.conf runqemu - INFO - Continuing with the following parameters: KERNEL: [tmp/deploy/images/qemux86/bzImage--4.10.17+git0+e92bd55409_6648a34e00-r0-qemux86-20170830201818.bin] MACHINE: [qemux86] FSTYPE: [ext4] ROOTFS: [tmp/deploy/images/qemux86/core-image-mono-qemux86-20170830201818.rootfs.ext4] CONFFILE: [/mnt/sdb2/data_drive/monotest/poky.pyro/build/tmp/deploy/images/qemux86/core-image-mono-qemux86-20170830201818.qemuboot.conf] runqemu - INFO - Running /sbin/ip link... runqemu - INFO - Acquiring lockfile /tmp/qemu-tap-locks/tap0.lock... runqemu - INFO - Using preconfigured tap device tap0 runqemu - INFO - If this is not intended, touch /tmp/qemu-tap-locks/tap0.skip to make runqemu skip tap0. runqemu - INFO - Network configuration: 192.168.7.2::192.168.7.1:255.255.255.0 runqemu - INFO - Running ldd tmp/work/x86_64-linux/qemu-helper-native/1.0-r1/recipe-sysroot-native/usr/bin//qemu-system-i386... runqemu - INFO - Running tmp/work/x86_64-linux/qemu-helper-native/1.0-r1/recipe-sysroot-native/usr/bin//qemu-system-i386 -device virtio-net-pci,netdev=n et0,mac=52:54:00:12:34:02 -netdev tap,id=net0,ifname=tap0,script=no,downscript=no -drive file=tmp/deploy/images/qemux86/core-image-mono-qemux86-20170830 201818.rootfs.ext4,if=virtio,format=raw -vga vmware -show-cursor -usb -usbdevice tablet -device virtio-rng-pci -cpu pentium2 -m 256 -serial mon:vc -se rial null -kernel tmp/deploy/images/qemux86/bzImage--4.10.17+git0+e92bd55409_6648a34e00-r0-qemux86-20170830201818.bin -append 'root=/dev/vda rw highres= off mem=256M ip=192.168.7.2::192.168.7.1:255.255.255.0 vga=0 uvesafb.mode_option=640x480-32 oprofile.timer=1 uvesafb.task_timeout=-1 ' ^Cqemu-system-i386: terminating on signal 2
NB. If I modify the master branch build to use the pyro branch 'qemu-system-i386' binary then it displays correctly so it would appear this is related to QEMU itself
Reassigning Jussi's bugs.
So if you have a working commit and a non-working commit, can you 'git bisect' this further please? The problem is we don't really have qemu experts here, and I suspect the issue appeared when qemu was updated from one version to another newer version, so the best we can do is probably report the issue upstream.
git bisect takes me to 7f45ea5083b845490bc3db2a449b6e8b71eab6ba is the first bad commit commit 7f45ea5083b845490bc3db2a449b6e8b71eab6ba Author: Juro Bystricky <juro.bystricky@intel.com> Date: Mon Aug 14 12:44:34 2017 -0700 qemu: upgrade to 2.10-rc2 In order to support Nios2 emulation by QEMU, we need at least QEMU version 2.9. (From OE-Core rev: f2d725d9268563f7bbcac770a34aceacb56cb2aa) Signed-off-by: Juro Bystricky <juro.bystricky@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Right. The next step is a little bit more complicated (but still doable): a) modify the qemu recipe to take source code from git b) 'devtool modify qemu-native' c) do the bisection procedure over qemu commit history Depending on what the offending commit looks like we can revert it and/or report to upstream - they would appreciate knowing exactly where the breakage happens.
It appears the initial NEEDINFO was answered.
Nope, we're still in NEEDINFO. Also, the original assignee was Maxin.
I spent a fair bit of time git bisecting the qemu code and thought I'd gotten to the bottom of the issue. However when I tested around the particular commit I can't reliably cause a failure. It was this - https://github.com/qemu/qemu/commit/5fe309ff0d1e8234fd79c21544bfcc436ece6386 I've not had time to continue with this to track down what's been happening and also using a X2Go client instead of TightVNC works for me (oddly enough) I can perhaps try to look at it in future or we can close as won't fix?
By default we disable gtk, and if it's enabled, it defaults to gtk3. I doubt this is the issue. You can try to report the problem upstream, but to be honest, I don't think there is enough useful evidence, or an easy way to reproduce for them. WONTFIX?
Agreed Alex. I'll set to WONTFIX and keep an eye on it. If I have a light bulb moment I'll reopen... Cheers, Alex