For a while now, I was not happy with the speed my Debian GNU/Linux booted. It was taking approximately 1:10 minutes to drop me in the GDM prompt. Today, I decided that I will try to probe into what exactly is happening. I have already heard of bootchart a few years ago. However I never had a chance to use it. So, I installed bootchart. I am not going to talk in detail about the installation. It is available in Debian and Ubuntu repositories. If you are using some other distribution, you can either find it in the repository or compile it from the source.
After installation, reboot the system and add 'init=/sbin/bootchartd' to the 'kernel' command line arguments in Grub. This will use bootchartd as init and bootstartd will in turn start the original init. If alternative init environment like init-ng is used, there might be additional arguments needed. Please consult the bootchartd man page for more information. Once the systems boots, the data collected is available in /var/log/bootchart.tgz. Run bootchart to generate bootchart.png from /var/log/bootchart.tgz.
After doing this, I figured out that udevadm is taking almost 30 seconds. I later figured out that the udev rule that tries to rename 'wlan0' to 'eth1' is the culprit (search on Google). Then I commented the 'eth1' line in /etc/udev/rules.d/70-persistent-net.rules, rebooted and did the bootchart thing again. I was happy to see that a portion of around 30 seconds is now removed from my boot time. That’s great!
| Before udev fix |
After udev fix |
|
|
I am using Lenovo Thinkpad T60 that has ATI Mobility Radeon X1300 on it. I run Debian GNU/Linux sid on my laptop. Even though I am not extensively using a lot of 3D applications on my laptop, I am forced to use AMD’s proprietary fglrx driver so that I can have my dual screen setup running with AMD’s big desktop. I have used NVIDIA’s proprietary driver on Linux three years ago. It was much better even three years back compared to the crippled fglrx driver that AMD distributes currently.
I am so much annoyed with the driver releases that AMD makes. I was so unhappy that fglrx driver didn’t have AIGLX support. This kept me away from Compiz that I was running on my old laptop in spite of the fact that I just had a mediocre Intel graphics adapter. Finally AMD added the much awaited AIGLX support in fglrx 8.42. However, I was not able to run Compiz using that driver on my box as there was a bug that made it crippled with XOrg 1.4. That is not all of it. Scrolling in most of the applications had become very slow. I can’t do anything but to wait for the next driver release where things would be fixed.
Then came the fglrx 8.43 release. I didn’t see a significant stuff in the driver apart from their change of version number. Now the driver is known as “ATI Catalyst” and the version number uses y.mm format. I got ATI Catalyst 7.11. They didn’t even care to fix the bug that crippled the driver with XOrg 1.4. The scrolling speed issue is not fixed as well. The first application to communicate with the driver would hang eternally till you kill it. Wait, that is not all! It also brings a shiny memory leak issue in the OpenGL applications. What now? Wait for the next ATI Catalyst.
Here comes ATI Catalyst 7.12. They have fixed OpenGL memory leak issue. But the XOrg 1.4, scrolling speed, first application to communicate to the driver still stays. I got an added bonus. This driver breaks the support for wide screen resolutions for certain displays. Well, I was the unfortunate. My Thinkpad can’t run 1400×1050 anymore with this driver. It fell back automatically to 1024×768. It looked horrible! I had no option than to switch back to 7.11 and wait for 8.1, where they will ‘Fix one; break two’ again.
Here are the few thoughts that came to my mind after this whole experience.
- I would never buy a ATI graphics card given the state of their Linux driver. I am planning to go for NVIDIA GeForce 8800 GT for the gaming PC that I would get assembled shortly. Can’t AMD realize that they are losing at least a bunch of customers because of their awful Linux driver?
- It is clear that AMD’s driver release follows Iterative approach with an iteration cycle close to 4/5 weeks. If AMD can’t either add significant stuff to the driver or test the driver thoroughly, why don’t they revisit the iteration cycle? It makes no sense to me to release a quick degrading versions. Each incremental release should evolve consistently.
- How many developers are working on the driver as of now? I guess it is one or maybe two. Does AMD find it difficult to hire developers for their Linux driver? I would expect that AMD should have atleast 4 developers dedicated to their driver development.
Xorg 7.3 is now available in Debian sid. I am using fglrx 8.40.4 for my ATI Mobility Radeon X1300. Looks like fglrx 8.40.4 works only with XFree86 4.3 and X.Org 6.7, 6.8, 6.9, 7.0, 7.1, 7.2. When I restarted my X after the upgrade, it failed to start with the following message.
(II) LoadModule: "fglrx"
(II) Loading /usr/lib/xorg/modules/drivers//fglrx_drv.so
(II) Module fglrx: vendor="FireGL - ATI Technologies Inc."
compiled for 7.1.0, module version = 8.39.4
Module class: X.Org Video Driver
ABI class: X.Org Video Driver, version 1.0
(EE) module ABI major version (1) doesn't match the server's version (2)
(II) UnloadModule: "fglrx"
(II) Unloading /usr/lib/xorg/modules/drivers//fglrx_drv.so
(EE) Failed to load module "fglrx" (module requirement mismatch, 0)
I can’t wait till I get updated driver from AMD. I have asked X to ignore ABI versions. If you are using gdm, edit /etc/gdm/gdm.conf to have the following lines at the end.
[server-Standard]
command=/usr/bin/X -audit 0 -ignoreABI
I have just upgraded to Gnome 2.20 in Debian sid. It just got released last Friday (Sep 21). Debian developers have impressed me this time with the speed they brought it to sid. Some packages are not yet available due to some dependencies and other usual stuff. The control center has gone through a major revamp. Looks like the new control center queries the X driver for DPI settings. Most of the X drivers still doesn’t report the DPI properly. Because of this, I was getting unusually huge fonts after my upgrade. To fix this, choose the DPI manually under “System -> Preferences -> Appearance -> Fonts -> Details”.
After a long break, today I planned to hang around on some of my favorite channels on IRC. I normally use xchat to do IRC. But this time, my xchat was replaced by xchat-gnome. It inherited all the settings from my previous xchat configuration. When I invoked xchat-gnome, it tried to use one of the proxy servers that I have configured before. I was wondering where xchat-gnome is picking up that proxy server setting from! It was not obeying the gnome proxy settings. It doesn’t have an UI to configure the proxy settings. It was a bit of strange behavior. When I searched about this problem, I found that xchat-gnome has proxy support. But there is no UI to configure the proxy. Here is how you do the proxy setup in xchat-gnome.
Most of the settings of xchat-gnome are stored as variables. It gives an option to edit the variables to configure various settings through the /set command. Here is the list of variables that are related to the proxy configuration.
net_proxy_auth - Toggle proxy authentication.
net_proxy_host - Proxy host to use.
net_proxy_pass - Password to use if proxy authentication is turned on.
net_proxy_port - Port to use for proxy host.
net_proxy_type - Type of proxy to use (0=disabled, 1=Wingate, 2=Socks4,
3=Socks5, 4=HTTP, 5=MS Proxy (ISA).
net_proxy_use - What to use proxies for (if set). (0=all, 1=IRC Only, 2=DCC Only).
net_proxy_user - Username to use if proxy authentication is turned on.
For instance, if you want don’t want to use any proxy, issue the command /set net_proxy_type 0.
More list of xchat-gnome configuration variables are available here.
Assume that you have done an accidental commit of a wrong version into the svn repository and wondering how to revert that commit, this tip is for you.
Let us take a case where one has committed a revision 543 of a file something.cc to the trunk and he discovers that the commit is an invalid one and he wants to revert to the revision 542. For most of the novice svn users, the command is not quite obvious. One should use svn merge to achieve this.
$ svn merge -r 543:542 http://your-svn-server/your-repository/trunk
U something.cc
$ svn stat
M something.cc
$ svn diff
...
# Verify if the change is reverted
...
$ svn commit -m "Undoing the wrong commit in revision 543"
Sending something.cc
Transmitting file data .
Committed revision 545.
Please note that you should use the svn URI in the svn merge instead of using your local path for that file. It also should be noted that the revision 543 would still live in the repository. You can’t make it to disappear as svn is designed not to lose any data. But the trunk is free of the buggy commit. It is not possible to achieve this using any other way like updating to the required revision and trying to commit it.
A dual monitor setup is supposed to increase the productivity of a person. I wanted to go for dual monitor setup on my Toshiba Satellite A80 laptop. The layout I wanted was to run the Laptop’s built-in LCD as my primary display sitting on my left side and a 21″ CRT monitor as my secondary display sitting on my right. My laptop’s LCD would run at 1024×768 and my CRT would run at 1600×1024. I am using Ubuntu Edgy on my laptop. My laptop uses Intel Mobile 915GM Express graphics controller. I decided to use Xinerama to achieve this.
(more…)
If one wants to check if a given thread or a process is alive in the system, here is the way of doing it. This code snippet is guaranteed to work on Linux NPTL threads. What we need as an input to this function is the tid (thread id) given by the kernel. You can get the tid of a thread by issuing gettid() system call. In case of a process, gettid() is going to return the pid (process id) of the process.
1
2
3
4
5
6
7
8
| bool
isalive( pid_t tid ) {
if ( 0 != kill( tid, 0 ) && ESRCH == errno ) {
/* The thread or process is not alive */
return false;
}
return true;
} |
It should be noted that just checking for the return value of kill() is not going to be sufficient as it is going to be -1 even if the thread or the process exists but the calling process has no permission to send signal to it (errno is set to EPERM).
People say that pthread_kill() could also used to achieve the same purpose. But I ran into issues when trying that approach. Also pthread_kill() approach can’t be used on processes. The kill() approach is uniform to both processes and threads. But one overhead in this approach is knowing or finding the tid of the thread of interest. Note that the tid used in kill() is not the pthread_t type but it is pid_t type.
I am right now working on an interesting requirement. We need to netboot a few diskless clients from a server that is running on GNU/Linux. A few clients would run GNU/Linux on then and a few will run Solaris on them. I am exploring about the possibility of netbooting multiple operating systems from the same server. I am sure that some could have tried this already. But there is no straight forward howto on this topic. One more challenge here is going to have Solaris to have it’s /root and /usr on a RAM disk instead of an NFS mount. The RAM disk would be a real big one like 512MB with all the essential software in it. We already have this setup for GNU/Linux clients. I have no idea how RAM disks are used with Solaris kernel. This is going to be an interesting experiment to carry out. You can soon expect an howto on this topic in my blog.
I have a server that is running Fedora Core 3. I was trying to setup SSH X forwarding to work on this server. The server had only a minimal set of required packages installed. I have added the line X11Forwarding yes to the file /etc/ssh/sshd_config and restarted the daemon. But even after that the DISPLAY variable was not setup in the ssh session when I invoked ssh with -X option. Because of this I was not able to get X forwarded through ssh. I was breaking my head to find out what was wrong. Finally I found out that the package xorg-x11-xauth was needed for SSH X forwarding to work properly. It was a tricky fact to observe on the first hand as there is no direct connection between these two packages. Thanks to Gentoo wiki for giving the clue.
