ukripper
May 21st, 2008, 11:46 AM
Is hard-disk ticking bug(load/unload cycle) still in hardy ( Vostro 1400)? Please can anyone confirm that for me? I had it on gutsy and I had to use hdparm workaround to fix that in 7.10.
Bug:https://launchpad.net/ubuntu/+source/acpi-support/+bug/59695
This is very critical bug and I really hope that is fixed in Hardy!
From the above link: an interesting post:
"ethanay wrote on 2008-05-12: (permalink)
for people without heat problems, the ugly fixes for /etc/pm/*.d/ or /etc/acpi/*.d/ will work just fine. However, for people who have heat problems or require shock protection, the solution is much more complicated. furthermore, a solution for everyone is the most complicated, because it has to take into account both of the previous.
like someone else has pointed out, an ugly fix such as hdparm -B 254 is NOT a viable fix for Canonical to release for everyone because some people are dealing with excessive heat problems. This means that they have to work much harder to develop a more sophisticated solution to the problem that will be OK for everyone: appropriate apm settings for both unoptimized hdd i/o and also settings to optimize hdd i/o to allow for aggressive apm. given the complex software environment that this situation exists in, that takes time to develop and test.
however, i agree with others pointing out that it seems communication from Canonical to the general user population on this issue has been extremely lacking. that seems to me to be the bigger issue that this bug has exposed. either this is a fluke, or Canonical needs to use a more effective communications model in order to get messages out to the general user base."
Bug:https://launchpad.net/ubuntu/+source/acpi-support/+bug/59695
This is very critical bug and I really hope that is fixed in Hardy!
From the above link: an interesting post:
"ethanay wrote on 2008-05-12: (permalink)
for people without heat problems, the ugly fixes for /etc/pm/*.d/ or /etc/acpi/*.d/ will work just fine. However, for people who have heat problems or require shock protection, the solution is much more complicated. furthermore, a solution for everyone is the most complicated, because it has to take into account both of the previous.
like someone else has pointed out, an ugly fix such as hdparm -B 254 is NOT a viable fix for Canonical to release for everyone because some people are dealing with excessive heat problems. This means that they have to work much harder to develop a more sophisticated solution to the problem that will be OK for everyone: appropriate apm settings for both unoptimized hdd i/o and also settings to optimize hdd i/o to allow for aggressive apm. given the complex software environment that this situation exists in, that takes time to develop and test.
however, i agree with others pointing out that it seems communication from Canonical to the general user population on this issue has been extremely lacking. that seems to me to be the bigger issue that this bug has exposed. either this is a fluke, or Canonical needs to use a more effective communications model in order to get messages out to the general user base."