We have three of these machines, purchased mid summer 1999. Having three
has been helpful in trying to debug problems. Ours are 128Mby, 333Mhz 6G
disc machines with the 14" displays. Here are some notes on our experiences
- they are just our own personal observations in getting these machines
going, not the opinions of the university, or the AIG.
Overall they offer an excellent spec for the price, but there are problems,
and getting linux going has been difficult for us. If you are looking for a
linux laptop, then you are probably best to go for a machine listed on the
site as being known to work (unless you like a challenge).
If you have experience of these machines, I'd be interested to hear.
Bios and Windows notes
First some general comments about the machine and its setup, before we get
The bios is Pheonix 4.0 Release 6, pretty
minimal. For example, there is no way of disabling the power on memory
test, or skipping it by pressing "esc". So on a 128M machine, thats a
The power on button is a little strange,
it needs pressing for just the right amount of time: <~20ms causes a
curious up-then-down behaviour, >1 sec turns it off again. Commonly in our
experience the machine fails to boot properly and needs another go. If
caught inadvertantly, it powers the machine down immediately, which can be
a bit unfortunate.
The IDE floppy/zip port has problems;
with the zip in, the machine stalls at boot, needing an resume to
continue. This behaviour varies depending on when you last had the floppy
Under win98, you should know that pico have some additional setup you
need to get the machine to run acceptably (i.e. less than 8 mins to
boot). On the supplied machines there's a directory c:\erd which is not supplied on cd or floppies. If
you reinstall win, then you must run the erd executable in that directory
(which you'll need to have preserved yourself), immediately after
installing win. If you dont the behaviour of the system at boot is very
I've no idea what will happen if you subsequently want to install a newer
version of win.
We have failed to make the "save state to disk
and power down" facility function usably. This could in part be due to
bouncing of the on/off switch.
We use the RedHat 6.0 installation.
Pico dont support linux at all (in our experience), so you are on your own.
X is as always, the bugbear. In this case, the
ragepro-lt graphics card isnt currently supprted (as of mid 99) by the
Mach64 driver with XFree.
Fortunately, the dell inspiron 7000 has the same card, so the advice
offered for that works in many respects. It can be found
We have X working using the linux virtual frame buffer driver mentioned as
the second method to try for getting X working on the Inspiron. That works
fine for 2D, but there is as yet no 3D acceleration for that card. (so
mesa, the opengl work-alike, doesnt benefit from it). The hope is
that the next generation of X, which is in beta, will permit 3D
acceleration on the RageProLT, in which case these will be quite impressive
You will need to follow the advice on the Dell Inspiron page for compiling
your own kernel sooner or later, as the inspiron doesnt have the atapi
floppy/zip, so you'll need to roll your own kernel setup when you want to
The sound card is the same as the
inspiron too, and the advice there is that this is not currently supported
in any linux driver. So, no sound as yet.
The IDE ZIP suffers from the redhat 6.0
zip driver bug, so writing to it will trash the files you are writing to. A
fix has been published recently: either upgrade your kernel, or use the
ide-scsi module to access the zip. We have done the latter, though need to
integrate that into the boot process. Details of the fix can be found via
the redhat bugzilla bug tracking system.
Ethernet. This works fine out of the box
under linux, using the pico ethernet pcmcia card. However I've failed to
get it working properly under windows as yet.
Our biggest problem is that linux engages a power saving feature which
reduces the processor clock by about 5:1. This
kicks in at random and doesnt come out of it. It happens with, or without
X, so seems fundamental. A benchmark loop goes from ~1.5 seconds to ~10
seconds, and the machine becomes pretty unusable. The only cure found to
date is to completely disable APM (Advanced Power Management) in the kernel
- we have tried most combinations of APM tweaks to no avail. Disabling APM
completely, means that the machine burns power whilst idling - so you get
the fan too - and renders the battery monitor inoperable. Disabling APM
also means that the supplied pcmcia software does not work, as it makes
calls on apm routines. Perhaps its possible to recompile the pcmcia
software without that dependency.
So until we find an acceptable fix for the clock speed problem, the machine
is pretty much useless for using linux under batteries. Its ok under mains
power if you dont mind the fan being on and a hot machine.
When linux is working full speed on these machines though, it is a real
joy, and very impressive.
If we get any further with this, I'll update these pages to reflect
that. If you know of any solutions to the above problems, I'd be interested