Bug 883

Summary:

[Sugarbay] GFX 3D game test fail to run with sugarbay BSP image due to libsdl.so

Product:

[Build System, Metadata & Runtime] BSPs

Reporter:

Xudong Hao <xudong.hao>

Component:

bsps-configuration

Assignee:

Jiajun Xu <jiajun.xu>

Status:

VERIFIED FIXED

QA Contact:

Severity:

normal

Priority:

Medium

CC:

dexuan.cui, jessica.zhang, jiajun.xu, kunwei.tian, sgw, shane.wang, tom.zanussi, wenhuax.fan, yp.bsp.watcher, yp.watcher

Version:

unspecified

Target Milestone:

1.1

Hardware:

Other

OS:

x86

Whiteboard:

Fixing patch sent out for review (8/23)

OS type for building Yocto:

---

Type of Regression:

---

Verified:

Documentation change:

---

Attachments:

Description	Flags
openarena test error	none
urbanterror test error	none

Description Xudong Hao 2011-03-16 01:59:39 UTC

Image location:
http://autobuilder02.pokylinux.org/sugarbay-bernard/nightly/20110314-1/machines/sugarbay/x86_32/poky-image-sato-sdk-live-sugarbay-20110314091833.hddimg.bz2

commit: a33a2cc024f9c9147c92c5da70d8fbb631b968f9

On Sugarbay with RC3 BSP image installed, we copy the Dynamic lib file(attchment) to /usr/lib/, then run GFX test. All 2D test can pass, but 3D test (openarena and urbanterror)fail to run.

For RC2 BSP image, both 2D and 3D can pass to test.

Comment 1 Xudong Hao 2011-03-16 02:06:31 UTC

Created attachment 111 [details]
openarena test error

Comment 2 Xudong Hao 2011-03-16 02:07:13 UTC

Created attachment 112 [details]
urbanterror test error

Comment 3 Xudong Hao 2011-03-16 02:14:02 UTC

The Dynamic lib files are big so that I can not attach the zip file to attachments.

Comment 4 Tom Zanussi 2011-03-16 07:39:20 UTC

Can you please tell me more about which version worked previously and which are failing now?  According to our build people, there was no RC2 BSP image made available.  Could you tell me what you had that previously worked, so I can do a comparison between that and the failure.

Comment 5 Jiajun Xu 2011-03-16 07:59:55 UTC

(In reply to comment #4)
> Can you please tell me more about which version worked previously and which are
> failing now?  According to our build people, there was no RC2 BSP image made
> available.  Could you tell me what you had that previously worked, so I can do
> a comparison between that and the failure.

Hi Tom,
Previously, we used 20110307 build for RC2 testing and above error did not occur. The image could be found @ http://autobuilder02.pokylinux.org/sugarbay-bernard/nightly/20110307-1/machines/sugarbay/x86_32/poky-image-sato-sdk-live-sugarbay-20110308070406.hddimg.bz2.
The commit is 1bac3117fab34673f08bb335170ad013bbd089cf.

Comment 6 Tom Zanussi 2011-03-16 08:20:17 UTC

Can you provide me with all the info I need to reproduce this:

- the actual GFX test (is that a script, etc?) that I need to run
- the 'Dynamic Lib' file that couldn't be attached (or another place to get it)
- instructions on how to get/build/install urbanterror and openarena into the image for testing

Comment 7 Dexuan Cui 2011-03-16 22:10:00 UTC

(In reply to comment #5)
> (In reply to comment #4)
> > Can you please tell me more about which version worked previously and which are
> > failing now?  According to our build people, there was no RC2 BSP image made
> > available.  Could you tell me what you had that previously worked, so I can do
> > a comparison between that and the failure.
> Hi Tom,
> Previously, we used 20110307 build for RC2 testing and above error did not
> occur. The image could be found @
> http://autobuilder02.pokylinux.org/sugarbay-bernard/nightly/20110307-1/machines/sugarbay/x86_32/poky-image-sato-sdk-live-sugarbay-20110308070406.hddimg.bz2.
> The commit is 1bac3117fab34673f08bb335170ad013bbd089cf.

I've tried the RC2 image according to Xudong's instructions and got the same issue. So I think this is an environment setup issue, e.g. the .so files may be copied to the correct place? I had a quick check, but didn't find the issue. I'm still checking...

Comment 8 Dexuan Cui 2011-03-17 05:52:10 UTC

(In reply to comment #7)
> (In reply to comment #5)
> > (In reply to comment #4)
> > > Can you please tell me more about which version worked previously and which are
> > > failing now?  According to our build people, there was no RC2 BSP image made
> > > available.  Could you tell me what you had that previously worked, so I can do
> > > a comparison between that and the failure.
> > Hi Tom,
> > Previously, we used 20110307 build for RC2 testing and above error did not
> > occur. The image could be found @
> > http://autobuilder02.pokylinux.org/sugarbay-bernard/nightly/20110307-1/machines/sugarbay/x86_32/poky-image-sato-sdk-live-sugarbay-20110308070406.hddimg.bz2.
> > The commit is 1bac3117fab34673f08bb335170ad013bbd089cf.
> I've tried the RC2 image according to Xudong's instructions and got the same
> issue. So I think this is an environment setup issue, e.g. the .so files may be
> copied to the correct place? I had a quick check, but didn't find the issue.
> I'm still checking...

I did more tests: what's weird is: following the same instructions, sometimes it's always fine and sometimes it's always not... The same phenomenon happens to both RC2 image and RC3 image, so I don't think this bug is a regression.

BTW: when it's not fine, sometimes it looks rebooting the host can resolve the issue.

My suggestion is maybe we can lower the priority and try to fix this after 1.0.
(After all, the libSDL, mesa-demo, libva, etc, are not built into target in Poky's master and bernard branches.)

Comment 9 Dexuan Cui 2011-03-18 01:59:22 UTC

(In reply to comment #8)
> (In reply to comment #7)
> > (In reply to comment #5)
> > > (In reply to comment #4)
> > > > Can you please tell me more about which version worked previously and which are
> > > > failing now?  According to our build people, there was no RC2 BSP image made
> > > > available.  Could you tell me what you had that previously worked, so I can do
> > > > a comparison between that and the failure.
> > > Hi Tom,
> > > Previously, we used 20110307 build for RC2 testing and above error did not
> > > occur. The image could be found @
> > > http://autobuilder02.pokylinux.org/sugarbay-bernard/nightly/20110307-1/machines/sugarbay/x86_32/poky-image-sato-sdk-live-sugarbay-20110308070406.hddimg.bz2.
> > > The commit is 1bac3117fab34673f08bb335170ad013bbd089cf.
> > I've tried the RC2 image according to Xudong's instructions and got the same
> > issue. So I think this is an environment setup issue, e.g. the .so files may be
> > copied to the correct place? I had a quick check, but didn't find the issue.
> > I'm still checking...
> I did more tests: what's weird is: following the same instructions, sometimes
> it's always fine and sometimes it's always not... The same phenomenon happens
> to both RC2 image and RC3 image, so I don't think this bug is a regression.
> BTW: when it's not fine, sometimes it looks rebooting the host can resolve the
> issue.
> My suggestion is maybe we can lower the priority and try to fix this after 1.0.
> (After all, the libSDL, mesa-demo, libva, etc, are not built into target in
> Poky's master and bernard branches.)

I located the cause: the libsdl.so I built doesn't work in sugarbay target (I don't know why yet and I'm trying to figure it out): when running the 3D openareana game: it shows:
SDL using driver "x11"
Initializing OpenGL display
Estimated display aspect: 1.333
...setting mode -1: 1024 768
Available modes: '640x480 800x600 1024x768 848x480'
Couldn't get a visual
...WARNING: could not set the given mode (-1)
Initializing OpenGL display
...setting mode -1: 1024 768
Available modes: '640x480 800x600 1024x768 848x480'
Couldn't get a visual
...WARNING: could not set the given mode (-1)
Setting r_mode -1 failed, falling back on r_mode 3
Initializing OpenGL display
...setting mode 3: 640 480
Available modes: '640x480 800x600 1024x768 848x480'
Couldn't get a visual
...WARNING: could not set the given mode (3)
----- CL_Shutdown -----
RE_Shutdown( 1 )
-----------------------
GLimp_Init() - could not load OpenGL subsystem


If I use a libsdl.so built inside the target, or copied from another x86_64 host, the 3D game can run fine.
In RC2 testing, actually the libsdl.so is from another x86_64 host(we didn't recoginze that as there were 2 disks in the sugarbay host and we incorrectly thought both the libsdl.so files in the 2 disks were ok); in RC3 testing, we did use the file I built and found this bug...

So this is not a regression from RC2 to RC3. Since the we haven't pushed the libsdl recipe change into poky's master or bernard branch, I think we can fix this bug after 1.0.

BTW: I found another intersting thing: when switching between DRI and non-DRI, we need to restart X server: e.g., when we can run the 3D game, if we rename i965_dri.so to i965_dri.so.bak, restart the host, we'll find we can't run the 3D game with the same above error, and this time, even if we rename i965_dri.so.bak back to i965_dri.so, we still can't run the 3D game before restarting X server (or the host). This explains my previous strange experience about rebooting the host.

Comment 10 Dexuan Cui 2011-03-21 00:06:48 UTC

(In reply to comment #9)
> (In reply to comment #8)
> > (In reply to comment #7)
> > > (In reply to comment #5)
> > > > (In reply to comment #4)
> > > > > Can you please tell me more about which version worked previously and which are
> > > > > failing now?  According to our build people, there was no RC2 BSP image made
> > > > > available.  Could you tell me what you had that previously worked, so I can do
> > > > > a comparison between that and the failure.
> > > > Hi Tom,
> > > > Previously, we used 20110307 build for RC2 testing and above error did not
> > > > occur. The image could be found @
> > > > http://autobuilder02.pokylinux.org/sugarbay-bernard/nightly/20110307-1/machines/sugarbay/x86_32/poky-image-sato-sdk-live-sugarbay-20110308070406.hddimg.bz2.
> > > > The commit is 1bac3117fab34673f08bb335170ad013bbd089cf.
> > > I've tried the RC2 image according to Xudong's instructions and got the same
> > > issue. So I think this is an environment setup issue, e.g. the .so files may be
> > > copied to the correct place? I had a quick check, but didn't find the issue.
> > > I'm still checking...
> > I did more tests: what's weird is: following the same instructions, sometimes
> > it's always fine and sometimes it's always not... The same phenomenon happens
> > to both RC2 image and RC3 image, so I don't think this bug is a regression.
> > BTW: when it's not fine, sometimes it looks rebooting the host can resolve the
> > issue.
> > My suggestion is maybe we can lower the priority and try to fix this after 1.0.
> > (After all, the libSDL, mesa-demo, libva, etc, are not built into target in
> > Poky's master and bernard branches.)
> I located the cause: the libsdl.so I built doesn't work in sugarbay target (I
> don't know why yet and I'm trying to figure it out): when running the 3D
got the reason: there is a video-opengl config option not turned on when I built from poky... I'll fix the option.

> openareana game: it shows:
> SDL using driver "x11"
> Initializing OpenGL display
> Estimated display aspect: 1.333
> ...setting mode -1: 1024 768
> Available modes: '640x480 800x600 1024x768 848x480'
> Couldn't get a visual
> ...WARNING: could not set the given mode (-1)
> Initializing OpenGL display
> ...setting mode -1: 1024 768
> Available modes: '640x480 800x600 1024x768 848x480'
> Couldn't get a visual
> ...WARNING: could not set the given mode (-1)
> Setting r_mode -1 failed, falling back on r_mode 3
> Initializing OpenGL display
> ...setting mode 3: 640 480
> Available modes: '640x480 800x600 1024x768 848x480'
> Couldn't get a visual
> ...WARNING: could not set the given mode (3)
> ----- CL_Shutdown -----
> RE_Shutdown( 1 )
> -----------------------
> GLimp_Init() - could not load OpenGL subsystem
> If I use a libsdl.so built inside the target, or copied from another x86_64
> host, the 3D game can run fine.
> In RC2 testing, actually the libsdl.so is from another x86_64 host(we didn't
> recoginze that as there were 2 disks in the sugarbay host and we incorrectly
> thought both the libsdl.so files in the 2 disks were ok); in RC3 testing, we
> did use the file I built and found this bug...
> So this is not a regression from RC2 to RC3. Since the we haven't pushed the
> libsdl recipe change into poky's master or bernard branch, I think we can fix
> this bug after 1.0.
> BTW: I found another intersting thing: when switching between DRI and non-DRI,
> we need to restart X server: e.g., when we can run the 3D game, if we rename
> i965_dri.so to i965_dri.so.bak, restart the host, we'll find we can't run the
> 3D game with the same above error, and this time, even if we rename
> i965_dri.so.bak back to i965_dri.so, we still can't run the 3D game before
> restarting X server (or the host). This explains my previous strange experience
> about rebooting the host.

Comment 11 Jiajun Xu 2011-05-26 22:41:37 UTC

There is no libsdl.so in Yocto 1.1 M1 RC1 build, we need to add it into sugarbay image.

Comment 12 wenhua.fan 2011-06-23 20:38:29 UTC

In Yocto 1.1 20110617 build can not find libsdl.so, need to add it to sugarbay image.

Comment 13 wenhua.fan 2011-07-19 01:37:01 UTC

This issue still exist in Yocot 1.1 M2 RC3 build, which blocked the 3D testing.

Tree/Branch: Poky/1.1_M2
Poky Commit id: fa4bcfdb73167f8159b88e5a4d711c0d37627a70

Meta Branch: 1.1_M2
Meta Commit id: 738d2bc6d1a0d7ff6589000893c1c8b4f983d76f

Image location:
http://autobuilder02.yoctoproject.org/sugarbay-1.1_M2/nightly/20110717-4/machines/sugarbay/x86_32/core-image-sato-sdk-live-sugarbay-20110717092416.hddimg.bz2

Comment 14 Dexuan Cui 2011-08-17 09:28:16 UTC

I suppose this was fixed by 
http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=9939c3664e8cfa2ad0308958ad1281a71c35af00
http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=92b2e942e1e98492c73a7b888f00975c2423673a
http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=354bd05ee6139e821ec58d99b46dcaa868c911b9

Jiajun, please mark it RESOLVED.

Comment 15 Jiajun Xu 2011-08-17 18:26:04 UTC

(In reply to comment #14)
> I suppose this was fixed by 
> http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=9939c3664e8cfa2ad0308958ad1281a71c35af00
> http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=92b2e942e1e98492c73a7b888f00975c2423673a
> http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=354bd05ee6139e821ec58d99b46dcaa868c911b9
> Jiajun, please mark it RESOLVED.

Thanks, Dexuan.
The bug is fixed with above commit.

Comment 16 wenhua.fan 2011-08-19 03:59:58 UTC

Change the status to verified.

Commit information:

Tree/Branch: Poky/Master
Meta Branch: Master
Poky commit id: 978cdd5cb5b445f1cf406296444cb57cd8aa526a

Image location:

http://autobuilder02.yoctoproject.org/sugarbay-master/nightly/20110818-1/machines/sugarbay/x86_32/core-image-sato-sdk-sugarbay-20110818134503.hddimg.bz2

Comment 17 wenhua.fan 2011-08-19 04:34:01 UTC

Same as above commit information. Sorry about to change the status , since when ran the 3D game still couldn't find libsdl.so file. So change to REOPENED.

Comment 18 Jiajun Xu 2011-08-23 18:49:48 UTC

The bug should be fixed with following commit:
commit 5c78d94543c81f8e53e48ebc616ec729fa872533
Author: Jiajun Xu <jiajun.xu@intel.com>
Date:   Mon Aug 22 23:30:18 2011 +0800

    task-core-x11-sato: add libsdl into sato image

    We add libsdl into sato image since some 3D graphics testing needs it.

    (From OE-Core rev: 0934dc7c421ea6fb8f16ce535be72dda9ecb17de)

    Signed-off-by: Jiajun Xu <jiajun.xu@intel.com>
    Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>

commit 9a75040320ec12da1a08bbe88d11b8da089e4a2a
Author: Jiajun Xu <jiajun.xu@intel.com>
Date:   Mon Aug 22 23:29:07 2011 +0800

    libsdl: do not inherit nativesdk

    We already enable target version for libsdl and use BBCLASSEXTEND
    to enable nativesdk. No need to inherit nativesdk then.

    (From OE-Core rev: f3945cf1a9d33438afbcb28ee35edc10b9d047d9)

    Signed-off-by: Jiajun Xu <jiajun.xu@intel.com>
    Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>

Comment 19 wenhua.fan 2011-08-26 02:22:03 UTC

This issue fixed in Yocto1.1 20110824 build, and change the status to verified.

Commit information:

Tree/Branch: Poky/Master
Poky Commit id: 6c2b7beac3cd23ed44bd3e195c6360a0932876bf
Meta Branch: Master
Meta commit id: fb15cc4e1c4be75c81acaf6a1dd33675a9142975

Image location:
http://autobuilder02.yoctoproject.org/sugarbay-master/nightly/20110825-1/machines/sugarbay/x86_32/core-image-sato-sdk-sugarbay-20110825184435.hddimg.bz2