Next Previous Contents

11. Samsung APC164UX (Ruffian)

(This section is written by Stig Telfer.)

11.1 Ruffian Links

Note: I accept no responsibility for anything that goes wrong as a consequence of reading this section of the FAQ. If you have anything to add to it, please do!

11.2 Introduction

The Ruffian board is broadly similar to the 164LX board, but beefed up with six DIMM slots instead of four (giving a maximum memory capacity of 1536MB), and with on-board SCSI and ethernet. It also takes higher-clocked EV56 processors (up to 667MHz) and has more PCI slots.

Hardware configuration:

In all, a well-configured EV56 workstation. Yet it is plagued with a bad reputation.

The Caveat

While the vast majority have no trouble with their Ruffians (author included), a handful of users find fundamental shortcomings that make the board unusable for their applications.

The Symptoms

A virtual memory stress-test that induces continuous heavy paging can cause the machine to die. The problem manifests itself through various "Unable to handle kernel paging request", "killing the swapper", "attempting to swap the idle process" messages, and a register dump. The system may become unusable after that.

The stress-test may run without failure (I have run it for three days without fault), or it may fail within seconds.

Some people claim this problem only arises with large memory configurations.

The Fix

Lukasz Dobrek of Hannover University has identified that his processor has been overheating and believes that this has been causing the problems described above. He put some silicon paste between processor and heatsink and found that his machine became stable again. Silicon paste is an interface material that improves heat transfer between surfaces.

Other people have suggested that the problem is aggravated in large memory configurations.

Elsewhere it has been suggested that using the latest milo will help improve stability.

11.3 Hardware Issues with the Ruffian

Ruffian On-board Ethernet

The Ruffian's on-board DEC Tulip Ethernet is not very good at auto-sensing a 100Mbit link with the Linux Tulip driver. Using recent versions of the tulip driver appears to help. The author has also found the problem to be sensitive to the network hardware. By changing hubs, or even ports on the same hub, the problem disappears.

The tulip device driver page is well documented at:

These pages also contain instructions on how to install the driver. Alternatively, try looking at the section on building your own kernel in this FAQ. (The location of the tulip device driver in the linux source tree is drivers/net/tulip.c, copy your newly-downloaded version in here and you're ready to build)

If your ethernet doesn't autosense 100Mbit, there are some other options I have found to sometimes work, although we're in experimental territory here and what may work for me may not work for you.

Your first option is to hard-code your ethernet interface to be 100baseTX, bypassing the autosensing mechanism. However, this doesn't always work. What does sometimes work is hard-coding the medium to be 10Mbit, and then 100Mbit. The first packet will fail transmission, but after that the link is brought up in 100Mbit mode. To bypass the auto-sensing mechanism, edit tulip.c and put numbers into the options array, according to your media type as defined in an array further down the code (10baseT is 12, 100baseT is 4). If you still can't get this to work, try this patched version of the tulip driver, actually patched for the Miata by Loic Prylli. What it does is to keep trying with user-specified hard-coded media.

Again, your experience may vary...

Video Cards

Older versions of MILO (the bootloader) required that the video card was put into the 64-bit slot. This was because all the other PCI slots are behind a PCI-PCI bridge which was not correctly supported by MILO.

However, work by Nikita Schmidt and Stefan Reinauer have addressed this problem and recent MILOs support a video card in any PCI slot, freeing that 64-bit slot up for better things...

You can find Nikita's work here and Stefan's work here. Stefan's work builds upon the improvements done by Nikita on the stock MILO available from Compaq at the Gatekeeper FTP site above.

11.4 The Red Hat Release CDs and the Ruffian

Unfortunately, both Red Hat 5.1 and 5.2 releases have flaws to be aware of when installing on a Ruffian.

11.5 Red Hat 5.1

For your first disk, you should use a different milo and ldmilo.exe file, which are downloadable from Gatekeeper, Digital's FTP server:

How to build your milo disk

  1. Take a DOS-formatted floppy
  2. Copy the two files above onto it, renaming them to 'ldmilo.exe' and 'milo'
  3. Thats it, you're done :-)

Running XFree with Red Hat 5.1

If the XFree X server fails to start on your system, try adding the following link:

cd /etc; ln -s EB164 alpha_systype

If your graphics card uses the SVGA X-server (eg, if you have a Matrox graphics card), you should also pick up the patched SVGA server. ( ftp://mea.tmt.tele.fi/pub/XFree86/ ). Or, upgrade to a newer version of XFree, as packaged with any current distribution.

Reading the time and date correctly with Red Hat 5.1

The Ruffian ARCSBIOS uses a different format for time and date. In releases of Red Hat up to 5.1, this meant that Linux would not report the correct date and time.

This can be fixed using:

Date and time issues are fixed for the Ruffian in Red Hat 5.2

11.6 Red Hat 5.2

Unfortunately the Ruffian kernel provided on the Red Hat 5.2 CD doesn't contain support for the Symbios 875 on-board SCSI. However, you can take the kernel image from Red Hat 5.1 to perform the install. Once installed, you can build your own kernel - the sources on ftp://gatekeeper.dec.com/pub/DEC/Linux-Alpha/Kernels for 2.0.35 are tried and trusted.


Next Previous Contents