2012-07-05 // Buggy Board - Von Problemen mit einem ASRock H61/U3S3

Seit über zwei Monaten schnurrt ein neuer Server in meinem Keller. Die Hardware habe ich bereits vorgestellt. Eigentlich hatte ich auch vor nichts mehr über jene zu schreiben, sondern mehr auf die Software eingehen. Doch dazu soll das Dank einigen Problemen nicht kommen.

So viel es mir immer wieder auf, dass die sekundäre Netzwerkkarte (ältere Realtek, nur temprär eingebaut) nach einer gewissen, meistens kurzen Zeit (etwa 30 Minuten) nach dem Reboot der Durchsatz extrem drosselte (um das 20fache langsamer!!) und bei Pings ungewöhnlich hohe Latenzen auftraten.
Dazu hat mir Logcheck dann folgendes gemailt:

Jun 27 02:03:41 host kernel: [ 2671.854895] irq 17: nobody cared (try booting with the "irqpoll" option)
Jun 27 02:03:41 host kernel: [ 2671.854942] Pid: 0, comm: swapper/0 Tainted: G         C   3.2.0-25-generic #40-Ubuntu
Jun 27 02:03:41 host kernel: [ 2671.854945] Call Trace:
Jun 27 02:03:41 host kernel: [ 2671.854947]  <IRQ>  [<ffffffff810db45d>] __report_bad_irq+0x3d/0xe0
Jun 27 02:03:41 host kernel: [ 2671.854960]  [<ffffffff810db6e5>] note_interrupt+0x135/0x190
Jun 27 02:03:41 host kernel: [ 2671.854964]  [<ffffffff810d8f49>] handle_irq_event_percpu+0xa9/0x220
Jun 27 02:03:41 host kernel: [ 2671.854968]  [<ffffffff810d9111>] handle_irq_event+0x51/0x80
Jun 27 02:03:41 host kernel: [ 2671.854972]  [<ffffffff810dc13a>] handle_fasteoi_irq+0x6a/0x110
Jun 27 02:03:41 host kernel: [ 2671.854978]  [<ffffffff81015282>] handle_irq+0x22/0x40
Jun 27 02:03:41 host kernel: [ 2671.854984]  [<ffffffff8166875a>] do_IRQ+0x5a/0xe0
Jun 27 02:03:41 host kernel: [ 2671.854988]  [<ffffffff8165daee>] common_interrupt+0x6e/0x6e
Jun 27 02:03:41 host kernel: [ 2671.854991]  <EOI>  [<ffffffff8108e499>] ? enqueue_hrtimer+0x39/0xc0
Jun 27 02:03:41 host kernel: [ 2671.855000]  [<ffffffff8136b74d>] ? intel_idle+0xed/0x150
Jun 27 02:03:41 host kernel: [ 2671.855003]  [<ffffffff8136b72f>] ? intel_idle+0xcf/0x150
Jun 27 02:03:41 host kernel: [ 2671.855008]  [<ffffffff815051a1>] cpuidle_idle_call+0xc1/0x280
Jun 27 02:03:41 host kernel: [ 2671.855012]  [<ffffffff8101222a>] cpu_idle+0xca/0x120
Jun 27 02:03:41 host kernel: [ 2671.855018]  [<ffffffff8162412e>] rest_init+0x72/0x74
Jun 27 02:03:41 host kernel: [ 2671.855023]  [<ffffffff81cfbc0d>] start_kernel+0x3ba/0x3c7
Jun 27 02:03:41 host kernel: [ 2671.855028]  [<ffffffff81cfb388>] x86_64_start_reservations+0x132/0x136
Jun 27 02:03:41 host kernel: [ 2671.855033]  [<ffffffff81cfb140>] ? early_idt_handlers+0x140/0x140
Jun 27 02:03:41 host kernel: [ 2671.855038]  [<ffffffff81cfb459>] x86_64_start_kernel+0xcd/0xdc
Jun 27 02:03:41 host kernel: [ 2671.855040] handlers:
Jun 27 02:03:41 host kernel: [ 2671.855068] [<ffffffffa00173a0>] rtl8169_interrupt
Jun 27 02:03:41 host kernel: [ 2671.855098] Disabling IRQ #17

Zumindest die Meldung rtl8169_interrupt spricht ja in erster Linie für ein Problem mit dem Realtek Treiber. Tatsächlich wird man bei Google mit dieser Fehlermeldung im Gepäck fündig – Linuxuser haben die Suchmaschine mit der Fehlermeldung und der Lösung, die bei mir nichts brachte gefüttert.

Da dieser Weg letzten Endes nicht das gewünschte Ergebnis bracht, hier nur sporadisch mein Vorgehen:

1. ältere Firmware ausprobiert (Stichwort linux-backports-modules-net-xxx) → kein Erfolg
2. r8168 statt r8169 ausprobiert → kein Erfolg
3. andere (rumliegende) Netzwerkkarte, nur dumm, dass die das gleiche Chipset hatte → kein Erfolg
4. nochmal googlen – die Probleme hängen anscheinend mit Asus und ASRock Boards zusammen

Wenn man sich nun eher irq 17: nobody cared (try booting with the „irqpoll“ option) widmet, wird man schnell fündig. Zu diesem Thema findet sich so einiges in den Archiven der Kernel Mailingliste – Linus meldet sich sogar zu Wort

Für die Sandy Bridge Plattform ist kein nativer PCI Support vorgesehen, in Intels Sandy Bridge Chipsets gibt es also keinen PCI Controller (vereinfacht ausgedrückt). D.h. damit das Mainboard einen PCI Slot anbieten kann, wird eine Brücke von PCIe zu PCI verbaut und genau in dieser Brücke, einem ASMedia Chip liegt das Problem – Er ist anscheinend etwas buggy.
Der Chip ist in vielen ASRock und Asus Sandy Bridge Boards verbaut, unter anderem auch in meinem:

ich@host:~$ lspci | grep "PCIe"
03:00.0 PCI bridge: ASMedia Technology Inc. ASM1083/1085 PCIe to PCI Bridge (rev 01)

Das Problem tritt logischerweise nicht auf, wenn diese PCI-Slots nicht verwendet werden. Also habe ich die Realtek PCI Netzwerkkarte (ehrlich gesagt: crap, hat Realtek überhaupt „gute“/performante Chipsets im Repertoire?) durch eine Intel PCIe (wesentlich besser) ersetzt und siehe da das Problem ist Geschichte

In den Bugtrackern aller namhaften Distributionen finden sich Einträge über diesen Bug (oder eigentlich Hardwareproblem). Ich habe es mir natürlich einfach gemacht, indem ich die PCI Slots nicht mehr nutze. Nur User, die auf ihr Slots angewiesen sind, dürften ein gewaltiges Problem haben

Wenn du dir jetzt dachtest, dass es das mit den Problemen war, hast du dich echt gehörig verschätzt. Natürlich sollte auf einem Server Wake on Lan (WOL) funktionieren, nur hier funktioniert die praktische Funktion trotz Aktivierung im UEFI/BIOS + OS nicht. Im Gegensatz: Das Mainboard besitzt nach Einschalten der Funktion Power up py PCI… noch die unglaubliche Fähigkeit sich nicht mehr ausschalten zu lassen. Statt dessen vollführt das Board nach jedem shutdown -r now (halt funktioniert komplett nicht) einen Neustart.

Wie soll ich nun also WOL testen, wenn ich das System nicht einmal richtig runterfahren kann (WOL funtzt nur, wenn der Rechner richtig ausgeschaltet wurde…). Doch auch hierzu gibt es eine Lösung – dieses mal noch unglaublicher: man aktiviere einfach Wake on mouse/keyboard!

Wie durch Zauberhand funktioniert dann WOL und man kann den Rechner, ohne dass er 5 Sekunden nach dem Shutdown einen Neustart durchzieht, normal ausschalten. Der Lösungsweg ist irgendwie schon verrückt - was hat den bitteschön eine Maus mit WOL zu tun? Wie verrückt die Welt doch ist

Ich muss ganz ehrlich sagen, dass diese Probleme wirklich unnötig waren - als nächstes friert die CPU wahrscheinlich ein, weil der Alpenföhn zu schnell dreht :D
Umso schöner ist es dann, wenn man das Problem gefunden und beseitigt hat. Wenn du ein Sandy Bridge Board für ein Linux System brauchst, solltest du vorerst besser nicht zu einem Board mir einer solch problematischen Bridge greifen, wenn du vor hast die PCI Slots zu nutzen. Ansonsten kann ich das Board nicht nur auf Grund des Preis-Leistungsverhältnisses empfehlen.

…und zum Schluss: normale Consumer Hardware ist halt definitiv nichts für Server - aber das 4-5 fache zahlen will man halt auch nicht.

Leave a comment…

   ____  _   __   ____  ____   __  __   ____   ___    ____     __ __  __  __  __   _  __
  / __/ | | / /  / __/ / __ \ / / / /  / __/  / _ \  / __/ __ / / \ \/ / / / / /  | |/_/
 / _/   | |/ /  / _/  / /_/ // /_/ /  _\ \   / , _/ _\ \  / // /   \  / / /_/ /  _>  <  
/_/     |___/  /___/  \____/ \____/  /___/  /_/|_| /___/  \___/    /_/  \____/  /_/|_|