chrishowells.co.uk

Please note that this procedure is definitely not for those that have never wielded a spanner before; if you are in any doubt whatsoever consult a qualified mechanic. This procedure involves disassembling part of the suspension, which is absolutely safety critical. If you break it, it’s not my fault.

I recently did the 50k mile service on my 2007 Jetta and noticed that the wheel and suspension components were covered in grease. Closer inspection revealed that this was leaking out of the CV joint boot around the larger metal clip. The CV (Constant Velocity) joint transits drive from the engine to the wheels and has to deal with the fact that the wheels aren’t in a constant position due to moving around on the suspension. It consists of the joint itself, on the end of the drive shaft, which is covered in grease — with a large plastic boot over it to keep the grease in, and water and dirt out. The boot is kept in place with a small metal band at one end, and a large metal band at the other end.

(more…)

The pollen filter filters air coming from outside the cabin via the ventilation system. As it’s heavily used throughout the year, in winter for demisting the windscreen, and in the summer for running the air condition, it can get dirty quite quickly.

Faults that can arise from a dirty filter include bad smells, lack of air flow, windscreen misting up.

Removal and replacing of the pollen filter is very easy, and is done entirely from the cabin. The only tool that is needed is a T20 torx screwdriver.

The part number for my Jetta 2.0 FSI is 1K2 819 653 B and should be obtainable from the parts desk of the VW dealer for around £15; check with the dealer for the correct part if you’re not sure.

Start in the front passenger footwell by undoing the two plastic screws in the middle of the foam sheet.

You should now be able to remove the foam sheet by unhooking it at the front and pulling it out.

At the back there is a plastic cover over the pollen filter, slide it to the left (away from the centre console) to unhook it. (The stuff on the carpet is all debris that fell down after removing the plastic cover).

You should now be able to withdraw the pollen filter from above the location where the plastic cover was removed from.

Re-fitting is a simple reversal of the above.

A comparision of the old and new pollen filter (old at top, new at bottom). The old wasn’t too bad, it was last replaced around a year ago.

Whilst out walking in Snowdonia recently I noticed this pill box/bunker on the shore of Llyn Ogwen, Snowdonia – on the other side of the lake from Tryfan and the A5 road. It is located at OS grid ref SH 655 605 (latitude 53.125115, longitude -4.010738).

It is constructed from concrete  and stone, and was presumably fairly well camouflaged, with a layer of soil and grass/moss on the top.

(more…)

I run my own private Asterisk system for the house. This is in conjunction with a Linksys PAP2T (which is cheap, supports SIP, and you can plug two normal BT phones into), and Sipdroid running on my Android phone.

Although, this might sound a little over the top for a house, it does have a number of nice features. Like being able to make persistent nuisance callers go away.

As an example:

I edited /etc/asterisk/extensions.conf and found the section relating to my incoming call provider.


[draytel]
exten => xxx,1,Dial(SIP/chris&SIP/mobile&SIP/flat,25)
exten => xxx,n,Answer()
exten => xxx,n,Wait(1)
exten => xxx,n,VoiceMail(1001&1002)
exten => xxx,n,PlayBack(vm-goodbye)
exten => xxx,n,HangUp()


This code rings the two SIP extensions for 25 seconds, if there is no answer, answers the call, waits a second, before leaving the message in mailbox 1001 and 1002.

I modified it as follows:


[draytel]
exten => xxx,1,GotoIf($["${CALLERID(num)}" = "01252555029"]?monkeys,s,1)
exten => xxx,n,Dial(SIP/chris&SIP/mobile&SIP/flat,25)
exten => xxx,n,Answer()
exten => xxx,n,Wait(1)
exten => xxx,n,VoiceMail(1001&1002)
exten => xxx,n,PlayBack(vm-goodbye)
exten => xxx,n,HangUp()

You’ll also need to add the monkeys section:


[monkeys]
exten => s,1,ringing
exten => s,n,Wait(10)
exten => s,n,Playback(tt-monkeysintro)
exten => s,n,Playback(tt-monkeys)
exten => s,n,Playback(tt-monkeys)
exten => s,n,Playback(tt-monkeys)
exten => s,n,Playback(tt-monkeys)
exten => s,n,Playback(tt-monkeys)
exten => s,n,Playback(tt-monkeys)
exten => s,n,Playback(tt-monkeys)
exten => s,n,Playback(tt-monkeys)
exten => s,n,Playback(tt-monkeys)
exten => s,n,Playback(tt-monkeys)
exten => s,n,Playback(tt-monkeys)
exten => s,n,Playback(tt-monkeys)
exten => s,n,HangUp


This will ring the phone for 10 seconds, answer, and then play monkey noises, then hang up.

So, now, if the incoming caller ID matches “01252555029″, they are taken away by monkeys. The phone doesn’t even ring.

Bliss.

This morning just as I was leaving the house I looked into the garden. As well as yet more snow, I saw this beautiful fox. Standing there in the daylight in the open.

I grabbed my camera with the 17-85mm lens and managed to get a few shots before he wandered off again.

(more…)

Whilst waiting for my BeBox to arrive, I wanted to make use of the Thomson Speedtouch 516 that I bought a few years ago and has sat unused since then. Documentation on accomplishing this is unfortunately lacking from Be, and there is little in the way of informatoin on the members-only Be forum or the Be usergroup.

However,  it can be done.

Configuring the Speedtouch is a real pain for Be, as the Speedtouch only supports PPPoA or PPPoE as standard. However, Be use RFC 1483 bridging (aka EthoA). The 516 can support RFC 1483 bridging, but you need to upload a template to add the configuration options to the Speedtouch’s web interface. That, or figure ou the magic CLI runes which can be entered over telnet, but that is left as an excercise to the reader.

Thankfully, the nice people at another LLU ISP, ADSL24, have provided a  template which works perfectly with the Speedtouch and Be.

Just follow the instructions here to download the template, upload it to the Speedtouch, enter your Be IP, netmask and gateway, and away you sh
ould go :)

Unfortunately certain models of Gigabyte motherboards play very nasty tricks with your hard disks — entirely without your permission — by setting up Host Protected Areas. These unauthorised modifications to your hard disk can cause the loss of hundreds of Gigabytes of data. Personally I lost a 1.2TB RAID 0 array. [1]

I do not know which models of Gigabyte motherboards are affected but the Gigabyte GA-MA74GM-S2H certainly is; according to this post on opensolaris.org, the GA-G31M-S2L is also affected. If anybody else has experienced this, please post a comment.

The Host Protected Area means that a certain area of the disk is reserved. That’s not too bad on a disk that has never been used in another system. You lose a few tens of megabytes, which isn’t too significant on disks of hundreds of gigabytes. However, if the system has already been used in another system, and contains a partition table or is part of a RAID array, or LVM volume, your data will not be accessible and will essentially be lost.

I unfortunately discovered this problem myself when I upgraded my home Linux-based home fileserver. I upgraded from an Asus motherboard. I had four 300GB IDE disks that had been part of a RAID 0 array (yes, I know about the data loss implications of RAID 0; they’re acceptable for my use). I discovered that Linux’s md could not reassemble two of the disks back into the RAID array. The other two were fine — these were connected to a Promise IDE controller. As the disks were around four years old and had been on 24×7 for that time, I came to the conclusion — although unlikely — that both of the disks had died simultaneously.

Hindsight is a wonderful thing. Unfortunately I had never had any prior experience of Host Protected Areas. However, whilst debugging, I should have noticed the following:

hde: max request size: 512KiB
hde: Host Protected Area detected.
 current capacity is 586070255 sectors (300067 MB)
 native  capacity is 586072368 sectors (300069 MB)
hde: Host Protected Area disabled.
hde: 586072368 sectors (300069 MB) w/8192KiB Cache, CHS=36481/255/63, UDMA(100)
hde: cache flushes supported
 hde: hde1 hde2
hdg: max request size: 512KiB
hdg: Host Protected Area detected.
 current capacity is 586112591 sectors (300089 MB)
 native  capacity is 586114704 sectors (300090 MB)
hdg: Host Protected Area disabled.
hdg: 586114704 sectors (300090 MB) w/16384KiB Cache, CHS=36483/255/63, UDMA(100)
hdg: cache flushes supported
 hdg: hdg1 hdg2

Unfortunately the motherboard, without my permission, was denying md access to part of the disk, meaning that md could not assemble it into the RAID array. Data loss bugs are some of the the worst kind of bugs and I find this behaviour of this motherboard rude and entirely unacceptable.

For me, this wasn’t terrible. Most of the data was backed up to tape, and thus restorable, and what wasn’t, was easily replaceable. But I hope that this post helps someone that thinks that they have lost their data, and encourages Gigabyte to change the unacceptable behaviour of their motherboards.

[1] Sure, using RAID 0 dramatically increases the risk of data loss, and that was acceptable to me as it was personal use, not business critical, and I was happy with the possiblity of a disk dieing. I’m not happy with the fact that Gigabyte hardware behaves in unexpected and totally different ways to all of the (considerable quantity of) other hardware that I’ve used.

I’m trying to statically compile a Qt application. There are lots of google hits for instructions on doing this, but none of the instructions actually appear to be complete, or indeed work.

Configuring Qt with -static is the easy bit, I built Qt with the following options:


chris@thinky:~/qt-embedded-linux-opensource-src-4.4.3$ ./configure -embedded x86 -static -fast -no-exceptions -no-stl -no-accessibility -no-qt3support -no-xmlpatterns -no-phonon -no-phonon-backend -no-svg -no-webkit -no-sse -no-3dnow -no-sse2 -qt-zlib -qt-gif -qt-libtiff -qt-libpng -no-libmng -qt-libjpeg -no-openssl -no-nis -no-cups -no-iconv -no-dbus -no-freetype -qt-gfx-linuxfb -no-glib


Then as I already have Qt 4 installed on my system due to KDE, need to set $PATH to run the correct tools:


export PATH=/home/chris/qt-embedded-linux-opensource-src-4.4.3/bin:$PATH


I decided to modify the t1 example as a test, so I modified the t1.pro file, by adding ‘static’ to the CONFIG line


chris@thinky:~/qt-embedded-linux-opensource-src-4.4.3/examples/tutorials/tutorial/t1$ cat t1.pro
TEMPLATE = app
CONFIG += qt warn_on static
HEADERS =
SOURCES = main.cpp
TARGET = t1

chris@thinky:~/qt-embedded-linux-opensource-src-4.4.3/examples/tutorials/tutorial/t1$ qmake -config release
chris@thinky:~/qt-embedded-linux-opensource-src-4.4.3/examples/tutorials/tutorial/t1$ make clean && make
rm -f .obj/release-static-emb-x86/main.o
rm -f *~ core *.core
g++ -c -pipe -fno-exceptions -O2 -Wall -W -D_REENTRANT -DQT_NO_DEBUG -DQT_GUI_LIB -DQT_NETWORK_LIB -DQT_CORE_LIB -D_LARGEFILE64_SOURCE -D_LARGEFILE_SOURCE -I../../../../mkspecs/qws/linux-x86-g++ -I. -I../../../../include/QtCore -I../../../../include/QtCore -I../../../../include/QtNetwork -I../../../../include/QtNetwork -I../../../../include/QtGui -I../../../../include/QtGui -I../../../../include -I.moc/release-static-emb-x86 -I.uic/release-static-emb-x86 -o .obj/release-static-emb-x86/main.o main.cpp
g++ -fno-exceptions -Wl,-rpath,/usr/local/Trolltech/QtEmbedded-4.4.3/lib -Wl,-rpath,/usr/local/Trolltech/QtEmbedded-4.4.3/lib -o t1 .obj/release-static-emb-x86/main.o -L/home/chris/qt-embedded-linux-opensource-src-4.4.3/lib -lQtGui -L/home/chris/qt-embedded-linux-opensource-src-4.4.3/lib -lQtNetwork -lQtCore -lm -lrt -lpthread -ldl


However, the binary is still dynamically linked:


chris@thinky:~/qt-embedded-linux-opensource-src-4.4.3/examples/tutorials/tutorial/t1$ file t1
t1: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for GNU/Linux 2.6.8, dynamically linked (uses shared libs), not stripped
chris@thinky:~/qt-embedded-linux-opensource-src-4.4.3/examples/tutorials/tutorial/t1$ ldd t1
linux-gate.so.1 => (0xffffe000)
librt.so.1 => /lib/tls/i686/cmov/librt.so.1 (0xb7fb5000)
libpthread.so.0 => /lib/tls/i686/cmov/libpthread.so.0 (0xb7f9d000)
libdl.so.2 => /lib/tls/i686/cmov/libdl.so.2 (0xb7f98000)
libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0xb7ea5000)
libm.so.6 => /lib/tls/i686/cmov/libm.so.6 (0xb7e80000)
libgcc_s.so.1 => /lib/libgcc_s.so.1 (0xb7e75000)
libc.so.6 => /lib/tls/i686/cmov/libc.so.6 (0xb7d2b000)
/lib/ld-linux.so.2 (0xb7fdc000)


Google seems to be out of results, and I appear to be out of ideas, as does the official Qt documentation.

Speaking to a Qt developer (who shall rename nameless to preserve his sanity, although I appreciate his help :), you can configure qmake to make a fully static app by adding the following line to the qmake config:


QMAKE_LFLAGS += -static


After running qmake again, this leads to the following:


chris@thinky:~/qt-embedded-linux-opensource-src-4.4.3/examples/tutorials/tutorial/t1$ make
g++ -c -pipe -fno-exceptions -O2 -Wall -W -D_REENTRANT -DQT_NO_DEBUG -DQT_GUI_LIB -DQT_NETWORK_LIB -DQT_CORE_LIB -D_LARGEFILE64_SOURCE -D_LARGEFILE_SOURCE -I../../../../mkspecs/qws/linux-x86-g++ -I. -I../../../../include/QtCore -I../../../../include/QtCore -I../../../../include/QtNetwork -I../../../../include/QtNetwork -I../../../../include/QtGui -I../../../../include/QtGui -I../../../../include -I.moc/release-static-emb-x86 -I.uic/release-static-emb-x86 -o .obj/release-static-emb-x86/main.o main.cpp
g++ -fno-exceptions -static -Wl,-rpath,/usr/local/Trolltech/QtEmbedded-4.4.3/lib -Wl,-rpath,/usr/local/Trolltech/QtEmbedded-4.4.3/lib -o t1 .obj/release-static-emb-x86/main.o -L/home/chris/qt-embedded-linux-opensource-src-4.4.3/lib -lQtGui -L/home/chris/qt-embedded-linux-opensource-src-4.4.3/lib -lQtNetwork -lQtCore -lm -lrt -lpthread -ldl
/home/chris/qt-embedded-linux-opensource-src-4.4.3/lib/libQtCore.a(qlibrary_unix.o): In function `QLibraryPrivate::load_sys()':
qlibrary_unix.cpp:(.text+0x307): warning: Using 'dlopen' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking
/home/chris/qt-embedded-linux-opensource-src-4.4.3/lib/libQtCore.a(qfsfileengine_unix.o): In function `QFSFileEngine::owner(QAbstractFileEngine::FileOwner) const':
qfsfileengine_unix.cpp:(.text+0x838): warning: Using 'getgrgid_r' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking
qfsfileengine_unix.cpp:(.text+0x736): warning: Using 'getpwuid_r' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking
/home/chris/qt-embedded-linux-opensource-src-4.4.3/lib/libQtNetwork.a(qhostinfo_unix.o): In function `QHostInfoAgent::fromName(QString const&)':
qhostinfo_unix.cpp:(.text+0x30e): warning: Using 'getaddrinfo' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking


Not good. It turns out that linking statically to glibc is hard, because getXXbyYY such as getpwuid_r require NSS, which is a loadable module….

Next step is to try compiling Qt against uClibc.