Help: HVR-4000 + Gigabyte EP43-DS3

Hallo zusammen,

ich habe aktuell folgendes Testsystem hier:

Gigabyte EP43-DS3 Mainboard (P43 + ICH10R Chipsatz)
mit einem Intel Quadcore drauf, sowie einer HVR-4000 (DVB-S2).

Nun habe ich schon mehr als 3 HDTV Systeme mit HVR-4000 eingerichtet und hatte bisher nie Probleme, leider erhalte ich aber mit diesem Board, im dmesg Log folgende nervige Fehler (Multiproto-Treiber):

cx88[0]: irq mpeg [0x80000] pci_abort*
cx88[0]/2-mpeg: general errors: 0x00080000

Das ganze zeigt sich als Artefakte wie man sie von schlechtem Empfang her kennt im Bild, bis hin zu Stand-/Ruckelbild, abhängig wie oft sich dieses Meldung im Log wiederholt. Leider habe ich inzwischen absolut keinen Anhaltspunkt mehr, was ich noch tun könnte, folgendes habe ich bereits probiert:

- Bios update auf aktuellste verfügbare Version (18.08.2008)
- Durchtesten aller 4 verfügbaren PCI-Slots ( bei den unteren beiden, 3+4 taucht diese Meldung praktisch sofort auf, in den Slots 1+2 meist erst nach einer Weile, vorzüglich nach dem Umschalten)
- Diverse Kernelversionen (2.6.22.15, 2.6.24.5, 2.6.25.16) in Zusammenhang mit verschiedene Distributionen (64-bit LennyBeta2, 32-bit easyVDR)
- Manuelle IRQ zuweisung für die Karte / BIOS-Einstellungen
- Deaktiviern möglichst sämtlicher sonstiger hardware im BIOS
- Verschiedene Kernel Paramter (acpi=off, pci=routeirq, apic=off usw..)

Taucht diese Meldung erst einmal im Log auf, geht sie auch nicht mehr weg, genauso wie die Bildfehler. Dann hilft nur noch ein Entladen & Neuladen des Treibers.

Hat denn vielleicht noch irgendwer einen Tipp für mich?
Einen Anhaltspunkt? Bei google finden sich nur Leute mit dem gleichen Problem, ich find aber keine Lösungansätze

grüße

PS: Eine tt-budget 1500 statt der HVR-4000 funktioniert mit gleichem multiproto Treiber/Installation in allen PCI-Slots fehlerfrei

Hat denn niemand einen Ansatzpunkt für mich .... ?

Inzwischen habe ich übrigens noch etwas weiter getestet, u.a. den alternativen Multiproto treiber von:
http://liplianindvb.sourceforg…gwebdir.cgi/liplianindvb/

in Zusammenhang mit dem frisch-freigegebenen 2.6.26er Kernel...
leider keine Veränderung

Zusätzlich noch einen RAM-Test gemacht -> auch alles ok.

Da ich wie gesagt die HVR-4000 schon mit mehr als 3 anderen Boards bei Bekannten problemlos am Laufen habe, denke ich das Problem liegt klar am Board

Bleibt die Frage:
Möglicherweise ein allgemeines Problem des Chipsatzes (P43/ICH10R) mit der HVR-4000, oder einfach nur Schlamperrei bei dem Mainboard?
(Ich verweise nochmal auf den Fakt, dass seit Markteinführung des Mainboards etwa 14-tägig neue BIOS-Versionen erscheinen....)

Hat denn schon evtl. irgendwer eine HVR-4000/Nova-HD-S2 auf einem Mainboard mit gleichem Chipsatz problemlos am Laufen? (denke gerade über alternativ-mainboards nach...)

*nach oben schieb*

Also ich bin immernoch an der Sache dran, inzwischen habe ich noch:

1) Eine neuere HVR-4000 Firmware probiert
2) Den aktuellen dev. Kernel (2.6.27 rc5)

nachdem beides keine veränderung brachte, hab ich angefangen das Problem nochmals grundlegend zu analysieren, dabei sind mir 2 dinge aufgefallen.

Solange das Problem noch nicht auftritt, finde ich gelegentliche:
cx88_wakeup: 2 buffers handled (should be 1)

Meldungen im dmesg. Scheint als ob dies, so eine Art "vorfehler" ist, der macht sich aber lange nicht so stark qualitativ bemerkbar, wie der pci_abort.

Diese Meldung taucht dann aber, sobald die "richtige" pci_abort fehlermeldung kommt, nicht mehr auf.

außerdem habe ich noch wahlweise mit setpci manuell an der latency der karte rumgespielt (alles von 0 --> ff (hex) getestet).

Dabei scheint:
Je geringer der latency Wert ist, desto höher frequent wiederholt sich die Meldung und desto stärker sind die Bildfehler. Je höher der Wert ist, desto seltener wiederholen sich die Fehlermeldung und die Bildfehler.
Beides ändert aber nichts an der Tatsache dass,

a) es unakzeptabel für den produktiveinsatz ist
b) beidesmal tritt diese nervige meldung irgendwann eben auf

Ich hab 2 HVR4000 hier... ist beidesmal das gleiche Problem

Ich habe auch einen VDR auf einem Asus A8N-SLI (älter, nvidia chipsatz) mit den HVR4000s wunderbar OHNE diese Fehler am laufen...

hier ist eines der Postings, die sich bei google zum stichwort "pci_abort" und meinen dmesg meldungen finden lassen (das thema ist schon öfters aufgetaucht):
http://lkml.org/lkml/2007/10/4/252

obwohl das mainboard älter und deutlich verschieden von meinem "problemboard" ist, so ist mir doch folgender dort geposteter eintrag ins auge gefallen:

PCI bridge: Intel Corporation 82801 PCI Bridge

Genau dieses Gerät habe auch ich in der lspci Ausgabe !!
Vielleicht ein Ansatzpunkt? Bei Zeiten werde ich mal die übrigen threads dies im internet so dazu gibt durchforsten, ob noch mehr verschiedene boards mit dieser pci-bridge evtl. genannt werden?

Oder kann jemand Gegenteiliges behaupten?
Hat jemand ein P43 Chipsatzboard mit einer HVR-4000 am laufen?
Oder sogar jemand eine HVR4000 auf ienem System mit oben genannter PCI-Bridge?

Also, da ich so schnell noch nicht aufgeben wollte und mich mal weiter intensiv auf Ursachenforschung begeben hab, gibt's folgende neue Fakten zu berichten:

a) Ursache des Problems ist eindeutig das Umschalten des Senders, dabei nach erstem Stand auch NUR durch Umschalten auf einen ANDEREN Transponder. Solange ein Sender bleibt passiert dieser "Fehler" nicht... taucht er allerdings auf, löst er sich nicht von alleine.

b) In den Bildfehlern/Artefakten, die Folge der Fehlermeldungen sind, kann man eindeutig Teile des Bildes des letzten Senders vorm Umschalten erkennen. Das passt finde ich sehr gut zu der von mir ebenfalls geposteten Meldung:

cx88_wakeup: 2 buffers handled (should be 1)

Zur Erinnerung: Tritt diese Meldung auf, entstehen die Fehler im Gegensatz zur "pci_abort" Meldung nicht, es scheint als hätte sich das System "gerade noch gefangen"...

c) So wie dieses Problem urplötzlich, aber definitiv irgendwann im Betrieb durch Umschalten auf einen anderen Transponder entstehen kann, so lässt es sich ebenfalls durch vehementes Umschalten auf andere Transponder beseitigen... (kann unter Umständen genausoviele "Versuche" brauchen, wie um es zu erzeugen, ist also definitiv kein "workaround"

ergänzung: am besten reproduzieren lässt sich das problem bei mir auf diesem system durch kurzes "festklemmen" der kanal+/- taste... sowohl zum erzeugen als auch zum "beheben" des problems ...

Nach diesen Erkenntnissen bin ich mir nicht mehr so sicher, ob es wirklich ausschließlich am verwendeten Mainboard liegt. Ich denke das Ganze könnte zumindest mit Anpassungen am Treiber gefixed werden(?) ....

Ha! Nun habe ich mein Problem gelöst...

wie? ich hab mir eine tt-budget S2-3200 gekauft und die HVR-4000 rausgeschmissen
die S2-3200 läuft in der Kiste problemlos.

Ich kann also in Anbetracht der Unmengen Zeit und verschiedenen Dinge, die ich probiert hab, jedem nur empfehlen, falls er die Meldung kriegt: Karte tauschen!

Alles andere macht euch verrückt

Das soll übrigens nich heißen, dass die Nova-HD-S2/HVR-4000 schlecht ist. Die läuft hier in anderen PCs problemlos... und die Umschaltzeiten sind etwas besser als bei der S2-3200 (vielleicht wird mir das auf diesem Board zum Verhängnis).

grüße