ubuntuusers.de

mwildam schrieb:

@Astrid: Du hast nicht geschrieben, ob Du es mit anderen Kernels probiert hast. Wie ich geschrieben habe, war das bei mir die Ursache der Instabilitäten.

@axt: BTW: Ich fahre jetzt mit der Ubuntu-Version vom 3.5er-Kernel, wie Du mir empfohlen hast - danke nochmals herzlich an dieser Stelle. Sieht soweit gut aus, aber mit Sicherheit kann ich das erst nach ein paar Tagen sagen.

Ich hoffe, es ist ok, wenn ich mich hier auch mit einer "Zusatzfrage" anhänge?

Es ist inzwischen erwiesen, daß der 3.2 Kernel zu bösen Freezes mit Ivy Bridge + HD4000 Graphik führt (s. dieser und merged Bugs). Ich selbst bin deshalb auf Kernel 3.4 von kernel.org umgestiegen (original config aus /boot/ mit "make silentoldconfig" verwendet) - das ist grundsolide jetzt. Grund für 3.4 ist, daß 3.5 schon EOL erreicht hat und 3.6 zu viele Neuerungen hat, so daß mit Inkompatibilitäten zu rechnen ist. 3.4 ist auch ein "Long Term Kernel" und wird von Greg Kroah-Hartman selbst für ca. 2 Jahre gepflegt.

Daraus ergibt sich auch meine Frage:

Muß man/sollte man auch diesen Kernel regelmäßig updaten - ist ganz schön mühsam? Ich habe mit 3.4 aus GIT angefangen und den 3.4.18-Patch eingespielt. Jetzt ist 3.4.19 raus, also den 3.4.18-Patch entfernen (patch -R) und den 3.4.19-Patch einspielen. Dauert incl. kompilieren zwar nur 15 Minuten, aber ist diese Prozedur wirklich sinnvoll bei jedem Update, falls eigentlich alles ok. und stabil läuft?

Beste Grüße,
Ingo

Seit dem Abtrennen aus diesem Thread - wo die Frage eigentlich zum Thema gepaßt hätte - ist sie in den Tiefen des Forums still verschwunden.

Gibt es Niemanden, der hier schon Erfahrung hat oder Ratschläge geben kann?
(bin jetzt über von Kernel 3.4.18 über 3.4.19, 3.4.20 bei 3.4.21 angelangt)

Viele Grüße,
Ingo

Hi Ingo,

ich habe ähnliche Hardware und nutze deswegen auch nicht den 3.2er Kernel. In experimental ist momentan 3.6.8, da muss man also nicht extra kompilieren. Es gibt kein Metapaket für diese Pakete aus experimental, also kann man sich z.B. durch Abonnieren des entsprechenden Feeds von der PTS-Seite 🇬🇧 über Updates informieren. (Ich gehe davon aus, dass du Debian nutzt.)

Oder bist du auf eine bestimmte Konfiguration angewiesen? Dann fällt mir momentan keine Abkürzung ein.

Gruss Lasall

Was soll man denn anderes sagen als "selbstverständlich mußt Du ständig aktualisieren"?

Du brauchst ja nicht selbst kompilieren, kannst z.B. auch unter Precise (das hast Du zumindest vor kurzem gefahren) Ubuntu-Kernel 3.5.0-x oder 3.7.0-x nutzen.

so daß mit Inkompatibilitäten zu rechnen ist.

Und sind welche aufgetreten? Gar nicht erst getestet, stimmt's?

Lasall schrieb:

Hi Ingo,

ich habe ähnliche Hardware und nutze deswegen auch nicht den 3.2er Kernel. In experimental ist momentan 3.6.8, da muss man also nicht extra kompilieren. Es gibt kein Metapaket für diese Pakete aus experimental, also kann man sich z.B. durch Abonnieren des entsprechenden Feeds von der PTS-Seite 🇬🇧 über Updates informieren. (Ich gehe davon aus, dass du Debian nutzt.)

Jepp, ist richtig: Wheezy

Oder bist du auf eine bestimmte Konfiguration angewiesen? Dann fällt mir momentan keine Abkürzung ein.

Danke für die schnelle Antwort. Hatte schon mal den 3.5.x probiert. Auch der war bezüglich Stabilität absolut ok, ist jetzt aber EOL. Außerdem hat da VBox 4.1.18 aus dem Wheezy-Repo Probleme gemacht - ist ja auch gemäß changelog noch nicht für 3.5-Hosts geeignet. Deshalb habe ich 3.4 gewählt. Und mit der .config von Kernel 3.4.4... aus experimental ist das Kompilieren problemlos (ein make -j4 deb-pkg dauert hier komplett 11 min. und liefert fertige *.deb's).

@ axt Ich dachte mir, wenn alles stabil läuft, ist ein Update nur bei ernsten Security-Fixes nötig - und die erfährt man dann auch durch die "Presse"?

Beste Grüße,
Ingo

EDIT:

Bei Debian sieht es nicht danach aus, als würde der Bug (ist als serious + RC getagged) in absehbarer Zeit behoben. Schätze mal, das hat mit den vielen Backports für Ivy Bridge zu tun, da 3.2 ja schon vor Erscheinen der CPU's raus kam). Im Moment ist man daran, per bisect den Übeltäter zu finden - und das kann dauern. Bei Wheezy möchte ich aber langfristig bleiben ... das ist das Probem 😉

Sorry!

Dieser Beitrag wurde am 27.03.2013 geschrieben.

War mein Fehler, ich habe "editieren" statt "zitieren" gewählt - damit ist natürlich auch der "zitierte Post" weg ☹

Bei Debian sieht es nicht danach aus, als würde der Bug (ist als serious + RC getagged) in absehbarer Zeit behoben. Schätze mal, das hat mit den vielen Backports für Ivy Bridge zu tun, da 3.2 ja schon vor Erscheinen der CPU's raus kam). Im Moment ist man daran, per bisect den Übeltäter zu finden - und das kann dauern. Bei Wheezy möchte ich aber langfristig bleiben ... das ist das Probem 😉

So, jetzt ist das Problem wohl endgültig unter Wheezy gelöst mit Kernel 3.2.41-2. Den kompletten Backport von drm/i915 vom 3.4 gab's ja schon etwas länger, aber es gibt da einen ganz aktuellen Patch für i915, welcher erst jetzt in alle Kernel (bis einschließlich 3.8) eingezogen ist. Ich zitiere daraus den Author Stéphane Marchesin:

This increases GEN6_RC6p_THRESHOLD from 100000 to 150000. For some reason this avoids the gen6_gt_check_fifodbg.isra warnings and associated GPU lockups, which makes my ivy bridge machine stable.

Ich hatte bisher noch sehr sporadisch Probleme nach Suspend (s2ram) mit hoher CPU-Last auf 2 Kernen - sah' aus wie eine race condition. Das sollte jetzt auch der Vergangenheit angehören. So, wie es aussieht, hat Intel beim i915 wohl größten Wert auf Energiesparen gelegt, was dann nicht das Optimum an Stabilität gab.

Das regelmäßige "Kernel bauen/pflegen" alle 1 - 2 Wochen hat damit ein Ende - und Wheezy ist fast fertig!

Ich markiere deshalb den Thread als gelöst,
Ingo

Wer noch betroffen ist: in wie weit dieser Patch auch schon in Ubuntu-Kerneln ist - wüßte nicht, wie man das feststellt.