Tag Archives: kernel

Runes of Magic, Linux und der Performance Bug

Posted on by

Ihr könnte Euch gaaaaaaaaaaaaaaanz sicher an die Intel CPU Bugs erinnern und wie die im Linux Kernel abgewehrt wurden, so in etwa. Der Nebeneffekt war, u.a., daß bspw. Runes of Magic als WineApp mit DX9 Teil auf meinem  Achtkerner von im Durchschnitt 150% CPU Last pro Instanz auf 250% hochgeschnellt war. Die Kernels 4.19.9+ > 4.20.latest waren allesamt davon betroffen.

66% mehr CPU Last

Das Phänomen war besonders nervig, weil zwar im Regelbetrieb nur eine leichte Erhöhung von 150% auf 180% vorhanden war, aber sporadisch brach die Lasthölle los, mit den erwähnten Peeks auf 250%, die dann für einige Minuten blieben um dann wieder zu verschwinden. Ein Spielen war so natürlich nicht mehr mit mehreren Instanzen möglich.

Seit Kernel 5.0.6 und vermutlich auch eher, ist die Last wieder zurück auf den Normalwert von 150% im normalen Spielbetrieb. Die Reaktion vom Kernel bzw. Wine Maintainer auf diesen Bugreport war übrigens „Damit können wir nichts anfangen“ mit anderen Worten, sie konnten nicht mal glauben, daß es den Effekt überhaupt gab.

top – 13:11:29 up 1 day, 3:52, 1 user, load average: 4,09, 4,31, 4,87
PID   USER   PR NI VIRT   RES    SHR   S %CPU %MEM TIME+ COMMAND
3542  marius 20 0 2240024 1,238g 76976 S 155,8 7,9 1159:15 H:\Programme\GameforgeLive\Games\DEU_deu\Runes Of Magic\Client.exe NoCheckVersion20398 marius 20 0 2378776 1,291g 78152 R 142,2 8,3 1369:03 H:\Programme\GameforgeLive\Games\DEU_deu\Runes Of Magic\Client.exe NoCheckVersion

Da die Last seit einiger Zeit wieder konstant im grünen Bereich ist, kann man das Problem wohl als gelöst betrachten. Falls jemand von Euch mit einem Programm unter Linux ähnliche Erfahrungen gemacht hat oder derzeit macht, wisst Ihr was die Lösung ist => Kernel Updaten.

Bevor Klagen von Lesern reinkommen: klar hatte ich überprüft, ob sich Wine oder die Grafikkartentreiber geändert hatten, hatten sie nicht.

XenServer zu alt um Kernel 5.0 zu laden

Posted on by

Wer XenServer und Kernel 5.0.x einsetzen will, sollte jetzt gut aufpassen, sonst => VM Streik

Kernelimage zu neu für XenServer 6.2.x

Da es sich um etwas handelt, daß international wichtig sein könnte, gibts das auf Deutsch und English,
so don’t wonder if you just understand halve of it 😉

Ihr wollt Eure VM booten, bekommt aber diesen Fehler?
You wanne boot your VM and get this message ?

xenopsd internal error: XenguestHelper.Xenctrl_dom_linux_build_failure(2, “ panic: xc_dom_core.c:616: xc_dom_find_loader: no loader\\\““)

Das passiert, weil das Kernelimage mit einer neuen Compressionmethode gepackt wurde, die das alte XEN nicht kann.  The reason is, that your kernel image file is compressed with a new algorithm, your old XEN can’t handle.

Als erstes brauchen wir die UUID der VM:
First, get the UUID of your VM:

xe vm-list | grep -A5 -B5 <vmname>

Um das zu beheben, braucht man den Befehl: xe-edit-bootloader.sh -u uuid
To fix your vm, you need to execute : xe-edit-bootloader.sh -u uuid

/root/xe-edit-bootloader.patched.sh -u 317fb132-283a-56c6-1627-8b39cf944148 -p 1

Nun kann man die Reihenfolge der Bootmenüeinträge so ändern, daß der bisherige Kernel vorn steht. Dann speichern und Editor beenden und jetzt sollte die VM auch wieder starten.
Now you can change the order of your grub menuentries to the last working kernel being first. When you have saved and exited the editor, the parition will be unmounted and you can start your VM again.

Tipps – Additional hints for you

Der Befehl mountet die Systemplatte der VM und lädt die gebräuchliste grub.conf. Das wird aber vermutlich nicht auf anhieb klappen. Man muß etwas über das Festplattenlayout der VM wissen:
This will mount your VM’s main disk and access the most likely location of your grub.conf, but that will not work without your knowlage of the VMs structure:

-p: Partition number to mount (default: none)
-f: Location of bootloader config file to edit

Wenn man eine traditionelle SDA1 SDA2 Partitionierung in der VM hat, dann gibt man -p die Partitionsnummer der Platte an, wo man /boot/ finden kann. Wer LVM in der VM benutzt, dürfte jetzt so ziemlich am Arsch sein. Kleiner Tip, exportiert die VM auf einen neuern XenServer.

If you have a sda1 and sda2, where sda2 is swap, that -p 1 will mount partition 1 and your good to go.
If you have i.e. a seperate boot partition, you need to know it’s number.
IN CASE you have LVM inside your VM, i guess your screwed now. In this case, export it to a newer XenServer Version.

Weil sich Grub1+2 ein bisschen uneinig wegen der Verzeichnispfade sind, kann man Position der grub.cfg mit -f angeben. Wer eine eigene /boot Partition hat, braucht dann nicht /boot/ hinschreiben, -f grub2/grub.cfg reicht.

Grub1+2 differ a bit, where to find the grub.conf file. Thats where -f will be handy. You can just tell it, if you knew it: -f /boot/grub2/grub.cfg   should usally work, except, you are already on /boot (seperate partition) then it’s just -f grub2/grub.cfg .  As theres only a texteditor loaded, you could try to change other files too 😉

Ich habe einen gepatchten xe-edit-bootloader, der mir erlaubt, gleich die ganze Platte in Dom0 zu mounten. d.h. ich kann alles in der VM anpassen, nicht nur Textdateien, was extrem praktisch ist.
Why is my xe-edit-bootloader.sh  patched? because i adapted it to just mount the disk and wait for me to explore the disk. That’s so helpfull, you won’t believe it.

Bei einigen Systemen kann durch setzen der $EDITOR Variablen auf „/bin/bash“ eine Shell bekommen, aber ich rate davon ab, daß auf Produktivsystemen auszuprobieren, das könnte böse Nebenwirkungen haben.
In rare cases it’s possible to trick the script with the $EDITOR variable set to „/bin/bash“ to open a bash shell for you, but i really suggest not to mess with your dom0 on a production system.

Tablet ohne Tabletfunktionen: INTEL i915 IPTS

Posted on by

„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

suchen nach INTEL_IPTS und auf „m“ setzen.

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 😀

Games: Astrolords mit Touchsupport?