[solved] VDR 1.3 auf Kernel 2.6 instabil, vdsb error

Oje, der 2.6er Kernel scheint tatsächlich bei weitem noch nicht wirklich stable zu sein...

Es kann doch nicht sein, dass der bei mancher Hardware einfach einfriert... Bei mir liegt es sicher auch an irgendeinem Chipsatz Treiber oder so nem Mist... Aber da erstmal dahinter zu kommen...

Oh mann...

MG-f
Robsta

heiho,

Es kann doch nicht sein, dass der bei mancher Hardware einfach einfriert... 
Bei mir liegt es sicher auch an irgendeinem Chipsatz Treiber oder so nem Mist... 
Aber da erstmal dahinter zu kommen...

wegen diesem Mist habe auf einer anderen Partition eine stage1 Installation durchgefuehrt,
memtest 24 std laufen lassen,Netzteil ,Grafikk. getauscht,
mehrere Kernel-sourcen getestet ,mit verschiedenen Bioseinstellungen,
oje das hat echt viel Zeit gekostet
Vorher liefs ja aber auch,hatte dann mal die zweite lan ausgebaut,
da hats dann anscheinend begonnen mit Einfrieren ,
half nur noch ein reset.
mfg
/dachte erst es liegt am System,
komplett mit unstable packages geemerged,
daher die Parallelinstallation

ok, dann sind wir uns ja einig, dass es mit der verwendeten Hardware zu tun haben muss, jedoch nicht mit einem Hardware-defekt zu tun haben kann... (es läuft schließlich mit einem 2.4er Kernel)

--> Kernel 2.6.x = unstable

holymoly: Kannst du bestätigen, dass dieselbe Hardware unter einem 2.4.x Kernel einwandfrei läuft?

MG-f

Robsta

hi,

Kannst du bestätigen, dass dieselbe Hardware unter einem 2.4.x Kernel einwandfrei läuft?

die 3com hatte ich unter dem 2.4.x Kernel mit den Treibern von Asus --> 3c2000 genutzt,
aber nur im intern ,das hatte alles immer reibungslos funktioniert.
Mit rp-pppoe hatte ich es leider nicht getestet .
Das funktionierte auch seit dem 2.6.3 alles einwandfrei mit der Hardware,
bis ich die 3com fuer den Onlinezugang eingestellt hatte,
gab auch keine irq Konflikte ,hatte ich immer alles per
cat /proc/interrupts uberprueft.
mfg

Wenn ich das so lese, dann bleibe ich doch noch ein Weilchen beim 2.4.26.

Mein erster Test mit dem 2.6.5 passt übrigens auch exakt in das Bild hier. Jede Menge Firmware-Fehler..
Ich bin dann doch lieber zurück zum 2.4 gewechslet und hatte die leise Hoffnung, dass sich in der Zwischenzeit schon was gebessert hätte.

Da fällt mir doch noch was "unwichtiges" ein, wo mein 2.6 ja so schön läuft.

Wer von denen, bei denen es nicht läuft hat denn acpi im kernel aktiviert?

Ich habs nämlich wegen Instabilitäten, die aber am Board liegen, das lief auch unter windoof niemals stabil mit aktiviertem acpi, deaktiviert.
Da es aber bis vor ein paar Monaten zig boards mit acpi Problemen gab könnte es ja sein, dass acpi auch euch den 2.6er kernel verhagelt.

Zitat

Original von Egalus
Wer von denen, bei denen es nicht läuft hat denn acpi im kernel aktiviert?

Uiuiui, muss zugeben, dass ich in allen getesteten Versionen ACPI mit drin hatte.
Wie haben sich die Instabilitäten denn bei dir geäußert? System-freeze?

Werde es baldmöglichst mal ohne ACPI testen... Wie soll man bitte auf sowas kommen? Da kann es ja echt an jedem Modul liegen...

MG-f

Robsta

hi,

Wer von denen, bei denen es nicht läuft hat denn acpi im kernel aktiviert?

habe es im Bios aktiviert,
acpi--> apic Support nennt das,
da gibt es noch,
ACPI 2.0 Support und
Bios --> AML ACPI table,
wenn ich 'acpi--> apic' nicht aktiviere,
wird die Festplatte am pci-kontroller,ist nicht onbard,
nicht erkannt, ist ein DC 100 Raid controller,
den habe ich aber voruebergehend wieder entfernt.
Onboard ist noch ein Promise pdc20378 controller,
aber unter dem 2.6.x Kernel gibt es bisher noch keine Treiberunterstuetzung fuer den
single-ide modus ,raid funktioniert dagegen,das hatte ich mit den wd raptors getestet,
Unterstuetzung dafuer ist im 2.6.x Kernel unter scsi sata support mit drin.
mfg
/ habe smp kernel am laufen,hyperthreading enabled und auch den sonstigen kram

hi,
ohne acpi geht die Kiste nicht mehr aus,
ist auch beim mediaportal unterm 2.4er kernel (gs-sources) so,
da habe ich schon ewig nichts mehr am Kernel veraendert,
never touch a running system
cu

Wie ich darauf gekommen bin mit dem Acpi, ganz einfach, das board lief früher mal bei mir als Hauptrechner und da lief acpi nie zuverlässig (unter Windows) und mit aktiviertem acpi unter kernel 2.6 gabs bei mir schon beim booten arge probleme mit lost IRQs, da hab ichs deaktiviert und stattdessen wieder das gute alte apm aktiviert und habe seitdem nicht einen hänger gehabt.

Übrigens hing bei mir die Kiste mit kernel 2.4 auch ne ganze Weile immer wieder mal, bin nie wirklich dahintergekommen warum, aber nachdem ich von metalog auf syslog-ng umgestellt hatte (da im gentoo forum damals mehr Leute berichtet hatten, dass Ihr System mit metalog einfach so einfriert) lief es dann auch stabil (von Stromausfällen mal abgesehen) im 24/7 Betrieb über mehr als 1 Jahr - bis ich so dumm war mir mein gentoo zu zerbröseln und vor der Wahl stand es wieder als 2.4er oder 2.6er aufzusetzen und mich für 2.6 entschieden habe

Ob das Ausschalten mit oder ohne Acpi funktioniert und wie ist mir, da mein vdr eben nicht nur vdr sondern ne ganze Menge mehr ist, nie aufgefallen, wie auch, wo die Kiste doch höchstens mal abgestellt wird wenn ich was umbaue

hallo,

dass Ihr System mit metalog einfach so einfriert

hatte ich ebenfalls mit metalog,ist aber schon ne Weile her,
nutze seitdem syslog-ng .
mfg

hat jemand eigentlich schon mal versucht die SAT Kabel+Stecker zu prüfen?

Ich hab mal komplett neu abisoliert und seitdem sind zumindest die "broken video stream" weg.

Die fw_cmd_error hab ich auch noch, sind aber nach Umstieg auf SuSe9.1 erheblich weniger geworden bzw. weg (hab noch keinen Dauertest gemacht)

Zitat

Original von AnK
Da scheint mir der Hund nicht begraben zu liegen, das Signal auf der Budget Karte,
scheint besser zu sein als auf der FF DVB.

Ich habe sehr ähnliche Werte (STR~66%, SNR:70%-85%) wobei tendenziell der Empfang auf der Budget besser ist. Das scheint normal zu sein.

Ulrich

Möchte auch noch meine Erfahrungen mitteilen. Ich benutze VDR 1.3.10 unter Kernel 2.4.26 und 2.6.7. Mit dem 2.4er läuft alles sehr stabil, bis auf Abstürze (ca. alle 10 min) beim Streaming mit streamdev (segfault). Runvdr startet den VDR dann aber wieder. Alle anderen Funktionen des VDR einschließlich MediaMVP-Streaming laufen absolut problemlos.

Bei 2.6er kommen diese segfaults mit streamdev ebenfalls vor, VDR ist nach dem Restart durch runvdr aber völlig tot. Erst ein Restart der Maschine bringt wieder den alten Zustand. Habe schon alles mögiche probiert, auch die CVS-Version der DVB-Treiber.

Bin jetzt gezwungenermaßen wieder auf den 2.4er zurück, obwohl der 2.6er ansonsten superstabil läuft.

Hallo

mal eine neue Theorie zu den Problemen: Kann es sein, das der VDR neukompiliert werden muss, wenn man neuere DVB-Treiber benutzt bzw. das erst der VDR 1.3.x mit den Treibern aus dem Linux Kernel 2.6.x zurechtkommt?

Hintergrund: Ich hatte den ct-vdr (1.2.x) mit einem 2.6.7 Kernel benutzt, das ging überhaupt nicht. Bei Aufnahmen hat sich der VDR im minutenrythmus neu gestartet. Mit einem selbstgebauten vdr 1.3.11 scheint soweit alles zu funktionieren.

Ulrich

Hi,

nein, vdr muss nicht neu kompiliert werden wenn der Treiber wechselt, nur wenn sich was an der API ändert (DVB Include Dateien).

Und ein 1.2.6 sollte ebenso mit den aktuellen Treibern laufen wie auch der 1.3.11. Das dein 1.2.6er nicht lief hat demnach andere Ursachen.

BTW Ursachen: In allen Fällen die ich mir bisher angesehen habe (SS2, Nova budget-ci und auch ne FF 1.5) ist es so das nach einer gewissen Zeit keine IRQ´s mehr von der Karte generiert werden bzw. keine IRQ´s mehr bearbeitet werden.
Die genannten Karten benutzen zwar alle den gleichen Frontend Treiber bzw. Demodulator, aber ich sehe keinen Grund warum dieser auf einmal aufhören sollte Daten zu liefern, zumal die Feeds weiterhin geöffnet und geschlossen werden.

Ich glaube eher das der IRQ_HANDLER abschmiert weil beim übertragen der Daten an den Demux was hängenbleibt (verm. nicht Threat-Save oder sowas). Dafür würde sprechen das meine SS2 immer die kürzeste Laufzeit aller meiner Karten hat und bei dieser jedes TS Paket einzeln an den Demus geliefert wird, im Gegensatz zu den anderen Karten (immer mehrere Pakets in einem Aufwasch).

Demnach wäre der Fehler mit einer hohen Wahrscheinlichkeit im dvb_core Bereich zu suchen....

Andy

http://www.vdrportal.de/board/thread.php?threadid=18935&sid=

Hier geht es weiter.
Schonmal großen Dank, dass du dir das Fronmtend angeguckt hast.

Aber wenn das so ist wie du, dann stellt sich mir die Frage, warum nicht andere Karten abschmieren, sondern nur die genannten. Bei nem IRQ Fehler im core müssten alle, oder?