|Network||Power & Thermal||Other||Intro|
|CPU||Intel Pentium-M 1.6 GHz (type 730)|
|Motherboard Chipset||Intel 915PM (ICH6M, 82801FBM)|
|Memory||512 Mbytes DDR SDRAM|
|Secure Digital slot||Windows works, Linux works in kernel 2.6.15|
|Suspend Power Modes||Windows works, Linux... not in kernel 2.6.8, yes in 2.6.13 and patched 2.6.12|
Pentium-M 1.6 GHz stepping 08 (type
730). This is the
Sonoma variant of the Pentium-M. See
Intel Pentium M Processor on 90 nm Process with 2-MB L2 Cache and 533 -
MHz Front Side Bus Datasheet, dated January 2005, document number
302189-005, from www.intel.com.
It does not have hyperthreads. It does have stack non-execution. The level 1 cache has 32 KB each instructions and data; the level 2 cache is 2 MB.
CPU dynamic throttling works. To do this you need to run the powersaved daemon, and load the correct driver. For kernel 2.6.8 (SuSE 9.2) this is speedstep_centrino.ko; for kernel 2.6.11 (SuSE 9.3) and 2.6.13 (SuSE 10.0) the driver is acpi-cpufreq.ko; for kernel 2.6.16 (SuSE 10.1) it's back to speedstep_centrino.ko. (I don't know at which exact kernel version the transitions occurred.) The daemon will adjust the speed in four steps from 800 MHz to 1600 MHz according to actual usage. Much of the time your machine is just sitting waiting for you to look at stuff on the screen, and if the lowest speed is used the battery power is correspondingly reduced, but when you actually use the CPU it will be turned to the highest speed in a fraction of a second. When throttling is done manually, a task really does take twice as long at 800 MHz as at 1600 MHz.
However, it is practically impossible for a driver to determine the
correct relation between frequency and supply voltage. The standard, low
voltage and ultra low voltage chips have instances with the same basic
clock speed and different voltage schedules, all with the same CPU ID, and
as for the 715 and 730 chips and others in the same family, they are
individually calibrated at the factory over a 7.5% range of voltage, and
you just have to know which of the five voltage schedules you're supposed
to use for the particular chip you ended up with. In kernel 2.6.8 the
speedstep_centrino driver uses the generic voltage table for the
Dothan family of Pentium-M's. In kernel
2.6.11 the acpi-cpufreq driver uses the ACPI BIOS table, which should
squeeze out more CPU cycles per joule of battery energy.
I hope Dell sets the VID schedule
according to the markings on the chip and doesn't just use the highest
voltage schedule for everyone, which would waste about 1.8 watts for the
best chips. But there's no way to actually tell, without completely
disassembling the laptop.
Here's a comparison of speed on several of my benchmarks.
|CPU||Pentium M||Pentium M|
|Disc||Fujitsu MHT2040BH 5400 RPM Ultra ATA 100 MHz||IBM-Hitachi |
Travelstar4200 RPM ATA 100 MHz
|Western Digital |
Caviar7200 RPM Ultra ATA 100 MHz
Diamond Max 8, 7200 RPM Ultra ATA 133 MHz
|Matrix multiply, 50x50, fits in cache. Tests floating point. (mflop/sec)||694.9||298.9||356.2||333.4||732.2|
odand sort 100 MB. Tests integer. (bytes/cpu sec)
|SysV checksum of 10 MB memory, too big for cache. Tests integer. (bytes/sec times calibration factor)||2.69||1.17||1.11||1.09||2.39|
|Recursive grep of about 2 GB. Tests disc. (bytes/elapsed sec)||1.08e7||8.21e6||5.68e6||4.64e6||4.08e6|
Clearly the chip architecture has as much or more influence on throughput as the raw clock speed, and there are some real surprises in these tests.
Under different conditions the Pentium-M can run faster or slower.
Slow column's performance was attributed to use of
the wrong voltage schedule from the
Dothan processor family, but
further research proves that the culprit is the powersaved daemon; the
only issue from Dothan is that it uses a higher voltage than necessary
at low speeds, wasting power (but not harming the chip). On Dell Inspiron
(and likely Latitude) laptops it costs 26 msec with interrupts off, every
time you check the battery. I haven't proven that this is how powersaved
is slowing down the machine, but it's very plausible.
Avoid old powersaved versions on Dell laptops. However, in version 0.12 (SuSE 10.1) powersaved is OK; it uses ACPI events to monitor the battery and AC power state, rather than polling, and CPU time available to the user is the same with or without powersaved.
If you do CPU-intensive tasks, you definitely should spend the extra money for the Pentium-M vs. Celeron-M. I can't be sure how much the 400 MHz memory (see below) is holding back the CPU, but if Dell had offered qualified 533 MHz memory I would have gotten it.
Intel 915PM (identified on PCI as ICH6M; specific interface chip is 82801FBM). The front-side bus speed is 533 MHz. It includes a PCI Express bridge for the graphics chip.
The motherboard has two slots, each of which can hold 256 MB to 1 GB of dual channel DDR2 SDRAM. The DIMMs are by Hynix (Korea). The speed of these DIMMs is 400 MHz despite the faster FSB at 533 MHz; Dell is notorious for doing this.
SuSE 9.2 includes memtest86-3.1a, which can't handle the 915PM chipset. But both memtest86-3.2 and memtest86+-1.51 work. 9 hours overnight, 39 passes, zero errors.
It works in Windows; the card appears as a disc-type device. And
[update as of 2006-02-21] there is now a Linux driver for it, which soon
will be in the mainline kernel. Until then, follog this link to the driver status and
download page. Check the status and, if necessary, follow the link to
their mail archive where you will find a list of 3 URLs (presently dated
2006-02-06). Download them, patch your kernel, make oldconfig or xconfig,
MMC/SD Card Support (3rd from last
major category, scroll waaaay down) activate the
Secure Digital Host
Controller Interface Support (experimental). The driver's filename is
sdhci.ko, and you need to also load mmc_block.ko to use the card as a block
device. I added these lines to /etc/modprobe.conf.local (my
includes this at the end):
install sdhci /sbin/modprobe mmc_block ; /sbin/modprobe --ignore-install sdhci remove sdhci /sbin/modprobe -r --ignore-remove sdhci ; /sbin/modprobe -r mmc_block
This driver was written for kernel 2.6.14 and I tested it (fully successfully) on 22.214.171.124. On 2.6.13 the patch process needed twiddling and the result did not compile; perhaps the driver could be backported but it would be better to get the latest kernel version.
The controller appears to be the Ricoh R5c822. This is a PCI device which combines a PCMCIA (cardbus) controller with up to 2 slots and a SD controller with 1 slot, appearing on the PCI bus as separate devices. The PCMCIA controller identifies itself as a RL5c576A.
The role of the MMC-SD card is similar to USB flash memory. The advantage of the USB storage device is that all modern hardware (laptops, desktops and servers; Intel, Apple, etc.) have USB ports, which both Linux and Windows support, so you can expect to be able to move data easily between machines. Only a few laptops have MMC-SD slots, although you can get an inexpensive multi-format flash memory interface that plugs into USB. On the other hand, the MMC-SD card fits safely all the way inside its slot whereas the USB device hangs out the side or back of the laptop.
To my mind the MMC-SD card is particularly useful to hold secure host or personal digital keys, or to back up high-value files when you're in the field. Except when you actually use the laptop, keep the card in its plastic case, and that in your pocket, so if the laptop is stolen the card has a chance to be safe. If the data must not fall into enemy hands, encrypt it (and the same on the laptop's disc).
|Suspend to RAM works?||
ATI driver 8.25.18
|Time to suspend to RAM||15-20 sec|
|Time to resume from RAM||5 sec|
|Suspend to disc works?||
ATI driver 8.19.10
|Time to suspend to disc||45 sec|
|Time to resume from disc||37 sec|
In Windows, you can suspend and wake up, surviving the experience. It seems to suspend to RAM. In Linux (kernel 2.6.16 and ATI driver 8.25.18, but not with the Xorg-6.9.0 Radeon driver) suspend to RAM also works. Older kernels are not so fortunate. As is common, suspend to RAM is not useable. It can suspend and get into S3, but upon de-suspending it locks up solid before anything is visible on the screen. Rumors on the net suggest that the ATI M300 graphics chip and/or its X-Windows driver is the culprit; you may (or may not) have better luck with Intel integrated graphics.
Suspend to disc (software suspend) works fine with kernel 2.6.13 (SuSE 10.0) et seq. For 2.6.8 (SuSE 9.2) the kernel tries to de-suspend before it runs the initrd, and so the ata_piix (SATA) disc driver is not loaded at the time it's needed to read the suspended image, and the kernel code that suspends is idiotproof against that contingency. The symptom is that the kernel suspends all the way, then it may or may not (depending on the version) print a comprehensible and easily interpreted error message saying it cannot find the swap device, after which it wakes up, having accomplished nothing but not broken anything either. An inconvenient but effective fix is to compile a custom kernel and hardwire ata_piix and friends into it. (Or better, upgrade to kernel 2.6.13 or later.)
A number of web postings suggest that an erroneously programmed DSDT
can cause various malfunctions in ACPI. However, Dell's DSDT has only
one error: the
wake routine does not return the required result
code, a very common error, and people who have fixed it on other Dell
systems report no improvement in suspending.
Kernel 2.6.8 with customizations still has these idiosyncracies when you suspend to disc. These are fixed in subsequent kernel versions.
Even though I echo shutdown > /sys/power/disk, later something changes it to reboot, meaning the machine reboots after suspending. This is dumb, but until it's tracked down and fixed, just hit the power button when grub shows up. This is fixed in or before 2.6.12-rc1, but the mode occasionally changes to reboot for no reason, so it's best to echo shutdown > /sys/power/disk before every suspend.
In kernel 2.6.8 (SuSE 9.2), after the saved image is re-read, there is a 30 second timeout followed by a beep. I need to track what's causing it and shut it up. I tried unloading most modules, except ata_piix and friends, some crypto (in active use), ACPI (refused to come out) and iptables (same). This shut up the beep :-) but the 30 second timeout was still there. In kernel 126.96.36.199 (SuSE 9.3 stock kernel), after the timeout a kernel panic occurs. In kernel 2.6.12-rc3 the 30 second timeout happens only occasionally (no panic), and there's an error message attributing it to the SATA disc. Kernel 2.6.13 (SuSE 10.0 stock kernel) never has the timeout nor the beep.
The Alps touchpad is not reinitialized (as the Synaptics one was). You need to flip VT's, then flip back. This is fixed in kernel 2.6.12-rc3 or likely earlier.
|Network||Power & Thermal||Other||Intro|