| home history interests Linux projects remarks mail |
Since almost three years I'm using Linux as my primary operating system and I'm very happy with it. It was a great help in my studies, it gave me a comfortable and stable way to develop and write my diploma thesis and mostly it gave me a lot of fun. In this time I also discovered some curiosities of Linux in special and computers in general that I want to share with the world.
On this page I mainly wanted to put some experiences and hints on configuring hard- and software for people who have the same (or similar) hardware that I have and use the same software that I use. Why? Because I had to realize that not all problems (for example: spontaneous strange system behaviour) can be solved with HOWTOS or the Usenet, because these problems were to special, that someone already had have experience with. Some of the things mentioned below took me a long time to fix and not seldom a bit of luck finally helped me to let them disappear. Primary, I hope that this page will be helpful for this small amount of people who have got the same trouble as I had and still stuck in it and secondary I hope this page will be a bit entertaining for all the others who know such kinds of problems and finally solved them somehow.
Some of the following topics and their solutions are 2 years old and some are brand new. And even if this page is totally outdated, the mentioned hardware has already moldered to dust and all the software flaws are extinguished for years, this will still be a funny little piece of Linux and hardware history.
Some time in January 2002: There it was, my brand new and shining EPOX 8KHA+ board with the best Athlon chipset at this time: the VIA KT266A. Together with a GeForce2 Ti and an Athlon XP 1700+ it should be the long awaited upgrade to my system. After plugging it all together I pushed the power button and after all of the new hardware was configured (the new graphics card, the on board sound etc.) everything worked properly. That means I thought it would work properly...
(Although this was a hardware only problem I decided to put it here because it was the worst problem I ever discovered.)
While running Linux everything worked fine and so fast. Kernel compilation was that awesome fast you did not have time to enjoy your usual "compilation coffee". X-acceleration was also very amazing with XFree86-4 and the new Nvidia drivers. On board sound worked also fine although it's quality - as expected - wasn't that impressive. After that I wanted to see all the new hardware performing in a resource consuming 3D computer game. So I booted my Windows(tm) partition, set up all the required drivers and started playing with all the optical sugar enabled. A few minutes later either everything froze or I got a clean system reboot. Until this point I really loved my new system but now the love started to fade away. I tried different games to make sure that it isn't the fault of a single game, but - earlier or later - the problem also appeared. Over days I tried all possible driver and BIOS option combinations imaginable (including RAM timings, BUS clocks, voltage etc.). Nothing helped. I read Nvidia, Windows(tm) and VIA FAQs and trouble guides, examined a lot of help boards but nothing worked. I've heard of the VIA south bridge bug but I thought it wouldn't be my problem because I didn't have a PCI sound card and no IDE problems and additionally a different south bridge than the one mentioned with the bug. So I did not care about. But after many days of unsuccessful experimenting I was depressed. As a last chance, although I did not believe in it, I disabled my on board sound and retried the test games. And this time I played and played and played. The problem had disappeared.
To make sure it was the sound who crashed my system and not a Windows VIA/Nvidia driver bug I re-enabled the sound, booted into Linux and did what I didn't before: I stressed my gfx card AND my sound card at the same time. After a while I experienced the same problem. So I went to the next hardware store, bought a cheap PCI sound card (that is supported by Linux, of course) plugged it in, disabled on board sound and configured the new noname sound card (with Fortemedia fm801 chip which led me into another trouble later on) under Windows(tm) and Linux. Now I played with sound without crashes or freezes. After a few hours of running different benchmarks and other stress tests for graphics card and sound card I was sure: the problem was solved. The hardware dealer I got my board from never heard of problems with the on board sound and offered me to check my board. I thankful refused his offer because now everything worked fine and I decided not to touch it anymore.
Since those days I never had problems again with my system. Now I can confirm what other people owning this board say: It's rock solid!
Afraid of the heat that a powerful Athlon can develop and because of the situation living in an apartment being directly under the roof of the house which causes temperature peeks of 30°C and more in the summertime, I wanted to monitor my system temperature.
Most of the existing tools depended on the lmsensors package which I decided to set up first before I would choose one of the funky windowmaker applets to tell me the current temperature. The problem was choosing the right kernel module. I knew I have a VT8233 south bridge with a W83697HF sensor and I knew from somewhere on the Internet that lmsensors works with it. But it was quite hard to find the final hint: I got to use the w83781d driver with 'insmod w83781d force_w83627hf=9191,0x290' to get it work. After this was done all of the applets I've tried worked perfectly and inform me every day about the health status of my system.
As I've already written I had trouble with my sound hardware. Unfortunately I configured my on board sound under Linux BEFORE I discovered that it mainly crashes my system under Windows(tm). Why 'unfortunately'? you may ask. Because it wasn't that easy and it took me three days to configure and a little while afterwards I had to disable it and won't use it anymore.
As I investigated the currently available Athlon-mainboards and their compatibility with Linux on the web I also read that even the on board sound of my Epox would work under Linux, if I use ALSA drivers. So I downloaded the current version 0.9b and started to configure. My 2.4.17 kernel I configured to use sound card support as a module, I did not load any other sound modules and I disabled oss. I built the required ALSA drivers and loaded them. So lsmod told me:
snd-card-via8233 5792 1
snd-seq-oss 22720 0 (unused)
snd-seq-midi-event 2792 0 [snd-seq-oss]
snd-seq 38828 2 [snd-seq-oss snd-seq-midi-event]
snd-seq-device 4144 0 [snd-seq-oss snd-seq]
snd-pcm-oss 44064 1
snd-mixer-oss 10688 0 [snd-pcm-oss]
snd-pcm 56128 0 [snd-card-via8233 snd-pcm-oss]
snd-timer 11360 0 [snd-seq snd-pcm]
snd-ac97-codec 24224 0 [snd-card-via8233]
snd 30728 0 [snd-card-via8233 snd-seq-oss snd-seq-midi-event
snd-seq snd-seq-device snd-pcm-oss snd-mixer-oss
snd-pcm snd-timer snd-ac97-codec]
./snddevices to create the device nodes, unmuted all channels, started xmms, loaded my favourite mp3, pushed the play button and listened...but as you might have already guessed: I've heard NOTHING! I experimented with the alsamixer but nothing changed. I hunted the web but all the hints I got I'd already tried. So after three days fortune finally kissed me. By trying the twohundredtwelvethousandfivehundretthirtyseventh mixer configuration I accidently muted the previously unmuted ADC/DAC loopback channel and pushed the play button of xmms. The boxes of my with the computer connected hifi system almost blew me out of my chair. After turning down the volume I saved my mixer configuration with alsactl store and enjoyed.
When I had solved my freeze/reboot problem I was confronted with another funny thing: my noname PCI sound card with fm801 chip. This one was also supported by ALSA and I cherished the illusion that loading the right module would have been all I had to do. I should have known better... The snd-fm801 module refused to load properly: »AC'97 resource busy« it reported instead. This was really strange. The chip has already been supported for a long time and it never caused any trouble. Again I tried everything: I read the source to figure out what exactly went wrong but it didn't help me, I read all the ALSA FAQs and help materials available without success. Then I was again a lucky boy...
I found a newsgroup message which dealt exactly with my problem. Someone had have trouble with his fm801 and the latest ALSA drivers although his card worked fine with the old drivers. I punched my hand against my forehead with the words: Why the hell didn't you try an old version of the driver? The situation was extremely funny because the old 0.5.12a drivers already existed on my harddisk for about a month because they had been the first drivers I've tried with my on board sound before I recognised that they did not support the VT8233. This version of ALSA worked completely unproblematic and is still the one I use today.
(One word at the beginning: I've never tried to enable the remote control under Linux and I think I never will.)
My problem with this card was to get some sound (seems that I always have problems with the sound). I discovered the same silence under Windows(tm) when I used another TV application than the one that came with the card. Selecting the right tuner from the list solved the problem. Choosing the same tuner under Linux didn't break the silence. So I inspected the tuner options of my alternative Windows(tm) application and found what I'm looking for. The solution was to initialise the PLL at the beginning. Under Linux I used 'insmod bttv card=11 tuner=5 pll=1 radio=0' and everything worked fine.
This phenomenon (which is again completely independent from Linux and hardware related only) I discovered 3 times until today. The first contact was 5 or 6 years ago. A friend of mine asked me if I could help him building up a computer using second hand hardware. In those days I worked together with another friend in a company that dealt among other things with computers and software for special purposes. So it was quite easy to organise second hand hardware while keeping the prize very attractive. After plugging it all together I installed the operating system and some basic software. After that the final check of the system was not satisfying. That means: It drove me crazy! The system crashed spontaneously. I used an socket 7 board with VX chipset, an AMD K6 processor two 16 MB EDO DIMMs, an 2.1 GB IDE hard disk, an old SVGA graphics card and an ancient soundblaster. I tried different BIOS options and driver configurations, changed graphics card, sound card and processor but nothing worked. The board and the memory had already been tested before and they worked fine. No one in the company had another idea or hint for me. So I was completely perplex. At the end I thought I must have damaged the board or memory while installing and so I tried two 8 MB DIMMs instead of the two 16 MB DIMMs and suddenly the system run stable. I additionally plugged the two 16 MBs in and the system remained stable. So I investigated that the two 8 MB RAMs had been older and slower than the 16 MB EDOs and that must be the reason they worked.
The second contact I had 2 years ago. A friend of mine asked me if I could build in his new PCI sound card and install his new Windows98(tm) because he never did it before. As I plugged in the sound card he asked me if I could remove his old FP2 memory because it would slow down his machine. Among this 16 MB of FP2 memory he had also 64 MB of EDO RAM installed and it would be enough for him, he said. So I did it, because at this time I didn't remember the trouble I had with an old socket 7 system like his and its memory. But as you might guess I will be painfully reminded of this experience. The first time the system crashed while installing the OS. This sometimes happens, so I retried. This time the system crashed when I tried to install M$ Office. The next time it crashed while opening Outlook. It was awfully unstable. So I thought: Either the new sound card or Windows98(tm): One of them must cause the trouble. So I retried it without the sound card and with Windows95(tm) again but it did not help. While sitting depressed at my friends desk I looked around in his room to find some help. On his shelf laid the removed FP2 RAM. At this moment I remembered the situation from years before. I re-plugged the FP2 RAM and from this time the system was stable again.
My latest contact with the problem was with the old socket 7 board of my girlfriend. She got my old system because I got a new Athlon as you can read above. After removing the lower 16 MB of RAM to empower my printer, the system showed some stability problems. Under Linux I discovered some unexpected segmentation faults. This time I should have known from the very first second what exactly the problem was, but I didn't. This was the first time I discovered this problem under Linux. So my first thought was that the old and damaged harddisk would cause the trouble by a corrupted swap partition because the kswapd crashed sometimes. But then the kernel itself started to refuse its work with a "kernel panic" message. Then I knew it was the memory again. But my printer was so happy with his new gained memory, it broke my heart to take it away from him. So I tweaked the RAM timings of the computers BIOS to handle the memory as slow as possible. Now the time of crashes isn't over, but they have almost disappeared. So the system is almost stable. But if I get some old 8 MB EDOs again I will plug them in immediately.
I think it was in July of the year 2002 when a friend of mine asked me to get more redundancy in the computer system of the company owned by his dad. Half a year before we'd already installed a Linux gateway and mail server for the intranet of this company together. My friend has the job of being the sys admin for this Windows(tm) LAN. This year he started studying computer science and so he wanted some kind of redundancy for the Linux box because his greatest fear was that some hardware failure could break the Internet connection (which is very essential for the company) when he is not available.
So some online search led me to the page of the High-Availability Linux Project. It seemed to be exactly what we have needed: Two Linux boxes melted together to one virtual server with IP address takeover and LAN mirroring. Somewhen in August we met and first started to assemble two working Pentium systems (with 2 harddisks and three ethernet cards each) out of a box of second hand hardware of unknown state. After two days, one broken ethernet card, two kaputt cdrom drives, a damaged board, a malicious floppy drive and lots of lost nerves both systems finally run Debian. But the actual work has still to be done...
The next day we connected both machines to form up one cluster and started to configure the LAN mirroring via drbd. Although this project was open source it had commercial support which resulted in minimal free documentation. The first problem was that there were no information available about required parameters for the creation of the necessary device nodes. While trial and error didn't lead to the requested success, examining the source code helped. With 'mknod /dev/nb0 b 43 1' the kernel module finally accepted the device. After that everything seemed to work. File systems and config files had been set up correctly and both secondary harddisks of the machines successfully synchronised. Copying one file to the right place on one machine resulted in mirroring this file to the other machine. So I started to test the inverse mirroring and the data takeover in the case the master comes up again. At this point trouble started... There were several bad blocks on the second hard disk of the master which lead to never ending synchronising tries and retries and re-retries. Even after reformatting both secondary harddisks and reinitialising drbd the problem remained: They could not be synced. Totally frustrated, after many lost hours we gave it up.
The next morning we started with the IP address takeover via the heartbeat package. This worked fine for the LAN interface but did not operate due the lack of real IP addresses for the outer interface. We asked the ISP for getting two more real IP addresses. The answer was clear and unmistakable: No! We had to get along with only one IP number. Theoretically this is also possible but not supported by the heartbeat package. So our redundancy project seemed to fail completely. Depressed of our failure and due the lack of time we decided to leave the current Linux box untouched and only made some new backups. I planned to take the cluster with me to retry it at home a few days later.
At home I put the machines in a corner and did not look at them for a day. Then I integrated them into my two home LANs to test the inner (companys intranet) and outer (companys ISP) interface. Target was to mount the outer interface only by the currently active machine of the cluster. In the case of the failure of the active machine (master) the other computer would mount its outer interface on the same subnet with the masters IP address and send an gratious arp request to tell the ISPs gateway the new MAC address. A similar job does the heartbeat package (but with 3 real IP addresses and permanently mounted network interfaces of both machines on the same subnet) for the inner interface. In my testing environment at home this worked fine. The script for bringing up the outer interface is started from the heartbeat services startup script '/etc/ha.d/haresources' and looks like this:
#!/bin/sh
#
# config/drop outer network interface.
# Heiko Lippmann august 2002
ADR=192.168.2.50 # IP address of the outer interface
ADRMAC=??:??:??:??:??:?? # MAC address of the network card
MASK=255.255.255.0 # netmask of the subnet
GATEWAY=192.168.2.1 # IP address of the gateway
GATEMAC=??:??:??:??:??:?? # MAC address of the gateway
case "$1" in
start)
echo -n "Setting up outer network interface:"
echo -n " eth0"
/sbin/ifconfig eth0 $ADR netmask $MASK up
/sbin/route add default gw $GATEWAY
/usr/lib/heartbeat/send_arp eth0 $ADR $ADRMAC $GATEWAY $GATEMAC
echo "."
;;
stop)
echo -n "Dropping outer network interface:"
echo -n " eth0"
/sbin/ifconfig eth0 down
echo "."
;;
reload)
echo -n "Resetting outer network interface:"
echo -n " eth0"
/sbin/ifconfig eth0 down
/sbin/ifconfig eth0 $ADR netmask $MASK up
/sbin/route add default gw $GATEWAY
/usr/lib/heartbeat/send_arp eth0 $ADR $ADRMAC $GATEWAY $GATEMAC
echo "."
;;
force-reload)
$0 reload
;;
restart)
$0 reload
;;
*)
echo "Usage: worldif {start|stop|reload|restart}"
exit 1
;;
esac
exit 0
It's simply started as the first service in the haresources script. After figuring out the right heartbeat timeouts I set up a firewall, installed and configured the mail server and caching proxy and tested the whole thing. Everything worked fine. Even stressful portscans on the outer interface didn't disturb the heartbeat. That's important, because a disturbed heartbeat could result in some unwanted alternating IP address takeover. But this problem did not occur. If one node failed the other one came up, sent me an email about the failure and all necessary services had been available again. But at this point there were no mirroring at all. "This will be a task for tomorrow", I thought, unplugged the power cable of one node and enjoyed watching the cluster operating. (Yes, I did this very often and it pleased me again and again. ;-) )
The last chapter of this little story tells about the realisation of the LAN mirroring. Because of my bad experiences with drbd I decided to not touch it again. After reading the documentation of heartbeat again I found the file rsync.html which described the heartbeat package in cooperation with rsync. After some calculations I decided that this technique would be sufficient for our demands. So I configured and tested it and it operated satisfying.
After further successful tests I mailed my friend that the cluster works and we arranged an installation date in the company. After adjusting the IP and MAC addresses we did some successful real life tests and replaced the old Linux box with the cluster. Today (touch wood and keep fingers crossed) both nodes of the cluster are still up and running.
Most of the stories I've told until now were related to Linux in general. Now I'll tell you about some Debian specific problems I had to get along with. Notice: Although I use Debian for about two years now the following problems are the only ones I discovered, that could not be solved easily. I suppose Debian to be the most flexible and most robust distribution available at the moment.
It was a usual day. I switched on my gateway and desktop computer and logged in. I opened a ssh session to my gateway and started to check for security updates. Apt-get told me that there's an update for the ssh package available. After downloading and unpacking, the package is usually set up. But this time apt-get exited with an error code. So I started to reinstall the package by hand. The same error occurred. I can't remember the exact message but something in the Question.pm module couldn't be initialised because it was a template or had no template, I don't know. This error message appeared from this time for each new or updated package that needed some user interaction during set up, because debconf uses it for questioning. Reinstalling the debconf package was the only thing that helped. After this the problem was solved. That means: solved for the moment. As I did an distro upgrade from potato to woody a few weeks ago, the error appeared again. So I had to install critical packages by hand before deselect could do the rest. Updating ssh over a ssh link is unhesitating so until today I really don't know what had happened.
To minimise my Internet traffic when checking for security updates I use apt-get through wwwoffle from all machines of my little LAN. This worked fine for a several period of time but since the woody upgrade of my gateway some unwanted behaviour occurs from time to time. Although the packages files on ftp.de.debian.org did not change since my last download, apt-get downloads them again. But not always and not all of them. I tried to access the debian mirror by ftp and http and realized that by ftp all packages files are always downloaded and via http just some are sometimes downloaded. The other sources in /etc/apt/sources.list (all of them accessed via http because they are http sources) are processed correctly. Only newer files will be downloaded. Solution: I don't know. I did not solve the problem yet, I live with it.
Some time in summer 2002 I got a DVD drive from Relisys and wanted to use it additionally to its main function of being a data drive as a DVD player for the living room. Because my computer lives in the bedroom next door to the living room, the idea was to activate the TV-out of my GeForce 2 and connect it via a long cable to the TV-set by tunnelling through the wall. This worked very well with a S-VHS to scart cable and the 'nvtv' command.
Now I needed a powerful player. My search led me to MPlayer, which I can fully recommend. After compiling and installing, the first run wasn't very satisfying. The playback was a little sluggish, the speech was not in sync with the movement of the actors lips and sometimes you saw when the picture was rendered. So I experimented with the options and recognised, that a very large cache, a small audio delay and the 'xv' video output driver work best for me.
But I wanted more! After starting MPlayer I wanted the window to be perfectly placed to see the movie centred on the TV-screen without any manual interaction. Therefore I had to patch the source of the 'xv' driver because no option for placing the window at a special position on the screen was available. Additionally the borders of my MPlayer window should be small enough to be invisible on the TV-screen. I decided to realize this by simply switching the window manager theme on startup. To do all of this and more I use this little bash script:
#!/bin/sh
# activate tv out and invoke mplayer
# usage: playdvd <OPTION>
#
# note: all the display options are for running this
# script remote via telnet
#
# Heiko Lippmann 2002
usage () {
echo "Usage: $0 [<OPTION>]"
echo " --help show help"
echo " -t <num> play title <num>"
echo " -al <code> play language <code>"
echo " -ai <code> audio id <code>"
echo " -sl <code> show subtitles <code>"
}
OPTIONS="-softsleep -quiet -cache 64000 -delay -0.15 -vo xv -aspect 4:3 -display :0.0"
TITLE="1"
AID=""
ALANG="de"
SLANG=""
while [ $# != 0 ]
do
case "$1" in
-al*) ALANG="$2" ;;
-ai*) AID="$2" ;;
-sl*) SLANG="$2" ;;
-t*) TITLE="$2" ;;
--help) usage; exit 0 ;;
-*) echo $"Unrecognised option: $1" >&2
usage >&2; exit 1 ;;
*) break ;;
esac
shift
shift
done
scp /usr/share/blackbox/styles/noborder root@localhost:/usr/share/blackbox/styles/myblackmagic
killall -HUP blackbox
echo -n "Playing DVD Title $TITLE in $ALANG language "
if [ -z "$SLANG" ]; then echo "with no subtitles...";
else echo "with $SLANG subtitles...";
fi
echo ""
ssh root@localhost nvtv -t -r 768,576 -s Large
killall -STOP xscreensaver
xset -display :0.0 -dpms s off
amixer set PCM 100%
if [ -z "$SLANG" ]; then
if [ -z "$AID" ]; then mplayer $OPTIONS -dvd $TITLE -alang $ALANG;
else mplayer $OPTIONS -dvd $TITLE -alang $ALANG -aid $AID; fi
else
if [ -z "$AID" ]; then mplayer $OPTIONS -dvd $TITLE -alang $ALANG -slang $SLANG;
else mplayer $OPTIONS -dvd $TITLE -alang $ALANG -slang $SLANG -aid $AID; fi
fi
scp /usr/share/blackbox/styles/myblackmagic.orig root@localhost:/usr/share/blackbox/styles/myblackmagic
killall -HUP blackbox
killall -CONT xscreensaver
xset -display :0.0 -dpms s on
ssh root@localhost /usr/sbin/alsactl restore
ssh root@localhost nvtv -m
To avoid walking to the the neighbour room I configured my old i386SX-laptop to act as a remote control for my DVD machine via ppp over a nullmodem cable. This has two advantages: 1.) The laptop comes with completely no fans and that's why it's very silent. 2.) The laptop is easier to carry from the bedroom to the living room than my noisy Athlon tower. ;-)