/ tuxmobil.org / DELL laptops
Last update: August 24, 2006 (wi-fi section)
Summary: This laptop is quite Linux friendly and can be set up to be very much usable with this OS. Rather surprisingly, perhaps, since it is a fairly new piece of hardware in the time of writing this page (the first wave of Core Duo laptops, 2 months after launch). Some things still need some manual adjustments, though, but I expect these will be greatly reduced once new versions of distributions such as SUSE 10.1 or Ubuntu Dapper are out. These are not exactly my cup of tea (especially SUSE) but might be yours.
Below is a list of things I tried together with results of my attempts. Bold red text means that the item does not work satisfactorily with the Slack 10.2 default install and some (maybe significant) labour is needed. All devices inside the laptop as printed out by lspci.
|processor||Intel Core Duo T2300 (1.66GHz)||works fine|
|X-server||Intel integrated i945GM graphics chip||works fine|
|sound||Intel High Definition Audio||works fine|
|DVD +/- RW||NEC ND-6650A (dual layer?)||works|
|ethernet||Broadcom BCM5752 Gigabit Ethernet||works fine|
|Wi-Fi||Intel 3945||works fine|
|ACPI||fan control, CPU frequency scaling, battery etc.||works fine|
|ACPI||suspend to RAM||works unreliably|
In short: To achieve the indicated working status I use Slackware 10.2 with a custom kernel (2.6.16 from SUSE updates - kernel-source-2.6.16-12.src.rpm - with my rather minimal/conservative .config) and patched X.org 6.9.0 X-server.
The default installation kernel does not see the disk as SATA (/dev/sda) but as IDE (/dev/hda). There is a choice of several installation kernels but I did not experiment with that. I simply installed to /dev/hda then compiled my own kernel and changed all occurrences of /dev/hda to /dev/sda in /etc/fstab and /etc/lilo.conf (and run lilo).
With the stock X.org 6.8.2 that comes with Slack 10.2 works nothing but the "vesa" driver. To get native resolution of the LCD (1440x900) one needs to patch the video BIOS with 915resolution utility,
915resolution 5c 1440 900
before starting X, preferably somewhere inside start-up scripts, such as in /etc/rc.d/rc.local. (Well known issue for all i8xx and i9xx graphics chips from Intel.)
Upgrading X-server to X.org 6.9.0 from Slackware-current (the latest X.org release) does not help to get native (i.e. accelerated) graphics support. Driver "i810" still complaints it cannot detect any known device. Fortunately, patches for X.org 6.9.0 exist that resolve this issue and one thus can get Xvideo as well as GLX/DRI with the "i810" driver. To access "1440x900" resolution with "i810" driver an appropriate modeline is needed in /etc/X11/xorg.conf inside the "Monitor" section (it is not necessary with the "vesa" driver). I use
Modeline "1440x900" 108.84 1440 1472 1880 1912 900 918 927 946
generated with the aid of an on-line modeline generator. Working packages compiled on Slack 10.2 (these links might be unstable, I have slight problems with hosting such large files):
The patches to compile the X.org yourself (found in the context of Ubuntu "Dapper Drake" development):
(Thanks to Maarten Wisse.)
replace="58" with="1280 800" replace="38" with="1280 800"
Option "ForceBIOS" "1280x1024=1280x800"
ALSA sound driver for Intel high definition audio behaves strangely in older kernels (sound in both speaker and headphones, or no sound at all although drivers seems to be loaded O.K.). Fortunately, very recent kernel versions work (successfully tested with 2.6.17-rc2 and SUSE patched 2.6.16). The only small annoyance is that sound remains silent after the laptop wakes up from suspended state. The easy fix is to change a volume a bit with some mixer application. I do that automatically inside the acpi_handler.sh script, see below.
The drive can be operated as an IDE device, as a SCSI device through "ide-scsi" kernel interface or as a SCSI device through SATA (decided inside Linux, no BIOS setting needed, actually none available anyway). The first two options do not allow to switch on DMA (which is quite limiting for reading/writing speed) while the third one is still quite experimental. Some further reading on this issue. I decided to completely switch off the IDE/ATA layer (not to compile into the kernel - otherwise it tends to be used as a default interface for the CD-ROM). I use the SCSI/SATA mode provided via Intel PIIX/ICH driver. This way the DVD+/-RW works O.K., no problems encountered so far.
Works quite flawlessly with tg3 module/driver. The only glitch shows up while suspending while not having the network activated. (I prefer to switch of DHCP configured network before suspending the laptop to avoid possible conflicts in a new networking environment the machine might be connected to after resuming from sleep.) If the ethernet device is not configured at suspend time, the network card does not get reactivated properly on wake up. The solution is rather simple - unload tg3 module before suspend and insert back afterwards. See my acpi_handler.sh script in the suspend to RAM section.
Note: This thing might be related to the power saving behavior the ethernet card shows under Windows XP - if you unplug ethernet cable while on battery power, the card powers off and can be brought back only after connecting to a power outlet.
Wi-fi works fine with the driver available at http://ipw3945.sourceforge.net/. Just follow the instalation instructions provided there. Make sure that your kernel has enabled everything needed (my .config; the one provided on this page previously has some features missing). Then modify 3 configuration files if your Slackware system: /etc/modprobe.conf, /etc/rc.d/rc.inet1.conf and /etc/rc.d/rc.wireless.conf. The relevant lines to change/add are:
install ipw3945 /sbin/modprobe --ignore-install ipw3945 ; \ sleep 0.5 ; /sbin/ipw3945d --quiet remove ipw3945 /sbin/ipw3945d --kill ; \ /sbin/modprobe -r --ignore-remove ipw3945
# Config information for eth1: IPADDR="" NETMASK="" USE_DHCP="yes" DHCP_HOSTNAME=""
Here remove the section on the top as indicated inside this file and modify the default entry of the "case" statement at the very bottom. Below is shown very minimal configuration with advanced settings turned off by default. Put the name of your network into ESSID.
# Generic example (decribe all possible settings) *) INFO="Fill with your own settings..." ESSID="tady_je_Krakonosovo" NWID="" MODE="Managed" FREQ="" # CHANNEL 0 means any CHANNEL="0" SENS="" RATE="auto" KEY="" RTS="" FRAG="" IWCONFIG="" IWSPY="" IWPRIV="" ;;
This part of ACPI support is perfect, fan switches on/off as needed, battery status is reported and CPU frequencies are adjusted according to load (in my case between 3 states – 1.00 GHz, 1.33 GHz and 1.66 GHz). Frequency scaling needs to be activated (in an init script) with
echo "ondemand" >> /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor echo "ondemand" >> /sys/devices/system/cpu/cpu1/cpufreq/scaling_governor
as the default governor is "performance", which keeps CPUs at maximum frequency. Another possible governor is "conservative" that behaves similarly to "ondemand".
Suspend to RAM works quite reliably with 2.6.16 kernel from SUSE distribution/updates. (With vanilla kernels I had no success at all, I suspect it is due to problems somewhere in SATA/SCSI.) One needs to be in X-window when suspending the machine, otherwise the display would not wake up (see Documentation/power/video.txt inside the kernel source tree for more comments on that). The X-server must be configured to use "i810" driver, "vesa" does not seem able to wake up the display.
There are some small issues with sound and ethernet (mentioned in the respective sections above) that are handled inside the /etc/acpi/acpi_handler.sh script. I put quite a lot of comments in that file, so enjoy.
If you have looked into the script you have found that there is no reaction to the "lid" event. Yes, I am using solely the "Stand by" button (Fn-Esc) to suspend the machine and only then I close the lid as the laptop responds somewhat strangely to closing the lid when the system is on. After the lid is closed, the display always switches off whether I call
echo "mem" > /sys/power/state
as a response or not. If I do, the system does not finish the suspending sequence properly, and if I don't the laptop is also unusable, since the screen is off. In both cases the only way out is Ctrl-Alt-Del from an invisible console. It might be that the notebook's BIOS wants to be smart and does some action that Linux does not expect to happen. Unfortunately, I did not find any related setting in BIOS (that overall has a very limited set of options).
I am experiencing some random issues with SMP enabled kernel (uniprocessor works just fine). Sometimes the suspending operation does not finish. Fortunately, machine usualy does not freeze, it is almost always possible to (blindly – as the screen was already gone) switch to a console and reboot with Ctrl-Alt-Del.