Bug 6584

Summary: dmesg uvesafb: probe of uvesafb.0 failed with error -22 on genericx86/genericx86-64 on NUC and MinnowMax
Product: [Build System, Metadata & Runtime] BSPs Reporter: Stoicescu Cornel <corneliux.stoicescu>
Component: bsps-runtimeAssignee: Jianxun Zhang <jianxun.zhang>
Status: RESOLVED FIXED QA Contact: Cristina Agurida <cristina-danielax.agurida>
Severity: normal    
Priority: Medium CC: alejandro.hernandez, alexandru.c.georgescu, cristina-danielax.agurida, dvhart, georgex.l.musat, pravin.shankarx.patil, richard.purdie, yp.kernel.watcher, yp.watcher
Version: 1.7   
Target Milestone: 2.1   
Hardware: x86   
OS: x86_64   
Whiteboard:
OS type for building Yocto: --- Type of Regression: Regression (Found by QA test)
Verified: Documentation change: No (bug/feature does not impact docs)
Attachments:
Description Flags
More errors found in the logs.
none
log.do_testimage none

Description Stoicescu Cornel 2014-07-28 09:32:36 UTC
STATUS: FAILED
BUILD: master: 8b7116d25ed6255a03895d835e5a0560858ab496
ENVIRONMENT: genericx86-64 on Sugarbay
STEPS TO REPRODUCE: 
1.run " dmesg | grep -i error" in the terminal.
2.check if there is any error log printed.

OUTCOME:

[    2.328502] v86d[103]: segfault at 0 ip 0000000000401749 sp 00007fffcab15990 error 4 in v86d[400000+19000]
[    7.330763] uvesafb: probe of uvesafb.0 failed with error -22
Comment 1 Darren Hart 2014-07-31 13:48:49 UTC
which image was used here? Please include that in all bug reports.
Comment 2 Stoicescu Cornel 2014-07-31 14:06:26 UTC
A core-image-sato-sdk.
Comment 3 Lucian Musat 2015-02-04 14:59:10 UTC
Appears also on 1.8.M2.RC2 (22c38e2d8a058619e3d05534b5e830b750aa4241)
Comment 4 Nitin Kamble 2015-02-24 19:30:14 UTC
I have not spent much time on it. This needs further debugging.
Comment 5 Alexandru Georgescu 2015-03-05 10:44:50 UTC
Created attachment 2429 [details]
More errors found in the logs.
Comment 6 Saul Wold 2015-04-28 19:10:47 UTC
I just checked this on the Sugarbay machine I was using to look at the tar 
related issue and did not see this error with that build, please verify this is 
no longer an issue
Comment 7 Cristina Agurida 2015-07-14 11:14:42 UTC
This issue appears on 1.9_M1.rc2: f9ea480e6c26fea46c3011c4e9d0e2de3d5c81b4, genericx86-64 on NUC and MinnowMax and on genericx86 on MinnowMax.

Log: dmesg_output.log
-----------------------
Central error: [    6.843864] uvesafb: vbe_init() failed with -22
***********************
[    3.261093] scsi host4: usb-storage 1-4:1.0
[    4.367385] scsi 4:0:0:0: Direct-Access     Kingston DataTraveler 3.0 PMAP PQ: 0 ANSI: 6
[    4.883531] sd 4:0:0:0: [sdb] 15155200 512-byte logical blocks: (7.75 GB/7.22 GiB)
[    4.885440] sd 4:0:0:0: [sdb] Write Protect is off
[    4.885447] sd 4:0:0:0: [sdb] Mode Sense: 23 00 00 00
[    4.887245] sd 4:0:0:0: [sdb] No Caching mode page found
[    4.887283] sd 4:0:0:0: [sdb] Assuming drive cache: write through
[    4.968561]  sdb:
[    4.972900] sd 4:0:0:0: [sdb] Attached SCSI removable disk
[    6.843790] uvesafb: Getting VBE info block failed (eax=0x4f00, err=1)
[    6.843864] uvesafb: vbe_init() failed with -22
[    6.843916] uvesafb: probe of uvesafb.0 failed with error -22
[    6.963980] udevd[119]: starting version 182
[    7.012946] snd_hda_intel 0000:00:03.0: enabling device (0000 -> 0002)
[    7.013086] snd_hda_intel 0000:00:1b.0: enabling device (0000 -> 0002)
[    7.043234] sound hdaudioC1D0: autoconfig: line_outs=1 (0x21/0x0/0x0/0x0/0x0) type:hp
[    7.043238] sound hdaudioC1D0:    speaker_outs=0 (0x0/0x0/0x0/0x0/0x0)
[    7.043240] sound hdaudioC1D0:    hp_outs=0 (0x0/0x0/0x0/0x0/0x0)
[    7.043242] sound hdaudioC1D0:    mono: mono_out=0x0
[    7.043244] sound hdaudioC1D0:    inputs:
[    7.043246] sound hdaudioC1D0:      Mic=0x19
***********************
Central error: [    6.843790] uvesafb: Getting VBE info block failed (eax=0x4f00, err=1)
***********************
[    3.260626] usb-storage 1-4:1.0: USB Mass Storage device detected
[    3.261093] scsi host4: usb-storage 1-4:1.0
[    4.367385] scsi 4:0:0:0: Direct-Access     Kingston DataTraveler 3.0 PMAP PQ: 0 ANSI: 6
[    4.883531] sd 4:0:0:0: [sdb] 15155200 512-byte logical blocks: (7.75 GB/7.22 GiB)
[    4.885440] sd 4:0:0:0: [sdb] Write Protect is off
[    4.885447] sd 4:0:0:0: [sdb] Mode Sense: 23 00 00 00
[    4.887245] sd 4:0:0:0: [sdb] No Caching mode page found
[    4.887283] sd 4:0:0:0: [sdb] Assuming drive cache: write through
[    4.968561]  sdb:
[    4.972900] sd 4:0:0:0: [sdb] Attached SCSI removable disk
[    6.843790] uvesafb: Getting VBE info block failed (eax=0x4f00, err=1)
[    6.843864] uvesafb: vbe_init() failed with -22
[    6.843916] uvesafb: probe of uvesafb.0 failed with error -22
[    6.963980] udevd[119]: starting version 182
[    7.012946] snd_hda_intel 0000:00:03.0: enabling device (0000 -> 0002)
[    7.013086] snd_hda_intel 0000:00:1b.0: enabling device (0000 -> 0002)
[    7.043234] sound hdaudioC1D0: autoconfig: line_outs=1 (0x21/0x0/0x0/0x0/0x0) type:hp
[    7.043238] sound hdaudioC1D0:    speaker_outs=0 (0x0/0x0/0x0/0x0/0x0)
[    7.043240] sound hdaudioC1D0:    hp_outs=0 (0x0/0x0/0x0/0x0/0x0)
[    7.043242] sound hdaudioC1D0:    mono: mono_out=0x0
[    7.043244] sound hdaudioC1D0:    inputs:
Comment 8 Alexandru Georgescu 2015-07-14 11:20:14 UTC
reopening based on Cristina's comments
Comment 9 Saul Wold 2015-10-01 14:23:59 UTC
Has this issue been seen again?  I have not been able to reproduce this.
Comment 10 Cristina Agurida 2015-10-02 09:01:59 UTC
It appears also on 1.9_M3.rc1: ea562de57590c966cd5a75fda8defecd397e6436 poky commit, core-image-sato-sdk image for genericx86-64 tested on NUC and MinnowMax and genericx86 on MinnowMax.

This is the error:
Central error: [    6.904144] uvesafb: probe of uvesafb.0 failed with error -22
***********************
[    3.971505] scsi 4:0:0:0: Direct-Access     Kingston DataTraveler 3.0 PMAP PQ: 0 ANSI: 6
[    4.509839] sd 4:0:0:0: [sdb] 15155200 512-byte logical blocks: (7.75 GB/7.22 GiB)
[    4.511750] sd 4:0:0:0: [sdb] Write Protect is off
[    4.511756] sd 4:0:0:0: [sdb] Mode Sense: 23 00 00 00
[    4.513485] sd 4:0:0:0: [sdb] No Caching mode page found
[    4.513505] sd 4:0:0:0: [sdb] Assuming drive cache: write through
[    4.598734]  sdb:
[    4.602942] sd 4:0:0:0: [sdb] Attached SCSI removable disk
[    6.904025] uvesafb: Getting VBE info block failed (eax=0x4f00, err=1)
[    6.904094] uvesafb: vbe_init() failed with -22
[    6.904144] uvesafb: probe of uvesafb.0 failed with error -22
[    7.034071] udevd[119]: starting version 182
[    7.085258] snd_hda_intel 0000:00:03.0: enabling device (0000 -> 0002)
[    7.085395] snd_hda_intel 0000:00:1b.0: enabling device (0000 -> 0002)
[    7.085417] snd_hda_intel 0000:00:03.0: bound 0000:00:02.0 (ops i915_audio_component_bind_ops)
[    7.136159] snd_hda_codec_realtek hdaudioC1D0: autoconfig for ALC283: line_outs=1 (0x21/0x0/0x0/0x0/0x0) type:hp
[    7.136163] snd_hda_codec_realtek hdaudioC1D0:    speaker_outs=0 (0x0/0x0/0x0/0x0/0x0)
[    7.136166] snd_hda_codec_realtek hdaudioC1D0:    hp_outs=0 (0x0/0x0/0x0/0x0/0x0)
[    7.136168] snd_hda_codec_realtek hdaudioC1D0:    mono: mono_out=0x0
[    7.136169] snd_hda_codec_realtek hdaudioC1D0:    inputs:
[    7.136172] snd_hda_codec_realtek hdaudioC1D0:      Mic=0x19
Comment 11 Saul Wold 2015-10-22 23:38:06 UTC
After some further investigation and ensuring reproducible, the root cause seems to be that the generix86*  BSPs uses the v86d in MACHINE_EXTRA_RRECOMMENDS and when used with systems that have non-vesa framebuffers will fail.

Since the v86d package installs either a fbsetup script (for sysvinit) or a modprobe.d/uvesafb.conf for systemd.  These need to be modified to check for an existing framebuffer driver is installed.
Comment 12 Jianxun Zhang 2015-11-12 00:59:41 UTC
 - "It appears also on 1.9_M3.rc1: ea562de57590c966cd5a75fda8defecd397e6436 poky commit, core-image-sato-sdk image for genericx86-64 tested on NUC and MinnowMax and genericx86 on MinnowMax."

Will checkout this head and do some debugging with generic-x86 & MinnowMax for a solution.
Comment 13 Jianxun Zhang 2015-11-25 00:01:50 UTC
This can also reproduced on jethro. Maybe a short-term solution is just disable uvesafb module on non-emu machines as we discussed. I am doing some debugging today towards to these steps and more clues in logs:

rmmod uvesafb
modprobe uvesafb

root@genericx86-64:~# cat /var/log/messages
Nov 24 12:03:25 genericx86-64 user.warn v86d: EBDA too big (38800), truncating.
Nov 24 12:03:25 genericx86-64 user.err v86d: Video BIOS not found at c0000.
Nov 24 12:03:25 genericx86-64 user.err v86d: v86 memory initialization failed.
Nov 24 12:03:30 genericx86-64 user.err kernel: uvesafb: Getting VBE info block failed (eax=0x4f00, err=1)
Nov 24 12:03:30 genericx86-64 user.err kernel: uvesafb: vbe_init() failed with -22
Nov 24 12:03:30 genericx86-64 user.warn kernel: uvesafb: probe of uvesafb.0 failed with error -22
Nov 24 12:03:34 genericx86-64 authpriv.notice login[758]: ROOT LOGIN  on '/dev/ttyS0'
Comment 14 Jianxun Zhang 2015-12-02 17:34:28 UTC
After some investigation, the root cause for this issue is:

Vx86d tries to access to physical address 0xc0000 for video bios and also expects region from 0xa0000 as video ram. Clarified by FW team, Minnow Board Max BIOS is pure EFI-based and legacy free firmware. That means it doesn't support video bios and ram at these addresses.

I think we can disable uvesa on minnow Max or degrade this bug since I don't see any functional impact from this error message.
Comment 15 Jianxun Zhang 2015-12-15 18:23:04 UTC
patch has been submitted to poky mailing list today.
Comment 16 Jianxun Zhang 2016-01-09 04:03:26 UTC
patch has been merged into poky master brand:

http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=6af89812e8a9931ffed63768ed85367519bf7aef

close it.
Comment 17 Cristina Agurida 2016-01-22 13:01:27 UTC
This should be backported to jethro branch.
Comment 18 Alexandru Georgescu 2016-02-15 14:43:16 UTC
Verified with master (m2_rc1) and jethro (2.0.1.rc6)
Comment 19 pravin 2018-06-13 05:01:35 UTC
Tried on actual hardware minnowmax.

same error log is comming.

STATUS: FAILED
BUILD: 2.3.4 RC1: ebb42af2829edfca1a23c7a51a431c656ffc2090
IMAGE: core-image-sato-sdk_generic-x86_64
ENVIRONMENT: generic-x86_64 on minnowmax 
STEPS TO REPRODUCE: 
                      Parse dmesg log and all log files in /var/log for  k
                      keywords like: "error" , "failed" , "cannot", "can't" etc.
                      Filter out the known and invalid errors or errors that  
                      appear in certain situations and need to be ignored.


I have attached test_image log.
Comment 20 pravin 2018-06-13 05:02:56 UTC
Created attachment 4326 [details]
log.do_testimage
Comment 21 Richard Purdie 2018-06-14 15:11:46 UTC
This is a slightly different error message compared to the original bug. Here, the kernel has uvesafb in it but the userspace does not, its missing v86d. This is expected given the original change to remove it from the genericx86 images. This is therefore not a bug.