Posts

fsync() Across Platforms

When an application writes a file, the data does not become permanent immediately. The write operation first moves the data into the operating system cache in RAM, where it is vulnerable to system crashes and loss of power. The second step is the transfer to the hard disk, which normally has write caching enabled. The disk acknowledges the data straight away, but keeps it in the disk write cache which is still volatile memory. The data is now safe from system crash[1. Ignoring some worst case scenarios.], but is not safe from loss of power. On a modern disk, this may be 16MB or more of data in unknown state.

As performance enhancements in ext4 have made committing data to disk a contentious issue, I’ve written a note on how different platforms handle data consistency.

Read more

A Working TFTP Server for Multi-Homed Linux Systems

Linux machines with multiple network interfaces are unreliable as TFTP servers. This issue has been outstanding for a long time, without any resolution. The patch attached to the Debian bug fixes the problem for an old release of tftpd-hpa, but does not apply cleanly to recent releases.

Recent releases of dnsmasq contain a TFTP server which does not have this problem. While this doesn’t solve every case, it provides a tidy solution for a machine which provides BOOTP and TFTP services to several subnets.

Read more

Running Linux on a PCI Add-in Card: Hardware

Every so often I see someone attempting to run the Linux kernel on a PCI add-in card. I’ve done this myself, but there are a lot of complications. This article covers the hardware, and a second article will cover software. Don’t take this as chipset selection advice: before you commit to hardware double-check both the errata and the availability of the silicon.

Read more

In the Year 2038

I have now seen my first ever year 2038 bug. An embedded Linux system that was installed two years ago became unable to acquire a network address by DHCP. The machine did not require an accurate clock, and nobody had initialised its battery-backed real-time clock. Once installed, it had started counting forward from 1st January 1900.

32 bit Unix time covers a range from December 13th 1901 to January 19th 2038. As the real-time clock value was outside this range, Linux wrapped the time round to the year 2036. After the machine had been running for nearly two years, it passed through the 2038 rollover and jumped back to 1901.

This would have been harmless in itself if all the applications on the machine used a monotonic clock, such as the uptime counter returned from the sysinfo function. But the machine in question used an older version of Busybox, and the udhcpc DHCP client in that release failed when faced with a time in the negative number range before 1st January 1970.

The moral of the story? Even though a machine doesn’t need a real-time clock function, it may not be immune to clock related bugs.

Slow Reboots of NFS Server

After several years of use, the server for my development machines developed a problem. If I rebooted the machine without an internet connection, it would pause for several minutes while starting the NFS service.

The Linux NFS server keeps track of status in several files. Whenever a client mounts a filesystem, the server records this in /var/lib/nfs/rmtab. If the server reboots, exportfs passes this list to the kernel to ensure that the reboot is invisible to the clients. So far, this is harmless.

If the server is used with clients that do not send clean unmount requests, such as diskless machines in a development lab, then rmtab fills up with entries for machines that aren’t around anymore. This is mostly harmless.

The final part of the problem is that on reboot exportfs performs a reverse DNS lookup for each entry in rmtab. If the DNS server is unavailable, the request waits for a timeout. This can take a very long time.

And the moral of the story? If NFS clients come and go on your network, check rmtab for clutter.

MPC107/Tsi107 I2C in Linux 2.6

As of Linux 2.6.9.1, the driver is in the kernel as i2c-mpc.c. This version of the driver has been tested on Tsi107 (formerly MPC107), and on MPC8240, MPC8540, and MPC5200 PowerPCs. Thanks to all the testers.

MPC107/Tsi107 Cache Coherency

The Tsi106 (formerly MPC106) and Tsi107 (formerly MPC107) PowerPC host bridges both contain a data cache. This note describes why it may be necessary to mark memory as SMP coherent even in a single processor system using these bridges.

Read more

MPC107 I2C Driver

The driver is supplied ready to be inserted into the linuxppc-2.4-devel tree.

The driver has so far been tested on a small number of systems and with a small number of I2C parts. Thanks to Gleb Natapov, Matthew S. McClintock, and others for testing. Further test results are welcome.
Read more

Asiliant 69030 Driver for Linux 2.4

These are experimental Linux 2.2 and 2.4 framebuffer drivers for the Asiliant 69030 graphics chip. This chip was previously available from Intel, and is descended from a Chips and Technologies part. The 2.2 driver is thus based on the Linux chipsfb.c driver, which supports the 65555 part in certain Apple Powerbooks. The 2.4 driver is also based on work by Jordan Crouse.

This driver is experimental, but is intended as a basis to merge into the mainstream kernel. Though the driver should work on the 69000, I currently have no 69000 hardware to test it on. Reports of using a panel and CRT simultaneously on 69000 are very interesting.

Read more

Asiliant 69030 Driver for Linux 2.2

These are experimental Linux 2.2 and 2.4 framebuffer drivers for the Asiliant 69030 graphics chip. This chip was previously available from Intel, and is descended from a Chips and Technologies part. The 2.2 driver is thus based on the Linux chipsfb.c driver, which supports the 65555 part in certain Apple Powerbooks. The 2.4 driver is also based on work by Jordan Crouse.

The driver currently leaves the flat panel as it was set up by the BIOS. In most cases this displays the same image on flat panel and VGA outputs. The goal for the driver is to support multi-head operation, and multiple 69030 chips. The driver supports operation without a VGA BIOS for embedded applications, but currently contains no flat panel setup code.

Read more