Created attachment 3321 [details] kernel panic Git rev: master/36feb38045b7a2af86ece147fec54b0db3bf491f Host OS: Ubuntu 16.04 x86_64 Steps: 1. Following the https://wiki.yoctoproject.org/wiki/Transcript:_Using_the_Yocto_BSP_tools_to_create_a_qemu_BSP to create a myqemux86-64 layer: $ yocto-bsp create myqemux86-64 qemu Checking basic git connectivity... Done. Which qemu architecture would you like to use? [default: i386] 1) i386 (32-bit) 2) x86_64 (64-bit) 3) ARM (32-bit) 4) PowerPC (32-bit) 5) MIPS (32-bit) 6) MIPS64 (64-bit) 2 Would you like to use the default (4.4) kernel? (y/n) [default: y] Do you need a new machine branch for this BSP (the alternative is to re-use an existing branch)? [y/n] [default: y] Getting branches from remote repo git://git.yoctoproject.org/linux-yocto-4.4.git... Please choose a machine branch to base this BSP on: [default: standard/base] 1) standard/arm-versatile-926ejs 2) standard/base 3) standard/beaglebone 4) standard/edgerouter 5) standard/fsl-mpc8315e-rdb 6) standard/mti-malta32 7) standard/mti-malta64 8) standard/qemuarm64 9) standard/qemuppc 2 Would you like SMP support? (y/n) [default: y] Does your BSP have a touchscreen? (y/n) [default: n] Does your BSP have a keyboard? (y/n) [default: y] New qemu BSP created in meta-myqemux86-64 2. Set the MAHCINE="myqemux86-64" and add the meta-myqemux86-64 layer to conf/bblayers.conf 3. Build the image: $ bitbake core-image-sato 4. Launch the qemu image: $ runqemu tmp/deploy/images/myqemux86-64/bzImage-myqemux86-64.bin tmp/deploy/images/myqemux86-64/core-image-sato-myqemux86-64.ext4 Set MACHINE to [qemux86-64] based on kernel [tmp/deploy/images/myqemux86-64/bzImage-myqemux86-64.bin] Continuing with the following parameters: KERNEL: [tmp/deploy/images/myqemux86-64/bzImage-myqemux86-64.bin] ROOTFS: [/buildarea1/poky/build-1/tmp/deploy/images/myqemux86-64/core-image-sato-myqemux86-64-20160726044644.rootfs.ext4] FSTYPE: [ext4] Setting up tap interface under sudo Acquiring lockfile for tap0... Running qemu-system-x86_64... /buildarea1/poky/build-1/tmp/sysroots/x86_64-linux/usr/bin/qemu-system-x86_64 -kernel tmp/deploy/images/myqemux86-64/bzImage-myqemux86-64.bin -net nic,model=virtio -net tap,vlan=0,ifname=tap0,script=no,downscript=no -cpu core2duo -drive file=/buildarea1/poky/build-1/tmp/deploy/images/myqemux86-64/core-image-sato-myqemux86-64-20160726044644.rootfs.ext4,if=virtio,format=raw -show-cursor -usb -usbdevice tablet -vga vmware -no-reboot -m 256 -serial mon:vc -serial null -append "vga=0 uvesafb.mode_option=640x480-32 root=/dev/vda rw mem=256M ip=192.168.7.2::192.168.7.1:255.255.255.0 oprofile.timer=1 rootfstype=ext4 " warning: TCG doesn't support requested feature: CPUID.01H:EDX.vme [bit 1] The image can not boot up and prints kernel panic message. It's difficult to copy the panic message text, I attached the screenshot.
Humberto, the problem is still present d57de67357a4cd3da2824f8bd2b02d100f1ac9c3 and its parent 3ddde5f32afe9225994df607f6b8dfcc58f6bdc7, so was introduce before these.
(In reply to comment #1) > Humberto, > > the problem is still present d57de67357a4cd3da2824f8bd2b02d100f1ac9c3 and > its parent 3ddde5f32afe9225994df607f6b8dfcc58f6bdc7, so was introduce before > these. BTW, the test was done with the core-image-minimal image.
Created attachment 3360 [details] kenerla_panic_full screenshot Ok, so after bisecting I found the guilty commit to be: http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=55159ef0567c9c5f47609a18cff8866a17e53173 It seems a little weird since the code change is just to warn the user about the C library not being compatible with the kernel, and even if that was the case, there is no such warning shown. Also, I noticed the attachment is a bit misleading, since it looks like the panic is caused by a pritnk, although its missing some information, the error is actually no valid root filesystem found, I will attach a new screenshot.
(In reply to comment #3) > Created attachment 3360 [details] > kenerla_panic_full screenshot > > Ok, so after bisecting I found the guilty commit to be: > > http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/ > ?id=55159ef0567c9c5f47609a18cff8866a17e53173 Nice, this is a good start. > > It seems a little weird since the code change is just to warn the user about > the C library not being compatible with the kernel, and even if that was the > case, there is no such warning shown. > > Also, I noticed the attachment is a bit misleading, since it looks like the > panic is caused by a pritnk, although its missing some information, the > error is actually no valid root filesystem found, I will attach a new > screenshot. Alex, naive question: is the kernel command line changed somehow so the root FS became invalid? Can you try with another working FS using the same kernel?
(In reply to comment #4) > Alex, naive question: is the kernel command line changed somehow so the root > FS became invalid? Can you try with another working FS using the same kernel? Nope, I already checked and the kernel cmdline isn't changed, in both cases its when trying to boot is uses /dev/vda, it may be that for some reason /dev/vda isn't found in our case.
Created attachment 3361 [details] kernel config diffs qemux86-64 vs myqemux86-64 I took the diff between the kernel configs for a working qemux86-64 and the myqemux86-64 on the commit where it starts failing, here it is in case someone finds something interesting.
(In reply to comment #6) > Created attachment 3361 [details] > kernel config diffs qemux86-64 vs myqemux86-64 > > I took the diff between the kernel configs for a working qemux86-64 and the > myqemux86-64 on the commit where it starts failing, here it is in case > someone finds something interesting. Actually, the diff should be or should have been between the same machine (myqemux86-64) using two different commits, the one where it starts failing and the one before that, I just did that, and there is nothing different between configs, so the error has to be coming from somewhere else.
I found something interesting: When switching commits from the working one, to the first one where it fails, I noticed that it was taking linux-yocto from SSTATE, BUT if I clean the SSTATE on the working commit and then switch to the non working one and rebuild, it was still taking it from SSTATE, which means the following: Yes, 55159ef0567c9c5f47609a18cff8866a17e53173 is the first commit where the bug is present, BUT there could be several commits after that one where the linux-yocto signature is the same, meaning that if we didnt change anything regarding the kernel, it'd have the same signature, which also explains why there is a signature change on this specific commit because the kernel class was indeed modified. Anyway, the point is that this isn't necessarily the guilty commit which presented the bug, to be sure this needs to be re-tested, after cleaning linux-yocto SSTATE on the "guilty" commit
After cleaning the shared state and re-testing , I can confirm that this is not the commit causing the issue, although it gives us a good clue, the actual commit where the bug occured must be between this, and the next one that involves somehow changin the kernel, which would invalidate the sstate signature.
So, we go back to commit http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=d57de67357a4cd3da2824f8bd2b02d100f1ac9c3 It is the first one where this issue is introduced, cleaning the shared states, and doing a: $ bitbake linux-yocto -c deploy fixes the problem, and vice versa, building on its parent 3ddde5f32afe9225994df607f6b8dfcc58f6bdc7 works fine, cleaning the shared states, and doing a $ bitbake linux-yocto -c deploy shows the problem again, so somehow, this commit is causing the error when bulding the kernel.
Moving this to M4 due to time constraints.
This is fixed on master, likely due to the kernel tools change. Note that runqemu will fail to start with the reproduction steps right now due to the created bsp layer not creating a qemuboot.conf file the runqemu scripts not being able to correctly guess the architecture of the machine. This is currently being worked on. In the mean time, you can apply the following patch (which has a significant error but can be used to verify that this bug is fixed) found here: https://patchwork.openembedded.org/patch/132469/ If you wish to test yourself.