Scheduled Outage Notification

Hi guys,

The data center that resides is to be powered down for mains power works on Sunday 03/05/12 from approx 00:00 to 05:00.

This will mean all services hosted will be unavailable during this time.

The following will be impacted: (All services) (All services) (All services excluding * Statum 2 NTP server on

DNS will still be live due to secondary DNS servers being hosted outside of the Melbourne data center. will be powered down a little early for these works to ensure a clean shutdown before power is lost.

All going well, services should resume by 5am at the latest.

NOTE: All times are in AEST (UTC+10).

Noise on FXS ports using cheap TDM410P analogue cards

About a year ago I purchased a cheap TDM410P clone from eBay. The pricing was just too cheap to refuse.

To compare the pricing:

  • Digium Card with 2 x FXO, 2 x FXS = $637.78 USD + shipping
  • Chinese Card with 2 x FXO, 2 x FXS = $84.94 USD inc shipping

One good thing is that these cards work straight out of the box with the dahdi drivers. From my experience, the FXO ports seem to work perfectly. The FXS ports however gave me no end of trouble.

So finally I decided to spend some time on it to try and figure out what is going on. Now on the documentation, for using these cards in Australia, there is a opermode switch that is passed as the module is loaded (for me, in /etc/modprobe.d/dahdi.conf): options wctdm24xxp opermode=AUSTRALIA

What I noticed is that when this was set, the noise levels on the FXS ports was unacceptably high. It was almost at a point where it started to drown out the dialtone! Interestingly enough, this ONLY happens on the receive side and the person on the other end can hear you fine.

To cut a long story short, I played around with the options available and I came across this combination: options wctdm24xxp latency=6 companding=alaw

Now the noise is just about gone (I would swear it is CNG now) and the audio quality is much better than before. Oh - and before I forget, as this changes the impedance on the line etc, make sure you run fxotune again!

On a side note, I would love to see Digium produce a much cheaper card to compete with the chinese cards - as really, they are a victim of their own success in the home / hobby market. Maybe a suggestion could be to offer a card with no support - but a warranty service. Sadly, I've dealt with Digium before (yes, I actually own some completely useless G729 licenses!) so I'm not expecting much to happen.

Dropbox referrals

Hi all,

Well, I've started using Dropbox quite a lot now for my own syncing of stuff between PCs - as some are still on Windows XP - which doesn't have a great method of syncing documents.

One thing I'd love is to grab a bit more space! As they give you an extra 500Mb for referring people, if you don't have an account with Dropbox already, please use my referral link to sign up!

Night VFR Rating complete

Its been a while since I've posted about my aviation training... Last week I finally managed to get that wonderful sticker in the log book for my Night VFR rating. Held up for months after having issues with aircraft, and mixing that with the variable Melbourne weather - its finally complete.

That is all.

Xen 4.1.2-6 & kernel-xen- available

Another round of updates just pushed out. Some of the mirrors are still syncing so you may have to be a little patient.

NOTE: You will need to upgrade to kernel-xen-release 6-3 or above to get these updates.

Kernel changes: * Mon Feb 20 2012 Steven Haigh - kernel-xen- - Linux USB: ftdi_sio: fix initial baud rate USB: cp210x: do not map baud rates to B0 USB: serial: CP210x: Added USB-ID for the Link Instruments MSO-19 hwmon: (sht15) fix bad error code hwmon: (f71805f) Fix clamping of temperature limits USB: usbsevseg: fix max length usb: io_ti: Make edge_remove_sysfs_attrs the port_remove method. USB: cdc-wdm: updating desc->length must be protected by spin_lock USB: ftdi_sio: Add more identifiers USB: serial: ftdi additional IDs USB: ftdi_sio: add PID for TI XDS100v2 / BeagleBone A3 USB: ftdi_sio: fix TIOCSSERIAL baud_base handling dm: do not forward ioctls from logical volumes to the underlying device block: fail SCSI passthrough ioctls on partition devices Revert "ARM: 7220/1: mmc: mmci: Fixup error handling for dma" crypto: sha512 - reduce stack usage to safe number crypto: sha512 - make it work, undo percpu message schedule drm: Fix authentication kernel crash eCryptfs: Make truncate path killable ecryptfs: Improve metadata read failure logging eCryptfs: Sanitize write counts of /dev/ecryptfs

Xen changes: Thu Feb 02 2012 Michael Young - 4.1.2-6 - Fix buffer overflow in e1000 emulation for HVM guests [CVE-2012-0029]   Sat Jan 28 2012 Michael Young - 4.1.2-5 - Start building xen's ocaml libraries if appropriate unless --without ocaml was specified - add some backported patches from xen unstable (via Debian) for some ocaml tidying and fixes

Xen i386 kernel available for testing

After a monster effort of building kernels, the 32 bit version of my Xen Dom0 kernel is now available for testing.

Installation procedure is exactly the same as for x86_64. The howto can be followed here.

Bug reports are most welcome via the new mailing list.

As there are no changes to the x86_64 kernel, I have not bumped the version number for 64 bit builds. The build numbers will come back into sync when we go to kernel

Xen repo update and new gizmos

I've been doing a little work on the development and repo hosting side of things. We now have 5 mirrors around the globe mirroring these packages. Sadly, they don't always update at the same time - so today I've implemented a script to check each mirror hourly and either add or remove it from the mirror pool as they change into or out of sync.

This brings me to the next change. I've updated the kernel-xen-release package to revision 3 now. This uses the mirrorlist directive by default to take advantage of the script mentioned above to automatically exclude out of sync mirrors... This is a much more flexible system and will cause less errors as updates are pushed out to mirrors.

The third change is that I have now also build Xen for a 32 bit (i386) environment. I am still working on a kernel for this - so work is not yet complete - however the core hypervisor and associated tools as well as an updated bridge-utils package is also available for use on 32 bit systems. Once I get a successful kernel build, I'll be making it available via the 32 bit repo.

The fourth and final change today is the addition of the $basearch tag in all mirrors. This will allow compatibility with all systems I'd expect to see Xen packages for without having to change too may things manually.

The update to kernel-xen-release-6-3 should be pain free using yum -y update kernel-xen-release and you'll need to do this to be able to continue using the repo going forward.

Current kernel-xen conflicts - and why!?

I've made a number of changes to the kernel-xen repo today - and it will probably break a lot of things for everyone except new installs - however the pain is worth it... Here's why:

1) All RPM packages are now signed with a 4096 bit key. Now I've got mirror sites popping up its probably a good thing to sign them to ensure your safety and that they haven't been altered.

2) There are now 4 mirrors and counting for packages. This means you'll get faster downloads and upgrades in the future.

3) I don't have to roll out a new kernel-xen package for every update to the mirrors!

The problem?

Well, versions of kernel-xen older than contain the file we use to set the mirrors and contains all the repo config. At the beginning, this didn't matter - however as changes to mirrors happen, the only way to update each and every system with new mirrors is to roll a new kernel RPM! This is a bad thing.

To combat this, I've created a new package called kernel-xen-release. This contains the new GPG signature for the packages and also the repo config file /etc/yum.repos.d/kernel-xen.repo. This means changes to the mirrors can be done with a simple 10Kb update instead of the entire kernel.

Now, why it breaks:

You never want to UPGRADE a kernel RPM. Doing this would remove the running kernel from under your running system and replace it with the newer one. Generally, removing the running kernel is NASTY. However, this now causes an issue that if you have kernel-xen- installed, it will conflict with the new kernel-xen-release package!

At this stage, I can't figure out a workaround that will cause this to go smoothly for upgrades, so the only real fix I can think of right now is to remove all kernels at or below and manually install and kernel-xen-release. You'll also notice that kernel-xen-release requires yum-plugin-fastestmirror. This will make sure you get your updates from the fastest mirror around.

So in a nutshell, sorry for breaking your upgrade path! If I had thought ahead on how things would pan out, I would have split up the repo config from the kernel from day #1, but I didn't see it being as popular as it has been and requiring mirrors from around the world!

How to fix this?

Thankfully, its quite easy:

# wget

rpm -ivh --nodeps kernel-xen-

Edit /etc/grub.conf and set the default to, then reboot your system. Keep in mind you'll have to add the kernel line for xen.gz and modify the existing KERNEL and INITRD lines to MODULE.

After rebooting, erase the old kernels (anything older than and install the new kernel-xen-release package: # yum erase kernel-xen-

yum install