You are not logged in.

Dear visitor, welcome to VDR Portal. If this is your first visit here, please read the Help. It explains in detail how this page works. To use all features of this page, you should consider registering. Please use the registration form, to register here or read more information about the registration process. If you are already registered, please login here.

SHF

Sage

  • "SHF" started this thread

Posts: 3,942

Location: hessische Bergstrasse

  • Send private message

1

Saturday, June 8th 2013, 2:30am

ASM1083 PCI Bridge fehlerhaft. Betrifft viele ASUS, ASROCK und MSI Mainboards!

... sofern sie PCI-Slots oder PCI-Onboard-Komponenten haben.
Ausnahmen bei Mainboards für Intel sind welche mit B65 und B75-Chipsatz, da ist PCI Bridge im Chipsatz integriert.
Bei AMD-Basis bin ich momentan nicht informiert. Das E45M1-M PRO von Asus ist zumindestens betroffen.

Der Fehler äussert sich indem, dass der Rechner plötzlich sehr langsam, bis unbedienbar wird. Im Logfile ist dann die folgende Meldung zu finden. Ein Reboot behebt das Problem normalerweise.

Source code

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
Jun  1 15:53:26 H61MU kernel: [38840.476890] irq 18: nobody cared (try booting with the "irqpoll" option)
Jun  1 15:53:26 H61MU kernel: [38840.476897] Pid: 0, comm: swapper/0 Tainted: G           O 3.2.0-4-amd64 #1 Debian 3.2.41-2
Jun  1 15:53:26 H61MU kernel: [38840.476900] Call Trace:
Jun  1 15:53:26 H61MU kernel: [38840.476902]  <IRQ>  [<ffffffff81092505>] ? __report_bad_irq+0x2c/0xb5
Jun  1 15:53:26 H61MU kernel: [38840.476914]  [<ffffffff810928c2>] ? note_interrupt+0x170/0x1f2
Jun  1 15:53:26 H61MU kernel: [38840.476918]  [<ffffffff81090c8c>] ? handle_irq_event_percpu+0x15f/0x17d
Jun  1 15:53:26 H61MU kernel: [38840.476924]  [<ffffffff8101361a>] ? read_tsc+0x5/0x14
Jun  1 15:53:26 H61MU kernel: [38840.476927]  [<ffffffff81090cde>] ? handle_irq_event+0x34/0x52
Jun  1 15:53:26 H61MU kernel: [38840.476933]  [<ffffffff8106bd8d>] ? arch_local_irq_save+0x11/0x17
Jun  1 15:53:26 H61MU kernel: [38840.476937]  [<ffffffff81093039>] ? handle_fasteoi_irq+0x7c/0xaf
Jun  1 15:53:26 H61MU kernel: [38840.476942]  [<ffffffff8100f89d>] ? handle_irq+0x1d/0x21
Jun  1 15:53:26 H61MU kernel: [38840.476946]  [<ffffffff8100f5cd>] ? do_IRQ+0x42/0x98
Jun  1 15:53:26 H61MU kernel: [38840.476951]  [<ffffffff8134dc6e>] ? common_interrupt+0x6e/0x6e
Jun  1 15:53:26 H61MU kernel: [38840.476953]  <EOI>  [<ffffffff811afabc>] ? timerqueue_add+0x80/0xa0
Jun  1 15:53:26 H61MU kernel: [38840.476961]  [<ffffffff811ed5c9>] ? intel_idle+0xea/0x119
Jun  1 15:53:26 H61MU kernel: [38840.476965]  [<ffffffff811ed5a8>] ? intel_idle+0xc9/0x119
Jun  1 15:53:26 H61MU kernel: [38840.476970]  [<ffffffff8126ecc3>] ? cpuidle_idle_call+0xec/0x179
Jun  1 15:53:26 H61MU kernel: [38840.476975]  [<ffffffff8100d243>] ? cpu_idle+0xa5/0xf2
Jun  1 15:53:26 H61MU kernel: [38840.476980]  [<ffffffff816abb36>] ? start_kernel+0x3b8/0x3c3
Jun  1 15:53:26 H61MU kernel: [38840.476984]  [<ffffffff816ab140>] ? early_idt_handlers+0x140/0x140
Jun  1 15:53:26 H61MU kernel: [38840.476988]  [<ffffffff816ab3c4>] ? x86_64_start_kernel+0x104/0x111
Jun  1 15:53:26 H61MU kernel: [38840.476991] handlers:
Jun  1 15:53:26 H61MU kernel: [38840.477006] [<ffffffffa00e5c29>] rtl8139_interrupt
Jun  1 15:53:26 H61MU kernel: [38840.477009] Disabling IRQ #18


Erklärung:
Die Bridge soll ab und zu den von einer PCI-Karte kommenden Interrupt nicht zurücksetzen, wenn die Karte es tut. Der Interrupt bleibt vom System aus gesehen also praktisch hängen.
Da nun kein Grät was diesen Interrupt nutzt -und dabei ist es unerheblich ob am PCI-BUS oder nicht- mehr eine Interrupt-Aufforderung senden kann, schaltet der Kernel auf polling um. Das hat dann den massiven Leistungseinbruch zur folge.
Weitere Informationen gibt es in den folgenden Links.
http://www.hardwareluxx.de/community/f12…083-896288.html
http://www.computerbase.de/forum/showthread.php?t=1061561
http://www.gossamer-threads.com/lists/linux/kernel/1461009
http://www.gossamer-threads.com/lists/linux/kernel/1484406
Im letzten hat sich sogar Linus Torvalds dazu geäussert.


Als Ersatz für meinen inzwischen in die Jahre gekommen VDR / Homeserver, habe ich mich in das C847MS-E33 von MSI verguckt, was leider auch diese ASM1083-Bridge verbaut hat. Ich hatte schon fast bestellt, als ich zufällig über dieses Problem gestolpert bin.

Da ich Zugriff auf zwei andere Boards mit dem Chip drauf habe, habe ich erst mal einige Tests gemacht:

Das erste Mainboard ist ein MSI H61MU-E35 mit einem ASM1083 rev 01.

Source code

1
2
3
lspci
[...]
02:00.0 PCI bridge: ASMedia Technology Inc. ASM1083/1085 PCIe to PCI Bridge (rev 01) 
Mit dem waren die Fehler reproduzierbar. Einfach eine PCI-Netzwerkkarte (so ein 08/15 Realtek-Teil) rein, etwas warten und es knallt. Es hat nichtmal einen Tag gedauert. Log Abschnitt siehe oben.
Die Datenübertragung übers Netzwerk bricht massiv ein, von Megabyte pro Sekunde zu einigen Kilobyte pro Sekunde und das System ist nur noch sehr schwerfällig zu bedienen.
Das Board ist in einem Büro-Rechner, da steckt noch nichtmal eine Grafikkarte drin und auch keine Onboard-Komponente ist über PCI angebunden, da ist es bislang noch nicht aufgefallen.

Das zweite Board ist ein MSI Z77A-G43. Das wurde erst kürzlich gekauft und da ist ASM1083 der rev 03 verbaut.

Source code

1
2
3
lspci
[...]
04:00.0 PCI bridge: ASMedia Technology Inc. ASM1083/1085 PCIe to PCI Bridge (rev 03)
Bei dem Board ist es mir bislang nicht gelungen den Fehler auch nur ein einziges mal zu provuzieren.
Selbst bei verschärften Bedingungen, mit extra traffic passiert nichts.
Dann kam noch eine PCI DVB-S-Karte dazu, auch das hat das Board kalt gelassen.
Der Rechner läuft jetzt schon eine Woche mit laufendem Netzwerk-Traffic und TV durch, ohne dass was passiert ist.
Auch ist es mir im Internet nicht gelungen, die rev 03 in Verbindung mit den Fehlermeldungen zu finden. Die waren immer in Verbindung mit der rev 01.

Asmedia hat es wohl geschafft mit der rev 03 die Probleme in den Griff zu bekommen.
Nach meinen Tests denke ich es ist sicher ein Mainboard zu kaufen, sofern man darauf achtet, dass der ASM1083 in rev 03 verbaut ist.
Trotzdem würde ich mich über weitere Erfahrungen freuen um das zu untermauern.
Gruss
SHF


Mein (neuer) VDR:

Software:
Debian Wheezy mit Kernel 3.14
VDR 2.0.7 & div. Plugins aus YaVDR-Paketen
noad 0.8.6

Hardware:
MSI C847MS-E33, onboard 2x1,1GHz Sandybridge Celeron 847, 4GiB RAM
32GB SSD (System), 4TB 3,5" WD-Red HDD (Video)
TT FF DVB-S 1.5 FullTS-Mod PWM-Vreg-Mod, DVB-Sky 852 Dual DVB-S2
Das ganze im alten HP Vectra VLi8-Gehäuse versorgt von:
PicoPSU-160-XT und Meanwell EPP-150 im ATX-NT-Gehäuse

This post has been edited 2 times, last edit by "SHF" (Jun 8th 2013, 2:54am)


2

Saturday, June 8th 2013, 1:01pm

Hallo,
mein Board ist auch betroffen. Ich hatte die letzten Tage den Verdacht, daß mein Problem mit der langen Latenzzeit auch daher kommt (Asus E35M1-M PRO).

Warum braucht UpdateOsdSize viele Sekunden?

Allerdings sehe ich im Syslog nichts davon.
Grüße, Dieter :-)

Click to see my VDRs


VDR1: Asrock B75-Pro3, G1610, 3+2TB WD, Sat->IP von Octopus Net, Gainward GT630 Rev2, NVidia 331, Ubuntu Precise AMD64, Kernel 3.13.0-57-generic, Kernel DVB, VDR 2.2.0-0yavdr0~precise~0.5, SoftHdDevice 1:0.6.1rc1.git20150630.0812-0yavdr1~precise, rc_core mit RC6+RC5, eventlircd, CIR-Homebrew-RS485 mit 8m Kabel, 10m HDMI, TV: LG 42LM670S
VDR2: E35M1-M PRO, Nvidia GT210, easyVDR 2.3 testing, SoftHdDevice, Sat->IP von Octopus Net.
VDR3: Raspberry Pi1B, Client, gemäß Wiki
VDR4: Raspberry Pi2B, Client, Jessy mit yaVDR-Source-Paketen compiliert gemäß Wiki
VDR5: Server, Trusty mit yaVDR Paketen, Sat->IP von Octopus Net.

3

Saturday, June 8th 2013, 1:16pm

Hmm, das hat "iampivot" hier: yavdr 0.4 auf altem 32bit Notebook schon einmal angesprochen, im Februar 2012 ...

Wenn ich es noch richtig zusammen bekomme, war das in Verbindung mit 64-bit Installationen.
Setzt Euch gegen CETA & TTIP zur Wehr!!!

>>click<< for my VDR stuff

>> HowTo: APT Pinning <<
[¹] Modu CD21, MeanWell (80W)/LC-Power (75W), Futaba MDM166A, Intel DH77EB, G1610T, 2x1GB DDR3, Intel 313 SSD 24GB, WD20EFRX 2TB, Zotac GT630 ('GK208'), SHDD, Octopus Net SAT>IP (DVBS2-8), Jultech JESS, CIR, Ubuntu LTS 14.04.3, VDR 2.2.0 (x64, 35W)
[²] Modu CD21, MeanWell (80W)/PicoPSU (90W), Futaba MDM166A, ASRock Q1900M, 2x1GB DDR3, Intel 320 SSD 40GB, WD10JFCX, Palit GT630 ('GK208'), SHDD, Octopus Net SAT>IP (DVBS2-8), Jultech JESS, mceusb, Ubuntu LTS 14.04.3, VDR 2.2.0 (x64, 22W)
[³] HP ProLiant ML10 v2, Xeon E3-1225v3, 2x8GB DDR3 ECC, Intel 320 SSD 120GB (Sys & HostCache), HPDSA B120i, 4x WD7500BPKX, HPSA P212 256MB BBWC, 5x WD1003FBYX, VMWare ESXi 6.0 (6 VM)(x64, 48W)

wofritz

Intermediate

Posts: 530

Location: Schwüblingsen/NDS/DE

Occupation: Coding for food

  • Send private message

4

Saturday, June 8th 2013, 2:00pm

Schreck lass nach... Aber das C847MS-E33 hat die rev 03 drin:

Source code

1
05:00.0 PCI bridge: ASMedia Technology Inc. ASM1083/1085 PCIe to PCI Bridge (rev 03)

Dann bin ich hoffentlich nicht betroffen. Bisher habe ich auch keine seltsamen Effekte bei diesem Board bemerkt, und in den vorhandenen syslogs gibt es auch keine entsprechenden Meldungen.
VDR 1: (in Rente) EPIA ME6000, Nexus-S 2.1, Skystar2 2.6d, VDR-1.4.7 auf SuSE 9.3 (Kernel 2.6.21.7)
VDR 2: (work in progress) MSI C847MS-E33, Cine S2 6.0, Zotac GT630 (GK208), yaVDR 0.6

SHF

Sage

  • "SHF" started this thread

Posts: 3,942

Location: hessische Bergstrasse

  • Send private message

5

Sunday, June 9th 2013, 2:14am

Allerdings sehe ich im Syslog nichts davon.
Dann ist in diesem Fall nicht der Fehler.

Beim Asus E35M1-M PRO hängt aber der Firewire am PCI, der Fehler kann also auch ohne PCI-Karte auftreten. Dann muss aber auch in den Logfiles was zu finden sein.
Gruss
SHF


Mein (neuer) VDR:

Software:
Debian Wheezy mit Kernel 3.14
VDR 2.0.7 & div. Plugins aus YaVDR-Paketen
noad 0.8.6

Hardware:
MSI C847MS-E33, onboard 2x1,1GHz Sandybridge Celeron 847, 4GiB RAM
32GB SSD (System), 4TB 3,5" WD-Red HDD (Video)
TT FF DVB-S 1.5 FullTS-Mod PWM-Vreg-Mod, DVB-Sky 852 Dual DVB-S2
Das ganze im alten HP Vectra VLi8-Gehäuse versorgt von:
PicoPSU-160-XT und Meanwell EPP-150 im ATX-NT-Gehäuse

6

Monday, June 10th 2013, 10:25pm

Danke für die Warnung, leider für mich zu spät, aber gut für die nächsten. Ist bei mir aufgetreten in einem Asus E35M1-M PRO und einen Asus P8H67-M PRO, beide für meine zwei VDRs gekauft. Irqpolling aktiviert und an den PCI Latency Parametern rumgeschraubt, mit mässigen Erfolg. Ich habe dann von PCI Budget Karten auf PCIe Digital Devices aufgerüstet.

447377

Intermediate

Posts: 175

Location: Kreis Böblingen

Occupation: Bastler

  • Send private message

7

Friday, August 29th 2014, 11:36am

Ist das eigentlich aktuell noch ein Thema? Oder wird das durch einen neuen Kernel umgangen?

meine VDRs


Hardware
VDR Wohnzimmer: Thermaltake DH 102, Pico PSU XLP, Meanwell, Asus B85M-E, Intel G1820, 4 GB RAM (1,35 V), Zotac GT 630 Zone Edition, Samsung 850 EVO SSD, DD Max S8, Jultec Einkabel, IR605Q + Harmony 350 (33 W, Boot: 15 s)
VDR Hobbyraum: Atlas SF101, be.quiet 300 W, MSI C847MS-E33, 4 GB RAM, SanDisk SSD 32 GB, Samsung F2 EcoGreen 1,5 TB, TT S2-6400, Hauppauge PVR 250
VDR Backup-Server: Atlas SF101, PicoPSU 80 W, Asus E35M1-M (AMD-VDPAU), 4 GB RAM, Technisat Skystar 2 eXpress HD, SanDisk SSD 32 GB, WD Red 4 TB (31 W, Boot: 26 s)
VDR Desktop: Silentmaxx ST-11 Pro, be.quiet 300 W, Asus P8H77-M, Intel i7-3770, 16 GB RAM (1,35 V), Zotac GT 630 Zone Edition, 2x OCZ Vertex 4, Samsung F4 EcoGreen 2 TB, DD Cine S2, TT USB IR (44 W)

Software
OpenSUSE 42.1, Kernel 4.1.13, VDR 2.2.0

Similar threads

Immortal Romance Spielautomat