Howto use Debian GNU/Linux on a Gericom Phantom notebook

This is just a quick page describing what works on my notebook under Linux and (sometimes) how I got it working :-) It is no longer up-to-date, but might still be of use to somebody. Since about a year, I now work with an IBM/Lenovo Thinkpad T42p.

I would not have been able to set all that up without the help of many other webpages like this one. Therefore I want to give a short summary on the infos I have gathered, especially trimmed for the Gericom Phantom notebook (which is IMHO a very nice one).

This webpage has been written quickly, with all of the details just from remembering. If you find anything to be incorrect or there is a description missing, feel free to email me and I might be able to dig it up.

Basic Hardware

The Gericom Phantom Hardware is currently (June 2002) pretty well supported under Linux. When using any current Linux distribution, there should be no bigger headaches in setting it up. On this page, I will concentrate on Debian GNU/Linux, since I am using (and developing for) it since over 3 years and therefore definitely know it best. At the moment I am using Debian unstable, staying on the bleeding edge.

At the moment I am using BIOS version 1.07 which seems to be rather stable. Don't try to update it for yourself or you might destroy!! your mainboard during BIOS flashing. It happened to me but fortunately the Gericom support staff exchanged it without charging for it (because the BIOS update came from their server and I did what the docs told me to do) - many thanks to them.


In this notebook there is a plain ATI Mach64 Rage Mobility with 8 MB of RAM. It is supported perfectly by X-Windows with the "ati" driver and by the vesafb kernel module for framebuffer support (and of course the obligatory bootlogo). I had no problems setting that up, but you might want to look at my XF86Config-4 file for details. Working with the LCD display and/or an external monitor just works by using the normal Fn-F8 key combination for switching between the modes. The only disadvantage of this chipset is that dual head mode is not supported - the external monitor will always display the same as the LCD display, therefore resolution and graphic depth can not be different.

Recently I also set the kernel framebuffer support up so that I get 1024x768 console mode and a nice bootlogo. Please look at my kernel config and grub menu file for details. You might note that I am using the grub bootlogo patch from the Debian bug tracking system - gives a very nice image.


The notebook uses a CS4281 sound chip, which currently works with both OSS support in kernel 2.4.18 and ALSA 0.9rc. In the past, sound support did not work quite correctly. With older kernels, sound was clipped, it looped forever etc. But later kernels (can't remember the exact version, but must ba around 2.4.10) work correctly and I had no problem since then. ALSA works only very recently, but now since it works I prefer it over the kernel OSS support (more features, better design, should also be more compatible with APM/ACPI).

For using the kernel support, you only need to load the "cs4281" kernel module and everything just works. For alsa, you can use my ALSA modules config, which is under Debian located in /etc/alsa/modutils/0.9 and linked from /etc/modutils/alsa. Nothing else to configure (maybe besides setting "startosslayer=true" in /etc/alsa/alsa-base.conf).


I had some headaches with PCMCIA support, but now it works like a charm (now that I know how it must be set up on this hardware). The interesting point is that the "i82365" module from the PCMCIA package sources works with the integrated cardbus controller, but is unable to initalize it - that took me 1 day :-)
So when loading the kernel "yenta_socket" module (which is used for cardbus support), unloading it and then loading the "i82365" module (generated from external PCMCIA package source, not from the kernel), it works. But then loading "i82365" directly, it will be unable to initialize the hardware. To make a long story short: Don't use the PCMCIA package source (which are in the pcmcia-source package in Debian), but use the kernel PCMCIA support. In fact, it works nice with that - here is my PCMCIA config file (in Debian under /etc/default/pcmcia). The only reason for me to try the external PCMCIA modules was to get the prism2 driver for my D-Link DWL-650 wireless LAN card running. But it turned out that although an unpacked and configured PCMCIA source package is needed for compiling this driver, it can also work with the kernel level support (even when the authors of this driver advise against this). Therefore, I installed the kernel (review my kernel config), the PCMCIA package sources, compiled the kernel with Debian's wonderful make-kpkg utility and then compiled the prism2 (linux-wlang-ng-0.1.13, 0.1.14-pre5 didn't work for me) driver. Now everything works. I can connect to access points and use the connections normally and are able to use airsnort and kismet for probing for networks.

I also have a PCMCIA-to-Compactflash adapter (only costs about 11€), which just creates another IDE harddisk device when plugged in - nothing to configure. But beware that removing the adapter without unmounting and maybe using hotplug to remove it from the kernel will hard-lock the system. Switching it off is the only solution known to me.


The network support is painless - the standard kernel module "eepro100" works perfectly. The external module "e100" is an alternative (seems to have more features and is maybe a little faster - but I have not tested this), but at the time I have tried it it had problems with suspends. Therefore I use "eepro100" (you can look at my module aliases in /etc/modutils/local).


I got the internal Lucent-based WinModem to work once, but then updated the kernel and did not care to patch it again. The binary module can be installed, but it requires some work and I usually don't need the modem anyways. You can email me for details, I might be able to remember how it worked when I tried it.

Infrared port

It took me quite some time to get this working, but now it does. In the BIOS, I enabled it as "FIR" (fast infrared) and now use these module aliases to initialize it. When used with the irda-tools package, it is initalized correctly and detects other notebooks and my Nokia 8210 mobile phone when in range. Unfortunately I was unable to get the IrCOMM support with my 8210 to work - so surfing on the road does currently not work. Maybe I will play with that again when I have too much time.
 I have not tried to transfer file between notebook via infrared - I am always using a Ethernet crossover cable to get 100MBit/s.


The USB support works with the standard kernel module "usb-uhci". I have tried it with a optical USB mouse, a HP895Cxi printer, a Philips 680 webcam and a Canon Powershot S40 digital camera - no problems with any.

DVD / Floppy hotplugging

This is kind of weird sometimes, but when using with discipline, it poses no problems. Both the floppy and the DVD drive can be accessed normally when they are plugged in at BIOS boot time (i.e. before Linux is booted) - independently if they are connected via the external port or the home base (one or both). However, I usually deactivate the floppy controller completely in the BIOS when I don't use the floppy. When the controller is enabled, the floppy is not present and Linux tries to access it, there will be a really long timeout. When the controller is disabled, it returns immediately.

Hotplugging: For the DVD drive, it should work with the hotplug package, which seems to be able to tell the kernel to add and remove IDE devices. But I had no time to try it (I will in the near future).
Just removing the DVD drive after it was present when booting the kernel will just freeze the kernel - don't do try that at home :-)
Hotplugging the floppy does not seem to work and I think it will also not be supported by the hotplug package.

External PS/2 mouse and keyboard

Nothing to say about this, it just works when the keyboard and/or the PS/2 mouse (both can be connected simultaneously when the home base is used - it has a second PS/2 port) are/is connected before powering the system on.

Power management

I just recently got the power management fully working, which is now the reason for writing this page. It was difficult for me and maybe this page helps others to get ot running.


Principally, I would like to use ACPI because it has more features and can control the hardware to a much better degree. But at the moment (June 2002) neither the standard ACPI kernel support from kernel 2.4.18 nor the patches from provide a satisfactory degree of support. The kernel support is out of question because it is unable to read the battery state and the acpi patch version 20020517-2.4.18 does never switch off my fan - and this is too much noise for me.....


Because of those reasons, I stick to the APM support, which currently offers everything I need: the battery state is read correctly, the processor fan only runs occassionally when doing heavy computation (like LaTeX or kernel compiling) and suspend-to-RAM as well as suspend-to-disk work. To get this working, I just loaded the normal "apm" kernel module and use the apmd daemon in default configuration.
 However, it took me quite some time to get the suspend-to-disk partition correctly set up so that the BIOS recognizes it. After I exchanged my 64 MB RAM module to a 256 MB one, yielding 320 MB of system memory (with 64 MB being installed on the mainboard), the previous partition was obviously to small. So I made room for enlarging it and re-created it with lphdisk. This didn't work, so I tried the DOS phdisk utility that comes with the notebook - didn't solve the problem either. It seems that the partition table was in a state that the BIOS was unable to interpret correctly. Booting a simple DOS and running fdisk /mbr finally solved. Therefore it might be enough to use lphdisk when the partition table can be understood by the BIOS - but I don't want to try it now.....

Now Fn-Esc sends the notebook to suspend-to-RAM (and waking it up really works :-) ), the "hidden" Fn-a or Fn-q combinations send it to suspend-to-disk. Every piece of hardware is re-initialized when waking the notebook up from either suspend mode (including my wireless LAN card, which I find impressive), with the exception of my USB mouse.
After suspending and waking up, the USB mouse does not work anymore under X-Windows. Removing it, plugging it in again and restarting the X-Server solves the problem, but I would rather have it being re-initialized automatically (without restarting X). I will try to solve this by using GPM for mouse support, but this will take some time.
Update: Now the USB mouse also works after resuming and also when removing it and plugging it in again during the X-Server running. The trick was to use /dev/input/mice instead of /dev/usbmouse for the second input section in the X-Server configuration *and* loading the kernel module "mousedev" unconditionally during bootup - in Debian by adding it to /etc/modules. This module creates the device /dev/input/mice (when using devfs) and is normally loaded by hotplug when the USB mouse is getting plugged in. When it is already loaded when the X-Server starts, everything works like a charm: unplugging it, connecting it, suspend, resume.... I am really amazed by how mature X and USB support are currently.

Harddisk spindown

Under Linux, this has nothing to do with either APM nor ACPI, it is handled by the daemon noflushd. Here you can find my configuration for noflushd (in Debian under /etc/default/noflushd), which spins the hard disk down after 5 minutes of inactivity (and I don't use cron, so it usually stays down).

Various Linux remarks

I use the notebook for nearly everything - writing my diploma thesis (and hopefully soon my PhD thesis) in LaTeX, developing Gibraltar, maintaining my Debian packages, writing letters with OpenOffice, communication via ICQ, Email via Mozilla, ......
You can view my list of installed Debian packages (will most probably not be up to date, but this is a state where I do almost the same as on my main desktop PC).

I used to use ext3 for my Linux partitions, but since it has an own write strategy which can currently not be controlled by noflushd, I switched back to ext2. But I am not very happy with having a non-journalled file system again - when the battery is failing, the next reboot will take a long time :-(

Summary of my configuration files

Some of those files will be Debian specific, some will not. Nevertheless they should help.
X-Server configuration: /etc/X11/XF86Config-4
kernel config: /boot/config-2.4.18
grub menu file: /boot/grub/menu.lst
ALSA modules config: /etc/alsa/modutils/0.9
PCMCIA config file: /etc/default/pcmcia
module aliases: /etc/modutils/local
modules loaded during bootup: /etc/modules
configuration for noflushd: /etc/default/noflushd
list of installed Debian packages (dpkg --get-selections)

All of the correct things were probably borrowed from somewhere else and all of the mistakes are certainly mine...
Rene Mayrhofer, last updated in October 2005, but technical content is still from June 2005


Update 2007-12: now running Kubuntu 7.10

As of December 2007, this Gericom Phantom laptop is now running Kubuntu 7.10 and acts as my parents' mobile "Internet" machine, including UMTS connectivity via one of these Huawei E220 USB UMTS/GPRS modems. The Kubuntu installation went without any difficulty and all the hardware (I haven't tried the Winmodem so far) seems to be supported out-of-the-box and works well. Even the suspend modes (suspend-to-RAM and suspend-to-disk) work without tinkering with all built-in hardware components.
Only two minor tweaks were required with Kubuntu 7.10:

Bootsplash support broken

For some reason I haven't found out, the bootplash support (usplash) doesn't work on the Gericom Phantom. When used, it messes up the console and makes it completely unusable. Therefore, I simply disabled it by removing the "splash" and "vga" options from /boot/grub/menu.lst and calling "update-grub".

PCMCIA WLAN broken after resume

As the Gericom Phantom does not have any built-in wireless LAN, we use it with an old D-Link DWL-650 PCMCIA WLAN (802.11b only) card, which is based on a Prism 2.5 chipset. Kubuntu 7.10 supports it out-of-the box using the hostap_cs module, and after the first bootup with the card inserted, it could be set up easily using the KDE KNetworkManager front-end for NetworkManager. Even WEP and WPA(2) support works without any trouble - in contrast to the D-Link drivers under Windows 2000/XP that don't support WPA at all and WEP only unstably.

The problem was that NetworkManager failed to recognize this card after resume from one of the suspend modes with no apparent difference in configuration than after a fresh bootup. I tried completely unloading PCMCIA support (yenta_socket for the PCMCIA host on the Gericom Phantom, rsrc_nonstatic, pcmcia, and pcmcia_core) and the loaded card modules (orinoco_cs, orionoco, and hermes - none of which are used for this card -, hostap_cs, and hostap), ejecting and re-inserting the card, and re-loading the modules. Nothing got the card to work again. One issues seemed noteworthy, namely that the network interface was wlan0_rename instead of the usual name wlan0. Interestingly, NetworkManager deals with this well after a fresh bootup, but no longer after suspending.
It turns out that the problem was a persistent udev rule created automatically in /etc/udev/rules.d/70-persistent-net.rules. This rules "remembers" the MAC address of the WLAN card to assign the name eth1 when it is inserted. The problem is that the hostap driver actually created two network interfaces: wifi0 as a "master" interface for controlling virtual access points and wlan0 as the actual interface to use, e.g. in managed mode. udev now tries to apply the rule - and thus set the name eth1 - twice, because both interfaces have the same MAC. Obviously, this can't work and the actual interface ends up being named wlan0_rename.

The fix is simple: disable the rule with the respective MAC address in /etc/udev/rules.d/70-persistent-net.rules by putting a hash sign (#) in front, and completely disable the rule generator in /etc/udev/rules.d/75-persistent-net-generator.rules (e.g. by removing the file, but I just commented all the lines in it to make sure that no package update will automatically re-create the file).
Additionally I created a file /etc/modprobe.d/blacklist-local with

blacklist orinoco
blacklist orinoco_cs
blacklist orinoco_pci
blacklist hermes
blacklist prism2_pci
blacklist prism_pci

to prevent the unused orinoco modules from being loaded (and prevent any chance of them interfering with hostap). But I don't think this is necessary to fix the problem.

There seem to be two issues in Kubuntu 7.10 that create this problem: that persistent rules are generated for network modules that create multiple network interfaces with the same MAC addresses, and that NetworkManager can not deal with the resulting mess of interface names after a suspend-resume cycle while it can after a fresh bootup. The first issue is IMHO a real bug in the udev rules while the latter is mostly annoying and makes debugging hard.

This page was last modified on 2010-05-03