glxgears shows blank window

I am trying to get opengl working on my Fedora 10 macbook (2,1). glxgears seems to be a good check for that.

The video card is:

00:02.1 Display controller: Intel Corporation Mobile 945GM/GMS/GME,
943/940GML Express Integrated Graphics Controller (rev 03)

I had xorg-x11-drv-i810-2.5.0-4.fc10.x86_64 installed. Yet whenevever I ran glxgears I saw blank screen.

I had to do some changes to my /etc/X11/xorg.conf, now the relevant sections look like:

Section "Device"
 Identifier  "Videocard0"
 Driver      "intel"
 Option      "NoAccel" "True"
 Option      "DRI" "True"
EndSection

I restarted x-server by logging back in and glxgears started showing the rotating gears.

[Note: after doing above changes I started seeing that my display would not refresh after some intervals. The work around I am using so far is, either relogin or change to text console terminal (ctrl+alt+F2) and switch back to graphical console (ctrl+alt+F1)]

Update:

I now realize what I have done. By setting 'NoAccel' to 'True' I have turned off the acceleration in hardware. Although this makes my opengl programs work, it means all the acceraltion is done in software - as is evident from the 90+% CPU during running of these programs. It also proves that the graphics card driver fails to accelerate graphics in hardware.

This is not a big issue for me, because I am using this setup just to develop some basic opengl programs. So I can live with the CPU hog.

Also by not loading the 'intel' Driver I seem to have fixed the screen freeze problem I mentioned above. Now my xorg.conf entry looks like this:

Section "Device"
   Identifier  "Videocard0"
   Option      "NoAccel" "True"
EndSection

segfault in libselinux

#0 0x00007f471e25281d in fini_context_translations () at setrans_client.c:211
#1 0x00007f471e2452ff in __do_global_dtors_aux () from /lib/libselinux.so.1
#2 0x0000000000413c80 in ?? ()
#3 0x00007fff2c6fade0 in ?? ()
#4 0x00007f471e2540c1 in _fini () from /lib/libselinux.so.1
#5 0x00007fff2c6fade0 in ?? ()
#6 0x00007f47244ed0e4 in ?? () from /lib64/ld-linux-x86-64.so.2
Backtrace stopped: previous frame inner to this frame (corrupt stack?)

After making some changes in my code I started getting this crash at the end of my application (during exit). No change that I made had anything to do with libselinux. I referred to this post a bit. Getting debug version of libselinux helped. But the above stack trace and the discussion in forum led me to believe this was some memory corruption that I had introduced. Running valgrind didn't help a lot.

After carefully going through all the changes, I figured out that I was now linking to the opengl library, although I hadn't enabled its use yet. When I commented it out, the crash went away. Probably the __fini__ routine of libgl was expecting some cleanup tasks from me.

freeglut Internal error

freeglut (): ERROR: Internal error <Visual with necessary capabilities not found> in function fgOpenWindow

Ran into this error while trying some opengl examples from the redbook. There are some obvious reasons for this error - like absence of 3D graphics card or driver support absent for glx. But that wasn't my case.

I could solve the problem just by replacing

glutInitDisplayMode (GLUT_SINGLE | GLUT_INDEX);

to

glutInitDisplayMode (GLUT_SINGLE | GLUT_RGBA);

Reference thread that helped.

scons on Maemo is old

On Maemo's latest Diablo SDK scons version is from 2004.

script: v0.96.1.D001, 2004/08/23

This breaks some scripts that would work on relatively recent scons installations.

Workaround: Install scons from source inside SDK. It's pure python code, so no architecture issues. But for some reason distutils will try to write to /scratchbox/tools/bin which has no write permissions from inside scratchbox.

So I installed inside my directory using --install-lib option of setup.py. But for scripts it would still try to write to /scratchbox/tools/bin I noticed this happens only for few executables inside scripts subdirectory. So I went outside scratchbox and 'su' copied them to those locations, chmod +x'ed them. Now they could be executed. Yet it reported that the engine was old, so I had to set SCONS_LIB_DIR to the installation in my home directory.

unable to set property `editable' of type `gboolean' ...

unable to set property `editable' of type `gboolean' from value of type `gchararray'

This happened when I misunderstood the parameters of TreeViewColumn->add_attribute() method. I was setting an 'editable' property to 1; whereas it should have been a boolean value.

X--tag=CC: command not found

autotool's idiosyncrasies!

delete ltmain.sh, run autoreconf. probably happens when the libtool version is newer and you are working with old autogenerated files.

Check this too:
http://www.mail-archive.com/libtool@gnu.org/msg10248.html

"configure" .pc files

"configure" might be a very good utility used while building from source code in many open-source softwares. But some of the errors it generates just leave you baffled if you don't know what it is. For instance when the script tells that so-n-so package is not installed, but you can see from your package manager that it IS installed, you wonder what might be wrong. On redhat systems the solution is to install -devel RPM of the package. This is because the configure script runs "/usr/bin/pkg-config --exists --print-errors " command. The pkg-config command will know of only those packages that have registered their ".pc" files with it. On redhat systems these .pc files come with -devel versions of various packages. So that solves the problem.

partition LABEL problem and making cp recurse infinitely

Today was an eventful day, in the sense that many problems got solved. The one I spent my whole morning on was a typical silly mistake of mine. Nothing interesting, just mis-reading my own past email.

When I was trying to get a domU up, I was getting a file system corruption error something, the one where the kernel give you Ctrl+D option and asks root password, so that you can fix the file system. I don't have the error message right now, but at the boot time it was doing "fsck.ext3 -a LABEL/1" and it was not finding any disk having this label. Some googling made me check my /etc/fstab. It showed a garbled line for swap drive. The line looked like:
"LABEL=bClsid<8d>Ôèÿÿÿvk swap swap defaults 0 0" (in vi)
"LABEL=bClsid�vk swap swap defaults 0 0" (in cat)

Such garbled text was enough to blame that line for my file system problem. So I thought on the lines of fixing its label. I found tune2fs -L , and set the label on my booting partition to this. But that didn't help. I also thought that this Label thing gets set if you make it a root device (as per my understanding. But now I understand having a partition as root means to have only its mount point as a root). Eventually one google result made me understand the problem. The first line of fstab was:
LABEL=/1 / ext3 defaults 1 1
So it was trying to fsck the root file system, but by assuming that it has LABEL=/1. So I just changed the line from LABEL=/1 to /dev/ and it all worked fine.

The other funny experience was with cp. Yesterday I was copying a whole partition of one build host to my desktop linux machine for running it as a domU. Today when checked I saw it had filled the whole of my 75G drive. To my amazement I saw that it was a /usr/bin/mh directory which had 'mh' directories recursively. After playing around for sometime, I found that mh was a link to '.' (to that directory itself). So I have witnessed that cp is dumb about such softlinks (at least only with the options I had tried -r and -p). It kept on copying the same directory instead of the symbolic link.

Re-setup of xen

After I screwed my laptop last week while installing Ubuntu Lite, I lost all my previous installation of Xen. So while rebuilding my laptop, I installed RH FC4, and now on weekend when I tried launching xen domUs, it started giving me mount errors.
"mount: error 6 mounting ext3"

I made one mistake. When you want to reproduce any working system, you should set all the parameters same as they were in your past working system and should not try anything new. I started to boot from LVM volumes this time, which I had never tried before. So it made me believe that the error was because of trying booting from LVMs.

But when I tried from another physical partition, which used to work before, I found it also giving same error.

I tried fsck'ing, reinstalling all file systems, and then deleted all the extra partitions and created and reinstalled RHFC4 again on them. Even this didn't solve the problem. At last as it turned out, the 'root' parameter in the xm config file had to be set to the drive from which I was eventually loading OS. I was using it as /dev/hda1 while my domU OS was being loaded from /dev/hda3. So changing this actually solved the problem, and I could boot my domU.

To my surprise, I had noticed this 'root' anomaly before, but changing it did not help that time. Now I don't recall, but it might had to do with LVM being installed on an extended partition at that time. I don't have any clue on this.

Anyway, now the field is clear for new experiments.

Why this blog?

I already have one blog titled 'My Frequency' then why put this blog?

My original intention for blogging was to document all kinds of new technical things I learn. Because hacking takes hell lot of effort in learning new things. But now that I have published that blog's link to all my friends, I don't like to bore them by posting debug information which most of them are uninterested in. Hence I am starting this blog which will hopefully serve my original purpose of blogging. The tile itself is enough warning of things to come.

Besides I don't want to keep my debug posts locally on my machine. This realization came to me when last week a Ubuntu Lite installer CD wiped my entire laptop clean with almost no warning. So I am keeping all my documets on internet from now on. That's the most reliable backup media I guess.

So keep 'tail' -ing this blog!!!

I hope to update this one more frequently.

Cheers!!!!