Imaging an RLL hard drive in 2019 with the Linux xd driver

The other day, I found a Western Digital FileCard 30 hardcard in my attic. (For those who've never seen one, a hardcard consists of a hard drive and its matching controller card, bolted together and designed to plug into a full-length ISA slot. There were versions for 8-bit and 16-bit ISA systems).

The drive powered up OK, and by using a DOS boot floppy I was able to get a directory listing and determine there was nothing of particular value on it. Using a home-written tool, I was able to image the readable sectors under MSDOS. More out of curiosity than anything else, I decided to try and repeat the process using ddrescue under Linux.

Hardware

The hardware I used for this was a 'tweener' PC, based on a Supermicro P6SLA motherboard. For storage I used a SCSI hard drive attached to an Adaptec 2940 PCI SCSI controller. The intention was to avoid any conflict between the FileCard and the motherboard's built-in IDE hardware/BIOS, by having all drives on external controllers. I don't know if it made any actual difference to the dumping process.

The FileCard uses IRQ 5 and DMA channel 3. These needed to be allocated in the BIOS for ISA rather than PCI usage.

The FileCard controller is labelled WD1002-27X; the drive is labelled WD383R. The usual geometry of a WD383R is 615 cylinders, 4 heads, 26 sectors.

Software

The system software used was Slackware Linux version 10, which is what I happened to have to hand. The kernel version is 2.4.26.

It proved to be a reasonable choice; it fitted in the space available on the SCSI drive, was not overly slow, had hardware support for the important peripherals and allowed me to recompile the kernel if necessary.

Pitfalls

The following obstacles had to be overcome before Linux could successfully access the FileCard:

Booting

When the FileCard was added to the system, it took precedence over the SCSI drive which had previously been the boot drive. In order to boot Linux from the SCSI drive, I had to create a LILO rescue floppy as described in the LILO mini-howto.

Booting from a Slackware installation CD or LiveCD would have been possible, but the use of a rescue floppy allowed me to boot from a custom kernel rather being restricted to the pre-built kernel(s) on the CD.

The xd driver

Under Linux, the xd driver provides access to hard drives on 8-bit XT-type controllers. Fortunately Slackware 10.0 includes this driver as a loadable module, so in theory it's just a matter of typing modprobe xd and letting the drive be detected.

In practice, it took rather more effort:

xd: Out of memory

On a typical Linux 2.x kernel (prior to 2.6.33), attempting to use the xd driver, either compiled into the kernel or as a loadable module, will fail with the error xd: Out of memory. This is a bug in the xd initialisation code: it tries to allocate memory for a transfer buffer before having worked out how big the buffer should be.

The proper fix was committed in Linux 2.6.33. Rather than build a 2.6.33 kernel or try to backport the bugfix to Linux 2.4.26, I instead read the module source and found that for a WD1002-27X controller, xd_maxsectors is always set to 1. Initialising this at compile time seemed to work.

< static u_char xd_drives, xd_irq = 5, xd_dma = 3, xd_maxsectors;
> static u_char xd_drives, xd_irq = 5, xd_dma = 3, xd_maxsectors = 1;

Since I had compiled the xd driver into the kernel, I therefore had to rebuild the kernel and the recovery floppy.

Incorrect geometry

The modified xd driver now detected the drive — however, the reported geometry was incorrect. Fortunately it is possible to override this on the kernel / module command line with the xd_geo option. In my case, xd_geo=615,4,26 proved successful.

No device nodes

The Slackware 10.0 installer does not create the device special files necessary to access an xd drive, so these had to be created manually:

# mknod /dev/xda b 13 0
# mknod /dev/xda1 b 13 1
# mknod /dev/xda2 b 13 2
# mknod /dev/xda3 b 13 3
# mknod /dev/xda4 b 13 4

Results

With the above fixes, I was able to access the drive and image it with ddrescue. I don't think it recovered any more data than the original DOS dump, but at least it kept me out of mischief for a couple of evenings.

John Elliott 12 July 2019