Bug 6038

Summary:	[dylan] qemux86-64 v86d segfault at init
Product:	[Runtime] General Runtime	Reporter:	Alexandru Palalau <alexandrux.palalau>
Component:	General Runtime	Assignee:	Scott Rifenbark <srifenbark>
Status:	RESOLVED WORKSFORME	QA Contact:
Severity:	normal
Priority:	Medium	CC:	bluelightning, richard.purdie, srifenbark, sstncr
Version:	1.4.3
Target Milestone:	1.4.3
Hardware:	x86
OS:	x86_64
Whiteboard:
OS type for building Yocto:	---	Type of Regression:	Regression (Used to work)
Verified:		Documentation change:	No (bug/feature does not impact docs)

Description Alexandru Palalau 2014-03-25 11:59:39 UTC

Running core-image-sato-sdk image from:
http://autobuilder.yoctoproject.org/pub/nightly/20140318-5

Checking dmesg for errors, comes up with:
**************************************************************************
INIT: version 2.88 booting
v86d[48]: segfault at 0 ip 0000000000401799 sp 00007fff5d3de680 error 4 in v86d[400000+1a000]
uvesafb: Getting VBE info block failed (eax=0x4f00, err=1)
uvesafb: vbe_init() failed with -22
uvesafb: probe of uvesafb.0 failed with error -22
Error opening /dev/fb0: No such file or directory
Starting udev
***************************************************************************

This is not present on qemux86 image for the same commits.

Comment 1 Stefan Stanacar 2014-04-01 15:10:22 UTC

Okay so this bug is missing important information on how to reproduce this... I'm inclined to set it to one WORKSFORME/NOTABUG.

I've tried to reproduce it in many ways, some of them being:

 - build core-image-sato-sdk on dylan on the same commit as the image from the AB
-> nope, works fine
 - run the image/kernel built by the AB in that build dir - nope works fine
 - run the image in a 1.6 build dir (so it uses qemu from 1.6) - nope works fine

I then I realised...  you did bitbake qemu-helper-native and ran the image - but you didn't mention that and didn't paste the runqemu output.
So I reproduce this with:
  - clean build dir on dylan branch
  - bitbake qemu-helper-native
  - runqemu ... (and notice it uses /usr/bin/qemu-... 

The thing is that bitbake qemu-helper-native isn't enough, because it will use the qemu binary from your system which is totally unsupported. You need at least bitbake qemu-native qemu-helper-native, if you do that you won't see the error. 

I think there is a chapter somewhere in the manual where it says how to run an already built qemu image and what you need to build before instead of a full image (you need a sdk or buildtools or bitbake meta-ide-support or something like that). If this isn't in the docs, we should add it.

Comment 2 Richard Purdie 2014-04-01 15:18:05 UTC

Adding Scott Rifenbark for comment

Comment 3 Saul Wold 2014-04-01 17:09:54 UTC

This is possibly an addition to the Release Notes and ensure that the 
Documentation is correct

Comment 4 Scott Rifenbark 2014-04-01 22:00:11 UTC

The QS covers this stuff that Stefan is asking about in his comment 1.  No changes to the mainstream docs required.

Maybe in the release notes as suggested by Saul.

Scott

Comment 5 Stefan Stanacar 2014-04-02 10:20:47 UTC

The docs are correct as far as I'm concerned.
As about the release notes - hmm, did we ever supported using the system's qemu?
As I see it, if I correctly start that 1.4.3 image published I don't get the dmesg errors.

Comment 6 Alexandru Palalau 2014-04-09 08:15:15 UTC

I can confirm that I only built qemu-helper-native.