Schlagwörter-Archiv: kernel

Niedriger Ethernet-Durchsatz auf P8P67 und kernel3

Veröffentlicht am von — Keine Kommentare ↓

Wer ein ASUS-Board der Reihe P8P67 (Pro/Evo/Deluxe) und damit oft einen maximalen Ethernet-Durchsatz von ~6 kB/s netto hat sollte mal ins Kernel-Log schauen:

Jan  6 11:14:56 localhost kernel: Pid: 0, comm: swapper Tainted: P         C  3.1.7-1-ck #1
Jan  6 11:14:56 localhost kernel: Call Trace:
Jan  6 11:14:56 localhost kernel: <IRQ>  [<ffffffff810bbcf6>] __report_bad_irq+0x36/0xe0
Jan  6 11:14:56 localhost kernel: [<ffffffff810bbfac>] note_interrupt+0x15c/0x210
Jan  6 11:14:56 localhost kernel: [<ffffffff810b9e89>] handle_irq_event_percpu+0xc9/0x2a0
Jan  6 11:14:56 localhost kernel: [<ffffffff810ba0a8>] handle_irq_event+0x48/0x70
Jan  6 11:14:56 localhost kernel: [<ffffffff810bc8da>] handle_fasteoi_irq+0x5a/0xe0
Jan  6 11:14:56 localhost kernel: [<ffffffff81016992>] handle_irq+0x22/0x40
Jan  6 11:14:56 localhost kernel: [<ffffffff814095da>] do_IRQ+0x5a/0xe0
Jan  6 11:14:56 localhost kernel: [<ffffffff8140622e>] common_interrupt+0x6e/0x6e
Jan  6 11:14:56 localhost kernel: <EOI>  [<ffffffff81275f3b>] ? intel_idle+0xcb/0x120
Jan  6 11:14:56 localhost kernel: [<ffffffff81275f1d>] ? intel_idle+0xad/0x120
Jan  6 11:14:56 localhost kernel: [<ffffffff81319916>] cpuidle_idle_call+0xc6/0x350
Jan  6 11:14:56 localhost kernel: [<ffffffff81013229>] cpu_idle+0xc9/0x120
Jan  6 11:14:56 localhost kernel: [<ffffffff813e2d62>] rest_init+0x96/0xa4
Jan  6 11:14:56 localhost kernel: [<ffffffff8194ec15>] start_kernel+0x3bf/0x3cc
Jan  6 11:14:56 localhost kernel: [<ffffffff8194e347>] x86_64_start_reservations+0x132/0x136
Jan  6 11:14:56 localhost kernel: [<ffffffff8194e140>] ? early_idt_handlers+0x140/0x140
Jan  6 11:14:56 localhost kernel: [<ffffffff8194e44d>] x86_64_start_kernel+0x102/0x111

Tauchen diese Zeilen auf, so ist das Board von einem Problem mit ACPI und der verwendeten BIOS-Version betroffen. Workaround: die andere Ethernet-Karte benutzen ;)

Wie der Timestamp sagt ist das Problem recht alt, tauchte bei mir mit kernel-3.5.4-1 wieder auf.

Thinkpad X220 Power Saving

Veröffentlicht am von — 2 Kommentare ↓

Das Thinkpad X220 leidet wie alle Rechner mit SandyBridge-Grafik (Intel HD 3000) an den Auswirkungen der aktuellen Kernel Power Regressions (siehe hier und hier), was zu CPU-Temperaturen über 50°C (idle!) und permanent relativ hoch drehendem Lüfter führt.

Mit folgenden Zeilen schaffe ich es im Idle auf 42°C und einen gelegentlich inaktiven Lüfter:

# /etc/rc.local
# set governor
cpufreq-set -g ondemand -c 0
cpufreq-set -g ondemand -c 1
 
# disable bluetooth
echo disable > /proc/acpi/ibm/bluetooth
 
# set brightness level
echo 6 > /sys/class/backlight/acpi_video0/brightness
 
# set vm laptop-mode
echo 5 > /proc/sys/vm/laptop_mode
 
# increase vm dirty writeback time
echo 1500 > /proc/sys/vm/dirty_writeback_centisecs
 
# set SATA link power management
for D in /sys/class/scsi_host/host*/link_power_management_policy; do
	echo min_power > $D
done
 
# disable kernel nmi watchdog
echo 0 > /proc/sys/kernel/nmi_watchdog
 
# set pci/i2c bus power management
for I in /sys/bus/{pci,i2c}/devices/*/power/control; do
    echo auto > $I
done
 
# enable scheduler power saving
echo 1 > /sys/devices/system/cpu/sched_mc_power_savings

In der Kernel-Line im Bootloader noch folgende Parameter:

pcie_aspm=force i915.i915_enable_fbc=1 i915.i915_enable_rc6=1

Thinkpad X220 Lüfter Stillstand

ALSA Power Saving unter Arch

Veröffentlicht am von — Keine Kommentare ↓

Nach dem Wechsel der Soundkarte zurück auf die Semi-Onboard-Lösung hatte ich ein kleines Soundproblem: kurze Sounds (Mail-Benachrichtigungen, Chat-Töne, etc.) wurden gar nicht oder nur teilweise abgespielt – es fehlten oft die ersten Millisekunden.

Das Problem verursachte das aktivierte Power Saving feature des verwendeten Moduls snd_hda_intel. Hier sind zwei Parameter relevant:

  • power_save: setzt den Timeout für den Power Saving Modus
    (in Sekunden, 0=deaktiviert)
  • power_save_controller: Schaltet im Power Save auch den Controller ab
    (Y=aktiviert, N=deaktiviert)

Der zweite Parameter wird unter Arch standardmäßig auf Y gesetzt, was einen tieferen Schlaf für den Soundchip, aber auch eine dementsprechend längere Aufwachphase bewirkt. Durch Deaktivieren dieses Features konnte ich mein Problem mit den Benachrichtigungen lösen.

Übrigens: in der /etc/conf.d/alsa wird leider nicht ganz deutlich, dass über POWERSAVE direkt der Timeout-Wert gesetzt wird, d.h. es sind auch Werte >1 zulässig:

# Enables powersaving mode for AC97 and hda_intel audio chips.
# Set to 1 to enable powersaving.
# Set to 0 to disable powersaving (default).
POWERSAVE=10

kernel26 vs. kernel26-ck

Veröffentlicht am von — Keine Kommentare ↓

Disclaimer: Die Vergleiche im Folgenden beruhen auf rein subjektivem Empfinden. Ich habe mir nicht die Mühe gemacht, mit synthetischen Tests irgendwelche empirischen Daten zu sammeln.

Vor einiger Zeit hatte ich mal den Zwang der Vorstellung, ein Betriebssystemkern solle doch möglichst auf die Architektur der Maschine, auf dem er läuft, optimiert kompiliert werden. Kombiniert mit einer großen Portion Neugier auf das Patchset von Con Kolivas und diversen Berichten über verbesserte Reaktionszeiten des Systems unter Last wechselte ich damals auf kernel26-ck, natürlich mit handoptimierter config.

Nach dem Wechsel bildete ich mir erfolgreich einen Performancegewinn und bessere Antwortzeiten unter I/O-Last ein. Mit der neusten kernel26-ck Version (2.6.36-9) bekam ich dann jedoch immer mehr seltsame Scheduling-Bugs: Dropdown-Menüs, die mitten in der Ausklapp-Animation plötzlich für Sekunden einfrieren, meine KDE-Desktop-Uhr, die Sprünge bzw. Aussetzer hat, und der Kleinigkeiten mehr.

Also wechselte ich zum Vergleich wieder auf den Arch Standard-Kernel, und stelle nun fest: der gefühlte Performancegewinn auf kernel26-ck war tatsächlich fast vollständig eingebildet. Einzige Ausnahme ist das Verhalten unter hoher I/O-Last: dort bleibt kernel26-ck mit BFQ deutlich reaktiver. Aber mal abwarten: wenn sich das als gängige Beobachtung erweist, wird der Scheduler sicher nicht lange im Standardkernel fehlen.

So gesehen also ein netter Ausflug zu einem anderen (bzw. zusätzlichen) Patchset und anderen Schedulern, aber ich bleibe vorerst dann doch wieder beim Standardkernel – nicht zuletzt weil das einiges an Dependency-Scherereien beim Update mit nvidia-ck vermeidet ;)

Partitions-Desaster

Veröffentlicht am von — Keine Kommentare ↓

Frisch zurück aus dem Urlaub und direkt wieder am Basteln ^^  Seit geraumer Zeit war ich am Überlegen, meinem Arch-System einen richtigen Fallback-Kernel zu verpassen, d.h. nicht nur eine eigene initrd sondern einen kompletten Kernel inkl. Modulen.
Dabei stieß ich auf kernel26-lts. Leider scheitert die ganze Sache allerdings nun an meiner Partitionierung:

partitioning

Partitionierung (schematisch)

Beim Aufsetzen des Systems hatte ich keinen zweiten Kernel, besser gesagt keinen zweiten Modulbaum, vorgesehen und die root-Partition dementsprechend klein gehalten. /lib (und damit die Module) liegen nun leider auf diesem gerade mal ~200MB großen Fleck digitalen Landes auf meiner Platte, und selbige müsste mindestens 25MB größer werden, um die zusätzlichen Module aufnehmen zu können.
Abgesehen davon, dass die Partition dann so gut wie voll wäre (und ein volles / ist sicher keine gute Sache…), bleibt als einzige vernünftige Quelle für den zusätzlichen Platz mein LVM-Setup. 7 Logical Volumes, eins davon LUKS-verschlüsselt, müssten also verkleinert und verschoben werden, bevor dann die (natürlich auch verschlüsselte) root-Partition wachsen könnte. Natürlich alles jeweils auf Dateisystem- und Partitions-/Volumeebene :) – a lot of fun.

Ob dieser Aufwand die zusätzliche Sicherheit eines Fallback-Kernels wert ist… (to be continued)

Update: Verblendet von dem ganzen LVM-Kram habe ich die wesentlich einfachere Lösung übersehen: den benötigten Platz vom NTFS-Volume zu klauen! Also NTFS verkleinern und nach rechts verschieben, die ganze LVM-Partition per dd sichern, neu anlegen und wiederherstellen, und schließlich root vergrößern. Alles lief reibungslos und ich habe endlich meinen Fallback-Kernel (kernel26-lts) :)

events/0 und events/1

Veröffentlicht am von — Keine Kommentare ↓

Seit geraumer Zeit war ich auf der Jagd nach zwei mysteriösen Prozessen: events/0 und events/1. Einer von beiden (gewählt beim Systemstart, zufällig), verursachte permanent ~6% Auslastung des CPU-Kerns gleicher Nummer. Kürzlich bin der Lösung einen Schritt näher gekommen: offenbar verursacht das Kernelmodul acer-wmi (zuständig für die gleichnamigen Erweiterungen von Acer Notebooks) den CPU-Hunger der genannten Prozesse.

Die konkrete Ursache (Code) habe ich damit zwar noch nicht gefunden, aber immerhin behebt ein Blacklisten des moduls die durch den erhöhten Energieverbrauch geschrumpfte Akku-Laufzeit (auf Kostendes LCD-Helligkeits-eintrages in /proc).