| Summary: | generic-x86_64 dmesg errors on Sugarbay | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Build System, Metadata & Runtime] BSPs | Reporter: | Razvan Ionescu <razvanx.ionescu> | ||||
| Component: | bsps-meta-intel | Assignee: | Nitin Kamble <nitin.a.kamble> | ||||
| Status: | RESOLVED FIXED | QA Contact: | |||||
| Severity: | normal | ||||||
| Priority: | Medium | CC: | corneliux.stoicescu, dvhart, richard.purdie, tom.zanussi | ||||
| Version: | 1.5 | ||||||
| Target Milestone: | 1.5 | ||||||
| Hardware: | x86 | ||||||
| OS: | x86_64 | ||||||
| Whiteboard: | |||||||
| OS type for building Yocto: | --- | Type of Regression: | --- | ||||
| Verified: | Documentation change: | Don't know | |||||
| Attachments: |
|
||||||
Do these prevent a successful boot? Or are they benign? Nitin, can you please look at this while your working the other two sugarbay bugs? We're seeing these in the qemux86/qemux86-64 images occasionally too, e.g. on the -rc4 build: http://autobuilder.yoctoproject.org:8011/builders/nightly-qa-logrotate/builds/3/steps/Running%20Sanity%20Tests/logs/stdio in the automated sanity tests. Downloading that image didn't show the bug locally. So it seems like some kind of race. Bumping to Medium as it contains a segfault with v86d and is also seen on qemux86-64 on the AB. This does not happen with the oecore commit: This is the oecore commit pulling in the kernel fixes: commit 41875facc982f1c96a5ddf275adba1634b1a5ced Author: Bruce Ashfield <bruce.ashfield@windriver.com> Date: Wed Sep 25 15:30:12 2013 -0400 linux-yocto/3.10: common-pc* config updates Bumping the 3.10 meta branch SRCREV to import the following config changes for tghe sugarbay and common-pc wifi fragments. dad2b7e common-pc-64: add kernel CONFIG options for sugarbay platform 37c617d common-pc-wifi.cfg: add support for broadcom wifi drivers [YOCTO #5117] [YOCTO #5238] (From OE-Core rev: 180f465b0cab13e17dc92ac5c88d7d9001cd5b11) Signed-off-by: Nitin A Kamble <nitin.a.kamble@intel.com> Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org> I have tested with: dora:a02280f99f05b1c21de2a78de9222a2f62a0dabc (1.5 M5 RC6) which includes the: commit 41875facc982f1c96a5ddf275adba1634b1a5ced and it is not fixed. The bug remains open. I am not able to reproduce the issue here. I think it may be issue with the BIOS on your sugarbay platform. Hello Nitin, Can you please direct us to where we can get or we can find an appropriate BIOS update for the Sugarbay platform? Thank you :) Interesting fact: testing this bug on Sugarbay, using a Sugarbay image (so, NO generic), there is no dmesg segfault error at all. So, I incline to say that it is not a BIOS problem. I tested this on a Lenovo ThinkPad X220 (i5 2520M) that is compatible with the Sugarbay platform. The dmesg errors do not appear here and I incline to the fact that it's a BIOS issue. Marking it as RESOLVED. We will do a BIOS update on the other platform and set this to VERIFIED if all is well then. |
Created attachment 1525 [details] dmesg log - sugarbay - genericx86_64 There are dmesg errors on Sugarbay, generic-x86_64 image. Examples: [ 1.891913] v86d[96]: segfault at 0 ip 0000000000401749 sp 00007fffc9ff23d0 error 4 in v86d[400000+1a000] [ 6.893422] uvesafb: probe of uvesafb.0 failed with error -22 [ 7.509635] parport_pc: probe of 00:0a failed with error -16 [ 7.529112] ata6: SError: { HostInt 10B8B } res 51/24:03:00:00:00/00:00:00:00:00/a0 Emask 0x40 (internal error) 1.5_M5_RC4 Build poky 853bc53cd58a621918f0e5ce662dba263d1befb4 meta-intel 66def4d09cbdf1614622a7ab1d84bef312b5f55d