Posts Tagged ‘hardware’

Buggy motherboards

Monday, September 25th, 2006

I’d love to know how large motherboard manufacturers manage to produce buggy boards. Just as we’re putting two new servers into production at work, I discover an annoying problem: if there is a sustained data transfer over the network for about 10 minutes, the systems reboot. No warning, no error messages, just a reboot. Having poked around I discovered that changing the kernel’s interrupt timer frequency (i.e. setting how often Linux checks for interrupts) changes the amount of time it takes for the system to reboot during data transfer. Set to 100Hz, the system reboots immediately as soon as the transfer is started. At 250Hz, you get a few seconds before the reboot. At 1000Hz (the default), you get 5-10 minutes. So knowing that the problem was related to interrupts, I suspected it may be the APIC on the motherboard at fault, as it seems relatively common for motherboard manufacturers to stuff it up.

So I went into the BIOS and disabled the APIC (after first having to disable hyperthreading), rebooted and alas all is well: no more reboots.
My theory about the exact cause of the problem is that for some reason interrupts were being generated faster than the OS could handle them, possibly due to spurious interrupts being generated at the APIC. Interrupt controllers receive interrupts from components within the system and essentially queue them. Then at a pre-defined interval (between 100-1000Hz on Linux, 100Hz on Windows) the OS checks for interrupts, acknowledges them (causing the interrupt controller to remove them from the queue) then goes away to handle them. I believe that so many interrupts were being generated that the interrupt controller’s queue was getting full. When this happens the motherboard logic says ‘bloody hell this shouldn’t happen and I can’t recover from it’ and reboots the machine.

So if you are the unlucky owner of a Supermicro P4SCT+ motherboard, beware!

Server Problems

Monday, May 15th, 2006

I’ve been having some major server problems over the last few days, which basically involved my ultra-stable-with-an-uptime-of-over-250-days (since the last power failure) server having kernel oopses and crashing hard. As a result the site has been inaccessible at various points over the last few days and more importantly, all e-mail sent to me has been bouncing since I’m foolish enough to host my own mail server off my ADSL line without a working backup MX (I had a backup MX, but they’d kindly changed their mail server IP address and not told me, so everything was bouncing).

All it actually was was overheating caused by the CPU fan running very slowly and one of the two PSU fans having stopped completely. Why, oh why must computers use these rubbish little fans which last about 6 months if you’re lucky?

Sigh.

Anyway, the problem should now be fixed (until next time) so if you tried to send me mail and it bounced, please send it again. Ta!

The Linksys NSLU2

Thursday, December 29th, 2005

My Linksys NSLU2One of the things I got for Christmas this year was a Linksys NSLU2. It’s basically a device for attaching USB hard disks to for network attached storage (only accessible via SMB, aka Windows networking). So it’s basically a box with two USB 2.0 ports and a network interface. Not very interesting, eh? Well no, not until you realise that it runs Linux :-)

It’s actually quite easy to replace Linksys’ version of Linux with one that is accessible via SSH (a distro called OpenSlug) which makes it possible to install extra packages etc., then from there to get Debian (actually OpenDebianSlug) running on it!

So now I have a nice, silent Debian system. For some reason Linksys ship the device with the processor under-clocked, but it just requires a little targetted destruction to get it back to it’s original 266MHz. OK so that isn’t going to break any speed records, but it doesn’t mean that the device isn’t useful – far from it. People are using them for web servers, mail servers, Asterisk PBXs and iTunes servers. Should be fast enough for most simple tasks:

tiny:/home/user# cat /proc/cpuinfo
Processor : XScale-IXP42x Family rev 1 (v5b)
BogoMIPS : 263.78
Features : swp half thumb fastmult edsp
CPU implementer : 0×69
CPU architecture: 5TE
CPU variant : 0×0
CPU part : 0×41f
CPU revision : 1
Cache type : undefined 5
Cache clean : undefined 5
Cache lockdown : undefined 5
Cache format : Harvard
I size : 32768
I assoc : 32
I line length : 32
I sets : 32
D size : 32768
D assoc : 32
D line length : 32
D sets : 32

Hardware : Linksys NSLU2
Revision : 0000
Serial : 0000000000000000

So far I’ve installed an NFS server so I can actually use the device for network storage without having to mess with Samba. I’ve also bought a cheap USB webcam so I can experiment with having an Internet-connected webcam, possibly with streaming video. The possible uses for a silent Linux system with USB ports are almost endless…

A tip for Buffalo WYR-G54 owners

Monday, September 26th, 2005

The Buffalo WYR-G54 is a wireless router which eBuyer (probably others too) are selling really cheaply at the moment. Something many people (myself included) like to do with wireless networks is disable SSID broadcasts; this makes the network more difficult for people to detect unless they already know the SSID (no, security through obscurity is never the answer, but it helps).

In the manual there is a screenshot showing an “enable SSID broadcast” option. This option actually doesn’t exist either in the original firmware I got with my router or in the latest firmware. However, it is still possible to disable SSID broadcasts with a bit of effort:

  1. Use the web interface to save the router settings to a file
  2. Open the file (admcfg.cfg) and look for the ‘[533004:Broadcast SSID]‘ option (near the bottom)
  3. Simply change ‘yes’ to ‘no’
  4. Use the web interface to restore the settings from the file you just edited
  5. The router reboots and that’s it: no more SSID broadcast

Quite why Buffalo felt the need to remove the option from the web interface I can’t imagine…

While I’m moaning about Buffalo, I’ll also mention the fact that the web server on the device can’t cope with browsers that implement HTTP pipelining (this includes Mozilla & Firefox at least). While it basically works, pages take AGES to load, you end up with the server serving files other than the ones requested and you have to re-start the browser after you’ve done a form POST before the server will talk to you again. I dream of the day that people who only test their products with IE will get what’s coming to them…

But for £29.34 I guess I shouldn’t really complain too loudly…

Whinging about wireless

Thursday, August 25th, 2005

It never ceases to amaze me how long it can still take to get something as simple as a wireless card working under Linux. Today I got a super-cheap Safecom SWLC-54108 54Mbit card to replace my old Netgear MA401 11Mbit card, which plugs-and-plays in Linux. The new card, predictably, wasn’t quite so easy to get going. In fact, it took 5 hours of messing about. That’s right: 5 hours to get a wireless network card working.

The card is based on the acx111 chipset which is supported by the acx100 driver. I’ll go through the steps I took to get it working under Kubuntu Breezy (should be the same process for other distros too), to hopefully save someone else 5 hours of their life. This process should also apply to the PCI & USB versions of the card.

The first step is to download a CVS snapshot of the acx100 driver. But don’t get the latest one, as this won’t work. After lots of trial-and-error I got the card working reliably using the 20050810 snapshot (others may work, but I haven’t tried them).
This now needs to be compiled – follow the instructions in the README for building-out-of-tree (or in-tree if you prefer, but out-of-tree is easier), ensuring you have your kernel headers or source available. If you’re building in-tree do modules_install else copy the modules (everything .ko) into your kernel modules directory tree – maybe /lib/modules/2.6.xx/kernel/drivers/net/wireless/. Don’t follow the instructions for doing modules_install if you’re building out-of-tree – it doesn’t put them in the right place.
When the driver is loaded, it has to upload firmware into the card to make it work (I’d sure like to meet whoever decided doing this was a good idea). You’ll need to get the firmware package. But don’t use the latest firmware (acx_111_2.3.1.31) as this doesn’t work… you need to use acx111_1.2.1.34 – copy the files from this directory into wherever hotplug keeps it’s firmware in your distro ([K]Ubuntu keeps it in /lib/hotplug/firmware/).

That’s it. Now you just need to configure the card using your distro’s network config tool, or by manually editing the appropriate file. I found that the card wouldn’t work unless I specified the channel and mode for some reason, but YMMV.