Created attachment 1029 [details] system halt log Sometimes, after system halt of a qemu image, a "general protection fault" is encountered. Attached are the logs of two occurrences. Might be related to the "shutdown" test, part of the qemuimage-tests, sometimes timing out without a result. Build Configuration: BB_VERSION = "1.17.0" BUILD_SYS = "x86_64-linux" NATIVELSBSTRING = "Fedora-17" TARGET_SYS = "x86_64-poky-linux" MACHINE = "qemux86-64" DISTRO = "poky" DISTRO_VERSION = "1.3+snapshot-20130129" TUNE_FEATURES = "m64" TARGET_FPU = "" meta meta-yocto meta-yocto-bsp = "master:cfb082961a6c9ac3d65738031c4071210529cd07"
Created attachment 1030 [details] system halt log 2
I have tried with a current master build (same commit as the reporter). Build Configuration: BB_VERSION = "1.17.0" BUILD_SYS = "x86_64-linux" NATIVELSBSTRING = "Ubuntu-11.10" TARGET_SYS = "x86_64-poky-linux" MACHINE = "qemux86-64" DISTRO = "poky" DISTRO_VERSION = "1.3+snapshot-20130129" TUNE_FEATURES = "m64" TARGET_FPU = "" meta-yocto meta = "master:cfb082961a6c9ac3d65738031c4071210529cd07" I've run the image as: $ runqemu qemux86-64 core-image-base serial kvm qemuparams="-smp 4" $ runqemu qemux86-64 core-image-base serial kvm $ runqemu qemux86-64 core-image-base serial It successfully halts without reproducing the failure. My kernel version was at 3.4.26, not 3.4.24 from the report however, not sure why that is with the same master commit and no AUTOREV modifications in my local config. root@qemux86-64:~# uname -a Linux qemux86-64 3.4.26-yocto-standard #1 SMP PREEMPT Tue Jan 29 12:39:55 PST 2013 x86_64 GNU/Linux What specific command are you running to test the image? On a clean build, do you get the latest kernel?
(In reply to comment #2) > > What specific command are you running to test the image? > > On a clean build, do you get the latest kernel? Command used is: runqemu qemux86-64 core-image-base serial qemuparams="-snapshot" Yes, on a clean build the image gets the latest kernel 3.4.26-yocto-standard. I don't see to much success on reproducing this bug by simply running the image. The call trace comes up only _sometimes_. It might have something to do with consecutive runs using `runqemu`, there might be more chances to be caught on AB builds.
In my testing I've experience a single strange issue where the halt never completed (no GPF) and it happened when the sleep timeout happened before the login prompt appeared and some sort of race seemed to ensue. I'm thinking a better approach to this testing would be to use expect rather than the (sleep X; echo "root"; sleep 1; echo "halt") | qemu... approach. This allows us to make the test deterministic and to run it as fast as possible. I wrote the following for my own testing and it's working as expected: $ cat qemu-halt.exp #!/usr/bin/expect -f set timeout 60 set env(TERM) spawn tmp/sysroots/x86_64-linux/usr/bin/qemu-system-x86_64 -hda tmp/deploy/images/core-image-minimal-qemux86-64.ext3 -snapshot -nographic -append "console=ttyS0 root=/dev/hda" -kernel tmp/deploy/images/bzImage-qemux86-64.bin expect " login:" send "root\r" expect ":~# " send "halt\r" expect "Power down." After switching to userspace, the system log through halt follows: Freeing unused kernel memory: 1596k freed INIT: version 2.88 booting uvesafb: VGABIOS Cirrus extension, VGABIOS Cirrus extension, 1.0, OEM: VGABIOS Cirrus extension, VBE v2.0 uvesafb: no monitor limits have been set, default refresh rate will be used uvesafb: VBE state buffer size cannot be determined (eax=0x14f, err=0) uvesafb: scrolling: redraw Console: switching to colour frame buffer device 80x30 uvesafb: framebuffer at 0xfc000000, mapped to 0xffffc90000080000, using 4096k, total 4096k fb0: VESA VGA frame buffer device Starting udev udevd[59]: starting version 182 expr[200]: segfault at 7f2bc56a89a0 ip 00007f2bc58cee43 sp 00007ffffcd5b9c0 error 4 in ld-2.17.so[7f2bc58ca000+21000] Starting Bootlog daemon: bootlogd. EXT3-fs (hda): warning: updating to rev 1 because of new feature flag, running e2fsck is recommended EXT3-fs (hda): using internal journal Configuring network interfaces... done. INIT: Entering runlevel: 5 Starting syslogd/klogd: done Stopping Bootlog daemon: bootlogd. Poky 8.0 (Yocto Project 1.3 Reference Distro) 1.3+snapshot-20130129 qemux86-64 ttyS0 qemux86-64 login: root root@qemux86-64:~# halt Broadcast message from root@qemux86-64 (ttyS0) (Wed Jan 30 20:05:13 2013): The system is going down for system halt NOW! INIT: Switching to runlevel: 0 INIT: Sending processes the TERM signal INIT: Sending processes the KILL signal Stopping syslogd/klogd: stopped syslogd (pid 484) stopped klogd (pid 487) done Deconfiguring network interfaces... done. Sending all processes the TERM signal... Sending all processes the KILL signal... Unmounting remote filesystems... Deactivating swap... Unmounting local filesystems... Shutdown: hda ACPI: Preparing to enter system sleep state S5 Disabling non-boot CPUs ... Power down. And we can verify we exited properly, and via the timeout: $ echo $? 0
This threads appears to be what we are hitting: http://osdir.com/ml/debian-bugs-dist/2011-02/msg00450.html
Appears to be a PV optimization gone south. Digging.
More googling suggests this is more likely a paravirtualization issue with the older kernels on our Autobuilder. I have prepared the following which drops CONFIG_PARAVIRT_GUEST from the kernel config: http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=dvhart/noparavirt Saul will run it with MUT tonight to test. It would be a shame to disable paravirt, so if this proves to be the issue, we'll need to discuss how to manage this. It may be we ignore it until we can upgrade the Autobuilder machines.
*** Bug 3797 has been marked as a duplicate of this bug. ***
Have we seen this since?
This does not appear to have reproduced since we removed paravirt from the qemux86_64 kernel.