Known issues

From ata Wiki
Revision as of 03:21, 3 December 2008 by Tj (Talk | contribs)

Jump to: navigation, search


Hardware compatibility issues

Drives which perform frequent head unloads under Linux

Problem Description

Some ATA harddrives perform very frequent head unloads under Linux significantly shortening their lifespans.

Root cause

The inactivity timer for head unload is configured too aggressively either via ATA APM (Advanced Power Management) feature or other non-standard means. Such aggressive settings are very fragile to changes in IO pattern and under Linux many such drives unload their heads only to re-load them shortly. Note that this relentless unloading/reloading cycle can also be triggered under Windows by installing programs which can alter the IO pattern (e.g. certain vaccine programs which runs in background).

How to determine whether a machine has this problem

Many drives make small clunking noise when they unload and/or reload their heads, so if you hear such noise frequently (say, several times in a minute), it would be worth investigation. Drives usually implement Start_Stop_Count or similarly named counter in their SMART attributes which can be accessed by running "smartctl -a /dev/[hs]dX" where /dev/[hd]dX" is the drive in question. If the counter is too high compared to the hours the drive has been running (which is also often available in the SMART output), your hardware is likely to have this problem.

Note that modern laptop drives are supposed to unload frequently to save power. Unless the unloading is excessive, disabling powersaving is not a good idea. It seems that most modern drives are rated for 600,000 load/unload cycles which translates to about two years of uptime at 35 unloads per hour. Even when assuming continuous 12 hours of usage everyday, this means the drive will only reach its rated load/unload cycle limit after four years and shouldn't be considered malfunctioning. Please only report cases where the expected uptime is significantly lower than two years.

Known affected devices

This list is far from complete. If you have a hardware affected by this problem, please write to linux-ide and attach the outputs of "dmidecode", "hdparm -I /dev/[hs]dX" and "smartctl -a /dev/[hs]dX" where dev/[hs]dX is the affected drive. Also, please include how many times the drive unloads the head per-hour under nominal usage without any adjustment.

dmidecode hdparm -I report workaround
IBM ThinkPad T43 dmidecode hdparm -I report set APM to 255
Lenovo ThinkPad T60 w/ Hitachi drives dmidecode hdparm -I set APM to 255
HP Compaq nx6325 dmidecode hdparm -i report
HP Compaq nx6325 (w/ different drive) dmidecode hdparm -i report
HP Compaq nx7400 dmidecode hdparm -i report set APM to 255
HP Pavilion dv6500 Notebook PC dmidecode hdparm -i set APM to 255
HP Pavilion dv9500 Notebook PC dmidecode hdparm -I sda hdparm -I sdb report set APM to 254
Dell e1505 dmidecode hdparm -I set APM to 255
Western Digital Green Drives WD5000AACS, WD7500AYPS, WD1000FYPS Requires vendor specific tool wdidle3.exe to change the configuration. The tool can only be obtained via WD support.
Dell Vostro 1400 dmidecode hdparm -I report set APM to 254 (or 252)
Dell XPS M1330 dmidecode hdparm -I report set APM to 254
Dell XPS M1530 dmidecode hdparm -I report set APM to 254
Dell Inspiron 1318 dmidecode hdparm -I report set APM to 254
Dell Inspiron 1525 dmidecode -I report set APM to 255
Dell Insprion 1705 dmidecode hdparm -I report set APM to 255
Samsung Q45 dmidecode hdparm -I report set APM to 254
Mac mini 1,1 dmidecode hdparm -I report set APM to 255
Acer Aspire 1691wlmi dmidecode hdparm -I report set APM to 255
MSI Notebook EX600 dmidecode hdparm -I report set APM to 254
ASUS F6S dmidecode hdparm -I report set APM to 254
ASUS M50SV dmidecode hdparm -I report set APM to 254


storage-fixup is a script which uses dmidecode and hdparm outputs to match blacklisted devices and execute appropriate workaround. The script should be run early during the boot and while the system is coming out of sleep. Please read comments on top of the script and the configuration file.


Problem description

There is a known hardware issue when libata is used with certain TSSTcorp TS-L623D drives. The user might experience random system freezes for a few minutes periodically. The problem mostly occurs on Acer and Asus laptop computers.

Root cause

It seems that the firmware of the TS-L623D stops responding after being continuously polled by hald-addon-storage.

Affected firmware versions

  • Acer: All firmware versions including AC00 and AC01
  • Asus: All firmware versions including AS05 and AS99
  • Samsung: SC02

Good firmware versions

Samsung SC03

Workaround solution

  1. keep a CD in the TS-L632D drive or
  2. kill the hald-addon-storage process or
  3. cross-flash the drive firmware of TS-L632D to the SC03 version.

How to cross-flash

Be warned that you are at your own risk to cross-flash the firmware of the drive. Also it might void the warranty.

  1. Download the Samsung firmware update utility
  2. Download the Samsung firmware
  3. Run "sfdnwin -nocheck" to crossflash.

Seagate harddrives which time out FLUSH CACHE when NCQ is being used

Problem Description

On certain Seagate drives sold during late 2008, FLUSH CACHE sometimes times out when used in combination with NCQ commands.

Root Cause

Firmware bug.

Affected Devices

capacity model firmware revision remarks
1.5TB ST31500341AS 9JU138 problem happens most frequently on this model
1.0TB ST31000333AS 9FZ136 happens less frequently
640GB ST3640623AS 9FZ164 happens less frequently
640GB ST3640323AS 9FZ134 happens less frequently
320GB ST3320813AS 9FZ182 happens less frequently
320GB ST3320613AS 9FZ162 happens less frequently


libata will automatically disable NCQ when one of the above devices is detected and emit a warning message. Firmware update solves the problem. Contact Seagate for details.

Personal tools