ubuntuusers.de

Die Info kann ich bestätigen nach meinen Recherchen: https://bugs.launchpad.net/ubuntu/+source/acpi-support/+bug/205005 Nicht gerade LTS like. ☹

Ich hab das jetzt auch so gelöst, dass ich ein neues Skript für pm-utils geschrieben habe. Wie die neuen Scripte aussehen müssen, kann man hier sehen: usr/lib/pm-utils/sleep.d Und hier sollten, so hab ichs verstanden, die neuen Skripte hin: /etc/pm/sleep.d

Zumindest hat man mit der neuen Methode weniger Dateien zu verwalten.

punischdude schrieb:

Ich bin derzeit dabei diesen 🇬🇧 Fix zusammen mit dieser Verbesserung 🇬🇧 zu testen.

Bevor ichs vergesse: Ich hab das jetzt einige Tage getestet und es scheint auch mit Suspend2Ram und Suspend2Disk gut zu funktionieren.

Werde das ganze demnächst in den Wiki-Artikel mit einbauen.

punischdude schrieb:

punischdude schrieb:

Ich bin derzeit dabei diesen 🇬🇧 Fix zusammen mit dieser Verbesserung 🇬🇧 zu testen.

Bevor ichs vergesse: Ich hab das jetzt einige Tage getestet und es scheint auch mit Suspend2Ram und Suspend2Disk gut zu funktionieren.

Das kann ich auch hier bestätigen. Nach der Anleitung funktioniert der Fix auch auf Ubuntu Hardy nach dem Aufwecken aus dem Standby Modus.

Werde das ganze demnächst in den Wiki-Artikel mit einbauen.

Das wäre gut. Die Anleitung mit dem offiziellen Debian Fix funktioniert nicht unter Ubuntu Hardy.

hallo leute"

ist das problem denn endlich behoben? meine beiden notebooks (intrepid und hardy) haben das problem scheinbar! die smartausgabe des einen gibt zudem keine werte über die absolvierten parkvorgänge aus. aber es klackert munter, obwohl das acpi-support paket in intrepid scheinbar integriert ist? ich hab keine ahnung.

warum finde ich keine neueren einträge zu dem thema obwohl das problem scheinbar noch existiert?

Nein, offensichtlich ist der Fehler noch nicht behoben. Das können eigtl auch nur die Hersteller, da nur die wissen, was speziell für die eingebaute Platte am günstigsten ist.

Am besten du probierst mal die temporäre Methode aus und wenn das Klackern weg geht und die Temperatur im Rahmen bleibt, kannst du den dauerhaften Fix anwenden.

Sollte die Temperatur zu hoch werden, dann einfach mal niedrigere Werte eingeben und wieder prüfen.

das ist ja mal richtig furchtbar... hab die temporäre methode schon probiert. allerdings erst nur auf dem notebook mit intrepid, was keinen load_cycle_count anzeigt... das ergibnis: meine linke hand wird beim tippen stark erwärmt, oh mann... warum zeigt er mir keinen load_cycle_count an???

gibt es festplatten die definitiv nicht davon betroffen sind? wie kanns denn sein, dass dieser bug so lange besteht (gut, ich habe mich das auch erst nach einer bestimmten zeit gefragt, aber irgendwann fiel das klacken schon auf)?

Hab jetzt mit deim einem Workaround das Problem "beheben" können... (über das script mit hdparm wie im wiki beschrieben) habe ebenso mit samsung geredet. die meinten es könnte auch an der firmware liegen. ..und ich ärger mich über den im letzten zeitraum aufgetretenen verschleiß.

um linux da ein wenig in schutz zu nehmen: unter windows gabs das problem auch.

Aktiviert mal die "intrepid-proposed"-Quellen. Da gibt es ein Update für das Paket "acpi-support". Mit diesem soll laut Changelog das Problem endlich beseitigt sein.

glasen schrieb:

Aktiviert mal die "intrepid-proposed"-Quellen. Da gibt es ein Update für das Paket "acpi-support". Mit diesem soll laut Changelog das Problem endlich beseitigt sein.

In hardy-proposed ist ebenfalls ein Fix, wie es scheint.

ohne voreilig fro sein zu wollen: unter hardy scheint es zu funzen. wo er früher in wenigen minuten über 2 dutzend counts hatte, hat er jetzt keinen einzigen gehabt.

PROBLEM: meine smartausgabe auf meinem intrepid system gibt keinen LOAD_CYCLE_COUNT aus! wie bekomm ich die auf den schirm?

edit: definitiv: unter hardy klappt der patch. intrepid kann ich noch nicht bestätigen wg. obigen problems.

Ich habs mir ja fast schon gedacht: Grundsätzlich funktioniert es, nur beim Aufwachen aus dem Stand-By werden wieder die alten Werte geladen, bzw. das Skript nicht ausgeführt.

Ursache: https://bugs.launchpad.net/ubuntu/+source/acpi-support/+bug/205005/comments/2

Abhilfe:

sudo install /etc/acpi/resume.d/90-hdparm.sh /etc/pm/sleep.d/ 

naja, aber gibts denn jetzt auch nen "sündenbock" für den fehler? was verursachte ihn denn überhaupt? ich lese immer nur von workarounds etc, aber nichts von "kauft keine platten mehr von xy, die haben den fehlern"...

Morgen zusammen!

Ich habe gestern dank OlMightyGreek auch das acpi-support-Paket aus den proposed-Quellen installiert. Der load_cycle_count Zähler steht ☺. Hier bei mir mit Intrepid, keine Probleme, den anzeigen zu lassen. Nur das mit dem Standby habe ich dann gestern abend noch bemerkt. Mal schauen, was sich da gegen machen lässt.

Edit: @punischdude: Habe jetzt mal deine Methode getestet. Denke ja mal, dass einfach das Skript, das die Festplatte vor den ganzen "head load/unload cycles" schützt, in den Programmordner des Powermanagers installiert wird, von wo es auch nach einem Standby abgerufen wird. Meine Frage: Wieso nicht einfach cp? (Die ist nicht rhetorisch oder so, ich weiß es einfach nicht ^^)

Sasha schrieb:

Meine Frage: Wieso nicht einfach cp? (Die ist nicht rhetorisch oder so, ich weiß es einfach nicht ^^)

Install setzt zb. noch das x-Bit, cp tut das vermutlich nicht automatisch.

Kleiner Hinweis noch:

Statt install sollte man wohl besser nur einen symbolischen Link setzen:

 sudo ln -s /etc/acpi/resume.d/90-hdparm.sh /etc/pm/sleep.d/ 

Sehe ich es richtig, dass es also immer noch keine komplette Lösung gibt, da immer noch ein bisschen Handarbeit notwendig ist?

Löst die Methode das Problem nun auch, wenn man im Akkubetrieb ist?

Meine derzeitige Lösung unterbindet das Klicken nämlich generell: Mich nervt das Geräusch! 😉