Tablet ohne Tabletfunktionen: INTEL i915 IPTS

„Das kann nicht wahr sein!?“ Durchatmen.. “ ***** **** *** ***** *********** **** *********!“ ist besser so. Das kann einfach nicht wahr sein, oder ? Da hatte man ein Probegerät, daß sofort ging, und dann sowas. Stand der Dinge: Ein sehr teures, wenn auch recht leistungsfähiges Laptop mit nur einem USB Anschluß und einem Pappdeckel als Tastatur!

INTEL i915 IPTS

Das Ende vom Lied, M$ hatte dem Pro4 neue spezial Hardware von Intel spendiert um es mit dem i7-6th Gen auch voll ausreizen zu können. Natürlich hatte Intel M$ alle Infos gegeben um mit dem Chipsatz zu arbeiten, aber der freien Welt hatte man das nicht rechtzeitig mitgeteilt. Also: kein Touch, WLAN nur begrenzt, keine Kameras, und davon hat das Tablet gleich zwei Stück.

Auch wenn es im Dorf Braunschweig das zweite Tablet mit Linux war, in der Welt war es das nicht. Andere hatten das Problem auch schon vorgefunden und keine Lösung gehabt, bis Jake Day in seinem GithubRepo eine Patchserie für den Kernel veröffentlichte, und damit einen Teil des Problems löste.

Kernel selber bauen

Oh man, den Kernel also selbst bauen. Wieso nicht, habe ich früher öfter gemacht und einige GrSecurity Bugs behoben. Eigentlich hatte ich ja gehofft, daß diese Zeiten vorbei wären, aber watt mutt, datt mutt sagten sie auf dem Dorf meines Onkels immer. Daher für Euch jetzt die Anleitung, wie man das macht.

Jetzt muß ich vorher sagen, daß Jake seine Anleitungen für Ubuntu & Co geschrieben hat, was einige Adaptionen für Fedora nötig gemacht hat. Die kommen teilweise von Zak Myth.

Vorbereitungen

Ich habe mir das Leben einfacher gemacht und erstmal den SSHD so umkonfiguriert, daß ich mit Schlüssel auf das Surface drauf konnte und alle Kommandos vom PC absetzen konnte. Solltet Ihr auch machen, weil das TypeCover zwar funktioniert, aber nicht so schön, wie die eigene Tastatur ist 🙂

Zunächst mal die Tools, die wir brauchen werden installieren:

dnf groupinstall „Development Tools“
dnf groupinstall „C Development Tools and Libraries“
dnf install elfutils-devel openssl-devel perl-devel perl-generators pesign ncurses-devel

Dann brauchen wir natürlich den Source:

cd /root
mkdir -p kernel/4.19.23
mkdir -p patche/4.19
cd patche/4.19
git clone https://github.com/jakeday/linux-surface.git

Jetzt Setupen, also einstellen was man an Patchen haben will. Hibernate wäre clever, wenn man keine verschlüsselte Festplatte hat.

chmod 700 setup.sh
./setup.sh
cd /root/kernel/4.19.23
git clone git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git .
git checkout v4.19.23
vi Makefile

Hier ändern wir jetzt den Wert für „EXTRAVERSION“ auf z.B. „-surface-pro4“ . Damit bekommt man einen Zusatz am Kernelfile, was im Grubmenü später für Klarheiten sorgt. Wir wenden die Patche auf den Kernel an:

for i in ../../patche/4.19.23/patches/4.19/*.patch; do patch -p1 < $i; done

kopieren die aktuelle Fedora Kernelconfiguration, die ja so schlecht nicht ist :

cp /boot/config-4.20.6-200.fc29.x86_64 .config

man muß aber beachten, daß Ihr den für Euch neuesten Kernel und dessen Config benutzt! Dann erzeugen wir ein Backup:

make oldconfig

passen die config an :

vi .config

make -j `getconf _NPROCESSORS_ONLN` bzImage
make -j `getconf _NPROCESSORS_ONLN` modules
make -j `getconf _NPROCESSORS_ONLN` modules_install
make -j `getconf _NPROCESSORS_ONLN` install

und reboot.

Und wer vorher mal das Bootmenü wie im Artikel Wie man den GRUB2-EFI-Bootfont ändert beschrieben angepaßt hat, der kann sich jetzt auch den eigenen Kernel aussuchen ohne Augenschäden befürchten zu müssen.

Der Rückschlag

„Nichts ist, wie es scheint.“ der Leitspruch aus dem Film 23 trifft natürlich mal wieder voll ins Mark. Surface bootet nicht, weil dem Kernel nicht vertraut wird. Also muß man dem Surface Bios sagen, daß es doch bitte mitspielen soll. Am Ende wollte es nicht mitspielen ohne einen roten Balken einzublenden, daß wir ohne trusted Plattform usw. arbeiten und dann gings.

Der Kernel triggert dann im Bootprozess SELinux an, doch mal alles umzulabeln, weil ist ja jetzt per Se unsicher usw. Nervig 5 Minuten später der nächste Reboot und nun kanns endlich losgehen.

Und ja.. TOUCH GEHT! \o/

Wie jetzt, daß geht nur 5 Minuten lang ?

Mehr dazu im nächsten Teil der Serie 😀

Surface Pro4 … und nichts ist wie es sein sollte

Das Surface Pro4 kam prompt. Der Verkäufer war seriöse, das Gerät in Ordnung, genau wie in der Beschreibung. Eigentlich ein idealer Zeitpunkt vor Freude in die Luft zu springen. Ok, es kam aus der Kälte, also durfte es erst einmal warm werden.

Die Generation macht den Unterschied

Dann der Boot. Der Erzfeind erscheint: Windows 10. Der alte Besitzer hatte es frisch reinstalliert. Ok. Also dann USB-Stick dran und davon booten. Das ging noch. Der Livestick lies sich booten, wenn man im Bios den Bootmanager benutzt und per „Wischen“ sagt: „boote von dem wo ich gewischt habe“. Ja, man hat schon einfachere Bootmanager gesehen 🙂

Fedora bootet. So weit, so gut. Erstmal ein Backup von der alten Platte machen, besonders von der Windows Recovery. Gnome-Disks führte das anstandslos durch. Ein paar Gigabytes später, lagen zwei Partitionen der SSD auf meiner Backupplatte, vielleicht will man das Gerät ja mal weiter verkaufen, da könnte unschönerweise Windows helfen.

Die Installation

Ok, jetzt Fedora installieren. Jooooo.. wie man das von einem i7 und SSD erwarten würde, war das in wenigen Minuten erledigt. Neustart ausgewählt und ….  ging natürlich nicht so einfach. Der wollte doch jetzt glatt primär den Stick booten. Ernsthaft?! Da half nur das Tutorialvideo der M$ Hilfeseite ansehen, etwas textlich zu beschreiben reicht heute offensichtlich nicht mehr 🙁  Na gut. Bootmanager umgestellt, permanent gemacht, und nun bootet auch die SSD durch. Hat ja nur eine halbe Stunde Zeit gekostet. Wer braucht schon benutzerfreundliche und einsichtige Biosware ?

Also auch das Hindernis genommen, aber jetzt kann es … was zum Geier … wer soll das denn lesen können? Das Grubmenü war nur schwer mit Ü40 Augen zu lesen um nicht zu sagen, der klassische Sherlock hätte seine helle Freude gehabt. 3k Display halt, das war zu erwarten gewesen, aber eigentlich hoffte ich auf eine automatische Anpassung, weil die Riesenauflösung ja bekannt zu seien schien. Jetzt wisst Ihr auch, wieso es diesen Beitrag zu Die Schriftgröße des Bootprozesses anpassen gab 😉

Es bootet ja, da kann ja nicht all zu viel schief gehen, denkt man so. Naiv, ich weiß. Die nächste Hürde, und gut, daß ich ein gebrauchtes Gerät mit TypeCover ( so heißt das anflanschbare Keyboard von M$ ) bestellt habe, weil sonst wäre ich an der Festplattenverschlüsselung gescheitert. Ja, ich Wahnsinniger wagte eine Festplattenverschlüsselung bei einem Tablet einzusetzen und hoffte doch tatsächlich auf ein OSK ( On Screen Keyboard ) mit dem man das Passwort eingeben kann. Die Hoffnung war vergebens. Wo GRUB, wir reden vom Bootloader, also dem primitivsten Teil des Systems, der eigentlich kaum Userinteraktivität nötig hat, schon ein virtuelles Keyboard einblendete!!! da wagt es der Luksunlocker wirklich, ohne ein OSK daher zu kommen 🙁

Und Gnome startet

Fairerweise muß ich sagen, hatten wir das bei dem Pro3 im Januar nicht mit Krypto gemacht, daher war es ein Wagnis. Ok, verloren. Naja, nicht so schlimm, Bugreport an Red Hat, mal sehen was passiert. Krypto muß halt sein, schon falls das geklaut wird, da habe ich keinen Bock drauf, daß einer auf meine SSD glotzt. Hey, ein Loginscreen… 🙂  Ein Klick und Gnome ist da.

Hinweis: die meisten Screenshots sind auf FullHD reduziert worden.

Gnome Terminal mit OSKDas OSK von Gnome ist staaaaarkkkkkk verbesserungswürdig, weil:

– keine Umlaute
– keine Cursorsteuertasten
– kein deutsches Layout (mit Umlauten)

Auch dazu ist bereits ein Bugreport abgesetzt, denn schliesslich gibt es da eine Regions&Sprach Taste, die auch das Keyboardlayout umstellt, nur halt nicht im OSK 😀

Jetzt haben wir uns soweit vorgekämpft, dann laß uns mal das Touchgerät austesten…

What the Fuck !?!?!

„Herzlichen Glückwunsch zu Ihrem neuen Angeberlaptop! … und jetzt nerven Sie uns nicht weiter.“

Im nächsten Teil geht es um : INTEL i915 IPTS

Linux – Kernel 4.15.x starten unter 32Bit nicht mehr

Schlechte Nachrichten aus der 32bit Welt.. okok, Insel, soviele sind es ja nicht mehr 😉 Die Fedora Kernel der 4.15er Serie starten bislang nicht in einer paravirtualisierten Xen VM.

Es gibt keinerlei Hinweise auf die Gründe, da die VM nicht mal Dracut starten kann. Bugreport an RedHat ist raus, warten wir es ab. Ich kann derzeit nur abraten 32Bit Kernel mit 4.15 starten zu wollen. 4.14er funktionieren. Ich tippe ja auf die im Kernel verbauten Specture und Meltdown Patche.

Kernel 4.14.14 OOPSt rum

Heute soll es einen kleinen Bericht aus der Praxis mit den neuen Kernelpatchen geben. Seit 2 Wochen bauen die Kernelentwickler an den Patches für Spectre & Meltdown rum. Vermutlich schon länger, aber seit 2 Wochen sind die Ergebnisse im Umlauf 😉 Nach anfänglichen Erfolgen gegen den Angriff, wurden schnell die Probleme zu Tage gefördert, die durch den Patch verursacht werden.

Massenbetatests

Da ich auf unserer Serverfarm die neuen Kernel ausprobiert habe, habe ich die gefundenen Fehler an Redhat gemeldet. Das war vor 14 Tagen, als die Patche rauskamen. Seitdem sind „wir“ (an dem Bugreport sind viele Leute beteiligt) im ständigen Dialog und testen die neuen Kernel unter „real“(tm) Bedingungen aus.

Stand ist, die Kernel funktionieren soweit stabil. Aber einzelne Prozesse in der Virtualisierung und bei JAVA führen immer wieder zu Fehlern. Zwei von den vielen Fehlern, habe ich Euch mal mitgebracht:

Jan 21 06:04:21 xxx kernel: BUG: unable to handle kernel NULL pointer dereference at 0000000000000003
Jan 21 06:04:21 xxx kernel: IP: 0x99cf048
Jan 21 06:04:21 xxx kernel: PGD 461b067 P4D 461b067 PUD 57fd067 PMD 0
Jan 21 06:04:21 xxx kernel: Oops: 0002 [#3] SMP NOPTI
Jan 21 06:04:21 xxx kernel: Modules linked in: nfsv3 nfs fscache fuse nfsd auth_rpcgss nfs_acl lockd grace xt_owner xt_multiport ip6table_filter ip6_tables cfg80211 rfkill xenfs xen_privcmd sunrpc edac_mce_amd crct10dif_pclmul crc32_pclmul ghash_clmulni_intel xen_netfront xen_blkfront crc32c_intel
Jan 21 06:04:21 xxx kernel: CPU: 0 PID: 6020 Comm: xenstore-read Tainted: G D W 4.14.14-201.fc26.x86_64 #1
Jan 21 06:04:21 xxx kernel: task: ffff880005708000 task.stack: ffffc90000d18000
Jan 21 06:04:21 xxx kernel: RIP: e030:0x99cf048
Jan 21 06:04:21 xxx kernel: RSP: e02b:ffffc90000d1bfd0 EFLAGS: 00010206
Jan 21 06:04:21 xxx kernel: RAX: 0000000000000003 RBX: 0000000000000003 RCX: 00000000099cf048
Jan 21 06:04:21 xxx kernel: RDX: 0000000000000002 RSI: 00000000099cf048 RDI: 0000000000000000
Jan 21 06:04:21 xxx kernel: RBP: 00000000ffddc0a8 R08: 0000000000000000 R09: 0000000000000000
Jan 21 06:04:21 xxx kernel: R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000
Jan 21 06:04:21 xxx kernel: R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000
Jan 21 06:04:21 xxx kernel: FS: 00007f8761262b40(0000) GS:ffff88007f400000(0000) knlGS:0000000000000000
Jan 21 06:04:21 xxx kernel: CS: e033 DS: 002b ES: 002b CR0: 0000000080050033
Jan 21 06:04:21 xxx kernel: CR2: 0000000000000003 CR3: 0000000003556000 CR4: 0000000000000660
Jan 21 06:04:21 xxx kernel: Call Trace:
Jan 21 06:04:21 xxx kernel: ? switch_to_thread_stack+0x21/0x40
Jan 21 06:04:21 xxx kernel: Code: Bad RIP value.
Jan 21 06:04:21 xxx kernel: RIP: 0x99cf048 RSP: ffffc90000d1bfd0
Jan 21 06:04:21 xxx kernel: CR2: 0000000000000003
Jan 21 06:04:21 xxx kernel: ---[ end trace 50c257ff957ddb5b ]---
Jan 21 08:17:31 xxx kernel: invalid opcode: 0000 [#4] SMP NOPTI
Jan 21 08:17:31 xxx kernel: Modules linked in: nfsv3 nfs fscache fuse nfsd auth_rpcgss nfs_acl lockd grace xt_owner xt_multiport ip6table_filter ip6_tables cfg80211 rfkill xenfs xen_privcmd sunrpc edac_mce_amd crct10dif_pclmul crc32_pclmul ghash_clmulni_intel xen_netfront xen_blkfront crc32c_intel
Jan 21 08:17:31 xxx kernel: CPU: 0 PID: 7087 Comm: xenstore-read Tainted: G D W 4.14.14-201.fc26.x86_64 #1
Jan 21 08:17:31 xxx kernel: task: ffff88007a873c00 task.stack: ffffc900008c8000
Jan 21 08:17:31 xxx kernel: RIP: e030:0xffd9af11
Jan 21 08:17:31 xxx kernel: RSP: e02b:ffffc900008cbfd0 EFLAGS: 00010206
Jan 21 08:17:31 xxx kernel: RAX: 0000000000000004 RBX: 0000000000000003 RCX: 00000000ffd9af11
Jan 21 08:17:31 xxx kernel: RDX: 0000000000000022 RSI: 00000000ffd9af11 RDI: 0000000000000000
Jan 21 08:17:31 xxx kernel: RBP: 00000000ffd99b58 R08: 0000000000000000 R09: 0000000000000000
Jan 21 08:17:31 xxx kernel: R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000
Jan 21 08:17:31 xxx kernel: R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000
Jan 21 08:17:31 xxx kernel: FS: 00007f2cc2baeb40(0000) GS:ffff88007f400000(0000) knlGS:0000000000000000
Jan 21 08:17:31 xxx kernel: CS: e033 DS: 002b ES: 002b CR0: 0000000080050033
Jan 21 08:17:31 xxx kernel: CR2: 00000000088bb004 CR3: 0000000079d66000 CR4: 0000000000000660
Jan 21 08:17:31 xxx kernel: Call Trace:
Jan 21 08:17:31 xxx kernel: ? switch_to_thread_stack+0x21/0x40
Jan 21 08:17:31 xxx kernel: Code: Bad RIP value.
Jan 21 08:17:31 xxx kernel: RIP: 0xffd9af11 RSP: ffffc900008cbfd0
Jan 21 08:17:31 xxx kernel: ---[ end trace 50c257ff957ddb5c ]---

Die sind vom Kernel 4.14.14, also von gestern 🙂 und wie man an dem Datum sehen kann, sind die Kernel OOPS von heute morgen. Die Beschreibungen die gleich kommen, sind extra simple gehalten, da wohl die wenigsten wissen, was ein IP oder eine NULL POINTER Dereferenz ist. Wer schonmal in Assembler programmiert hat, dem wird das sofort was sagen, dem Rest eher nicht 🙂

Ein Opcode ist eine definierte Bitfolge, welche die CPU als Assemblerbefehl interpretiert und dann macht, was der Befehl meint.

„invalid opcode: 0000 [#4] SMP NOPTI“

Meint, daß die CPU über eine Anweisung gestolpert ist, die nicht definiert ist, in dem Fall eine 0x0000 = 0W . 0W meint den Wert Null (0) auf einer Bitbreite von 16 Bit (= 1 WORD daher das W von 0W => 00000000 00000000. 0L wäre Null(0) auf 32bit auch bekannt als LONGWORD = 00000000 00000000 00000000 00000000).

Das kann nur passieren, wenn ein IP ( Instruction Pointer ) im Speicher wohin gezeigt hat, wo „NICHTS“ war. Das da NICHTS war, war gut so, weil sonst hätte die CPU womöglich die dortigen Bits&Bytes als Befehle interpretiert und wäre Amok gelaufen.

Trivia: Wenn man eine CPU dazu bekommt, so einen Fehler zumachen während sie einen fremden Prozess(z.b. für root) ausführt UND bestimmen kann, WO im Speicher weitergemacht wird, hat man einen EXPLOIT geschafft, also einen ANGRIFF durchgezogen. Das ist dann immer das, was in den Medien landet 🙂

NULL pointer dereference

kernel: BUG: unable to handle kernel NULL pointer dereference at 0000000000000003
kernel: IP: 0x99cf048
kernel: Oops: 0002 [#3] SMP NOPTI

Das ist eine NULL POINTER Exception. Da ist die CPU über einen falschen IP(siehe oben) zu einer Adresse im Speicher gesprungen, wo ein weiterer Zeiger(Pointer) hätte sein sollen, es stand aber nur „0L“  dort.

Das ist eigentlich ein Programmierfehler, denn man müßte Zeiger genau auf „0L“ prüfen, bevor man sie benutzt. Da stellt sich jetzt die Frage, reagiert der Kernel seit den Patchen empfindlicher auf den Fehler ( der womöglich schon seit Jahren da war) oder ist der Fehler durch den Patch entstanden?

IMHO:

Es zeigen sich jetzt lustige Programmierfehler in allen möglichen Sachen/Kernel, weil der schlampige Stil jetzt nicht mehr hinhaut 😀 In C und C++, worin die Masse des Kernelcodes und der Anwendungen geschrieben ist, gibt es das Konstrukt des Doppelzeigers, also einem Zeiger auf einen Zeiger. Natürlich gibt es dafür eine Abkürzung im C Code die auch gern genommen wird, nur daß dabei der Code nicht prüft, ob da 0 als Zeiger steht. Das würde nämlich Performance kosten und genau die will man ja damit erreichen. Der Code geht also davon aus, daß die Zeiger immer stimmen, also optimistische Grundeinstellung des Entwicklers. Seit dem Patch kann man sich da wohl nicht mehr drauf verlassen.

Fazit

Aber zurück zur Situation, wenn man unbedingt muß, kann man die 64Bit Kernel benutzen. Für daheim ist das eh kein Problem, so weit ich das von meiner Serverfarm ableiten kann, betrifft es nur VM und JAVA Prozesse (z.b. Jitsi / Tomcat usw.). Die 32Bit Kernel sind besonders anfällig und derzeit noch nicht zu empfehlen, aber wer braucht auch noch 32bit ?

Die meisten werden die neuen Kernel also ohne Probleme fahren können.

Wer den 4.14.14 Kernel für Fedora 26 haben will :  https://koji.fedoraproject.org/koji/taskinfo?taskID=24303894

Eure Distros werden ähnliche Buildumgebungen haben, wo die aktuellen Testkernel gebaut werden.

 

Linux – Fedora – Spectre & Meltdown Kernels nicht fehlerlos

Seit einigen Tagen sind ja die „gepatchten“ Fedora Kernel zu den Specture & Meltdown Schwachstellen verfügbar. Leider kommt es bei 32 und 64 Bit zu diversen Bugs, die ganze Serverfarmen inoperabel machen.

Der Kernel OOPS

so sieht so ein Kernel Fehler aus :

Jan 8 15:15:43 xx kernel: BUG: unable to handle kernel NULL pointer dereference at 00000008
Jan 8 15:15:43 xx kernel: IP: __radix_tree_lookup+0xe/0xa0
Jan 8 15:15:43 xx kernel: *pdpt = 0000000019977027 *pde = 0000000000000000 
Jan 8 15:15:43 xx kernel: Oops: 0000 [#1] SMP
Jan 8 15:15:43 xx kernel: Modules linked in: nfsv3 nfs_acl nfs lockd grace sunrpc fscache rmd160 ip_vti ip_tunnel af_key ah6 ah4 esp6 esp4 xfrm4_mode_beet xfrm4_tunnel tunnel4 xfrm4_mode_tunnel xfrm4_mode_transport xfrm6_mode_transport xfrm6_mode_ro xfrm6_mode_beet xfrm6
_mode_tunnel ipcomp ipcomp6 xfrm6_tunnel tunnel6 xfrm_ipcomp chacha20poly1305 cmac camellia_generic cast6_generic cast5_generic cast_common deflate ccm serpent_sse2_i586 serpent_generic glue_helper ablk_helper blowfish_generic cls_u32 blowfish_common twofish_generic sch_h
tb twofish_i586 twofish_common xcbc sha512_generic des_generic geode_aes xt_owner xt_multiport ip6table_filter ip6_tables xenfs xen_privcmd coretemp xen_netfront nf_conntrack_pptp nf_conntrack_proto_gre nf_conntrack libcrc32c crc32c_intel xen_blkfront
Jan 8 15:15:43 xx kernel: CPU: 0 PID: 1740 Comm: java Not tainted 4.14.11-200.fc26.i686+PAE #1
Jan 8 15:15:43 xx kernel: task: d750c500 task.stack: d7f96000
Jan 8 15:15:43 xx kernel: EIP: __radix_tree_lookup+0xe/0xa0
Jan 8 15:15:43 xx kernel: EFLAGS: 00010282 CPU: 0
Jan 8 15:15:43 xx kernel: EAX: 00000004 EBX: 0de6d000 ECX: 00000000 EDX: 00000000
Jan 8 15:15:43 xx kernel: ESI: 00000000 EDI: 00000004 EBP: d7f97da8 ESP: d7f97d98
Jan 8 15:15:43 xx kernel: DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0069
Jan 8 15:15:43 xx kernel: CR0: 80050033 CR2: 00000008 CR3: 01ee4000 CR4: 00002660
Jan 8 15:15:43 xx kernel: Call Trace:
Jan 8 15:15:43 xx kernel: radix_tree_lookup_slot+0x1d/0x40
Jan 8 15:15:43 xx kernel: find_get_entry+0x20/0x160
Jan 8 15:15:43 xx kernel: pagecache_get_page+0x24/0x290
Jan 8 15:15:43 xx kernel: lookup_swap_cache+0x3a/0x100
Jan 8 15:15:43 xx kernel: swap_readahead_detect+0x55/0x280
Jan 8 15:15:43 xx kernel: ? xen_set_pte_at+0x81/0x140
Jan 8 15:15:43 xx kernel: do_swap_page+0x22a/0x990
Jan 8 15:15:43 xx kernel: ? wp_page_copy+0x361/0x6f0
Jan 8 15:15:43 xx kernel: ? kmap_atomic_prot+0x3e/0x130
Jan 8 15:15:43 xx kernel: handle_mm_fault+0x498/0xc90
Jan 8 15:15:43 xx kernel: ? xen_timer_interrupt+0x17/0x30
Jan 8 15:15:43 xx kernel: __do_page_fault+0x202/0x4d0
Jan 8 15:15:43 xx kernel: ? __do_page_fault+0x4d0/0x4d0
Jan 8 15:15:43 xx kernel: do_page_fault+0x27/0xd0
Jan 8 15:15:43 xx kernel: ? __do_page_fault+0x4d0/0x4d0
Jan 8 15:15:43 xx kernel: common_exception+0x6f/0x76
Jan 8 15:15:43 xx kernel: EIP: 0x1f51b404
Jan 8 15:15:43 xx kernel: EFLAGS: 00010202 CPU: 0
Jan 8 15:15:43 xx kernel: EAX: 00000000 EBX: 0de6df60 ECX: 00000000 EDX: 40000000
Jan 8 15:15:43 xx kernel: ESI: 00000001 EDI: 40000000 EBP: 0f1f40b8 ESP: 0f1f409c
Jan 8 15:15:43 xx kernel: DS: 007b ES: 007b FS: 0000 GS: 0033 SS: 007b
Jan 8 15:15:43 xx kernel: Code: b6 00 00 00 00 0f 0b 8d b6 00 00 00 00 b8 ef ff ff ff eb a4 e8 34 73 8b ff 8d 74 26 00 55 89 e5 57 56 53 89 c7 83 ec 04 89 4d f0 <8b> 5f 04 89 d8 83 e0 03 83 f8 01 75 6d 89 d8 83 e0 fe 0f b6 08
Jan 8 15:15:43 xx kernel: EIP: __radix_tree_lookup+0xe/0xa0 SS:ESP: 0069:d7f97d98
Jan 8 15:15:43 xx kernel: CR2: 0000000000000008
Jan 8 15:15:43 xx kernel: ---[ end trace 91253bf32b64ee98 ]---

Wie man sieht ist hier ein Java Prozess der gestorben ist. Das Problem dabei ist allerdings, daß die Prozesse gar nicht sterben, sondern einfach nicht mehr reagieren. Das ist besonders blöd, weil so Prozessüberwachungstools, die Prozesse nicht einfach neu starten können.

Im Fall oben war es ein Tomcat Webserver der hängen blieb und damit keine Webseiten mehr auslieferte.

Verschärfung

Problematisch an der Sache ist, daß auch kerneleigene Prozesse betroffen sind z..b der „swapper/0“ crasht mal einfach beim Hochfahren des Rechners weg. Ob sich das negativ auswirkt oder die Server einfach nicht mehr swappen, weiß man noch nicht.

Abhilfe ?

Da habt Ihr leider Pech. Redhat ist dran, aber das kann dauern. Bis zu einer Lösung könnte Ihr hängende Prozesse nur neustarten.