[Solved] libgles weird bug on Slackware


Linux-SWAT

Forum Addict!
Joined
Feb 13, 2010
Messages
9,171
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

  • dmesg.txt
    16.2 KB · Views: 705
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

  • dmesg-1.txt
    12.9 KB · Views: 286
  • dmesg-2.txt
    13.6 KB · Views: 513
  • dmesg-3.txt
    13.4 KB · Views: 685
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.
 
Have two potential culprits now.

More on this after a little investigations.
 
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