This is my notebook. ...where I stash trivia I want to remember that might also be useful to you. You're welcome to use it, but see the disclaimer

Linux Hardware compatibility

I've used the following specific hardware with various versions of RedHat Linux (6.1 - 7.1).

U.S. Robotics PCI faxmodem Model 5610

ISA slots are getting downright hard to find. Finally, someone got around to creating a PCI modem. ...and actual modem with a genuiine UART, as opposed to another "winmodem." I strongly recommend the
U.S. Robotics 56K FaxModem Model 5610 for anyone looking for a 56K PCI modem for Linux.

The following script (run as root) will configure the /dev/ttyS2 serial port to use the 5610.

DEVICE=$(lspci | grep "US Robotics" | awk '{print $1}')
IRQ=$(lspci -v -s $DEVICE | head -n 3 | tail -n 1 | cut -d ' ' -f 5)
PORTS=$(lspci -v -s $DEVICE | head -n 4 | tail -n 1 | cut -d ' ' -f 4)

echo US Robotics modem is at IRQ $IRQ
echo ...and the base of the I/O port range is $PORTS

setserial /dev/ttyS2 port 0x$PORTS irq $IRQ autoconfig

Kodak DC3200 1.1 MPixel digicam

You probably can't even buy these anymore since everyone seems to think they're photographic arteeests when it comes to digicam resolution. The DC3200 is a cheapo that can do 1024x768...all I care about. Unless you're a fine-art photog or really plan on making poster-size blowups of your shots, I can't imagine why anyone would want more than 1024x768 that this cam will do. Don't send me and email attachments bigger than that!

gPhoto supports the DC3200. I couldn't get it to work until someone pointed out to me the proper format for the "--port" option. The following is an example of a command line to download pictures:
gphoto2 --camera "Kodak DC3200" --port "serial:/dev/ttyS0" --speed "115200" -f "/DCIM/100K3200" --filename "1.jpg" -p "1"

To get a list of folders:
gphoto2 --camera "Kodak DC3200" --port "serial:/dev/ttyS1" --speed "115200" -l

Of course, the serial port is dog slow and flaky. Occasionally a command will just fail, but retrying it usually works. Use of a CompactFlash card with the DC3200 is a better option.

Hewlett Packard CD-RW cd12ri

Yes, like almost everything else HP makes, their cd12ri CD-RW drive works beautifully. Enough said about that.

Burning CDs

You have to slightly change the way the system boots in order to use cdrecord. You must access the CD-RW through a SCSI driver using the ide-scsi adapter module.

I added:

...to the end of my lilo.conf and reran lilo.

Then if you normally access (or if /etc/fstab references) the CDROM through a /dev/cdrom symlink change it to:

lrwxrwxrwx    1 root     root            9 Sep 12 09:24 /dev/cdrom -> /dev/scd0
Now, assuming you've booted appropriately, to burn a data CD:
mkisofs -r -o cdimage <some directory>
...makes a big honkin file that will be burned verbatim onto the CD
mount -t iso9660 -o ro,loop=/dev/loop0 cdimage /mnt/cdrom
...just to test the image. It should be mountable and browseable.
cdrecord -scanbus
...just to get the SCSI id triplet.
cdrecord -v speed=2 dev=0,0,0 -data cdimage
...to do the burn.
See the man page for cdrecord for more info.

Iomega Zip 100 external Parallel port

To use an
Iomega parallel port Zip drive you basically just have to:
  1. Create a mount point in /mnt, e.g. /mnt/zipdisk
  2. Insert the disk
  3. Load a stack of parallel port drivers followed by the ppa.o driver.
  4. mount the disk
I use the following shell script to load the drivers:

insmod parport
insmod parport_pc io=0x378 irq=none
insmod ppa
The 'io' value specified above will depend on the parallel port settings in the BIOS. Alternatively, you might be able to omit the io setting altogether if you precede 'insmod parport_pc' with 'insmod parport_probe'. I think that's the intent of parport_probe, but I haven't tried it.

I'm not sure why, but the Zip drive is consistently mapped to SCSI device number 4. Also, the disk should be inserted before loading the drivers.

...and another thing! I assume that lp (the printer driver) and ppa would conflict on the parallel port. I've always unloaded one before loading the other. Not a big deal since you can't physically connect both at the same time anyway!

16-bit ISA soundcard CT4520

sndconfig failed to detect my SoundBlaster CT4520 when I installed it after having installed RedHat 7.1. I realized this was because it is an ISA PnP card and had not been "enabled". To fix the situation...
  1. Make sure you have isapnptools-1.22-2 installed.
  2. As root and in /etc, run pnpdump >> isapnp.conf
  3. After verifying that there will be no resource conflicts uncomment one of the configurations in the isapnp.conf file.
    Make sure to uncomment the corresponding (ACT Y) line, too!
  4. run isapnp isapnp.conf. This should activate the card on the ISA bus.
  5. Run sndconfig. It will now find the card (whereas before it wouldn't).

Toshiba Satallite 2405-S201

Not much to say here. SuSE 8.0 works fine on it with three caveats:
  1. The Satellite won't boot the SuSE installation CDROM, so I had to create an installation diskette (from my RedHat machine) with the command:
    dd if=<the boot image> of=/dev/fd0 bs=1440k
  2. Time is consistently wrong when I boot up, so I just do a date MMDDTTTTYY as root after booting up.
  3. The keyboard would repeat keys when running X which I fixed by adding 'Option "XkbDisable" "true"' to the Section "InputDevice" of the "keyboard driver:
    Section "InputDevice"
      Driver       "keyboard"
      Identifier   "Keyboard[0]"
      Option       "Protocol" "Standard"
      Option       "XkbKeyCodes" "xfree86"
      Option       "XkbLayout" "us"
      Option       "XkbModel" "pc104"
      Option       "XkbRules" "xfree86"
      Option       "XkbDisable" "true"

General configuration issues

  1. Accessing CompactFlash cards
  2. Using PCMCIA cards on Linux
  3. Printers
  4. Qwest DSL with Linux
  5. PalmOS development on Linux
  6. Setting up sendmail and mutt withoutKDE or Gnome

Accessing CompactFlash cards


CompactFlash cards "look like" disk drives to the kernel. I have only used the PCMCIA variety, not USB, so the following is specific to PCMCIA.

Accessing a CompactFlash card

First, of course, you have to have
PCMCIA card support set up on your system. However, once PCMCIA is set up, all I have to do is:
  1. Insert the compact flash into its PCMCIA carrier
  2. Insert the PCMCIA card carrier
  3. cat /var/lib/pcmcia/stab, you see something like:
    Socket 0: ATA/IDE Fixed Disk
    0 ide ide-cs 0 hde 33 0
    Socket 1: empty
    The "hde" is crucial information.
  4. make a mount point if you haven't already. e.g. mkdir /mnt/cflash
  5. mount -t msdos /dev/hde1 /mnt/cflash

For the curious...

Before insert cat /proc/devices looks like this (with Character devices omitted):
Character devices:
Block devices:
  1 ramdisk
  2 fd
  3 ide0
  9 md
 22 ide1
After insertion, you'll notice a new entry in the "Block devices" section:
Character devices:
Block devices:
  1 ramdisk
  2 fd
  3 ide0
  9 md
 22 ide1
 33 ide2
Even without consulting /var/lib/pcmcia/stab you can guess you'll need to mount hde because drives are assigned in pairs to ide devices. ide0 gets hda and hdb. ide1 gets hdc and hdc. ide2 must get hde and hdf. Notice that this is the case even if a physical device is missing because letters are assigned to the controllers on the motherboard (or elsewhere), not the devices themselves. e.g. I don't have any disk in my "Secondary IDE" slave position, so hdd is unused but the "d" position is still reserved.

Note, most digital cameras (and for that matter probably everything that uses CompactFlash cards) will set up MS-DOS filesystems. (That filesystem will still be with us in 2025 whether we like it or not!)

Using PCMCIA cards on Linux

Commands to load necessary drivers and daemons

The following commands as part of an init script or executed manually (in this order!) prepare the system to handle PCMCIA card insertions:
  1. /sbin/modprobe i82365
  2. /sbin/modprobe ds
  3. /sbin/modprobe pcmcia_core
  4. /sbin/cardmgr
i82365 was originally a driver for the Intel chip of the same name, but it has been greatly expanded to handle all chip(set)s sufficiently similar to Intel's original. 'cardmgr' is a daemon that receives signals from the driver stack when a card is inserted, removed, or otherwise has its state changed.

For reference, here's the output of /sbin/pnpdump showing my ISA SCM "Swapbox" configuration.

# $Id: pnpdump_main.c,v 1.23 2000/04/19 22:49:44 fox Exp $
# Release isapnptools-1.22
# This is free software, see the sources for details.
# This software has NO WARRANTY, use at your OWN RISK
# For details of the output file format, see isapnp.conf(5)
# For latest information and FAQ on isapnp and pnpdump see:
# http://www.roestock.demon.co.uk/isapnptools/
# Trying port address 0273
# Board 1 has serial identifier 9e 38 45 fe bf 69 04 6d 4c

(READPORT 0x0273)

# Card 1: (serial identifier 9e 38 45 fe bf 69 04 6d 4c)
# Vendor Id SCM0469, Serial Number 944111295, checksum 0x9E.
# Version 1.0, Vendor version 0.0
# ANSI string -->SCM SwapBox Plug and Play<--
# Logical device id SCM0469
# Edit the entries below to uncomment out the configuration required.
# Note that only the first value of any range is given, this may be changed if required
# Don't forget to uncomment the activate (ACT Y) when happy

(CONFIGURE SCM0469/944111295 (LD 0
#     Logical device decodes 16 bit IO address lines
#         Minimum IO base address 0x03e0
#         Maximum IO base address 0x03fe
#         IO base alignment 2 bytes
#         Number of IO addresses required: 2
# (IO 0 (SIZE 2) (BASE 0x03e0))
 (NAME "SCM0469/944111295[0]{SCM SwapBox Plug and Play}")
# (ACT Y)
# End tag... Checksum 0x00 (OK)

# Returns all cards to the "Wait for Key" state


There are two major phases to this:
  1. Make sure you have a low-level hardware connection.
  2. Setup /etc/printcap to describe your printer
They're quite independent steps, and the hardware connection is all you have to setup...if you're content using your LaserJet like a teletype terminal. :)

Hardware setup

The following steps enabled me to cat to my LaserJet 6L. Of course, variations on this are possible; this is just the setup that's worked for me. Also, all the following could and should be scripted (like Zip driver loading above). I'm just aiming to show the "atomic" steps involved. Repackage them however you like. More info on the exact relationships between the stack of 'parport' drivers can be found in /usr/src/linux/Documentation/parport.txt and /usr/src/linux/drivers/char/lp.c. (Always go to the source!)
  1. Just to be safe, I set the parallel port in the BIOS to LPT1 (from its default of 'Auto assigned'). I assumed this would lock it into 0x378, and I have some circumstantial evidence this assumption is correct: PCMCIA Card Services (cs) knows to exclude the range 0x378-0x37f from its control. Look in the kernel log with dmesg.
  2. insmod parport
  3. insmod parport_pc io=0x378 irq=none
    Now if you ls /proc/parport you'll find a new directory with a single digit name has been created. Mine was '0'. ...And if you cat /proc/parport/0/hardware it should spit the resource settings you passed in back at you.
  4. Make sure you're printer is connected at this point.
  5. insmod parport_probe
    Now if you cat /proc/parport/0/autoprobe you should see some info about your printer.
  6. insmod lp parport=auto
    Now cat /proc/parport/0/devices should return 'lp' if all went well.
  7. cat <some text file> > /dev/lp0 just to verify you really can talk to the hardware.
    Note that what comes out might not be formatted correctly (or at all). As long as something comes out your hardware connection is solid.
The use of parport_probe isn't strictly necessary, but I believe you'll have to be more explicit than "auto" when you insmod lp if you haven't done the probe. Again, it's explained in the source file lp.c. No sense in my repeating it.


Don't bother hand editing /etc/printcap. Even if you get this right (which isn't hard) there is still the mess of print filters to set up. Just use printtool. Run it from a console within X. It will take good care of you.

Qwest DSL with Linux


Never mind Qwest's disclaimers. You do not need a Windoze OS to use DSL at least if you take their "external modem" option. With that option (which costs more) you receive a Cisco 675 "DSL modem" that is also, in fact, a router... useable with absolutely any OS that has a TCP/IP stack. I have three machines behind my Cisco all running "unsupported" (Qwest's words) operating systems: Linux and BeOS.

Cisco 675 CBOS updates -- don't to it!

If you follow security news you already know that early versions (up to 2.2.1, I believe) of the embedded OS that the 675 runs have security holes. The newest version, 2.4.1 last time I checked, allegedly fixes those, but nonetheless, my advice on upgrading the CBOS: Don't do it!.

Why? I've had a couple misadventures, been a pain in the ars of Qwest tech support, and had to return one 675 because of problems in the upgrade process itself. The short story: I rendered my Cisco unbootable after repeating an initially successful serial port upgrade. Seems the code that implements the Monitor Mode (in which you do serial port updates) is itself subject to versioning. (Note: Any self-respecting engineer would've stuck that in ROM, not flashable ROM, since it's your last resort to access troubled hardware without cracking the box. But no...)

The first upgrade went fine, and I ran with 2.4.1 for a month. I was repeating the process to refresh my memory (for this very page) and the 2nd time it failed and took the bootable image with it. ...And I was forced to return to dial-up access for a week. Ouch!

Digging around Cisco's site I found a tech article stating that you can't upgrade from 2.2.x to 2.4.x. You must update to 2.3.x, then to 2.4.x. Well, it might be that simple, but I'm not going to flirt with disaster. (If I have to return another modem, and I were Qwest, I'd probably make me pay for it, too.)

So...just live with the security holes. You know there are new holes in the new release anyway. Just make sure you've turned off all the externally accessible ports (web and telnet especially).

Monitor mode

The Cisco has a very low-level access mode you can enter by typing <ctrl>-C in a terminal window as the Cisco boot...specifically, when the red "alarm" light comes on. This is a terminal mode similar to an assembler. You can do a lot of damage in this mode and completely hose the 675 so tread lightly!

I can't find anything about this on Cisco's site, and Qwest tech support only seemed to know a few commands.

Erasing the passwords

To erase the password go into monitor mode and type:
es 6

Qwest DSL tech support

It's hit and miss. I've talked to some very with-it helpful people. I've talked to some useless script followers. But here are some good general rules:
  1. Don't call tech support
  2. Failing that, reveal that your running a real, I mean, a non-Microshaft OS, only as a last resort. Revealing this throws the script-followers off script and generally results in something like the following dialog:
    Tech Support: "...yes, but your contract agreement says we don't support Linux."
    Me: "Yes, but I'm not asking for support on my OS. I'm asking for support on the OS in the Cisco box you gave me. I can manage my own OS."
    Tech Support: "...but you're not running Windoze"
    Me: "yes, but I've got a terminal session open to the Cisco on the serial line."
    Tech Support: "...uh, you mean your inside Hyperterminal."
    Me: "No, I'm...uh, well, yes, sure. If that's what your script says. Yes, I'm inside hyperterminal."

PalmOS development on Linux

I'm running RedHat 7.1 updated with KDE 2.2 and glibc 2.2.4-5. This is the context for everything below unless otherwise specified.

What you need

There are, of course, numerous versions of the above. I'm using the versions explicitly referenced above...subject to the caveats described below! I'm not using the latest and greatest of everything, so your mileage may vary. For example:
  1. I'm currently using the 1.0.9 fltk, though there are newer versions available at www.fltk.org.
  2. I'm using the 3.5 SDK without the update though the SDK's currently on v4.0.

The PilRC, emulator, and FLTK packages must be built from source distros. The SDK is just a tarball of headers and libs.

The PalmOS Emulator

Running RedHat 7.1?    Don't bother trying to build the emulator.

If you're running RedHat 7.1 you're screwed—sorry, but see below. There's apparently a code generation bug in the 2.96 gcc. pose, the emulator executable, will build just fine, but it will just crash seconds after launching (if you're lucky). If you built a debug version, it won't crash; it will completely utterly hang the system.

I tried applying RPMs from RedHat to patch gcc, cpp, gcc-c++, libstdc++, and libstdc++-devel to 2.96-85, but this didn't fix diddly. 'Course I can't be sure it's gcc's fault because:

  1. I had just updated to KDE2.2 (and glibc 2.2.4-5), and
  2. I also might have missed a required patch.
Still I think the compiler is at fault because...

Build on RedHat 6.2, or...

I built pose on RedHat 6.1, naively copied it right over to my RedHat 7.1 installation, and it ran just fine! So that's the short story: Build on RedHat 6.1 or at least using a pre-2.96 gcc if you can.


Here's the basic sequence
  1. Build and install FLTK
    1. Unpack fltk
    2. run the configure script
    3. make
    4. make install (as root)
    Make sure you have the XFree86-devel (headers, etc.) and XFree86-libs installed. You'll need to rerun ldconfig (or just reboot) after installing the XFree86 libs.
  2. Build pose
    1. cd to the BuildUnix directory
    2. run the configure script
    3. make
It should be that simple. You should be able to run the resulting pose executable.

Installing the tools

Compiler toolchain

The "PRC tools" are a toolchain including, most importantly, a gcc 2.95 cross compiler that produces Motorola 68K binaries. You're in trouble again (minor, this time) if you're running RedHat 7.1 because rpm will complain that the prc-tools package needs libncurses.so.4. I forced an installation anyway using rpm -ivh --nodeps prc-tools-2.0-1.Linux-i386.rpm and everything seems to work.

This RPM seems to have stashed things all over. In particular, there are two identical (according to diff) sets of tools with different names in /usr/local/m68k-palmos/bin and /usr/local/bin. You'll need the build-prc executable in /usr/local/bin, though, so you should probably favor this directory when adjusting paths or setting up makefiles for a build.

For the record, the rpm creates:


The folks at
ardiri.commake some discouraging remarks about buildability of their tools "on *nix variants," but I found the source in pilrc-2.8p7.tar.gz built fine on RedHat 7.1.

Setting up sendmail and mutt withoutKDE or Gnome



  1. RedHat installs Gnome whether you want it or not.
  2. Printing doesn't entirely work on RedHat 7.1

...But I checked "KDE Workstation"!

I prefer KDE, but RedHat 6.1 may give you Gnome regardless of what you select in installation. I tracked the problem down to the "up2date" package...RedHat's Microsoft-esque "phone home for updates" software. It's installed by default and requires some Gnome stuff...so you're gonna get Gnome if you don't explicitly preclude this package in installation. Alternately, after a basic "KDE Workstation" installation, you can just 'rpm -e' the following packages in order:
  1. up2date
  2. pygnome
  3. gnorpm
  4. gnome-linuxconf
  5. gnome-core (...and rm -rf /usr/share/gnome/)
There are probably more, but get rid of these and "startx" will properly default to KDE...as you intended.

Printing doesn't entirely work in RedHat 7.1

I fixed this by dumping the fancy-ass new alchemy stuff, and reinstalling trusty old printconf from RedHat 7.0:
rpm -ivh printtool-3.54-1.noarch.rpm rhs-printfilters-1.81-1.i386.rpm 
rpm -e printconf
rpm -e printconf-gui


Since this is just an online notebook...
  1. It's not pretty,
  2. It's not all complete.
  3. It's not all up to date.
  4. It reports my experiences. Your mileage will vary, and...
  5. There is NO WARRANTY on anything on this site.
If you have a question, you can mail
me. If you have a lawyer, just go away.
Last updated: Sun Oct 27 14:00:40 PST 2002