| Summary: | BSP can't build due to recent upgrading to xserver | ||
|---|---|---|---|
| Product: | [Build System, Metadata & Runtime] BSPs | Reporter: | Dexuan Cui <dexuan.cui> |
| Component: | bsps-configuration | Assignee: | Tom Zanussi <tom.zanussi> |
| Status: | VERIFIED FIXED | QA Contact: | |
| Severity: | major | ||
| Priority: | Medium | CC: | dexuan.cui, edwin.zhai, sgw, tom.zanussi, yp.bsp.watcher, yp.watcher |
| Version: | unspecified | ||
| Target Milestone: | 1.2 | ||
| Hardware: | x86 | ||
| OS: | Multiple | ||
| Whiteboard: | |||
| OS type for building Yocto: | --- | Type of Regression: | --- |
| Verified: | Documentation change: | --- | |
|
Description
Dexuan Cui
2011-10-11 20:19:41 UTC
(In reply to comment #0) > OE Build Configuration: > BB_VERSION = "1.13.3" > TARGET_ARCH = "i586" > TARGET_OS = "linux" > MACHINE = "n450" > DISTRO = "poky" > DISTRO_VERSION = "1.1+snapshot-20111012" > TUNE_FEATURES = "m32 core2" > TARGET_FPU = "" > meta > meta-yocto = "master:7dfb9ce398a4ca62d2d53be9ddc7128e665d5126" > meta-n450 = "master:e0e52850cf5f84fb4ee1bfa15571aaf61e068450" > > NOTE: Resolving any missing task queue dependencies > ERROR: Nothing RPROVIDES 'xserver-xf86-dri-lite' (but > /distro/dcui/nas/p1/meta/recipes-sato/tasks/task-core-x11.bb RDEPENDS on or > otherwise requires it) > NOTE: Runtime target 'xserver-xf86-dri-lite' is unbuildable, removing... > Missing or unbuildable dependency chain was: ['xserver-xf86-dri-lite'] > NOTE: Runtime target 'task-core-x11-base' is unbuildable, removing... > Missing or unbuildable dependency chain was: ['task-core-x11-base', > 'xserver-xf86-dri-lite'] > ERROR: Required build target 'core-image-sato-sdk' has no buildable providers. > > > This is caused by > http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=c09f0eb561a53b97a769dd0744076af7d904eafb > > > We need upgrade meta-intel, too: > meta/recipes-graphics/xorg-xserver/xserver-xorg-common.inc (renamed from > meta/recipes-graphics/xorg-xserver/xserver-xf86-common.inc) > meta/recipes-graphics/xorg-xserver/xserver-xorg-lite.inc (renamed from > meta/recipes-graphics/xorg-xserver/xserver-xf86-lite.inc) > meta/recipes-graphics/xorg-xserver/xserver-xorg.inc (renamed from > meta/recipes-graphics/xorg-xserver/xserver-xf86-dri-lite.inc) I'm trying to figure out a fix. (In reply to comment #1) > (In reply to comment #0) > > This is caused by > > http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=c09f0eb561a53b97a769dd0744076af7d904eafb > > > > > > We need upgrade meta-intel, too: > > meta/recipes-graphics/xorg-xserver/xserver-xorg-common.inc (renamed from > > meta/recipes-graphics/xorg-xserver/xserver-xf86-common.inc) > > meta/recipes-graphics/xorg-xserver/xserver-xorg-lite.inc (renamed from > > meta/recipes-graphics/xorg-xserver/xserver-xf86-lite.inc) > > meta/recipes-graphics/xorg-xserver/xserver-xorg.inc (renamed from > > meta/recipes-graphics/xorg-xserver/xserver-xf86-dri-lite.inc) > > I'm trying to figure out a fix. I sent out 2 patches for this: http://git.yoctoproject.org/cgit.cgi/poky-contrib/commit/?h=dcui/fix_1670&id=6dfde724efa6c181b4249ed21cc0217557e90e6d http://git.yoctoproject.org/cgit.cgi/meta-intel-contrib/commit/?h=dcui/fix_1670&id=ad155bb2f7c2032a923332275d698d0787c764d2 (In reply to comment #2) > (In reply to comment #1) > > (In reply to comment #0) > > > This is caused by > > > http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=c09f0eb561a53b97a769dd0744076af7d904eafb > > > > > > > > > We need upgrade meta-intel, too: > > > meta/recipes-graphics/xorg-xserver/xserver-xorg-common.inc (renamed from > > > meta/recipes-graphics/xorg-xserver/xserver-xf86-common.inc) > > > meta/recipes-graphics/xorg-xserver/xserver-xorg-lite.inc (renamed from > > > meta/recipes-graphics/xorg-xserver/xserver-xf86-lite.inc) > > > meta/recipes-graphics/xorg-xserver/xserver-xorg.inc (renamed from > > > meta/recipes-graphics/xorg-xserver/xserver-xf86-dri-lite.inc) > > > > I'm trying to figure out a fix. > > I sent out 2 patches for this: > > http://git.yoctoproject.org/cgit.cgi/poky-contrib/commit/?h=dcui/fix_1670&id=6dfde724efa6c181b4249ed21cc0217557e90e6d > > http://git.yoctoproject.org/cgit.cgi/meta-intel-contrib/commit/?h=dcui/fix_1670&id=ad155bb2f7c2032a923332275d698d0787c764d2 The above patchset didn't fix the build problems for meta-intel and was incorrectly changing the common 1.9.3 recipe, so I posted a new patchset yesterday: http://git.yoctoproject.org/cgit/cgit.cgi/meta-intel/log/?h=tzanussi/xorg-rename-fixes-v0 The new patchset builds 3 representative BSPS - crownbay, crownbay-noemgd and sugarbay. The others were changed to be the same but were not build tested yet. The only one that boots into sato properly is sugarbay. The others all give runtime errors when starting Xorg: [4195256.798] (II) LoadModule: "extmod" [4195256.803] (WW) Warning, couldn't open module extmod [4195256.803] (II) UnloadModule: "extmod" [4195256.803] (EE) Failed to load module "extmod" (module does not exist, 0) [4195256.803] (II) LoadModule: "dbe" [4195256.804] (WW) Warning, couldn't open module dbe [4195256.804] (II) UnloadModule: "dbe" [4195256.804] (EE) Failed to load module "dbe" (module does not exist, 0) [4195256.804] (II) LoadModule: "glx" [4195256.805] (WW) Warning, couldn't open module glx [4195256.805] (II) UnloadModule: "glx" [4195256.805] (EE) Failed to load module "glx" (module does not exist, 0) [4195256.805] (II) LoadModule: "dri" [4195256.806] (WW) Warning, couldn't open module dri [4195256.806] (II) UnloadModule: "dri" [4195256.806] (EE) Failed to load module "dri" (module does not exist, 0) [4195256.806] (II) LoadModule: "dri2" [4195256.806] (WW) Warning, couldn't open module dri2 [4195256.807] (II) UnloadModule: "dri2" [4195256.807] (EE) Failed to load module "dri2" (module does not exist, 0) The problem is that the new recipe creates separate modules for the above, but they don't get installed for anything but sugarbay. The other problem so far noted is that for crownbay-noemgd and fri2-noemgd, the xserver-xorg_1.9.3 recipe is in the layer BBFILES and gets picked up in preference to xserver-xorg_1.11.1, which shouldn't happen and didn't happen before with 1.10. In order to get those to use the latest version as they should anyway, I had to assign a PREFERRED_VERSION to 1.11.1. I may have mistakenly booted the wrong sugarbay, and it actually wouldn't have worked, since a new build is not showing the modules and extensions in the rootfs.
However, adding this to crownbay-noemgd.conf does result in the modules and extensions showing up in the rootfs and a successful xserver start.
diff --git a/meta-crownbay/conf/machine/crownbay-noemgd.conf b/meta-crownbay/conf/machine/crownbay-noemgd.conf
index 3e268d3..bde9a5f 100644
--- a/meta-crownbay/conf/machine/crownbay-noemgd.conf
+++ b/meta-crownbay/conf/machine/crownbay-noemgd.conf
@@ -20,6 +20,12 @@ PREFERRED_PROVIDER_virtual/libgl ?= "mesa-dri"
PREFERRED_PROVIDER_virtual/xserver ?= "xserver-xorg"
PREFERRED_PROVIDER_virtual/xserver-xf86 ?= "xserver-xorg"
XSERVER ?= "xserver-xorg \
+ xserver-xorg-extension-dri \
+ xserver-xorg-extension-dri2 \
+ xserver-xorg-extension-glx \
+ xserver-xorg-extension-extmod \
+ xserver-xorg-extension-dbe \
+ xserver-xorg-module-libint10 \
xf86-input-mouse \
xf86-input-keyboard \
xf86-input-evdev \
(In reply to comment #4) > I may have mistakenly booted the wrong sugarbay, and it actually wouldn't have > worked, since a new build is not showing the modules and extensions in the > rootfs. > > However, adding this to crownbay-noemgd.conf does result in the modules and > extensions showing up in the rootfs and a successful xserver start. > > diff --git a/meta-crownbay/conf/machine/crownbay-noemgd.conf > b/meta-crownbay/conf/machine/crownbay-noemgd.conf > index 3e268d3..bde9a5f 100644 > --- a/meta-crownbay/conf/machine/crownbay-noemgd.conf > +++ b/meta-crownbay/conf/machine/crownbay-noemgd.conf > @@ -20,6 +20,12 @@ PREFERRED_PROVIDER_virtual/libgl ?= "mesa-dri" > PREFERRED_PROVIDER_virtual/xserver ?= "xserver-xorg" > PREFERRED_PROVIDER_virtual/xserver-xf86 ?= "xserver-xorg" > XSERVER ?= "xserver-xorg \ > + xserver-xorg-extension-dri \ > + xserver-xorg-extension-dri2 \ > + xserver-xorg-extension-glx \ > + xserver-xorg-extension-extmod \ > + xserver-xorg-extension-dbe \ > + xserver-xorg-module-libint10 \ > xf86-input-mouse \ > xf86-input-keyboard \ > xf86-input-evdev \ No, I didn't boot the wrong sugarbay - it just ends up with the modules in the image whereas crownbay-noemgd requires the above. I was also successful getting crownbay with emgd working with the above. Let me change the owner to Tom :-) I just pushed a patchset to meta-intel that gets all the BSPs building and Xorg working again. The last commit in the series is a94520555c1f9ab1db865f810bdaa79d870d8ee9. I wasn't able to disable the dri module as requested by Richard - removing it or disabling dri in preference to dri2 always resulted in run-time module-loading or drm init errors and prevented X from starting up, so I had to leave them in for now. I'll have to look into it later - I don't want it to hold up getting basic functionality back for now. The multiple inclusions will also be cleaned up in 1.2 M1. There's also the issue of xserver-xorg 1.9.3 being picked up instead of 1.11.1 without the explicit PREFERRED_VERSION assignment - the reason for that still needs to be investigated as well, so although things are working again, I won't be closing this or marking it resolved until those things are addressed. I also haven't been able to verify all the BSPs yet, which I will continue to do over the next week. The ones I have tested are crownbay/crownbay-noemgd, fri2/fri2-noemgd, n450, emenlow, and sugarbay. sugarbay boots into X ok, but there are no icons. The last time I looked into this, reverting commit [d39c6738df4b7e8ef22f2a7154274c1d08b1d51f matchbox: Upgrade SRCREV to reflect recent accpeted patches by upstream] fixed the problem, but I haven't tried it again in this round of testing. All meta-intel BSPs have now been updated so that X works again. The problems mentioned in the previous comment have been fixed or are no longer problems. (In reply to comment #8) > All meta-intel BSPs have now been updated so that X works again. The problems > mentioned in the previous comment have been fixed or are no longer problems. I can confirm I don't meet the bug recently. |