For qemux86 built and booted on OpenSuse, there are errors for uvesafb in dmesg: Central error: uvesafb: Getting VBE info block failed (eax=0x4f00, err=1) | *********************** | md: ... autorun DONE. | kjournald starting. Commit interval 5 seconds | EXT3-fs (hda): using internal journal | EXT3-fs (hda): mounted filesystem with ordered data mode | VFS: Mounted root (ext3 filesystem) on device 3:0. | devtmpfs: mounted | Freeing unused kernel memory: 680K (c1b59000 - c1c03000) | Write protecting the kernel text: 8000k | Write protecting the kernel read-only data: 3040k | random: nonblocking pool is initialized | 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 | udevd[77]: starting version 182 | hrtimer: interrupt took 4898626 ns | *********************** | Central error: uvesafb: probe of uvesafb.0 failed with error -22 | *********************** | EXT3-fs (hda): using internal journal | EXT3-fs (hda): mounted filesystem with ordered data mode | VFS: Mounted root (ext3 filesystem) on device 3:0. | devtmpfs: mounted | Freeing unused kernel memory: 680K (c1b59000 - c1c03000) | Write protecting the kernel text: 8000k | Write protecting the kernel read-only data: 3040k | random: nonblocking pool is initialized | 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 | udevd[77]: starting version 182 | hrtimer: interrupt took 4898626 ns | *********************** | Central error: uvesafb: vbe_init() failed with -22 | *********************** | kjournald starting. Commit interval 5 seconds | EXT3-fs (hda): using internal journal | EXT3-fs (hda): mounted filesystem with ordered data mode | VFS: Mounted root (ext3 filesystem) on device 3:0. | devtmpfs: mounted | Freeing unused kernel memory: 680K (c1b59000 - c1c03000) | Write protecting the kernel text: 8000k | Write protecting the kernel read-only data: 3040k | random: nonblocking pool is initialized | 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 | udevd[77]: starting version 182 | hrtimer: interrupt took 4898626 ns *********************** Build Configuration: BB_VERSION = "1.24.0" BUILD_SYS = "x86_64-linux" NATIVELSBSTRING = "openSUSE-project-13.1" TARGET_SYS = "i586-poky-linux" MACHINE = "qemux86" meta-yocto-bsp = "master:5367855fe56db0c09b8fa7bb423b9de18d11eecc" meta-qt3 = "master:3016129d90b7ac8517a5227d819f10ad417b5b45" Image built was core-image-sato. Cheers, Ionut C
Is this issue reproducible on any other host OS? Also, is this issue 100% reproducible?
(In reply to comment #1) > Is this issue reproducible on any other host OS? > Also, is this issue 100% reproducible? No, the issue appeared only on OpenSuse build and yes it was reproducible.
Hello Ionut, One more stuff to investigate, please: Do any of these errors have a real influence on the BSP operation? Is graphics performing OK even when these errors are encountered? Does anything brake?
From LogParser filters the issue appeared on generic x86_64 on Sugarbay also. ************************** ata6.00: failed to IDENTIFY (I/O error, err_mask=0x4) uvesafb: probe of uvesafb.0 failed with error -22 uvesafb: vbe_init() failed with -22 uvesafb: Getting VBE info block failed (eax=0x4f00, err=1)
There is still the open question about actual operation, is X able to start even with these errors or does it prevent X and Satofrom starting? Further on the OpenSuse issue, if you take the images to another Linux OS, does the error occur and vis-versa if you take an image build on a different OS does the same failure occur?
(In reply to comment #5) > There is still the open question about actual operation, is X able to start > even with these errors or does it prevent X and Satofrom starting? Further > on > the OpenSuse issue, if you take the images to another Linux OS, does the > error > occur and vis-versa if you take an image build on a different OS does the > same > failure occur? Assigned this to Ionut to update the needed info.
As I think this issue is now solved, I will test it and update the bug once again when the next 1.8 M2 will come in QA for FP validation. Cheers, Ionut C
Ionut is reviewing. Moved out of NEEDINFO.
For 1.7.1 RC1, commit: 6dd21a9f152a93e2df1178d7a5bd903d7edcf4be, the issue is solved. Closing the bug. Cheers, Ionut C
Verified.