1. What State Is Linux/Alpha In?

Contents of this section

It's true, it's true: Linux/Alpha is now fully self-hosting with ELF and shared libraries! A detailed announcement has been mailed to the various Alpha mailing lists (see below). If you want to get your hands dirty, here is how .

And the usual stuff, just to make sure everybody understands Linux/Alpha is for real: pretty much everything is up and running: there is XFree86, LaTeX, ghostview, Mosaic, Emacs, gcc, NFS, automounter, all sorts of shells, perl, python, Tcl/Tk, scheme, apache HTTP server, and pretty much anything else that's freely available. X11 works well on several video cards (see below).

Linux/Alpha presently runs on many (most?) of the Alpha boxes that come with the PCI or EISA bus. This excludes the older TURBOchannel based DEC 3000 series of workstations.

1.1 A Word on C++

There seems to be a lot of confusion as to what the state of C++ on Linux/Alpha is. Hopefully, this will clarify the situation somewhat. First, the GNU C++ compiler has been working for a long time. Get any recent gcc distribution, and g++ will come with it and it will work fine. A different issue is libg++. It can be patched to work together with the existing C library. In fact, Craftwork Linux does appear to include a working libg++ package. So, if anybody really cares about having libg++ around, it certainly can be done.

The hope is that libg++ will come standard with all future ELF based systems. At present, libg++ does not build on an ELF based system because there are some incompatibilities between libg++-2.7.x and the (newer) g++ that is needed for ELF. But by the time gcc-2.8 is released, these problems will hopefully be solved.

1.2 Supported Drivers

Drivers that are known to work (let us known if there is something new):

• X11: Servers for the following chips are available for ftp at DEC's ftp site :
  • Mach64
  • S3
  • TGA
• keyboard
• console (TGA, EGA+ or VGA+ compatible cards)
• selection (console mouse support)
• serial
• line-printer (centronics port)
• floppy
• SCSI: disks, CD-ROMs, and tapes seem to work fine. Host adapters that are known to work:
  • ncr53c810
  • aha1740 (on Jensen, at least)
  • BusLogic (all cards ISA or PCI cards should work fine except for the Flashpoint; EISA cards may be flakey in older EISA systems).
  • Qlogic ISP1020
• ftape (QIC-80 tape drives): you'll need the BFD-based insmod utility.
• IDE driver: disks and CD-ROMs (ATAPI) are know to work fine.
• Networking:
  • Ethernet drivers: de4x5, de500, depca, ewrk3, ne2000. The following drivers are supposed to be working as well:
    • Western Digital (aka SMC Elite) wd80x3
    • SMC Ultra
    • SMC EtherEZ
    • 3Com 3c503, 3c503/16
    • Cabletron e2100
    • Hewlett Packard PC Lan (model 27245, uses hp.c)
    • Hewlett Packard PC Lan+ (model 27247 or 27252A, uses hp-plus.c)
    • Ansel AC3200 EISA card.
    If you experience problems with one of these, you might want to drop a note to Paul Gortmaker
  • Other drivers: ppp, ibmtr (IBM token ring driver).
• Sound cards: SoundBlaster compatible cards seem to work well. The Microsoft Sound System compatible card built into the UDB is supported, too.
• Joystick: The joystick interface on a SoundBlaster16 (which is just a regular PC joystick port) is known to work with joystick-0.7.3 (as a module). There were a few minor patches that had to be applied. If you want it, send mail to David Mosberger . The "koules" game is known to work with the joystick.

1.3 Known Bugs And Workarounds

This section lists known bugs in Linux/Alpha and discusses how they can be avoided or worked around. As things are under constant development, this section is rather volatile. Just because it isn't listed here doesn't mean the problem isn't known already. However, before sending mail off to linux-alpha or axp-list , be sure to check this section first. If you discover a new problem/workaround, we would appreciate if you could send us a report (preferably in linuxdoc SGML format).

tar xvMf /dev/fd0 hangs.

Due to a bug in the malloc package that comes with libc-0.43, multivolume tar archives do not work. Recompile and link with the gmalloc standalone package, or get an updated libc.

Kernel reports 2.88MB floppy drive:

On the Alphas, the kernel always reports floppy drives as having 2.88MB capacity even if a smaller capacity drive is installed. This is nothing to worry about: normally, the floppy driver automatically detects and selects the correct capacity so everything will work fine. The only exception to this rule is when formatting a new floppy disk. To do this, you'll need to select the device name with the correct capacity. For example, if the system has a 1.4MB drive, format /dev/fd0H1440 instead of /dev/fd0.

Unaligned accesses:

The Alpha, like all real RISC CPUs, requires that memory accesses are naturally aligned. For example, reading a 4 byte integer from memory requires that the address of the integer be a multiple of 4. Similarly, 8 byte integers need to start at an address that is a multiple of 8. If the CPU attempts to access a word that is not properly aligned, the CPU will trap into the kernel and issue a warning message. The kernel will then go ahead and emulate the unaligned access so that the user-level process executes as if nothing had happened (except for a substantial slow-down due to the fault).

Typically, an unaligned fault message looks like this:

X(26738): unaligned trap at 000000012004b6f0: 00000001401b20ca 28 1
        

What this means is that the process executing command X (the X11 server) with process id 26738 caused an unaligned fault accessing address 0x1401b20ca. This access was performed by the instruction located at address 0x12004b6f0. The other numbers are less important, but if you check the kernel sources, you'll find that they tell you more info on what kind of instruction caused the fault (e.g., a load vs. a store).

You do not need to be overly alarmed when seeing such a message. The program causing the faults will work correctly. Eventually, all unaligned accesses will be fixed, but in the meantime, just ignore these messages (if you're a programmer, please take a minute and fix the source of the unaligned access instead...).

Linker issues warning: using multiple gp values message:

This is a warning message that is often issued by the linker when building a large program. Unless you're into low-level hacking, you don't want to know what it means. The good news is: you can safely ignore this message and this warning will be optional in the future.

IDE driver causes time to run slow:

The default configuration of the IDE driver disables interrupts for extended periods of time. This causes the kernel to loose timer interrupts and as a result, time runs slow. To avoid this, use the following command on all of the IDE drives in your system:

                hdparm -u 1 /dev/hd?
        

This reconfigures the IDE driver to reenable interrupts as quickly as possible.

minlabel,fdisklabel fail to update kernel partition table:

Do not attempt to use a system after changing the partition table. Even if minlabel and/or fdisk show the correct values you will have to reboot the machine before the new values take effect.

xterm has bad stty settings:

True enough: the initial terminal control characters are weird with the current xterm binaries. Be sure to issue stty sane before doing any real work in an xterm.

ps, top show incorrect values:

Be sure to get the latest psproc patches from the AZStarNet site. The kernel interfaces changed a couple times around 1.3.39 but should be fairly stable now. With the latest patches, you should get correct priority values, memory sizes, and even waiting channels will be displayed correctly.

Some X11 fonts look poor:

Older versions of the XF86_S3 and XFMach_S3 servers had problems displaying certain fonts. If your server suffers from this problem, you can get a fixed version here .

Kernel hangs or panics when trying to mount root file system:

The Linux kernel currently has /dev/sda2 hardcoded as its default root file system. Thus, if your root file system is on any other disk or partition, you will have to specify the boot option root=/dev/your-root-dev/partition. For example, if the root file system is on /dev/hda1, you'd specify root=/dev/hda1.

1.4 Porting to Alpha: the long and short of it

Here is a somewhat random collection of popular ways of shooting yourself in the foot on Unix when programming in C. This has practically nothing to do with Linux or Alpha, but since Linux/Alpha is among the pioneers in 64-bit land, these errors are more likely to show on such systems.

sizeof(long)!=32

Many programs assume a long is 32 bits wide. This is non-sense. The ANSI C standard does not specify anything like that. For example, on an Alpha running a grown up operating system such as DEC Unix or Linux, the fundamental C types have the following sizes and alignment restrictions:

• char: 8 bits as usual, byte alignment is fine.
• short: 16 bits as usual, 2 byte alignment required.
• int: 32 bits as usual, 4 byte alignment required.
• float: 32 bits as usual, 4 byte alignment required.
• long: 64 bits, 8 byte alignment required.
• void*: 64 bits, 8 byte alignment required.
• double: 64 bits as usual, 4 byte alignment required.

Note that the above implies that you cannot cast a pointer to an integer without loosing bits. In fact, Alpha binaries by default are purposely arranged in such a way that if you try to do this, they'll dump core---it is much better to learn about such program errors via a core dump than through some subtle errors.

If you need a variable with exactly n bits in it, you can use the following types in Linux applications (and most other systems that are based on GNU libc):

• int8_t: signed integer type with 8 bits.
• int16_t: signed integer type with 16 bits.
• int32_t: signed integer type with 32 bits.
• int64_t: signed integer type with 64 bits.
• u_int8_t: unsigned integer type with 8 bits.
• u_int16_t: unsigned integer type with 16 bits.
• u_int32_t: unsigned integer type with 32 bits.
• u_int64_t: unsigned integer type with 64 bits.

In the kernel, use the following types instead:

• __s8: signed integer type with 8 bits.
• __s16: signed integer type with 16 bits.
• __s32: signed integer type with 32 bits.
• __s64: signed integer type with 64 bits.
• __u8: unsigned integer type with 8 bits.
• __u16: unsigned integer type with 16 bits.
• __u32: unsigned integer type with 32 bits.
• __u64: unsigned integer type with 64 bits.

However, the availablility of these types is somewhat system dependent. In particular, on a 32 bit machine, the 64 bit integers are typically available only when using GNU C. Also, keep in mind that there are still machines out there that have odd word sizes, such as 36 bits. So, for the sake of portability, these types should be used sparingly.

Error return value of inet_addr()

It is a common myth to assume that inet_addr() returns -1 in case of error. In fact, even the Linux man-page propagates this un-wholesome believe. But don't be misguided: in truth, inet_addr() returns INADDR_NONE in case of error. This manifest constant is defined in netinet/in.h.

struct termio does not equal struct termios

Many Linux programs incorrectly assume it is all right to mix and match struct termio and struct termios and its ioctl(). Well, not quite. The two interfaces are in fact incompatibly on many systems (for historic reasons, this can't be fixed easily). Thus, if you use struct termio, then be sure to use the termio calls only (TCGETA, TCSETAF, TCSETAW, and TCSETA). In constrast, if you use the termios structure, be sure to use its calls only (TCGETS, TCSETSF, TCSETSW, and TCSETS).

Atomicity of sub-word loads/stores

It is generally not safe to assume that reading or writing a quantity that is smaller than the machine's word size is atomic. In particular, all early Alpha chips do not have atomic instructions to read or write a byte or a short (16 bits). Unless you're into kernel hacking where you need to synchronize with devices and/or interrupts, you probably won't care. But even in user-space this can cause problems in case your program is sharing data with another process through shared memory, for example.

Next Chapter

Table of contents of this chapter, General table of contents

Top of the document, Beginning of this Chapter