(c) Dr Paul Kinsler.
[Acknowledgements & Feedback]
Fujitsu-Seimens P7010 lifebook
I've got one, and it runs Slackware 10.2.
Mostly it was configured as per
WWWSITE. My comments below will hopefully be
helpful, but I can't make any guarantees that they'll work for you.
Other p7010 sites are here and
My first choice would have been a Samsung Q30,
but unfortunately the wireless wasn't supported.
I'm not complaining about the P7010 though,
it was more expensive but does have more stuff
My scripts (linked below) are not always in sync with these
text descriptions -- the text is updated more often.
Latest update at 20070807.
I started off with the 184.108.40.206 kernel (config),
based on the 2.6.7 one from WWWSITE,
using make oldconfig and tweaking it for my purposes.
Now I have upgraded (as of 20060504) to
I have compiled more recent kernels,
but usually give up at that point because I have no pressing need to upgrade,
and I don't have the time for all the extra tweakery needed to get
all the associated stuff to work.
Especially since I have forgotten most I what I did last time.
Wireless and Ethernet
01:0d.0 Network controller: Intel Corporation PRO/Wireless 2200BG (rev 05)
01:0c.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+ (rev 10)
To get wireless going most easily,
I chose a post 2.6.13 kernel (starting with 14-rc2, now updated) since they
have built-in ipw2200 drivers,
although not the latest ones
(see the ipw2200 sourceforge project).
However, you still have to get the correct firmware version
from (the sourceforge project),
and put it in the right place (/lib/firmware).
I found that (in <=2.6.14) both the 8139 ethernet card and the ipw2200
called themselves eth0 by default;
so I used modprobe ipw2200 iface=eth1 in rc.modules
so that wireless came up as eth1. From 2.6.16, the iface argument
had vanished, but ipw2200 seems smart enough to call itself
eth1 without prompting.
In order to get the wireless to work after an acpi_poweroff suspend (see below),
I need to rmmod/modprobe the ipw2200 module.
Touchpad/ scroll buttons:
(touchpad/scroll) I use the Synaptics TouchPad driver for XOrg/XFree86,
(touchpad/scroll) WWWSITE reports that append = "i8042.nomux" was necessary as a boot parameter,
although I don't need it. However, I did have to do just modprobe psmouse;
whereas before (for some reason) I had modprobe psmouse proto=imps,
which stopped X detecting the touchpad at startup. Only took me an hour to redscover that when I rebooted recently.
For some reason a few keys ( ]#/` and down-cursor) on my keyboard have stopped working.
Until I get a real fix,
I've just remapped the missing ones (using loadkeys) onto some
This covers both console and X.
I found xev a useful way to see what keypresses were (or were not) doing.
The dead down-cursor is a pain,
because I need it to navigate the BIOS settings;
if it wasn't for this I'd have tried reset-factory-defaults
in the BIOS in the vague hope it'd fix the key problems
(if it isn't an OS problem, so it must be hardware or BIOS ..?).
See my acpi_handler.sh;
The acpi_poweroff suspend-to-disk (i.e. swap) now works so well that
I almost never need to reboot. I've linked this to the power
button using acpi_handler.sh. The basic commands are
echo shutdown > /sys/power/disk ; echo disk > /sys/power/state.
After an acpi_poweroff suspend/resume,
for some reason button/lid events no longer get sent
to acpi_handler.sh, but this can be fixed by
always doing rmmod button; modprobe button
immediately following the resume.
I do all my acpi_poweroff suspend/resume stuff in my
currently my rc.hibernate is non-executable called manually from
I haven't done a lid open/close-triggered suspend/resume (to memory)
for a while, so don't remember how well it worked; I needed the
rmmod button; modprobe button to avoid losing button
I don't know whether the ACPI_BATTERY glitch still exists
(I think so, but haven't carefully checked ),
so I rmmod battery before suspending to memory;
and modprobe battery afterwards.
Annoyingly, X doesn't always survive the suspend/resume cycle:
the sucess rate is maybe 60-80% of the time. I'm
inclined to guess this because the 855resolution doesn't always
get done in time; but I really have no idea. I also get the vague impression
it's more likely to survive if I unplug network/modem/etc cables,
but this may be illusiory. I now use chvt 1 to switch to a console
window before suspending, and chvt 7 post-resume,
this seems to help X survive.
CPU speed switching
I use the kernel's cpu frequency switching;
i.e. modules speedstep_centrino and cpufreq_conservative.
Graphics and X:
00:02.0 VGA compatible controller: Intel Corporation 82852/855GM Integrated Graphics Device (rev 02)
00:02.1 Display controller: Intel Corporation 82852/855GM Integrated Graphics Device (rev 02)
Screen resolution 1280x768:
855resolution works fine to get the
best screen resolution in X (see also WWWSITE).
X sometimes survives my suspend/resume cycles, but not always
Curiously, my console resolution is now stuck in a state which
uses only the middle portion of the screen, in a correspondingly
smaller font; this has persisted even after many reboots; however
resently I went into the BIOS settings at bootup and it switched
back (until re-reboot). I'm currently
ignoring it as it is only mildly irritating: I presume the reason
is that 855resolution borrows the default 1024x768 mode and
makes it into 1280x768; this rewriting apparently persists even when
the laptop is turned off.
Preserving my desktop state:
To avoid losing all the apps sitting on my X desktop(s) across the
suspend/ resume process, I use VNC.
I run a VNC server
and now do all the work I want to preserve inside
a vncviewer connected to that server. Since the server is preserved
across the suspend/ resume (even if X dies), I just log in at the restarted X
prompt, and then (again) use vncviewer to conect to the server.
Much easier than learning the ins and outs of restoring the video
state and/or preserving X, and worked first time.
Sometimes when using vncviewer in fullscreen mode,
F8 seems to stop working and I get stuck.
I then try to switch back to a console, log in,
and kill the vncviewer -- it is easy to restart and
nothing gets lost.
SD and Memory stick slot:
01:0a.3 System peripheral: Ricoh Co Ltd R5C576 SD Bus Host Adapter (rev 01)
01:0a.4 System peripheral: Ricoh Co Ltd R5C592 Memory Stick Bus Host Adapter
for an early attemt to get this going; I haven't (yet) tried it myself though
(and thanks to Chris D. Vighagen for the pointer).
CF slot (and PCMCIA):
01:0a.0 CardBus bridge: Ricoh Co Ltd RL5c476 II (rev ab)
01:0a.1 CardBus bridge: Ricoh Co Ltd RL5c476 II (rev ab)
CF works fine, with memory cards appearing as hde;
and a NE2000 compatible CF ethernet card works fine too.
I'm sure I've even had a wireless card
recongised and working in there (although I didn't connect
wirelessly to anything) -- but
unfortunately my wireless CF card got bent/ broken and now works
only very intermittently.
I use this BP script to report battery status;
it saves reports to a file and uses those when
called by users (because I keep modprob'ing/ rmmod'ing the battery module.
I run it at 15m intervals from cron. It's a
bit of a mess and needs cleaning up, but it works for me. Also
I have a BP-watch script, run every
two minutes that shuts down if the battery gets very low --
it's quite irritating to forget it's not plugged on AC and have
the power fail on the system.
Kernel compilation (1)
On a vt (not X)
seems to use about 10% of the capacity (at circa 74% to 64%)
in 20 minutes (this implies that when working it hard, I'd get 3 hours battery life).
Of course it takes a little longer than that to
compile a kernel & modules.
Kernel compilation (2)
On X, I went from 47% to 0% in just over hour (coincidentally, as
long it took to compile kernel 220.127.116.11 and modules).
Note that the reported remaining
charge dived faster as the hour progressed: 47%, 43%, 36%, 20%, 10% in
15m intervals, followed about 5m later by nearly 0%.
Recently I used it for 45minutes on a train doing some random
desktop things, and running some code (maybe 30-50% of the time),
and it ate 5%-10% of the battery from 100% charged.
(this implies that in general use, I'd get 10+ hours battery life).
00:1d.0 USB Controller: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #1 (rev 03)
00:1d.1 USB Controller: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #2 (rev 03)
00:1d.7 USB Controller: Intel Corporation 82801DB/DBM (ICH4/ICH4-M) USB2 EHCI Controller (rev 03)
Seems to work fine.
- Firewire: (unused)
01:0a.2 FireWire (IEEE 1394): Ricoh Co Ltd R5C552 IEEE 1394 Controller (rev 03)
- Sound (works):
00:1f.5 Multimedia audio controller: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) AC'97 Audio Controller (rev 03)
- Modem (works):
00:1f.6 Modem: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) AC'97 Modem Controller (rev 03)
Some googling about found information suggesting the slmodem driver should work
with this hardware (based on googling for intel ac97 modem 2.6 82801DB).
You can get a commercial version from
SmartLink, although (as I read it) their license seems to require
you've bought the modem from them. Alternatively, (older/ restrictive/ equivalent?) versions are
available from linmodems.
Some other pages suggested that hsfmodem from
I've just downloaded slmodem-2.9.11-20051101 from linmodems, it compiled and installed
OK, and the result looks like a modem from minicom; and I've sucessfully dialled up my ISP.
- Other things:
00:00.0 Host bridge: Intel Corporation 82852/82855 GM/GME/PM/GMV Processor to I/O Controller (rev 02)
00:00.1 System peripheral: Intel Corporation 82852/82855 GM/GME/PM/GMV Processor to I/O Controller (rev 02)
00:00.3 System peripheral: Intel Corporation 82852/82855 GM/GME/PM/GMV Processor to I/O Controller (rev 02)
00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev 83)
00:1f.0 ISA bridge: Intel Corporation 82801DBM (ICH4-M) LPC Interface Bridge (rev 03)
00:1f.1 IDE interface: Intel Corporation 82801DBM (ICH4-M) IDE Controller (rev 03)
00:1f.3 SMBus: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) SMBus Controller (rev 03)
At one point, shortly after I got it,
the BIOS refused to to let me select the CD as a boot option.
This made it rather hard to install linux.
A call to the manufacturers support line
told me to "restore factory defaults" in the BIOS;
it could then be selected as normal.
This seems to be some random thing that sometimes happens,
apparently (I forget the marginally less vague explanation from the
The pre-existing NT partition:
I used the bundled Northon Ghost to squash the Windows NT partition into
something that I could fit in a small partition on the HD.
Thus I stll have the pre-installed OS,
although I can't boot from it (and don't much care, to be honest),
but it might be useful sometime.
Date=20070807 0328 0323 0221 0210 0209 20060126 1222 20051122 20051021 Author=P.Kinsler Created=20051021