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.
Created attachment 111 [details] openarena test error
Created attachment 112 [details] urbanterror test error
The Dynamic lib files are big so that I can not attach the zip file to attachments.
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.
(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.
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
(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...
(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.)
(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.
(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.
There is no libsdl.so in Yocto 1.1 M1 RC1 build, we need to add it into sugarbay image.
In Yocto 1.1 20110617 build can not find libsdl.so, need to add it to sugarbay image.
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
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.
(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.
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
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.
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>
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