Created attachment 4334 [details] Booting log file Following are the steps to arm64 on qemu following is the link form there I downloaded images of arm64 and ppc700. https://autobuilder.yocto.io/pub/releases/yocto-2.6_M1.rc1/machines/qemu/qemuppc/ 1)downloaded core-image-sato-sdk-qemuppc.tar.bz2 from above link 2)downloaded core-image-sato-sdk-qemuppc.qemuboot.conf from above link 3)downloaded vmlinux-qemuppc.bin from above link 4)downloaded toolchain from following link https://autobuilder.yocto.io/pub/releases/yocto-2.6_M1.rc1/toolchain/x86_64/poky-glibc-x86_64-core-image-sato-ppc7400-toolchain-2.5%2Bsnapshot.sh 5) install the toolchain in host system 6) source toolchain-path/environment-setup-ppc7400-poky-linux 7) extract the tar.bz rootfs file. used following command runqemu-extract-sdk core-image-sato-sdk-qemuppc.tar.bz2 rootfs 8) after that we tried runqemu command runqemu nfs vmlinux-qemuppc.bin rootfs core-image-sato-sdk-qemuppc.qemuboot.conf after this command booting process is completed but qemu screen comming blank for long time, I have attached logs. if I run following command with nographics option then it is booting successfully. runqemu nfs vmlinux-qemuppc.bin rootfs core-image-sato-sdk-qemuppc.qemuboot.conf slrip nographic
This works fine for me in my builds. I need source/build based reproducers, since I can't debug these images.
With the help from Anuj: Following the steps give, able to reproduce the issue, boot hang and graphic display not showing. Login with serial, capture dmesg error related matchbox. [ 75.163957] connman-applet[471]: unhandled signal 11 at 0048503c nip 0048503c lr 007bfab4 code 2 [ 76.038291] matchbox-panel[496]: unhandled signal 11 at 0048503c nip 0048503c lr 007bfab4 code 2 [ 76.045562] matchbox-deskto[495]: unhandled signal 11 at 0048503c nip 0048503c lr 007bfab4 code 2 [ 77.684595] settings-daemon[462]: unhandled signal 11 at 00088340 nip 00088340 lr 000b1fe8 code 1 After login with serial: root@qemuppc:~# export LD_USE_LOAD_BIAS=0; export DISPLAY=:0; matchbox-desktop Successfully bring up the graphic. Also Anuj found the similar bug https://bugzilla.yoctoproject.org/show_bug.cgi?id=9131
Verified that the although runtime/xorg.py test passed with assert that ps -ef contain xinit, but the display was not loading. Since runtime/xorg.py was not able to identify every display issue, need to perform manual testing on coming QA release. NOTE: ... ok NOTE: test_xorg_running (xorg.XorgTest) DEBUG: Checking if x11-base is in DISTRO_FEATURES or IMAGE_FEATURES DEBUG: [Running]$ ssh -l root -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no -o LogLevel=ERROR 192.168.7.4 export PATH=/usr/sbin:/sbin:/usr/bin:/bin; ps -ef | grep -v xinit | grep [X]org DEBUG: time: 1530146898.5619707, endtime: 1530147198.556345 DEBUG: Partial data from SSH call: root 398 392 4 00:47 ? 00:00:01 /usr/bin/Xorg :0 -br -pn
Reassigning to Mark, the prelink guy, for his take. Certainly looks like prelink on arm64 is breaking. However, I'm confused as to why we've a number of bugs recently that involve a convoluted way of booting images. How I'd test this: 1) download core-image-sato-sdk.ext4, vmlinux, and core-image-sato-sdk.qemuboot.conf 2) source oe-init-build-env 3) runqemu core-image-sato-sdk.qemuboot.conf I don't understand why the rootfs tarball and toolchain are downloaded, and extract-sdk used. Can this bug be replicated by QA with the straightforward runqemu call?
(In reply to comment #4) > Reassigning to Mark, the prelink guy, for his take. Certainly looks like > prelink on arm64 is breaking. > > However, I'm confused as to why we've a number of bugs recently that involve > a convoluted way of booting images. How I'd test this: > > 1) download core-image-sato-sdk.ext4, vmlinux, and > core-image-sato-sdk.qemuboot.conf > 2) source oe-init-build-env > 3) runqemu core-image-sato-sdk.qemuboot.conf > > I don't understand why the rootfs tarball and toolchain are downloaded, and > extract-sdk used. Can this bug be replicated by QA with the straightforward > runqemu call? Hi Ross, Sorry for confusion. The qemupcc graphic failed on both boot up with core-image-sato-sdk-qemuppc.ext4 as well as boot up from core-image-sato-sdk-qemuppc.tar.bz2 after extract rootfs with toolchain. As my understanding, some QA team member prefer download the core-image-sato-sdk tarball and toolchain to extract rootfs and runqemu for nfs because downloading core-image-sato-sdk.ext4 take 10x longer time. Hope this clear some confusion.
I don't have anything to do with qemu or BSP work. However, if you think this is prelink, have you disabled it and checked that things now work? If so, I don't see that anywhere in the comments or subject or this item. I don't typically pay any attention to BSP related defects in the bug system, but I do care about prelink. I suggest the subject be updated if someone believes this is a prelink issue.
Pravin, I didn't notice this defect in the YP-2.6-M2 test report. Was it tested and if so was it reproduced? Can you also re-test as Mark Hatle requested.
I have tested. this bug is not reproducible in YP-2.6-M2.
Works as reported by Pravin.