Confirmed to be fixed with AC power but not with Battery
Notebook HP 6720s

On Mon, Oct 27, 2008 at 9:20 PM, Ciso <email address hidden> wrote:

> Same problem with my Dell XPS M1330.
> In windows it works good :(
>
> --
> High frequency of load/unload cycles on some hard disks may shorten
> lifetime
> https://bugs.launchpad.net/bugs/59695
> You received this bug notification because you are a direct subscriber
> of the bug.
>
> Status in The Dell Project: Confirmed
> Status in "acpi-support" source package in Ubuntu: Fix Released
> Status in "linux-meta" source package in Ubuntu: New
> Status in "pm-utils" source package in Ubuntu: New
> Status in acpi-support in Ubuntu Hardy: Triaged
> Status in linux-meta in Ubuntu Hardy: New
> Status in pm-utils in Ubuntu Hardy: New
> Status in "acpi-support" source package in Baltix: New
> Status in "acpi-support" source package in Debian: Fix Released
> Status in "pm-utils" source package in Fedora: Invalid
> Status in "laptop-mode-tools" source package in Mandriva: Confirmed
> Status in Suse Linux: Fix Released
>
> Bug description:
> This is not a support forum.  Please do not use it as such (even though it
> has been used as such already).
>
> You can scan through the bug for links to the Ubuntu forums where many,
> many different questions have been asked, answered, and re-answered.  The
> temporary workaround is just below.
>
> See https://wiki.ubuntu.com/PowerManagement for an overview about what is
> involved and for a remedy.
>
>
> Following is a summary of the issue:
> It is confirmed that some systems are seeing an unusually high number of
> load/unload cycles on their hard disks, as evidenced by smartctl.
>
> It was originally surmised that this was related to laptop-mode being
> enabled, but this especially affects systems where laptop-mode is disabled.
>  In fact, aggressive APM is not a bad idea while a system is not on AC, as
> that system is much more likely to encounter a physical impact.
>
> This is due to disk APM settings that let the heads park or disk spin down
> after an idle period that is shorter than the regular disk access patterns
> of the OS.
>
> Then, the heads are only parked for a very short period of time and almost
> imediately loaded again. Making impact protection much ineffective and
> wearing out the drive.
>
> It can happen when the disk asumes aggressive APM settings (like many
> laptop disks) and the OS does not take care to set the APM settings
> accordingly to its current disk access pattern.
>
> This problem has been confirmed in Ubuntu as well as in other distributions
> and on MacOS X and Windows.
>
> Symptoms of this bug are:
> * Frequent HD clicks  -- more than one per 3 minutes while idle, louder
> than the typical access sounds.  Often more than twice per minute.  On some
> disks, the click is very quiet
> * Rapidly Increasing Load_Cycle_Count as displayed in the final number in
> "sudo smartctl -a /dev/hda | grep Load_Cycle_Count" (where /dev/hda is
> replaced with your own hard disk device)
> * Early hard disk failure  never stay parked, due to very frequent disk
> activity.  Thus this cycle occurs often, thus wearing out the drive, and any
> comparative benefit is negligible (whereas, if the-- some disks are cut down
> to less than a year of actual uptime.
>
> The problem is only present due to the existence of *all four* of the
> following factors:
> * Hardware is set (default or otherwise) to aggressive power management,
> causing heads to park.  (default behaviour of many drives and often the only
> user available type of power management)
> * Disk is touched often, causing heads to unpark. (default behaviour of
> many distributions)
> * Drives are spec'd to a limited number of these cycles.  (600,000 is the
> most common, although some may be spec'd higher or lower).
> * The OS not setting disk APM variables according to current disk access
> pattern.
>
> Reasonable Limits / Criteria for a fix:
> * There should be fewer than ~15 load cycles per hour, except during heavy
> usage while on battery.
> * This provides a life expectancy of over four years, which is reasonable
> for a hard disk.
>
> Temporary Workaround:
> * Follow the above link.
>
> Permanent Fix:
> * Obtain utility from your hard drive manufacturer to change the default
> head parking time if available.
> * Contrlolling the APM variables of hard drives according to the current
> disk access pattern. (i.e. chunked into blocks with minutes of idle time
> (disk-idleing or "laptop_mode") or continous disk access every x seconds
> expecting the disks to stay up all the time.)
>
> Some hardware with this issue:
> WD1200VE -- http://www.wdc.com/en/library/portable/2879-001121.pdf -- This
> aggressive parking is a feature of this disk, but that feature relies on
> behaviour that allows for significant amounts of (truly) idle time without
> the disk being touched. Notice the "Load/unload cycles" of 600,000.
>
> Example Load_Cycle_Counts:
> * Thinkpad Z60m/Hitachi HTS541080G9SA00 with well over 7000 load cycles in
> only 100 hours.  That's >70 per hour.
> * Gateway MT6451/Western Digital WD1200VE with 164762 load cycles in 3747
> hours (156 days) of uptime.  That's ~43 per hour -- except that the system
> was patched during the initial third of its life, which puts it at ~63/hour
> since Gutsy was installed (and wasn't patched, as I had done with feisty).
>
> Please see for yourself how often your drive is load cycling:
> smartctl -d ata -a /dev/sda
> (This command is for an SATA drive; you'll need to install the
> smartmontools package first.)
>
> You can get the average per hour by the following division:
> Load_Cycle_Count / Power_On_Hours
>
> Old workaround for 7.10 (not working in 8.04):
> https://bugs.launchpad.net/ubuntu/+source/acpi-support/+bug/59695/comments/14
> A more extensive description of the workaround:
> http://ubuntuforums.org/showthread.php?t=591503
>
> You may need to use '254', or a bit lower, as opposed to '255'.  If HD
> temperature gets high, you may want to set it all the way "down" to 200 or
> so.  ~1 click every 2.5-3 minutes is fine.
> Note:  Some disks are unresponsive to having their APM changed by hdparm,
> and therefore the workaround doesn't work.  It would be a good idea, in such
> cases, to disable APM in the BIOS if possible.
>
> See also http://paul.luon.net/journal/hacking/BrokenHDDs.html for a rather
> dramatic account of the effects the current default values may have.
>
>