[Precise] [Hardware-killer] HD restarts every few seconds

Thank you for taking the time to file a bug report on this issue.

However, given the number of bugs that the Kernel Team receives during any development cycle it is impossible for us to review them all. Therefore, we occasionally resort to using automated bots to request further testing. This is such a request.

We have noted that there is a newer version of the development kernel than the one you last tested when this issue was found. Please test again with the newer kernel and indicate in the bug if this issue still exists or not.

You can update to the latest development kernel by simply running the following commands in a terminal window:

    sudo apt-get update
    sudo apt-get upgrade

If the bug still exists, change the bug status from Incomplete to Confirmed. If the bug no longer exists, change the bug status from Incomplete to Fix Released.

If you want this bot to quit automatically requesting kernel tests, add a tag named: bot-stop-nagging.

 Thank you for your help, we really do appreciate it.

Confirmed with latest kernel update this morning.

Confirming this on a 2nd machine : Asus EeePC 1005PE. With numbers.

With the machine clean-booted on precise Beta 1, latest kernel update as of now, running on battery, user logged in, no network connection, wi-fi disabled, no apps running except for an open terminal window.

Leaving the machine alone in this state for 20 minutes and observing the HD SMART values before and after, I get during 20 minutes :

- (4) Start_Stop_Count : +19
- (193) Load_Cycle_Count: +29

That's much too much !

On this machine which has always been running 100% Ubuntu and over 2190 hours of HD runtime, I got 3288 "Start_Stop_Count", that makes on average 1.5 HD Start/Stop per HOUR.

With precise I get about 1 Start/Stop a minute doing nothing - which is 60 times more !

On my other machine for which I 1st reported the bug (network up and some apps running) I would say it's 3-4 Start/Stop per minute !

IMHO this is a show stopper, with such disk "power saving" parameters, this will kill HDs in a couple of months.

(I can also confirm that this crazyness ceases as soon as AC power is connected)

@Swami

Does the bug go away if you boot back into the Oneiric kernel?

Also, would it be possible for you to test the latest upstream kernel? Refer to https://wiki.ubuntu.com/KernelMainlineBuilds . Please test the latest v3.3 kernel[1] (Not a kernel in the daily directory). Once you've tested the upstream kernel, please remove the 'needs-upstream-testing' tag(Only that one tag, please leave the other tags). This can be done by clicking on the yellow pencil icon next to the tag located at the bottom of the bug description and deleting the 'needs-upstream-testing' text.

If this bug is fixed in the mainline kernel, please add the following tag 'kernel-fixed-upstream'.

If the mainline kernel does not fix this bug, please add the tag: 'kernel-bug-exists-upstream'.

If you are unable to test the mainline kernel, for example it will not boot, please add the tag: 'kernel-unable-to-test-upstream'.
Once testing of the upstream kernel is complete, please mark this bug as "Confirmed".

Thanks in advance.

[1] http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.3-rc7-precise/

Confirming again on a 3rd, different laptop (Acer Aspire 3104 WLMi)

Leaving the system alone on battery (no special software started, machine fresh booted with an user session open), in about 10 minutes I get :

- (4) Start_Stop_Count: = +9
- (193) Load_Cycle_Count: = +9

So it seems that every laptop running Precise, on battery, Starts/Stops its HD at least about once a minute (if left alone), and much more often if workling on it.

WE'RE GONNA BREAK A LOT OF HDs AND UBUNTU'll GET FAMOUS FOR THAT IF IT AIN'T FIXED before Precise final is released...

Per Joseph request I booted my Dell XPS M1330 (the machine on which I initially started this bugreport) back onto Oneiric's kernel :

# uname -a
Linux tethys 3.0.0-16-generic #29-Ubuntu SMP Tue Feb 14 12:49:42 UTC 2012 i686 i686 i386 GNU/Linux

...But with the rest of "Precise" of course.

I report that, left alone, the machine's HD start/stop count increased by +27 in 10 minutes.

So that's not the kernel itself, but that's surely a very aggressive default power-saving setting in Precise.

I can be damn sure that it didn't do that in Oneiric because my HD is fairly new on this machine and it counted (before I started this test) :

TOTAL:
- (4) Start_Stop_Count: 488
- (9) Power_On_Hours: 669

So the HD was started/stopped on average less then once per hour in Oneiric, now 3 times a minute in Precise on the same machine.

That's not a kernel bug, but I don't know where this bug should be affected. Power-management ??

Reassigning this bug to power management, as it triggers in Precise also when using the "old" Oneiric 3.0.0-16 kernel

UP !

Moving this hardware killer around until somebody notices it, realizes the house is on fire and decides to do something about it...

Bug still present on 3 machines with today's latest updates including new kernel : 3.2.0-19-generic

Hi there, thanks for verifying this with older kernels. I'd like you to run the following:

sudo pm-powersave off

and see if the problem still exists

Oops, my mistake, should be:

sudo pm-powersave false

I'd like to also know if you have got laptop-mode-tools installed or not. Can you let me know. Thanks!

I won't be able to check this further until a couple of days, but I can for sure say the following :

- Yes, it happens with Oneiric kernel on precise beta.
- It happens on all 3 machines I tried it on, and I would be very surprised if I had installed laptop-mode-tools on all three of them (unless it is part of the default installation...)

Swâmi, what tools are you using to check for HDD start and load cycles?

I first used my ears, that told me that the disk was spinning down then up etc... On one of my machines the disk is loud enough to be clearly noticeable.

Then I used "smartctl -A /dev/sda" to check the "(4) Start_Stop_Count" raw value over time, that's the HD's number of starts/stops in its lifetime. And that's increasing...

Checking disk's SMART attributes in Gnome Disk Utility shows the same results.

I just could check 2 of my laptops this morning : "laptop-mode-tools" is installed on neither of them.

@Colin : I just tried "sudo pm-powersave off" on my Asus EeePC 1005PE (after having applied latest updates and rebooted, kernel 3.2.0-19-generic).

It doesn't bring any improvement. I'm still getting about 1 HD start/stop per minute, system doing absolutely nothing and not even connected to the Internet.

@Swâmi,

I've tried to reproduce this on a few machines with no luck as yet. Just to eliminate any misbehaving application that may be doing writes (and possibly) causing this problem can you do the following:

sudo apt-get install fatrace
sudo apt-get install powertop-1.13
sudo power-usage-report > report.log

and attach report.log to the bug report.

Thanks!

Hi Colin,

I'll perform the checks you suggest, however I doubt the issue is caused by apps performing unwanted writes (I assume that the disk restarting every minute be related to cron activity or so...) as I feel that the issue is not with the disk restarting, but with the disk stopping much too soon (I've actually heard it spin down only some seconds after having been accessed, which is definitely unwanted).

I'll attach the resquest log soon.

@Swâmi,

I'm suspecting it may be that Precise is doing less disk activity now that we've worked on fixing a bunch of applications + daemons that were causing a load of (frequent) unnecessary writes. I wonder if the hdparm setting in /lib/hdparm/hdparm-functions when running battery is too aggressive. As an experiment, can you edit /etc/hdparm.conf and after the line:

#apm = 255

add

apm_battery = 255

and see if this reduces the start/stops (it should do).

Attached the requested power-usage-report output from my EeePC 1005PE, per Colin's request.

I have left my machine alone for 4 minutes wihtout any active network connection and not touching anything, while generating this.

System freshly booted, no running apps except for a logged in user and default system daemons.

At the end of these 4 minutes, my HD start/stop counter showed an increase of +3.

After I added "apm_battery = 255" to hdparm.conf per Colin's request, and rebooted my system, logged in then left it alone for 10 minutes, the HD's start/stop count DOESN'T INCREASE ANYMORE.

So this is effectively a "quick & dirty fix".

hdparm -I confirms : « Advanced power management level: disabled »

However disabling it completely doesn't sound like the best solution, it might be better to leave *some* HD power management active, but with values that doesn't allow the disk to spin down every so often !

"man hdparm" suggests that -B values >= 128 do not allow spindown, while -S values allow setting the desired timeout precisely.

So aggressive values that allow a disk to spin down after a couple of seconds should never be a default ! And upgrading from Oneiric to precise made this happen... :-/

Checking /lib/hdparm/hdparm-functions shows that battery -B default is 127 (spindown allowed).

That is not necessarily wrong, but should probably be followed by something by -S36 (that makes spindown after 3 minutes of inactivity) or no less than -S24 (would be 2 minutes), while I see no default value for -S ?!

A typical Linux machine usually accesses disks at least once a minute (unless laptop-mode tools are in use and syslogs are delayed, etc...) so spinning a disk down in a shorter amount of time really risks causing an undesired and disk-killing behaviour...

Checking the values in /lib/hdparm/hdparm-functions on a Linux Mint 12 (dual-boot installed on my EeePC), Mint 12 being based on Ubuntu Oneiric.

The default "battery mode" value for -B is "128" instead of "127" on Ubuntu Precise.

So it seems that this shift from "128" to "127", allowing disk spindown (much much much too often), has serious and undesired consequences on all of my 3 laptops...

Checking same value on a Bodhi Linux (based on Ubuntu 10.04), it was -B 128 also, and I use Bodhi on 2 of my laptops without disks issues either...

@Swâmi,

Thanks for following up with some useful data. I think a 2-3 minute setting for -S is sane. Since this isn't a kernel bug, I will re-assign it.

Hi,

On my Dell XPS M1330, it's enough to specify "apm_battery = 128" in /etc/hdparm.conf to solve the issue. That's the "old" value...

So I confirm that this parameter was the cause of the issue on 2 machines, and the fix fixes it on both.

On Tue, Mar 20, 2012 at 06:15:57PM -0000, Swâmi Petaramesh wrote:
> On my Dell XPS M1330, it's enough to specify "apm_battery = 128" in
> /etc/hdparm.conf to solve the issue. That's the "old" value...

> So I confirm that this parameter was the cause of the issue on 2
> machines, and the fix fixes it on both.

However, that's not a proper fix because apm_battery = 128 is not guaranteed
to spin the disk down when idle; 127 is the first value that enforces
spin-down.

We can set a default spindown_time value to make sure we're not spinning
down unless the disk is idle for, say, 2 minutes, but I'm not positive this
actually corresponds to Load_Cycle_Count anyway which is supposed to be
about head parking rather than actual disk powerdown. Could you test
whether you see a difference in the load count if you keep apm_battery at
127 but set spindown_time to 24 in /etc/hdparm.conf?

Ultimately, the reason that apm_battery is set to 127 is because when on
battery, we want to spin down the disk for power savings. But the only
effect the above changes will have is to prevent the disk spinning down at
all, and that's because something is hammering your disk and preventing it
from staying asleep. You may want to use the fatrace tool to examine the
causes of this, because those are the bugs that *really* should be fixed.

Hi Steve,

I'll try and give it a shot (not tonight) ; however, in 15+ years of intensive daily Linux use, I am yet to see any Linux machine (in use) that can keep its disk spinned down for more than a minute, unless using the laptop-mode tools and appropriate FS and write-cache settings, which are not so easy to finely tune, and very specific to some netbook uses.

That's probably why "128" was the default value so far. I strongly believe that allowing disk spindown will never result in actual energy savings, *but* it may and will result in a much shortened HD life.

One who wants max energy savings has better go for "suspend" mode after a short inactivity period (let's says 5 or 10 minutes) rather than playing with HD spindown. it's a nonsense for any modern multitasking OS with crons and other tasks schedulers.

@Steve #27 : Of course the counter for disk spin-ups is "4 Start_Stop_Count" and not "193 Load_Cycle_Count", which is the counter for heads load/park.

I've edited (on my EeePC 1005PE) /etc/hdparm.conf and removed the explicit setting for "apm_battery" which I had previously put, but specified instead "spindown_time = 36" (3 minutes).

I then rebooted my machine, and checked (using "hdparm -I") that I now have « Advanced power management level: 127 » on my HD.

I then left the machine alone for 10 minutes and checked the counters before and after :

4 Start_Stop_Count : No change
193 Load_Cycle_Count: +14

The 2nd one looks reasonable and is not an issue, as the disk can handle much more heads load/unload (typically 600,000 - 800,000) than it can stand start/stops (typically 40,000 - 50,000) - theoretically...

I would assume to get comparable results on my other machines, all of them having more or less the same disk behaviour, however both their brands and models are completely different.

So my advice would be that Ubuntu *may* use a battery default disk apm value of "127", but then *MUST* make sure that the disk gets a default "spindown_time" value which is never less than a couple minutes. My advice would be something between 3 and 5 minutes.

Otherwise we're gonna destroy laptops HDs.

This bug was fixed in the package hdparm - 9.37-0ubuntu3

---------------
hdparm (9.37-0ubuntu3) precise; urgency=low

  * debian/hdparm-functions: if we're going to set -B127 on battery, we
    should also set a sane (not too low) spindown time, to avoid wearing out
    disks. LP: #952556.
 -- Steve Langasek <email address hidden> Sat, 24 Mar 2012 03:06:35 -0700

Hi, Just wanted to throw some analysis into this bug report. It's take me ~30+ hours of running tests to gather this data, so apologies if this comes late in the day once the fix has been committed :-/

I've measured Spin Start/Stop counts on a HP Mini netbook measuring the start/stop count during 30 minutes of idle time for various settings of the spindown time. I ran these tests for hdparm -B 127 and also hdparm -B 128, and each test was ran twice to calculate an average and std.deviation. I also used a precision 6 digit multimeter and measured power consumption for each run to measure the impact of the various spindown times.

Attached is an LibreOffice spreadsheet with the data and some graphs.

No big surprises in the data - as the spintime increases we reduce the number of start/stops over the 30 minute idle time and also we see power consumption increasing since we are using more power to keep the drive spinning. The interesting thing to take from the data is the fact that the power savings between 60 seconds spindown time and 600 seconds are ~10-15 mA which is about ~3% of the total power consumption. So probably a good compromise is ~2-3 minutes spindown time for an idle system.

I'd like to repeat this with a more modern laptop and larger HDD, but alas my x220i is away for repair this week.

Thanks for the great bug fix guys :-)

3 minutes seems to be a very good default choice as far as I'm concerned.

Unfortunately the fix is not enough on Toshiba L735-101 (that's a new kind of system I've been testing it on) : The disk keeps on spinning down every few seconds unless "apm_battery = 128" is specified in hdparm.conf.

Just to add my 2 cents worth, I'm concerned that there are a class of "green" drives out there on the market where hdparm -B 255 is the only way to ensure they don't excessively impact the Load_Cycle_Count, for example:

WD20EADS, WD20EARS, WD15EADS, WD15EARS, WD10EADS, WD10EARS, WD8000AARS, WD7500AADS, WD7500AARS, WD6400AADS, WD6400AARS, WD5000AADS, WD5000AARS

References:

http://www.silentpcreview.com/forums/viewtopic.php?t=51401
http://wdc.custhelp.com/app/answers/detail/a_id/5357

I've filed a separate bug 969165 for the WD drives.

About the issue with the Toshiba L735-101 (needing at least -B 128 otherwise the disk spins down every few seconds even with latest patches), this might be related to the fact that Linux has hard times - probably an issue with Toshiba BIOS - to find out whether the system is on AC or battery: sometimes the battery isn't displayed, the machine never goes to slip when lid is closed but can be sent to sleep forcibly by menu, the "vision" that Linux has about the AC/battery status changes once the AC adapter has been plugged then unplugged etc.

In this situation I assume that the hdparm script may not be able to determine what set of parameters it should use (AC/battery/whatever).

But I believe that even in such "limit" conditions, we should take any provisions to not use any parameters that could possibly result in a damage to the hardware. That definitely doesn't compare with saving a few milliamps for gaining a small % of battery duration on most systems "that it wouldn't break"...

I can confirm that hdparm (9.37-0ubuntu3) indeed didn't fix the issue on Toshiba Laptops; model here is a Satellite C660 with a Seagate Momentus XT 500 GB hybrid HD. The drive is powercycling approximately 3 times per minute on battery and, funnily enough, also when the AC is connected AND the battery is fully charged.
So it seems that the AC adapter is only detected while it's charging the battery, not when it's supplying the power.

Nevertheless I have a (very probably quite embarrassing) problem here: The only item not commented out in my etc/hdparg.config is 'quiet'. Nothing else seems to have been set, or am I missing something here?

As I would be quite happy with not spinning down the HD at all, can I just add 'hdparm -B254' at the end?

@Andreas : If you don't wan't your disk to ever spin down, it should be enough to add "apm_battery = 128" in /etc/hdparm.conf

It won't fix this bug, bug that will be a perfect workaround for you ;-)

I can confirm this bug with my Thinkpad X200s. Running latest Precise.

Can confirm these very frequent (~10 seconds) spinups as well. Setting "apm_battery = 128" in /etc/hdparm.conf as a workaround works very fine.

This is a Samsung 300E laptop with a SAMSUNG HM641JI harddisk. Attaching the output of hdparm -I /dev/sda (with apm_battery=128 set) if that helps. Anything else I can provide to help?

Forgot to mention: using Lubuntu i386 Precise from tuesday.

A related issue here, I have a Samsung HS122JC in my Dell D430, and after updating to XUbuntu 12.04, I noticed that the HD started surging on battery power. Basically it spins up a bit faster for a while and the drive LED on the laptop glows solid for a moment while everything hangs, then it frees itself and resumes operation.

I messed around a bit, then noticed in the PM logs that you're setting the APM_Level to 127 on battery, but my HD only knows of 1, 128 and 254. Depending on what you set using hdparm -B, the drive rounds it down to the lower number. Setting it to 127 rounds the APM_Level to 1 and the drive starts doing these interesting things. Looking in the hdparm package's change log (and my pm-powersave.log), it seems you guys used 128 up until 11.10, and that's why it happened to work with my drive.

I set apm_battery = 128 in /etc/hdparm.conf and am happy again. I wonder what APM_Level = 1 really means to this drive.. Doesn't seem like a power saving mode in any case, more like a super high performance mode that somehow doesn't quite work (due to the hangs).

The drive itself reports what the level ended up being, so perhaps you guys might want to "fix" this by testing it in the package's install script. If the drive won't go to 127, then see if 128 still works and preconfigure /etc/hdparm.conf?

Here's some log snippets.

AC -> Battery
--
Running hook /usr/lib/pm-utils/power.d/95hdparm-apm true:

/dev/sda:
 setting Advanced Power Management level to 0x7f (127)
 APM_level = 1

/usr/lib/pm-utils/power.d/95hdparm-apm true: success.
--
Battery -> AC
--
Running hook /usr/lib/pm-utils/power.d/95hdparm-apm false:

/dev/sda:
 setting Advanced Power Management level to 0xfe (254)
 APM_level = 254

/usr/lib/pm-utils/power.d/95hdparm-apm false: success.
--

Maybe this depends more on the hard disk than the actual laptop/system?

I unplugged the power, then while doing nothing listened for the disk's powerdown. It happened after about 15 seconds, which I think shouldn't happen given the default values (-B is at 127, -S at 36, which would mean 3 minutes before spindown).

 I have Precise with hdparm 9.37-0ubuntu3. The system is a Samsung QX410, the hard disk is reported by hdparm as a "SAMSUNG HM641JI".

Confirming bug for Samsung NB30 netbook (HD Samsung HM250HI),
Precise 12.04 latest, hdparm 9.37-0ubuntu3 does NOT fixes the bug!
apm_battery=255 fixed it for me, but there are still a lot of users who can first think their HD is broken and needs to be replaced, as I thought at first.
Hardware-killing bug, so much time since this bug was discovered, and no working fix yet :(

Additionnal info about the bug:
If netbook is working on battery, even after rebooting and entering BIOS Setup (or booting some HDD utility from flash drive, for example) HD still spins down automatically after a few seconds of inactivity, either netbook is on battery or AC power already. But if I attach my netbook's HD to another machine, HD works fine.
I mean what Ubuntu's power management is somehow programmed into hardware (not HDD; BIOS?), and it will spindown HD even when you are not working under Ubuntu 12.04 any more!

The bug has been know and reported for a month and a half.

It's critical. It's one of the few bugs that can - and will - kill hardware.

The cause is known. The solution has been found, tested and confirmed.

Yet a LTS has been released with this critical bug and the fix is still not released.

This is exactly the kind of thing that make me completely lose confidence is a distribution, its developpers, and its Q&A system.

What is the purpose of bug reports, if critical bugs duly reported, with a found and tested solution, do not result in a very quick and responsive fix release.

Not even amateur job :-(

This issue is driving me crazy. I tried Setting "apm_battery = 128" in /etc/hdparm.conf and it seemed to work for a while and starts the same issue again. I don't want to keep on trying options for fear of damaging my 1TB HD on my Samsung Chronos 7 laptop, that would be too much.

On the extreme side, this is the kind of thing that makes people shy away from Linux. The problem has been known to be there for a while, so why not fix this imminently important issue, more important than UNITY, my two cents. If I can't use my laptop (which is supposed to give me 5+ hours battery life) on battery mode, what would be the reason for spending so much money on it and so much time on Linux. I say all this, because I Love Linux/Ubuntu and want to use it everyday. So, please fix this or at least tell us what to do so we don't end up damaging our HD. I know Ubuntu comes under 'Absolutely No Warranty ...'

Thank you.

The above two comments were written at the same time independently. This just shows the frustration that most are experiencing. Some may not even notice it up until their HD is dead, what a shame that would be.

Adding "apm_battery = 128" to /etc/hdparm.conf solves the problem also on my old BenQ notebook - thanks for providing this solution!

I can say that also I am sometimes very frustrated about these kind of bugs, that seem to come back ever so often after getting fixed.

But there is this great community - it didn't even take me 5 minutes to find a solution.

This bug was fixed in the package hdparm - 9.37-0ubuntu4

---------------
hdparm (9.37-0ubuntu4) quantal; urgency=low

  * debian/hdparm-functions, debian/95hdparm-apm: set our spindown policy
    back to -B128 instead of -B127. Too many drives misbehave too badly
    with this setting, possibly leading to drive failure. We should revisit
    this once we understand why people's drives are spinning back *up* so
    frequently. LP: #952556.
 -- Steve Langasek <email address hidden> Mon, 30 Apr 2012 23:04:05 -0700

Swâmi, in the case of your Toshiba laptop, can you confirm whether running 'hdparm -B 127' actually sets the level to 127? I'm wondering whether the drives where people are still seeing problems have an issue similar to what Ville describes in comment #42, where the APM setting is actually being rounded down by the drive.

In the short term we'll set it back to 128 across the board; but in the longer term, if this actually comes down to drives rounding down, and we can detect that, it would be nice to switch back to 127 again and only use 128 for those drives that can't handle 127.

@Steve : (#50)

root@tethys:/etc# hdparm -I /dev/sda | grep "power management level"
 Advanced power management level: 128

root@tethys:/etc# hdparm -B 127 /dev/sda

/dev/sda:
 setting Advanced Power Management level to 0x7f (127)
 APM_level = 127

root@tethys:/etc# hdparm -I /dev/sda | grep "power management level"
 Advanced power management level: 127

root@tethys:/etc# hdparm -B 128 /dev/sda

/dev/sda:
 setting Advanced Power Management level to 0x80 (128)
 APM_level = 128

root@tethys:/etc# hdparm -I /dev/sda | grep "power management level"
 Advanced power management level: 128

root@tethys:/etc# hdparm -I /dev/sda | more

/dev/sda:

ATA device, with non-removable media
 Model Number: SAMSUNG HN-M101MBB
 Serial Number: S2RQJ9BB704375
 Firmware Revision: 2AR10001

(Additionally I first reported this issue running the same HD in a Dell XPS M1330 ; I then replaced my computer but just dropped my existing Samsung HD in my new Toshiba machine. Although the Toshiba BIOS behaves completely differently from the Dell one [read : not as well] and especially on power management issues, however the HD behaviour, withe respect to hdparm -B, has remained exactly the same.)

On Tue, May 01, 2012 at 06:42:09AM -0000, Swâmi Petaramesh wrote:
> root@tethys:/etc# hdparm -B 127 /dev/sda
>
> /dev/sda:
> setting Advanced Power Management level to 0x7f (127)
> APM_level = 127

> root@tethys:/etc# hdparm -I /dev/sda | grep "power management level"
> Advanced power management level: 127

Ok, thanks for checking. It may still be worth fixing the code to check
that the apm setting has taken, but that evidently won't be enough to solve
this problem for everyone.

after setting apm_battery=128 in my /etc/hdparm.conf
as well as in /lib/hdparm/hdparm-functions:
            if hdparm_is_on_battery; then
                hdparm_set_option -B128

Here is what I get with sudo hdparm -I /dev/sda

 Advanced power management level: 1

Complete log: apparently, same HD as Swâmi Petaramesh above

/dev/sda:

ATA device, with non-removable media
 Model Number: SAMSUNG HN-M101MBB
 Serial Number: S2RQJ9ABB07710
 Firmware Revision: 2AR10001
 Transport: Serial, ATA8-AST, SATA 1.0a, SATA II Extensions, SATA Rev 2.5, SATA Rev 2.6, SATA Rev 3.0
Standards:
 Used: unknown (minor revision code 0x0028)
 Supported: 8 7 6 5
 Likely used: 8
Configuration:
 Logical max current
 cylinders 16383 16383
 heads 16 1
 sectors/track 63 63
 --
 CHS current addressable sectors: 1032129
 LBA user addressable sectors: 268435455
 LBA48 user addressable sectors: 1953525168
 Logical Sector size: 512 bytes
 Physical Sector size: 4096 bytes
 Logical Sector-0 offset: 0 bytes
 device size with M = 1024*1024: 953869 MBytes
 device size with M = 1000*1000: 1000204 MBytes (1000 GB)
 cache/buffer size = 8192 KBytes
 Form Factor: 2.5 inch
 Nominal Media Rotation Rate: 5400
Capabilities:
 LBA, IORDY(can be disabled)
 Queue depth: 32
 Standby timer values: spec'd by Standard, no device specific minimum
 R/W multiple sector transfer: Max = 16 Current = 16
 Advanced power management level: 1
 Recommended acoustic management value: 254, current value: 128
 DMA: mdma0 mdma1 mdma2 udma0 udma1 udma2 udma3 udma4 udma5 *udma6
      Cycle time: min=120ns recommended=120ns
 PIO: pio0 pio1 pio2 pio3 pio4
      Cycle time: no flow control=120ns IORDY flow control=120ns
Commands/features:
 Enabled Supported:
    * SMART feature set
      Security Mode feature set
    * Power Management feature set
    * Write cache
    * Look-ahead
    * Host Protected Area feature set
    * WRITE_BUFFER command
    * READ_BUFFER command
    * NOP cmd
    * DOWNLOAD_MICROCODE
    * Advanced Power Management feature set
      Power-Up In Standby feature set
    * SET_FEATURES required to spinup after power up
      SET_MAX security extension
    * Automatic Acoustic Management feature set
    * 48-bit Address feature set
    * Device Configuration Overlay feature set
    * Mandatory FLUSH_CACHE
    * FLUSH_CACHE_EXT
    * SMART error logging
    * SMART self-test
    * General Purpose Logging feature set
    * 64-bit World wide name
    * IDLE_IMMEDIATE with UNLOAD
    * WRITE_UNCORRECTABLE_EXT command
    * {READ,WRITE}_DMA_EXT_GPL commands
    * Segmented DOWNLOAD_MICROCODE
    * Gen1 signaling speed (1.5Gb/s)
    * Gen2 signaling speed (3.0Gb/s)
    * Native Command Queueing (NCQ)
    * Host-initiated interface power management
    * Phy event counters
    * Idle-Unload when NCQ is active
    * NCQ priority information
    * DMA Setup Auto-Activate optimization
    * Device-initiated interface power management
    * Software settings preservation
    * SMART Command Transport (SCT) feature set
    * SCT Long Sector Access (AC1)
    * SCT LBA Segment Access...

Hello Swâmi, or anyone else affected,

Accepted hdparm into precise-proposed. The package will build now and be available in a few hours. Please test and give feedback here. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you in advance!

@ Dagnachew, Swami, Steve:

I've noticed that in Dagnachew's output the power management has changed to 1 while his acoustic management setting is 128 after changing etc/hdparm.conf.

My disk is still spinning down after adding apm_battery=128.

Can it be that some disks interpret a power management setting mistakenly as acoustic management or both?

My current, abridged hdparm -I:

...
Capabilities:
 LBA, IORDY(can be disabled)
 Queue depth: 32
 Standby timer values: spec'd by Standard, no device specific minimum
 R/W multiple sector transfer: Max = 16 Current = 16
 Advanced power management level: 128
 Recommended acoustic management value: 254, current value: 0
 DMA: mdma0 mdma1 mdma2 udma0 udma1 udma2 udma3 udma4 udma5 *udma6
      Cycle time: min=120ns recommended=120ns
 PIO: pio0 pio1 pio2 pio3 pio4
      Cycle time: no flow control=120ns IORDY flow control=120ns
...

Any ideas?

Hi Martin,

Thank you. I just installed it after adding ubuntu-proposed to my 'software sources' and running:

sudo apt-get update
sudo aptitude install hdparm/precise-proposed

I accepted to install hdparm v9.37ubuntu3.1

sudo reboot

dd@dd01:~$ sudo hdparm -I /dev/sda | grep "power management"
 Advanced power management level: 1
    * Host-initiated interface power management
    * Device-initiated interface power management

Still spinning

If that helps, the spinning seems less aggressive while on iGPU mode:

I have currently AMD Catalyst 12.4 installed on my machine

dd@dd01:~$ sudo aticonfig --px-list-active-gpu
   PowerXpress: Integrated GPU is active (Power-Saving mode)

The spin becomes more frequent when on the dedicated graphics card (dGPU)

Hi!

I just reverted my hdparm.conf to default and updated hdparm from precise-proposed.

Results: no more spin-up sounds while on battery in ~45 minutes of testing. I had various spin-ups every minute before, so the patch works for me (APM level is correctly set to 128 by default). (See my comment above for information on my drive if you need it)

Thanks for fixing!

tags: added: verification-done
removed: verification-needed

Does that mean that we have to wait till it is released after verification?

Good luck! and thank you for being on top of this.

Danachew, yes, we have a 7 day minimum waiting period to shake out any unintentional regressions. The fix should progress to -updates on or around May 9. It may be delayed a bit, as most (all?) of the SRU team members will be attending the Ubuntu Development Summit next week.

OK, thanks Clint, Enjoy the summit.

this will be automatically marked 'fix released' when published to precise-updates, and should not be so marked until then.

Sorry Steve.
I was just checking and clicked on it inadvertently. But, I was surprised that I (a no dev member) could modify it. I am still hoping that the release will fix my persistent and annoying HD issue.

Best

This bug was fixed in the package hdparm - 9.37-0ubuntu3.1

---------------
hdparm (9.37-0ubuntu3.1) precise-proposed; urgency=low

  * debian/hdparm-functions, debian/95hdparm-apm: set our spindown policy
    back to -B128 instead of -B127. Too many drives misbehave too badly
    with this setting, possibly leading to drive failure. We should revisit
    this once we understand why people's drives are spinning back *up* so
    frequently. LP: #952556.
 -- Steve Langasek <email address hidden> Mon, 30 Apr 2012 23:04:05 -0700

Thank you for the final release. In fact, I installed it earlier (just before it was removed for validation) and apt-get tells me that I have the latest release. If so, my problem,sadly, is not fixed by this release. I don't know What to do next with this critical problem.
I noticed in the developer's site that there is a newer version (9.39), I don't know if that may solve the issue but ...

On Sat, May 12, 2012 at 05:22:13AM -0000, Dagnachew L. wrote:
> Thank you for the final release. In fact, I installed it earlier (just
> before it was removed for validation) and apt-get tells me that I have the
> latest release. If so, my problem,sadly, is not fixed by this release. I
> don't know What to do next with this critical problem.

This patch restores the behavior from previous Ubuntu releases.
Unfortunately, there are definitely some newer, "green" drives that behave
poorly even with the previous behavior. This isn't something that can be
fixed with a general-purpose SRU, because there currently is no single
setting that's appropriate for all users.

The only thing I can advise is that you set your apm_battery value even
higher - possibly even to 254 - if you're concerned about the wear on the
drive.

Steve,
My problem is, whatever number I set for apm_battery in /etc/hdparm.conf, it gets reset to: Advanced power management level: 1
at reboot. It shows: Advanced power management level: 255 when on AC power.

This is what I have in the conf file:
/dev/sda {
 apm = 255
 apm_battery = 128
}

sudo hdparm -B 128 -S 242 /dev/sda

this seems to make my HD happy. no spinning, no nagging, excellent battery life (+5 hours) , ...
But, i have to run the above at every boot.I tried putting that in /etc/rc.locale but no success. I can live with this at least for now, with the hope that someone will figure out what wrong is going on.

I can confirm this bug with my Lenovo G560. Running latest Precise. The continuous hd restarts is annoying !!!

For me everything works fine after the last update. Thank you

I might be missing something, apologies if i am, but I notice that for Precise a decision was made to define a value for -S, in /lib/hdparm/hdparm-functions, when on battery to -S36. From Dagnachewl's comment (70) it would seem that it's the defining of or value of -S that's still causing issues for some.

For anyone who has already updated hdparm to version '9.37-ubuntu3.1' and still experiencing early spindowns I would try commenting out (by preceeding with #) or removing the line "hdparm_set_option -S36" from /lib/hdparm/hdparm-functions. This should effectively revert hdparm-functions to pre-Precise settings - removing any spindown time.

Steve: thanks for the update, works great for me! Maybe the wording of the change in the changelog needs updating. Instead of '...drives are spinning back "up" so frequently' shouldn't it be '...drives are spinning "down" so soon'?
It's that the drive has spun down after only a few seconds of idle (with -B127 and -S36) that leads to it having to spin back up so frequently.

thanks and best of luck all

On Tue, May 15, 2012 at 08:20:42AM -0000, Neil Price wrote:
> I might be missing something, apologies if i am, but I notice that for
> Precise a decision was made to define a value for -S, in /lib/hdparm
> /hdparm-functions, when on battery to -S36. From Dagnachewl's comment
> (70) it would seem that it's the defining of or value of -S that's still
> causing issues for some.

It's incredibly unlikely that this is the cause of the problems some people
are still seeing. It's more likely that the affected users simply have
problematic handling of -B128 - as Dagnachew's output in comment #55 shows,
-B128 gives him "Advanced power management level: 1". I'm not sure if this
is in spec for the drives to do, but it's certainly unhelpful, and it seems
the *only* way to reliably prevent spin up/spin down nonsense on some drives
is to disable APM entirely with -B254. Fixing this is out of scope for the
present bug report, which was about the behavior regression on non-"green"
drives caused by the move from -B128 to -B127.

So other issues are best addressed by separate bug reports. We'll need to
gather a lot of information here before we dare making further changes - as
I said earlier, there's no magic setting that will work correctly across all
drives, so we need to be careful that as we tune things, we don't regress
behavior for other users (either in terms of power savings or in terms of
drive wear and tear).

In the meantime, users who find that -B128 causes their disks to spin down
too aggressively should probably just set apm_battery=254 in
/etc/hdparm.conf.

> For anyone who has already updated hdparm to version '9.37-ubuntu3.1'
> and still experiencing early spindowns I would try commenting out (by
> preceeding with #) or removing the line "hdparm_set_option -S36" from
> /lib/hdparm/hdparm-functions. This should effectively revert hdparm-
> functions to pre-Precise settings - removing any spindown time.

Since -S36 is a spindown time of 3 minutes, I don't think this setting is
related to the behavior users are seeing. If it *is*, then those drives are
operating contrary to the spec and users should complain to their hardware
vendors and demand firmware updates.

> Steve: thanks for the update, works great for me! Maybe the wording of the
> change in the changelog needs updating. Instead of '...drives are
> spinning back "up" so frequently' shouldn't it be '...drives are spinning
> "down" so soon'?

No, that wording is deliberate. Ultimately, the real bug here is not that
we're spinning the drives down; the bug is that we're unable to *keep* them
spun down on a typical desktop. There's no justification for having to hit
the disk any more frequently than once every 5-10 minutes on a default
install, and the fact that we do is a bug. It might be a kernel bug, or an
application bug, or a filesystem bug - it's difficult to say categorically
because everyone's usage patterns seem to be different. But ultimately, the
goal here should be to get better at our disk handling so that it doesn't
matter that we're spinning the disk down.

> It's that the drive has spun down after only a few seconds of idle (with
> -B127 and -S36) that leads to it ha...

Thanks Steve. The problem, as you said, might be coming from a combination of causes. I have tried all the numbers that are mentioned here and elsewhere but in vain. The only magic number that has worked so far while switching to battery mode, as I said earlier is:

hdparm -B 128 -S 242 /dev/sda

There seems to be confusion about the -B and -S options. There also seems another tool (may be laptop mode?) that changes these settings by overriding the hdparm settings. I got some hint about the above -S option from an old Fedora forum, which means the issue isn't that recent. It has been there for several years. It is a bit of a shame that a tool adopted universally by all Linux disros is causing such an issue for so long. Apparently, hdparm has lots of options, some of which very naughty if not cared for, but one important option seems faulty or messed up by something else. According to Google, this behavior has been reported in every distro forum since 2000-. Its behavior seems to change with kernel. Does acpid has a role here? This really needs further digging and shall not be left at this stage 'as solved'.

I can confirm that Start_Stop_Count doesn't increment any more, which is nice, but Load_Cycle_Count still increments by about 1-10 per minute.

I set apm_battery = 254 in /etc/hdparm.conf now, which stops Load_Cycle_Count from incrementing, so that is fine.

But isn't this the wrong solution? I guess it is a good idea to park the heads after some inactivity, wouldn't it be better to prevent Linux from writing to disk so frequently, causing the heads to be quickly unparked?

The average laptop HD life can typically stand :

~ 40,000 - 60,000 disk spin-up

~ 600,000 - 800,000 heads load-unload cycles

So it's quite normal (and desirable) that you load-unload heads much more frequently than you spin the disk.

Furthermore loading heads is a matter of a fraction of a second, while spinning disk takes several seconds...

Furthermore an HD with "parked" heads is much much more shock-proof than an HD with flying heads (some laptops HDs have a freefall sensor that automagically parks the heads when the disk is falling and before it crashes on the floor, but this is outside the scope of this bug ;-) so keeping the heads parked as much as possible makes sense, when talking about laptops that are subject to shocks and vibrations.

So basically you need to divide the time you'd like your disk to live by 600,000 to determine the pace at which you would allow your heads to park, and by 40,000 to determine how often you'd like to allow your disk to spin down. Then take some safety margin ;-)

Sounds reasonable, and without wanting to turn this bug report into a discussion thread: Are there some interesting values for apm_battery between 128 and 254 to try out, to sort of find a good trade-off between lots of load cycles vs. heads never being parked? I googled without much success, it seems to be all or nothing.

On Wed, May 16, 2012 at 03:04:07PM -0000, Torsten Römer wrote:
> Sounds reasonable, and without wanting to turn this bug report into a
> discussion thread: Are there some interesting values for apm_battery
> between 128 and 254 to try out, to sort of find a good trade-off between
> lots of load cycles vs. heads never being parked? I googled without much
> success, it seems to be all or nothing.

The meaning of these values is very implementation-dependent. As the
hdparm(8) manpage says, 1-127 "permit spin-down", and 128-254 "do not permit
spin-down"; other than that, there's no requirement for different values to
give different results, except that the lower the number the more aggressive
the power management.

--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
<email address hidden> <email address hidden>

Dear any interested,

I just found out that the hdparm -B and -S parameters were being overridden by the laptop_mode-tools. Whenever I put my laptop on battery after using it on AC, its hdparm values set at boot time are overridden by the settings inside the following file (if you have laptop_mode-tools installed, that is). I hope this will give insight to the devs to do something about this issue.
I checked it myself by modifying BATT_HD_POWERMGMT from 1 to 128 and voila, it keeps its 128 value.

Surely, the laptop_mode-tools is the place to fine tune the hdparm vales while on battery.

an excerpt of: sudo gedit /etc/laptop-mode/laptop-mode.conf

#
# Idle timeout values. (hdparm -S)
# Default is 2 hours on AC (NOLM_HD_IDLE_TIMEOUT_SECONDS=7200) and 20 seconds
# for battery and for AC with laptop mode on.
#
LM_AC_HD_IDLE_TIMEOUT_SECONDS=20
LM_BATT_HD_IDLE_TIMEOUT_SECONDS=20
NOLM_HD_IDLE_TIMEOUT_SECONDS=7200

# Should laptop mode tools control the hard drive power management settings?
#
# Set to 0 to disable
CONTROL_HD_POWERMGMT="auto"
#
# Power management for HD (hdparm -B values)
#
BATT_HD_POWERMGMT=1
LM_AC_HD_POWERMGMT=254
NOLM_AC_HD_POWERMGMT=254

On Fri, May 18, 2012 at 10:34:41AM -0000, Dagnachew L. wrote:

> I just found out that the hdparm -B and -S parameters were being
> overridden by the laptop_mode-tools.

Oops. I knew this was a possibility - sorry for failing to mention it.

laptop-mode-tools is not part of the standard stack, in part because it does
work at cross-purposes with the existing hooks in hdparm.

I wonder why you are not using by default laptop-mode in ubuntu instead of trying to hook hdparm rules here and there.
I have switched to laptop-mode, set all values for hdparm -B to 254 and problem is gone.
I have uncommented also in /etc/apm/event.d/20hdparm:
APMD_DRIVES=""
Don't know if it is relevant.
I am using xubuntu and I have unchecked in the power manager setting the spindown option, to let laptop-mode do the job.
laptop-mode allow fine settings for many other things also, using it would simplify a lot power settings in ubuntu.

hdparm is contradicting itself in /usr/lib/pm-utils/power.d/95hdparm-apm (Using LMDE+UP5, kernel 3.2+45, hdparm 9.39-1+b1)

$ head /usr/lib/pm-utils/power.d/95hdparm-apm

#! /bin/sh
#
# This script adjusts hard drive APM settings using hdparm. The hardware
# defaults (usually hdparm -B 127) cause excessive head load/unload cycles
# on many modern hard drives. We therefore set hdparm -B 254 while on AC
# power. On battery we set hdparm -B 127, because the head parking is
# very useful for shock protection.
#
# Refactored from acpi-support's 90-hdparm.sh for pm-utils

It is obviously confusing -B 127 (which permits spin-down) with APM (-B 128) permitting PM (including head-parking) but not spin-down.

For instance, on my WD Scorpio Blue WD10JPVT, which had idle3 in its firmware modified from default 8sec to 180sec (3min) using `idle3ctl` (or wdidle3 in DOS!), I'm parking at an acceptable rate with the default PM level of 128, when on battery, without spin-downs, just as I wanted.

# hdparm -I /dev/sda | grep Advanced
 Advanced power management level: 128
    * Advanced Power Management feature set

# hdparm -I /dev/sda | grep -i standby
 Standby timer values: spec'd by Standard, with device specific minimum

For me, this isn't fixed for Ubuntu 12.04.2 LTS.