[Solved] libgles weird bug on Slackware


Linux-SWAT

Forum Addict!
Joined
Feb 13, 2010
Messages
9,195
Hi !

I've updated libgles-omap3_4.00.00.01-r3.5 to libgles-omap3_4.00.00.01-r7.5, converting the ipk, and now i can't launch gles apps on my 1GHz unit, works on CC.

Any idea ?
 
Last edited by a moderator:
Update.

Seems it's more a totally random behavior. Sometimes it works, sometimes it doesn't.
 
Ok.

Now i'm rebuilding an image with the old 3.5 i used until now.

After some tests (downgrading the package didn't work), i want to ensure that the problem really come from this update.
 
As i'm on a stable release now and have less time than ever, i keep experiments away...
 
A little update:

So i have the exact same problem. It works once, and after a reboot, nada.

No i will check my build system to see which parts are taken from the Zaxxon rootfs. This 3d part is a mix of ipk and Zaxxon copy/paste.

BTW here's the dmesg:

pvr-init start reports no error, modules are loaded.
 

Attachments

Last edited by a moderator:
This is soooo weird !

All is working until i swap the card from the CC to the 1GHz, or the contrary.

Then gles contexts can't be created whatever Pandora i use.

This can be a very old unnoticed bug

dmesg1 on 1GHz gles working

dmesg2 on CC gles not working

dmesg3 on 1GHz gles not working

lsmod, pvr-init seems ok.
 

Attachments

Last edited by a moderator:
Update:

Seems it's not linked to the card swap, after a few reboots on the same machine, gles stopped working.
 
Have you tried it with another Kernel? Maybe a Kernel Bug.

Is on OP a newer Kernel as that what you use actualy?
 
have you copied contents of /usr/bin/ES* /usr/lib/ES* from zaxxon's rootfs?
I took the libgles-omap3_4.00.00.01-r7.5_armv7a.ipk from the pandora update repo, and created a Slackware package with it.

The old i was using since my first 13.37 release, the 3.5 was taken from Angstrom repo, and it appears to lead to the same problem.

I use the same 3.2.30 kernel. I copied it from it's first release.

I didn't do many modifications since the last working releases.

What is driving me nuts is the change from working to non-working with a few reboots.
 
No idea then, your kernel logs look good so probably something is messing up the libs or their symlinks. Also check if /etc/powervr* files are ok.
 
Last edited by a moderator:
/etc/powervr-esrev and /etc/powervr.ini are looking fine.

I've reinstalled the libgles* package inside the broken distro, no effect, avoided recent patches, no effect, rebooted on another kernel, no effect...

I'll try on another SD just in case.
 
This is what i did for MHz detection, rc.local:


#1GHz unit detected
if [ "$GPUCLOCK" == 400 ]
then
rm /etc/pandora/conf/cpu.conf
ln -s /etc/pandora/conf/1000.conf /etc/pandora/conf/cpu.conf
fi

#600MHz unit detected
if [ "$GPUCLOCK" == 332 ]
then
rm /etc/pandora/conf/cpu.conf
ln -s /etc/pandora/conf/600.conf /etc/pandora/conf/cpu.conf
fi

and rc.local_shutdown:


#1GHz unit detected
if [ "$GPUCLOCK" == 400 ]
then
cp /etc/pandora/conf/cpu.conf /etc/pandora/conf/1000.conf
fi

#600MHz unit detected
if [ "$GPUCLOCK" == 332 ]
then
cp /etc/pandora/conf/cpu.conf /etc/pandora/conf/600.conf
fi

Now, when i comment the rm, cp and ln in each files, the problem disappears on 1GHz unit, but still the same on CC units: gles works at first boot, then stop working after a few reboots.

Are the cpu settings and pvr-things linked in any way ?
 
Last edited by a moderator:
Back
Top