lspci (version 2.2.4), we find the following components listed:
00:00.0 Host bridge: ATI Technologies Inc RS480 Host Bridge (rev 01) 00:01.0 PCI bridge: ATI Technologies Inc RS480 PCI Bridge 00:13.0 USB Controller: ATI Technologies Inc IXP SB400 USB Host Controller 00:13.1 USB Controller: ATI Technologies Inc IXP SB400 USB Host Controller 00:13.2 USB Controller: ATI Technologies Inc IXP SB400 USB2 Host Controller 00:14.0 SMBus: ATI Technologies Inc IXP SB400 SMBus Controller (rev 10) 00:14.1 IDE interface: ATI Technologies Inc Standard Dual Channel PCI IDE Controller ATI 00:14.3 ISA bridge: ATI Technologies Inc IXP SB400 PCI-ISA Bridge 00:14.4 PCI bridge: ATI Technologies Inc IXP SB400 PCI-PCI Bridge 00:14.5 Multimedia audio controller: ATI Technologies Inc IXP SB400 AC'97 Audio Controller (rev 01) 00:14.6 Modem: ATI Technologies Inc ATI SB400 - AC'97 Modem Controller (rev 01) 00:18.0 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] HyperTransport Technology Configuration 00:18.1 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Address Map 00:18.2 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] DRAM Controller 00:18.3 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Miscellaneous Control 01:05.0 VGA compatible controller: ATI Technologies Inc ATI Radeon XPRESS 200M 5955 (PCIE) 08:08.0 CardBus bridge: O2 Micro, Inc. OZ711MP1/MS1 MemoryCardBus Controller (rev 20) 08:08.2 Generic system peripheral [0805]: O2 Micro, Inc. Integrated MMC/SD Controller 08:08.3 Bridge: O2 Micro, Inc. Integrated MS/xD Controller 08:09.0 Ethernet controller: Broadcom Corporation BCM4401-B0 100Base-TX (rev 02) 08:0a.0 Ethernet controller: Atheros Communications, Inc. AR5006X 802.11abg NIC (rev 01) 08:0b.0 FireWire (IEEE 1394): Texas Instruments TSB43AB21 IEEE-1394a-2000 Controller (PHY/Link)Also,
/proc/cpuinfo reports:
processor : 0
vendor_id : AuthenticAMD
cpu family : 15
model : 36
model name : AMD Turion(tm) 64 Mobile Technology MT-28
stepping : 2
cpu MHz : 800.000
cache size : 512 KB
fpu : yes
fpu_exception : yes
cpuid level : 1
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx
fxsr sse sse2 syscall nx mmxext fxsr_opt lm 3dnowext 3dnow pni lahf_lm
bogomips : 1594.17
TLB size : 1024 4K pages
clflush size : 64
cache_alignment : 64
address sizes : 40 bits physical, 48 bits virtual
power management: ts fid vid ttp tm stc
The S2110 comes with a Phoenix® BIOS, versioned 1.04. When Tim encountered a number of issues on the system, he contacted support and they supplied him with version 1.06, which has not been released to the public. Later, Fujitsu released versions 1.08 and 1.11.
For most of the issues encountered while running on Linux, it doesn't seem the newer BIOSes have helped a lot. The only exception is with ACPI support, where it appears some S3/S5 sleep mode issues may have been resolved. YMMV.
Early BIOS updates could only be installed from Windows, but with later releases Fujitsu made available a FreeDOS-based boot ISO, which makes the process much easier for Linux users. The latest boot ISO (as of this writing, version 1.11) can be obtained here.
The configurations and functionality statuses below apply to the system when running the following software:
Here is Tim's .config for Linux kernel version 2.6.18.
Also note, that Tim currently boots with the following additional options, which fix various issues:
no_timer_check irqpoll pci=assign-bussesJeremy uses the following boot options with his 2.6.12 kernel:
i8042.nomux noapictimer acpi=noirqSee details below for the reasons we use the options.
Working (although I haven't tried anything graphically intensive)
I used the ATI Linux fglrx drivers. Although, the standard installation program didn't work well. This page provided more helpful instructions: http://xoomer.virgilio.it/flavio.stanchina/debian/fglrx-installer.html
Load "int10"in the xorg.conf file.
fireglcontrolpanel tool doesn't seem to work on AMD64, or at least Debian doesn't support the necessary drivers.
Working
Works using ALSA and the snd_atiixp module
Mostly Working
The touchpad is recognized as an AlpsPS/2 ALPS GlidePoint on isa0060/serio4
Should be able to use the synaptics kernel module
The middle "scroll buttons" don't work. Currently they only act as a single third button.
Configuration for /etc/X11/xorg.conf
Section "InputDevice" Driver "synaptics" Identifier "ALPS" Option "Device" "/dev/psaux" #Option "Device" "/dev/input/event3" Option "Protocol" "auto-dev" #Option "Protocol" "event" Option "CorePointer" Option "SHMConfig" "on" Option "LeftEdge" "120" Option "RightEdge" "830" Option "TopEdge" "120" Option "BottomEdge" "650" Option "FingerLow" "14" Option "FingerHigh" "15" Option "MaxTapTime" "180" Option "MaxTapMove" "110" Option "EmulateMidButtonTime" "75" Option "VertScrollDelta" "20" Option "HorizScrollDelta" "20" Option "MinSpeed" "0.3" Option "MaxSpeed" "0.75" Option "AccelFactor" "0.015" Option "EdgeMotionMinSpeed" "200" Option "EdgeMotionMaxSpeed" "200" Option "UpDownScrolling" "1" Option "CircularScrolling" "1" Option "CircScrollDelta" "0.1" Option "CircScrollTrigger" "2" EndSection
Tim found that with some kernel versions, the kernel does not automatically
detect the touchpad at all. To work around this issue, the kernel boot
parameter i8042.nomux seems to work pretty well. However,
with kernels as late as 2.6.18 (at least Debian's flavor) this option
doesn't seem to be necessary.
Working
The Broadcom Corporation BCM4401-B0 100Base-TX (rev 02) ethernet controller
has a reverse-engineered driver distributed with newer 2.6 Linux kernels. The config symbol
is B44 and the module name is b44.
Jeremy has had problems tranferring files with FTP to/from a host on the LAN, but other hosts seemed fine.
Tim hasn't had any issues with the ethernet in the later 2.6 series kernels.
Working
The Atheros Communications, Inc. AR5006X 802.11abg NIC (rev 01) WiFi controller
seems to work well now with the newest stable MadWifi-NG
drivers (version 0.9.2.1).
If you are new to MadWifi-NG, it is designed in such a way as to allow multiple virtual cards to work in parallel on the same physical device. This means one could (in theory) create one virtual card to run as an AP, another to run as a client on some other network, and a third to run in ad hoc mode, all at once. It is best if you follow the documentation on madwifi.org to understand how this all works and how to use the command line tools.
Tim has found that release version 0.9.2.1 of the MadWifi drivers work well when using only a single virtual interface, but when multiple are used (such as one running an AP and another connecting to a secondary network), the secondary won't work.
However, Tim also tried using the unstable drivers in subversion (rev 2002) and was able to get HostAPD in parallel with wpa_supplicant on separate virtual interfaces (using Kismet on a monitor interface didn't work in parallel, though). However, this revision of the drivers also caused Tim's kernel to panic periodically. Perhaps the next stable release will resolve both the parallelism and the panics.
I found this a very helpful resource: [1]
I'm not sure which of these are supported by Linux itself, as I've not really messed with this. Without changing anything, though, I can only say that the screen-brightness buttons work.
Mostly Working
To disable wakeup on lid event, put this in some startup file (I put in /etc/init.d/acpi under "start)"):
echo 'LID disabled' > /proc/acpi/wakeup
Contents of /etc/acpi/powerbtn.sh (mode 644):
#!/bin/sh # /etc/acpi/powerbtn.sh # Initiates a shutdown when the power putton has been # pressed. SUSPEND_LOCK=/var/lock/suspend if [ -e $SUSPEND_LOCK ]; then # WE'RE in the middle of returning from suspend, # so we don't need to shut off again exit else touch $SUSPEND_LOCK echo Entering Suspend Mode #DO OTHER THINGS HERE??? #It's probably a good idea to rmmod any wireless modules here #Last minute hard drive sync /bin/sync # Tell the system to suspend to memory echo mem > /sys/power/state # Return to the windows termnial /sbin/hwclock --hctosys # And also to modprobe those wireless modules somewhere around here # Delay awhile before removing the lock # otherwise, the button even would execute again, # causing an infinite loop of sleeping (sleep 20;rm -f $SUSPEND_LOCK)& exit fi #if ps -Af | grep -q '[k]desktop' && test -f /usr/bin/dcop #then # dcop --all-sessions --all-users ksmserver ksmserver logout 0 2 0 && exit 0 #else # /sbin/shutdown -h now "Power button pressed" #fi
Contents of /etc/acpi/events/powerbtn
event=button[ /]power action=/etc/acpi/powerbtn.sh
The processor in this system supports just two CPU throttling states, 50% and 100%. Fortunately kernel modules exist which support these states nicely. Simply be sure the following modules are loaded or complied in to the kernel:
powernow-k8 cpufreq_ondemand
Tim has found that the best power save governor to use is the ondemand one, as it seems to change the throtting levels when expected. YMMV. See the documentation that came with your kernel sources (/usr/src/linux/Documentation/cpu-freq) for more information.
Tim has also added some scripts to turn on Linux's "laptop_mode" whenever the AC power is not connected. This mode simply causes the Linux kernel to sync data to disk at a lower frequency, thereby saving battery life. To accomplish this, a boot-time script checks to see if the AC power connected, and sets the laptop_mode accordingly. (This boot-time script also happens to set the power governor to ondemand.) From that point on, acpid is configured to catch AC power changes and set or unset laptop_mode as necessary. Feel free to use the boot-time script and acpid script on your systems. The acpid script needs an associated configuration such as:
event=ac_adapter action=/etc/acpi/ac_adapter.sh %e
It's also interesting to note the the current fglrx drivers available from Debian will install similar hooks into the ac_power and lid events to reduce the power usage of the monitor.
Working
USB seems to work great on this system, using the OHCI and EHCI modules (ohci_hcd and ehci_hcd respectively).
Working
This system comes with a 400Mbit FireWire Controller by Texas Instruments. lspci reports:
FireWire (IEEE 1394): Texas Instruments TSB43AB21 IEEE-1394a-2000 Controller (PHY/Link)
The FireWire support seems to be flawless. Tim simply loads the following modules:
ieee1394 ohci1394 sbp2
and he is able to use external drives through the FireWire port. Tim also found that adding the following module options to the sbp2 module increases read and write speeds by 10-20%:
synchronize_io=0 max_sectors=2048
These options can be added in a number of different ways, depending on Linux distro, but in recent Debian versions, creating a file at /etc/modprobe.d/sbp2 which contains the following line should work fine:
options sbp2 synchronize_io=0 max_sectors=2048
Working
TODO
Not Working
http://www.cs.sfu.ca/~ggbaker/personal/cf-linux
Windows Recognizes: O2Micro Integrated MMC/SD Controller : PCI Bus 8, Device 8, Function 2 O2Micro Integrated MS/xD Controller : PCI Bus 8, Device 8, Function 3
Not Working
Probably want to try [the apanel project]
apanel requires a working i2c subsystem, but I can't get that to work here
The sensors-detect tool, which comes with the lmsensors package is supposed to be able to detect the correct i2c module to load, but on this system it can't find one.
There appears to be a rather significant clock skew problem, with the clock running at twice the normal speed. Jeremy added the noapictimer kernel boot parameter and that seemed to fix this problem. Tim found that the no_timer_check boot option worked best for him.
With either of these approaches, there is still an issue with the clock booting with the wrong time initially, and occasionally some small clock skew still crops up.. Using ntpdate and ntpd are strongly recommended for this system.
Tim's system has always experienced periodic kernel messages such as:
kern.debug: APIC error on CPU0: 40(40)
It is not clear what's causing these or how they should be fixed.
Tim's current kernel spewed out the following message about transparent PCI bridges:
kern.info: PCI: Transparent bridge - 0000:00:14.4 kern.warn: PCI: Bus #09 (-#0c) is hidden behind transparent bridge #08 (-#09) (try 'pci=assign-busses') kern.warn: Please report the result to linux-kernel to fix this permanently
After adding the specified option, the message went away, but there wasn't any perceived change in functionality or device detection. For some of the system's more exotic devices (possibly the SMBus?), this may have an important impact though. If someone figures out what effect this might have on this laptop, please let me know, or notify the linux kernel mailing list.
This page was originally authored by Jeremy Whelchel.
It is now maintained by Timothy D. Morgan.