Bug 3799

Summary: [Autobuilder] nightly-x86-64 dmesg sanity failed (modprobe gpf)
Product: [Yocto Project Subprojects] Kernel Reporter: Bogdan Marinescu <bogdan.a.marinescu>
Component: linux-yoctoAssignee: Darren Hart <dvhart>
Status: RESOLVED FIXED QA Contact:
Severity: normal    
Priority: Medium+ CC: corneliux.stoicescu, infras.ab.watcher, Infras.watcher, sgw
Version: 1.4   
Target Milestone: 1.4 M4   
Hardware: Other   
OS: x86_64   
Whiteboard:
OS type for building Yocto: --- Type of Regression: ---
Verified: Documentation change: ---

Description Bogdan Marinescu 2013-01-28 09:26:38 UTC 
(I'm filing this under "Autobuilder" because I'm not sure what's the right category, as I was unable to find the root cause of the failure).

| /bin/dmesg
| QEMU: There is some error log in dmesg:
| QEMU: ##### Error Log ######
| modprobe[74] general protection ip:7f4017e8012c sp:7fff9fe4ef50 error:0 in ld-2.16.so[7f4017e70000+21000]
| QEMU: #####    End     ######

More details : http://autobuilder.yoctoproject.org:8010/builders/nightly-x86-64/builds/814/steps/shell_39/logs/stdio
Comment 1 Darren Hart 2013-01-29 23:03:18 UTC 
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 loads the aes_encryption modules and I don't see any general protection faults in dmesg before or after the loading of the module. I have not been able to reproduce this outside of the Autobuilder.

Bogdan, is this reproducible for you?
Comment 2 Bogdan Marinescu 2013-01-30 09:02:23 UTC 
(In reply to comment #1)
> 
> Bogdan, is this reproducible for you?

No, I am also unable to reproduce this locally.
Comment 3 Darren Hart 2013-01-31 00:14:00 UTC 
This may be the same root cause as 3806, paravirt hitting bug in older host kernel.
Comment 4 Stoicescu Cornel 2013-02-13 15:35:34 UTC 
Any update on this?

Are we able to reproduce it? Is anyone working on this?
Comment 5 Darren Hart 2013-02-13 17:02:29 UTC 
No update. As I understand it we haven't seen any of these failures with my patch to disable paravirt in the guest. We need to see if that can be disabled at runtime, but I haven't been able to get to that yet.
Comment 6 Darren Hart 2013-02-28 05:15:26 UTC 
Have we seen this since?
Comment 7 Darren Hart 2013-03-05 00:42:56 UTC 
This doesn't appear to have been reproduced since qemux86_64 disabled paravirt. Closing.