Dell Inspiron 6000d
Components: Discs

James F. Carter <jimc@math.ucla.edu>, 2005-03-30 (updated 2005-12-10)

Component Details: Discs

Hard disc

Fujitsu MHT2040AH, 40 GB, 5400 RPM. This is not one of the notorious IBM-Hitachi Deathstars, a model where they pushed a design parameter farther than was wise, and ended up having to replace a lot of customers' drives. Nominal reported size is 40.0 GB before overhead. Windows reports 33.8 GB. There were two hidden partitions with Dell Diagnostics (56 MB only) and System Restore (3.5 GB). Linux reports 37.3 GB total. The average transfer rate for reading data sequentially from the raw device is 3.30e7 byte/sec.

See here for how to run the Dell Diagnostics.

The interconnection style is Ultra ATA at 100 MHz. However, the disc controller in the 915PM chipset can also do SATA, and therefore Linux uses the ata_piix driver and SCSI emulation. The disc appears as /dev/sda. Involvement of the ata_piix (SATA) driver creates a number of problems which one would not have with a parallel ATA drive, which are mentioned where they rear their nasty heads. Linux developers are working on them...

Here are some tidbits from the drive's data sheet:

• Seek time: track to track 1.5 ms, average 12 ms, maximum 22 ms.
• Average latency 5.56 ms.
• Data transfer rate (burst): 1.5e8 byte/sec.
• Buffer size: 8 MB
• Error rates: 1 unrecoverable read error per 1e13 bits read. 1 seek error per 1e6 seeks. I'm assuming that unrecoverable means beyond the ability of the error-correcting codes to recover from, and if the read were done over, as the driver would naturally do, success would be likely unless the platter were actually damaged. Similarly, I'm assuming that the drive or the driver would check the destination sector address, would be aware that a seek had been botched, and would do it over.
• Startup time: 4 seconds.
• Power: Spin-up 5 W, operating 2.3 W, spinning with heads unloaded 0.85 W, motor off 0.25 W, electronics asleep 0.1 W. The drive has intelligent power management and should be allowed to shift between states by itself. A competitor claims, on a similar drive, that battery life can be increased as much as 8% by leaving the drive alone, compared to shutting it off a fixed time after the last access.
• Ramp head loading. This means that the heads are pushed up a ramp off the surface. The lifetime of the ramp is nominally 3e5 load-unload cycles (probably a lot more; this is hard to test, and competitors guarantee 3e5 cycles but claim to have tested to 1e6 cycles). That would be one cycle every five minutes 24 hours per day for three years. The lifetime for what they call emergency head unloads is 2e4 cycles, similar to non-ramp drives.
• Shock: 225G operating, 900G non-operating. It recalibrates the position of the disc whenever it starts up.
• Vibration: 1G operating, 5G non-operating.
• Temperature: 5 to 55 C operating, -40 to 65 C non-operating.
• GMR heads (Giant Magnetoresistance, an effect of spin tunneling suppression in layered manganate perovskite)
• MEEPRML (Modified Extended Enhanced Partial Response Maximum Likelihood) read channel technology
• Fluid dynamic bearings (oil, versus ball bearings; no metal-to-metal contact)
• Mass: 99 grams.
• Format: 2 platters, 2 heads per platter.
• Warranty: 3 years, only for OEMs. End users must claim from their OEM (Dell).

Optical disc

Toshiba-Samsung CDRW/DVD SN-324S 24X CD burner and DVD reader. It's a fixed drive, i.e. takes a screwdriver to put in a different drive, but only one screw. It's on the left side, which is an improvement over the Inspiron 4100, which had it on the front and the drive opened into your stomach.

As delivered, the drive misbehaved seriously in Windows; it could not read the SuSE installation discs and had many errors when burning. Be sure to get the R90275 driver patch from Dell, identified as being for the Sonic RecordNow software, which cures all these problems. The writing style appears to be packet writing.

On Linux [kernel 2.6.8] the result was similar. Burning was tested using k3b with the most conservative settings, e.g. not on the fly, DAO mode, and nominally at 2X. 390 MB was written. This took 11 minutes (6.16e5 b/s 4.1X). On readback there were actual I/O errors on 1% of the files, i.e. diff had to exit without reading the whole file. This error rate is not acceptable. I blame it on not having DMA, even though Burnfree was turned on.

In kernel 2.6.13 (SuSE 10.0) the DMA problem is fixed, out of the box. I have not determined whether the needed patch, described below, is merged yet with the general kernel sources, but the developer works for SuSE and the patch is in the kernel that SuSE distributes.

On Linux, with kernels 2.6.8 and 2.6.11 (and from web reports, likely any earlier 2.6.x kernel), on any chipset with a SATA primary disc controller, there is a wretched tangle that prevents DMA from being used for the PATA (parallel ATA) second channel that the optical drive is on. In a stock SuSE installation (and it ends up this way in most or all distros), you have IDE generic support compiled into the kernel, and it gets initialized first, attaching the CDROM. Since it has no chipset support, it has to use PIO and not DMA to read the drive. Later when the initrd is read, ata_piix is loaded and attaches the primary disc drive, whether PATA or SATA. So everything works, sort of, if you don't try to burn. The CD appears as /dev/hdc.

If you include a kernel parameter of ide1=none, or if you build a custom kernel and kick out ide-generic (build it as a module and don't include it in the initrd), ata_piix will initialize both channels and will attach the primary disc (as SCSI). However, it will ignore the CD even if the relevant modules are preloaded. So you have DMA on the channel, but no drive. (It would be /dev/sr0 if there at all.)

Some kernel hacking reveals that the issue is being worked on actively, and within the limits of my ability to test, the new code can read fast and error free, and can burn fast and error free. Here is the kernel patch to turn on the new code in kernel 2.6.12-rc1 and to fix a bug in recognizing the PATA channel on the laptop controller. NOTE: it has not been blessed by the maintainer of the SCSI subsystem; he will release the ATAPI code for general use when he feels it's ready; and if you're doing this on a desktop mobo with separate SATA and PATA PCI devices, I haven't tested that configuration at all, so you had better check carefully yourself. The new code dies horribly in kernel 2.6.8, so don't try patching that kernel or earlier.

If you don't use the kernel patch, you will need to provide the ide_generic driver, either hardwired in the kernel or before ata_piix in the initrd.

SuSE 9.3 (kernel 2.6.11.4) has the new ATAPI code turned on, but lacks the fix in the above patch for recognizing the PATA channel on the Inspiron 6000d.

In this table, data transfer speeds are in bytes per second. 1X = 1.5e5 byte/sec on CD or 1.35e6 byte/sec on DVD. The drive is rated as 24X for CDs. The task for read data CD or DVD is to search in the whole disc or a large subdirectory for a string known to not be present. The test of sequentially reading the block device naturally will be faster becasue there is no overhead of seeking or reading directories.

Item	Windows	Linux (no DMA)	Linux (patched)
Play music CD	Works (Windows Media Player)	Works (xmms)	Works (xmms)
Play video DVD	Works (Windows Media Player)	Needs libdvdcss and configuration to use it.	Needs libdvdcss
Read data CD	6.41e6 (42X)	5.65e5 (3.8X)	2.38e6 (15X)
Sequential CD			3.25e6 (22X)
Read data DVD	2.03e7 (15X)	5.65e5 (0.4X)	4.72e6 (3.5X)
Sequential DVD			4.63e6 (3.4X)
Burn data CD	8.93e5 (6X)	6.16e5 (4.1X)	1.32e6 (10X)
Read burned data CD	5.36e6 (35X) Error free	257 of 27176 files had I/O errors	1.07e6 (7X) Error free

It's a fact of life that there is no official way to play a video DVD on Linux. There are legal questions about the scope of the license under which libdvdcss was written, that preclude the distros from including it.

As it's only a 24X drive, how can Windows search at 35X or 42X? Perhaps it uses the SEARCH_EQUAL opcode of ATA-SCSI, which may have some kind of optimization on a CD drive, and which Linux (grep) would not even consider using, being at the wrong protocol layer. Windows can entangle the search program and the I/O driver because it is tightly integrated and doesn't have to consider the generality of applications that grep must perform in.