Probleme der S2-6400 - Archiv

Zitat von torsten lang

Hallo Falk,
tja, wie gesagt, int_type=1 funktioniert bei meinem Board überhaupt nicht, die Karte selbst läuft ansonsten mit den Standard-Einstellungen aber absolut stabil.

Was mich aber wundert - wie soll man diese Seite nur finden? Von der Hauptseite über die S2-6400 scheint sie überhaupt nicht verlinkt zu sein...

Viele Grüße,
Torsten

Hallo zusammen,
beim Experimentieren (mit dem ganzen PC-Geraffel geht das anscheinend wohl nicht anders) bin ich zumindest drüber gestolpert, daß es nur dann kracht, wenn auch noch der FB-Treiber für die PVR350 geladen ist (benutzt denselben Interrupt). Entlädt man den vorher, läßt sich der Treiber ohne Probleme neu laden, danach kann dann auch der ivtvfb wieder geladen werden.

Viele Grüße,
Torsten

Zitat von Falk

Danke an wtor und torsten lang für die Hinweise!

Ein

Code

modprobe saa716x_ff

führte auch bei mir zum sofortigen Einfrieren des Systems. Das ist dann wohl auch beim Neustart aus dem OSD über die runvdr so passiert.
Ein Stoppen und Starten des Systems über rcvdr (ich habe hier SuSE 11.4 im Einsatz) hat allerdings kein Problem gemacht.
Wie bei wtor funktioniert bei mir

Code

modprobe saa716x_ff int_type=1

Also habe ich gemäß vdr-wiki "TechnoTrend S2-6400 - Mainboard Kompatibilitätsliste" das Treibermodul auf die Blacklist gesetzt, den dvb Sercvice von SuSE deaktiviert und die runvdr dem Wiki entsprechend angepasst. Ergebnis nach 2 Versuchen:

Alles anzeigen

Hallo Falk,
hallo wtor,
was mich mal interessieren würde - welche Treiber benutzen denn den Interrupt der S2-6400 bei euren Systemen noch mit? Dazu darf der Treiber - wenn ich den Code richtig verstehe - aber nicht mit int_type=1 geladen werden, weil er dann den Interrupt exklusiv nutzt.

Also meine Bitte: Modul mal ohne int_type Option laden und unter /proc/interrupts nachschauen, was da alles drauf hängt.

Bei mir macht ein gleichzeitig installierter PVR350 Framebuffer-Treiber auf demselben Interrupt Probleme, der Absturz tritt aber im S2-6400-Treiber auf.

Viele Grüße,
Torsten

Zitat von sewn4

konntest Du dir das Problem mit ausgeschaltetem AV-Receiver schon anschauen? Wenn mein AV-Receiver ausgeschaletet ist startet die TV Karte nicht richtig und das hat zur Folge das der VDR ebenfalls nicht startet. Schalte ich den AV-Receiver ein und starte dann den Rechner läuft alles einwandfrei. Getestet habe ich es mit einem Denon AVR-1911 und einem Pioneer AV-Receiver leider weiß ich nicht mehr genau das Modell der war von einem Freund geliehen.

Ich habe es mit einem Yamaha RX-V663 probiert und da klappt es immer, egal ob aus oder sogar vom Strom getrennt. Ich werde dir mal eine Debug-Version der Firmware schicken, damit wir eingrenzen können wo es hängt.

torsten:

so funktioniert es nicht (einfrieren des Systems ohne int_type=1):

cat /proc/interrupts
CPU0 CPU1
0: 3750 68305 IO-APIC-edge timer
1: 0 8 IO-APIC-edge i8042
8: 0 28 IO-APIC-edge rtc0
9: 0 1 IO-APIC-fasteoi acpi
14: 2 230 IO-APIC-edge pata_atiixp
15: 293 19563 IO-APIC-edge pata_atiixp
16: 500 75231 IO-APIC-fasteoi ohci_hcd:usb3, ohci_hcd:usb4, SAA716x Core, lirc_serial
17: 0 4 IO-APIC-fasteoi ehci_hcd:usb1, parport0
18: 3 410 IO-APIC-fasteoi radeon, ohci_hcd:usb5, ohci_hcd:usb6, ohci_hcd:usb7
19: 0 31 IO-APIC-fasteoi ehci_hcd:usb2, hda_intel, serial
22: 128 16695 IO-APIC-fasteoi ahci
40: 14 2266 PCI-MSI-edge eth1
41: 0 1 PCI-MSI-edge xhci_hcd
42: 0 0 PCI-MSI-edge xhci_hcd
43: 0 0 PCI-MSI-edge xhci_hcd
44: 160 7403 PCI-MSI-edge eth0-rx-0
45: 54 3781 PCI-MSI-edge eth0-tx-0
46: 0 3 PCI-MSI-edge eth0
NMI: 1 2 Non-maskable interrupts
LOC: 95524 127874 Local timer interrupts
SPU: 0 0 Spurious interrupts
PMI: 1 2 Performance monitoring interrupts
IWI: 0 0 IRQ work interrupts
RES: 117130 98374 Rescheduling interrupts
CAL: 946 1558 Function call interrupts
TLB: 2519 7316 TLB shootdowns
TRM: 0 0 Thermal event interrupts
THR: 0 0 Threshold APIC interrupts
MCE: 0 0 Machine check exceptions
MCP: 1 1 Machine check polls
ERR: 0
MIS: 0

So funktioniert es (Laden des Treibers mit int_type=1):

cat /proc/interrupts
CPU0 CPU1
0: 19273579 480865415 IO-APIC-edge timer
1: 0 8 IO-APIC-edge i8042
8: 0 37 IO-APIC-edge rtc0
9: 0 1 IO-APIC-fasteoi acpi
14: 7615 156994 IO-APIC-edge pata_atiixp
15: 61039 2579265 IO-APIC-edge pata_atiixp
16: 4039774 171364063 IO-APIC-fasteoi ohci_hcd:usb3, ohci_hcd:usb4, lirc_serial
17: 0 4 IO-APIC-fasteoi ehci_hcd:usb1, parport0
18: 2 413 IO-APIC-fasteoi radeon, ohci_hcd:usb5, ohci_hcd:usb6, ohci_hcd:usb7
19: 23 883 IO-APIC-fasteoi ehci_hcd:usb2, hda_intel, serial
22: 162482 8380221 IO-APIC-fasteoi ahci
40: 0 1 PCI-MSI-edge xhci_hcd
41: 0 0 PCI-MSI-edge xhci_hcd
42: 0 0 PCI-MSI-edge xhci_hcd
43: 33970 1818318 PCI-MSI-edge eth1
44: 12801502 639815663 PCI-MSI-edge eth0-rx-0
45: 2453749 264810939 PCI-MSI-edge eth0-tx-0
46: 0 2 PCI-MSI-edge eth0
47: 1660043 74802497 PCI-MSI-edge SAA716x Core
NMI: 891 6490 Non-maskable interrupts
LOC: 162869129 1116400479 Local timer interrupts
SPU: 0 0 Spurious interrupts
PMI: 891 6490 Performance monitoring interrupts
IWI: 0 0 IRQ work interrupts
RES: 126210681 81521202 Rescheduling interrupts
CAL: 380324 177103 Function call interrupts
TLB: 209404 169165 TLB shootdowns
TRM: 0 0 Thermal event interrupts
THR: 0 0 Threshold APIC interrupts
MCE: 0 0 Machine check exceptions
MCP: 1563 1563 Machine check polls
ERR: 0
MIS: 0

Lirc läuft bei mir über eine zusätzliche serielle Steckkarte.

Zitat von powarman

Ich habe es mit einem Yamaha RX-V663 probiert und da klappt es immer, egal ob aus oder sogar vom Strom getrennt. Ich werde dir mal eine Debug-Version der Firmware schicken, damit wir eingrenzen können wo es hängt.

Hi Powarman,

das wäre super. Ich schicke Dir eine PM mit meiner EMailadresse...danke!

Hi Powarman,

ich habe Dir per Mail das Log geschickt. Falls Du noch etwas benötigst sag bescheid.

Vielen Dank für deine Hilfe!

Copperhead

Ich will hier nochmal auf einen schon älteren Beitrag hinweisen:

S2 6400 Aussetzer DolbyDigital

Die Aussetzer des AC3-Tones sind auch mit der letzten Firmware noch vorhanden.

Ich konnte das den anderen genannten Audioproblemen bisher nicht so ganz zuordnen, ein Zusammenhang könnte aber schon bestehen.

Deshalb bitte mit in die Liste aufnehmen.

vielen Dank
kamel5

Zitat von powarman

Mit der Firmware 0.3.4 sollte ersteres etwas besser sein. Das zweite Problem wurde gefixt.

Hallo Powarman,
habe gerade die aktuelle Firmware (0.3.4) auch bei mir eingespielt und möchte bestätigen das der Ton insgesamt sehr stabil zu sein scheint.
Vielen Dank für die letzten Korrekturen!

Ich habe lange nichts zum Artefakte-Thema geschrieben, bin mir auch nicht sicher, ob ich der Einzige mit verbleibenden Problemen bin. Insgesamt läuft die Karte stabil. Bei parallelen Aufnahmen mit beteiligtem HD (ZDF HD) oder bei Aufnahmen (SD) und liveTV (ZDF HD/ARD HD) bekomme ich immer wieder kleine Artefakte - niemals (glaube ich) bei reinem liveTV oder reinem SD Betrieb (egal ob live oder mit Aufnahme).
Diese sind nicht sehr ausgeprägt (meistens), lassen sich aber durch mehrere Aufnahmen enorm verstärken. Hier steigt dann die alt bekannte Interruptlast (INT A) in meinem System meist auch über 600.
Ich setze aktuell den VDR in aktueller, vanilla Version ein - alles möglichst aktuell. Es scheint seit nach VDR 1.7.18 etwas schlimmer bei mir geworden zu sein, aber das kann täuschen.

Gerne würde ich den alten Thread (TT S2-6400: Artefakte in Aufnahmen) nochmals wiederbeleben, vielleicht bin ich ja nicht der Einzige der mit dem AT5ION und der DVB-S2 6400 noch diese Probleme hat.

Gruß
Ingo

Evtl. hilft folgendes beim Fehlereingrenzen: Tobi hat auf der ML ein Check-TS als eigenständiges Programm und als Patch für VDR geposted, das Aufnahmen auf Continuity Fehler überprüft: http://permalink.gmane.org/gmane.linux.vdr/45048

Hallo Firefly,

danke für Deinen Vorschlag. Der Check ergibt bei einer HD Aufnahme von heute nachmittag, die ich um die Größe zu verkleinern um zwei herum Artefakte geschnitten habe, eine Anzahl von 7 discontinuity-Fehlern, bei anderen Aufnahmen mit Artefakten ist die Anzahl der discontinuity-Fehler gleich null. Ich weiss leider nicht, was mir das sagen soll.

Gruß
Ingo

Continuity-Fehler heißt, dass mitten drin Datenpakete fehlen. Die Pakete haben aufsteigende Nummern und wenn mitten drin eine Nummer fehlt, dann fehlt das Paket, also die Daten. Das macht sich dann als Artefakte bemerkbar. Falls die Continuity-Fehler am Anfang oder Ende sind kann man sie möglicherweise ignorieren, da das durch das Schneiden kommt.

Zitat von Copperhead

Beim Schneiden einer Aufnahme wird das System so stark ausgebremst, dass eine dabei laufende Wiedergabe anfängt zu Ruckeln und der Schnitt fast zum Stehen kommt.Die CPU ist aber nicht voll ausgelastet.

Das kenne ich auch ohne S2 6400, tritt aber auch nicht immer gleich stark auf.
Du kannst ja mal den Cutter Bandwith Limit Patch probieren.

Zitat von SHF

Du kannst ja mal den Cutter Bandwith Limit Patch probieren.

Ist der nicht auch im Extensionpatch drin
Ich habe ein ähnliches Problem, aber auch schon vor der FW 0.3.4: während eine Aufnahme geschnitten wird, ist das Setzen von Schnittmarken in einer anderen so gut wie unmöglich da es bis zu 2s dauert, bis der nächste Frame angezeigt wird (beim Springen mit Taste 4 und 6). Ich wüsste aber nicht, wo ich nach der Ursache suchen soll. IRQ? NCQ? VDR? S2-6400?

Im Moment hat der Cutter-Thread die niedrigste I/O-Prio innerhalb der Klasse best-effort (SetIOPriority(7); ), sollte man den evtl. auf die Klasse IDLE setzen?

Das hat auch nichts mit der CPU-Last zu tun, eher mit der Festplatten-Last. Aber es war schon bei der SDFF so, dass ein Playback während des Schneidens nicht 100% stabil lief. Speziell das Springen hat sich schonmal ein paar Sekunden Auszeit gegönnt.

Das es mit der neuen Firmware auftritt und vorher nicht liegt wahrscheinlich daran, das ich die Pes-Puffer auf der Karte verkleinert habe, die waren viel zu groß. Dann sollte aber nur bei SD-Kanälen ein Unterschied sein.

Hallo Copperhead,

was sagt denn das Kommando vmstat (oder besser vmstat 1 für sekündliches Update) wenn dein Rechner das Stottern anfängt. Ich hatte das mal bei einem Serversystem. Ist anscheinend ein Problem des 2.6er Kernels das ab und an auftritt (https://bugzilla.kernel.org/show_bug.cgi?id=13347). Wenn IOWait (spalte WA) hoch geht, dann kann sich das so weit aufschaukeln, bis das ganze System stehen bleibt. Die Prozessorlast ist dabei gering (teilweise <1%), er wartet eben dauernd auf I/O. Evtl. hilft der Deadline-Scheduler weiter.

Nur so eine Idee. Warum das jetzt mit der Version 0.3.4 auftritt und mit 0.3.3 nicht? Keine Ahnung...