[gelöst] Kernel 4.6 und später hängt

Hast Du Probleme mit Hardware, die durch die anderen Foren nicht abgedeckt werden? Schau auch in den "Tipps und Tricks"-Bereich.
Antworten
Benutzeravatar
smutbert
Moderator
Beiträge: 8317
Registriert: 24.07.2011 13:27:39
Wohnort: Graz

[gelöst] Kernel 4.6 und später hängt

Beitrag von smutbert » 24.12.2016 23:16:26

Hallo liebe Leute,

auf meinem schönen Notebook (Broadwell) habe ich seit Kernel 4.7 (glaube ich) ein paar Probleme. Unter jessie mit dem Kernel aus den backports äußert sich das so, dass das System nach einiger Zeit - vermutlich nach dem Aktivieren eines Stromsparmoduses, Suspend ist es allerdings noch nicht - in der GUI nur mehr extrem langsam reagiert. Mit ssh oder in einem Text-VT kann ich das System aber meist herunterfahren/neu starten:
NoPaste-Eintrag39648
zusätzlich ist meist, ohne dass ich in den Logs etwas darüber finde, die WLAN-Verbindung futsch


Unter stretch, das ich inzwischen noch etwas lieber verwende, passiert im wesentlichen dasselbe, aber ich kann das System durch einmal in den Suspendmodus schlafenlegen und wieder aufwecken wieder in einen benutzbaren Zustand bringen
NoPaste-Eintrag39649
hier kann ich etwas genauer sagen, was passiert ist. Um ~22:40 war er mit dem Start fertig und ich habe mich angemeldet, wollte dann erst gute 10 Minuten später (~22:52) etwas machen. Da war der Bildschirm schwarz, aber es war wieder noch nicht der Suspendmodus. Nach dem zweiten Tastendruck hat das System bereits nicht mehr reagiert und ich konnte auch auf kein Text-VT schalten. Ich habe dann den Powerschalter gedrückt, woraufhin das System ganz normal in den Suspend2RAM gegangen ist und eine Sekunde später beim nächsten Tastendruck, zwar mit etwas Geflacker, aber doch ordnungsgemäß wieder aufgewacht ist. Seitdem läuft das System wieder.

Das ganze passiert mit angeschlossenem Lade-/Netzgerät genauso wie im Akkubetrieb. Habt ihr eine Idee oder kennt ihr vielleicht eine Quelle für einen weiterhin gepflegten Kernel 4.5 oder 4.6?

lg smutbert
Zuletzt geändert von smutbert am 28.12.2016 00:27:47, insgesamt 1-mal geändert.

scientific
Beiträge: 3020
Registriert: 03.11.2009 13:45:23
Lizenz eigener Beiträge: Artistic Lizenz
Kontaktdaten:

Re: Kernel 4.7 und später hängt

Beitrag von scientific » 25.12.2016 11:59:45

Das ist mir auch schon aufgefallen.
Nach suspend hatte ich schon Probleme mit cups, Networkmanager, Gnome3...
Ich verwende schon seit langem die Testingkernel... Kann also nicht sagen, seit welchem das auftritt.
dann putze ich hier mal nur...

Eine Auswahl meiner Skripte und systemd-units.
https://github.com/xundeenergie

auch als Debian-Repo für Testing einbindbar:
deb http://debian.xundeenergie.at/xundeenergie testing main

rendegast
Beiträge: 15041
Registriert: 27.02.2006 16:50:33
Lizenz eigener Beiträge: MIT Lizenz

Re: Kernel 4.7 und später hängt

Beitrag von rendegast » 25.12.2016 13:05:20

Code: Alles auswählen

/sbin/modinfo i915 | sort
gibt einige power-Schalter.

Boot-Parameter 'i915.modeset=0' ?
Power-Sachen und Beschleunigung funktionieren dann zwar auch nicht, aber vielleicht bleiben die Hänger aus.
Dann wäre zumindest die Fehlerquelle eingekreist.



---------------------------------------------
Allgemeine Läster-Ergänzung
Mit/Ab dem 4.7 jessie-backports startet ein Board mit P4 (radeon) und eines mit P3 (modeset resp. KMS deaktiviert) nicht mehr.
Ab der grub-Ausgabe "Booting ..." Peng, nix mehr.
mfg rendegast
-----------------------
Viel Eifer, viel Irrtum; weniger Eifer, weniger Irrtum; kein Eifer, kein Irrtum.
(Lin Yutang "Moment in Peking")

Benutzeravatar
smutbert
Moderator
Beiträge: 8317
Registriert: 24.07.2011 13:27:39
Wohnort: Graz

Re: Kernel 4.7 und später hängt

Beitrag von smutbert » 26.12.2016 00:01:12

Ja, das sind viele Optionen. Wegen früherer Erfahrungen (aus denen vor allem du mir herausgeholfen hast) habe ich speziell bereits enable_ips, enable_execlists und semaphores deaktiviert und gerade sehe ich in meinen Kommentaren, dass ich enable_fbc auch schon deaktiviert später aber wieder aktiviert habe.
Also probiere ich nun die Optionen durch - bis jetzt hat nichts geholfen.

Die Fehler treten unter stretch mitunter auch ohne diese tracebacks (oder irgendwelche andere Meldungen) auf, vielleicht abhängig von den i915-Optionen und die eingefrorene Grafik lässt sich dann auch nicht mehr mit einem Suspendzyklus „lösen“ - dh vielleicht ginge das sogar, aber ich schaffe es dann nicht mehr zuverlässig den Suspend zu aktivieren. ssh funktioniert aber immer noch.
Zuletzt geändert von smutbert am 27.12.2016 11:00:33, insgesamt 1-mal geändert.

rendegast
Beiträge: 15041
Registriert: 27.02.2006 16:50:33
Lizenz eigener Beiträge: MIT Lizenz

Re: Kernel 4.7 und später hängt

Beitrag von rendegast » 27.12.2016 09:47:41

Ist eine weithergeholte Idee da erst mit dem kernel 4.8 (64bit debian) gekommen,
bei mir gab es Ausfälle dietlibc-bezogener Programme wegen einer neu gesetzten Option
/boot/config-4.8.0-0.bpo.2-amd64:# CONFIG_LEGACY_VSYSCALL_EMULATE is not set
/boot/config-4.8.0-0.bpo.2-amd64:CONFIG_LEGACY_VSYSCALL_NONE=y
(Debian Bugreport843128)
Vorher
CONFIG_LEGACY_VSYSCALL_EMULATE=y
# CONFIG_LEGACY_VSYSCALL_NONE is not set
Bei Dir gibt es auch nur diese Zeile, die irgendwie in die Richtung deutbar wäre
[Sat Dec 24 22:51:56 2016] [<ffffffff883efa76>] ? system_call_fast_compare_end+0xc/0x96
Der auszuprobierende Kernelparameter wäre 'vsyscall=emulate'.



smutbert hat geschrieben: oder kennt ihr vielleicht eine Quelle für einen weiterhin gepflegten Kernel 4.5 oder 4.6?
Vielleicht der kernel 4.4 aus ubuntu xenial (LTS)?
http://packages.ubuntu.com/linux-generic
Momentanes linux-image-4.4.0-57-generic (4.4.0-57.78) entspricht wohl linux 4.4.35 (aktuell 4.4.39).

Andernfalls ein lokales Repo mit 'make ... deb-pkg'-gebauten Kernelpaketen.
Empfehlung: CONFIG_DEBUG_INFO abschalten wegen enormer Verlängerung der Bauzeit und Platzverbrauch.
Bei einem 8-Kerner mit 'make -j9' (also Vollauslastung) und auf einem tmpfs geeigneter Größe (2GB) ist das Bauen wohl in 10 Minuten erledigt.
mfg rendegast
-----------------------
Viel Eifer, viel Irrtum; weniger Eifer, weniger Irrtum; kein Eifer, kein Irrtum.
(Lin Yutang "Moment in Peking")

Benutzeravatar
smutbert
Moderator
Beiträge: 8317
Registriert: 24.07.2011 13:27:39
Wohnort: Graz

Re: Kernel 4.6 und später hängt

Beitrag von smutbert » 28.12.2016 00:27:26

vsyscall=emulate wars (leider) nicht.

nomodeset=0 führt ediglich dazu, dass weder gdm noch X startet. X scheitert trotz xorg.conf mit dem Intel-, statt des Modesetting-Treiber mit "(EE) no screens found(EE)" und wayland geht ohne kms wohl sowieso nicht.

Nach langem Suchen habe ich eine Option gefunden, die das Problem zu lösen scheint enable_psr=0. Das ist wohl eine von 2 Optionen, die seit Kernel 4.6 standardmäßig aktiv sind (enable_dc=0 ist die zweite).

Jetzt hatte ich schon öfter Probleme mit der Grafik von Intel und aller guten Dinge sind bekanntlich drei
  • das erste Mal hat die Option fastboot=1 von i915, die ich in einer Konfigurationsdatei „vergessen“ hatte, zu Problemen geführt (viewtopic.php?f=13&t=152442&start=15)
  • das zweite Mal war nach einem Kernelupdate die Option enable_fbc=0 die Lösung (mit dem neuen Kernel wurde das Feature standardmäßig aktiviert, siehe viewtopic.php?f=12&t=159065)
  • und hier in diesem Thread ists wohl dasselbe mit enable_psr=0, nur hab ich den Unterschied/Fehler beim falschen Update gesucht 4.6→4.7 statt 4.5→4.6
ich hoffe damit hat sich das endültig erledigt. Ich bin einmal so optimistisch und markiere den Thread als gelöst.

Vielen Dank für die Hilfe und nicht zuletzt die moralische Unterstützung ☺

rendegast
Beiträge: 15041
Registriert: 27.02.2006 16:50:33
Lizenz eigener Beiträge: MIT Lizenz

Re: [gelöst] Kernel 4.6 und später hängt

Beitrag von rendegast » 28.12.2016 08:23:42

Jetzt hatte ich schon öfter Probleme mit der Grafik von Intel und aller guten Dinge sind bekanntlich drei

das erste Mal hat die Option fastboot=1 von i915, die ich in einer Konfigurationsdatei „vergessen“ hatte, zu Problemen geführt (viewtopic.php?f=13&t=152442&start=15)
das zweite Mal war nach einem Kernelupdate die Option enable_fbc=0 die Lösung (mit dem neuen Kernel wurde das Feature standardmäßig aktiviert, siehe viewtopic.php?f=12&t=159065)
und hier in diesem Thread ists wohl dasselbe mit enable_psr=0, nur hab ich den Unterschied/Fehler beim falschen Update gesucht 4.6→4.7 statt 4.5→4.6

ich hoffe damit hat sich das endültig erledigt. ...
Bei samba habe ich die Möglichkeit, mir die default-Werte ausgeben zu lassen, 'testparm -v /dev/null',
so auch bei 'doveconf', 'postconf'.
Ein Vergleich der Ausgabe mit früheren Versionen war mir bei samba schon öfter hilfreich.

Bei Deinem Modul gibt es wohl nur 'modinfo i915 -k xxxxx' zum Vergleich.
Bei 'enable_fbc' steht der Wert bei 3.16 wie 4.8 jedoch auf 'per chip'.

Eventuell können die effektiven Werte bei zumindest geladenem Modul (noch ohne X) irgendwo ausgelesen werden, /proc/, /sys/.
Vergleich dieser mit den Werten unter kernel 4.6 hätte ja dann vielleicht die Aktivierung von PSR für die Grafikkarte gezeigt.

Und eine Rückmeldung an kernel.org, daß PSR und fbc für diesen chip doch nicht funktionieren.
mfg rendegast
-----------------------
Viel Eifer, viel Irrtum; weniger Eifer, weniger Irrtum; kein Eifer, kein Irrtum.
(Lin Yutang "Moment in Peking")

Benutzeravatar
smutbert
Moderator
Beiträge: 8317
Registriert: 24.07.2011 13:27:39
Wohnort: Graz

Re: [gelöst] Kernel 4.6 und später hängt

Beitrag von smutbert » 28.12.2016 21:31:03

Das mit enable_fbc war eine merkwürdige Geschichte. NAB hat den Quellcode herausgesucht (viewtopic.php?f=12&t=159065&start=30#p1077411), keine Ahnung warum das erst mit dem Kernelupdate aufgetreten ist - hatte das falsch in Erinnerung.
Zwischenzeitlich war enable_fbc=0 jedenfalls nicht mehr notwendig - ich bin noch dabei schrittweise die vielen anderen Optionen, die ich ausprobiert habe wieder zu entfernen, dann seh ich ja ob fbc noch immer Probleme verursacht.

Ich habe auch versucht im sysfs die aktivierten Optionen in den Dateien unter »/sys/kernel/debug/dri/0/« zu vergleichern, aber dabei muss auch irgendwas schief gegangen sein sonst wäre mir das aktivierte psr vermutlich früher aufgefallen.

Das Feedback hab ich an den Maintainer von i915 geschrieben.

Antworten