Mahlzeit-ISO 3.2

Bitte auch an den nova se2 geschädigten Denken (siehe Post oben)

es gibt in der Tat viele Problemberichte zur SE2.

hast Du schon mal probiert, die zu kurze Zeitdauer zwischen dem Beenden von vdr und dem Entladen der Module zu erhöhen?

in /etc/init.d/runvdr

down)
#vdradmind.pl -k
PID=`ps -C vdr -o "%p" | grep -vw PID | tac`
if [ x"$PID" != "x" ]; then
kill $PID
fi
sleep 3

if [ x$START_FBTV == x"yes" ]; then
PID=`ps auxw | grep "fbtv" | grep -v grep | awk '{ print $2 }'`
if [ x"$PID" != "x" ]; then
kill $PID
fi
fi

unloaddriver

eventuell auch mal mit 5 (5 Sekunden) probieren.

Hi Dr. Seltsam,

hat leider nicht Funktioniert. Immernoch der kernel Oops. Das passiert immer dann wenn ich den VDR beende oder stoppe. Die beiden Karten sitzen in einer Riser Karte. Diese besitzt zwei PCI Steckplätze wobei der erste Slot einen PCI Stecker besitzt den man zusätzlich auf das Mainboard hinzustecken muss. Je nach dem in welchen Slot ich diesen dann stecke hat die se2 einen anderen Interrupt - aber nie den selben wie die Nexus. Beide Karten haben einen eigenen Interrupt welcher auch nicht mit einer anderen Komponente geteilt wird. Wie schon beschrieben kommt es auf die Reihenfolge an in der ich die Module Lade. Vor der nexus so kommt es zum buffer overflow oder kernel oops, nach der nexus so kommt es zu dem hier bereits einmal erwähnten Problem, dass der VDR beim Beenden der Aufnahmen auf der se2 abstürtzt. Ich hab hier auch schon viel zum Thema se2 gelesen und leider noch nicht die Lösung für mein Problem gefunden.

Bin weiter für jeden Rat Dankbar

Gruß
Atech

tja, sieht übel aus. kannst ja nochmal den neuesten Treiber von Sonntag abend probieren (im aktuellen 2.6.18-Paket enthalten). Vielleicht hat sich da ja die letzten Wochen etwas verbessert.

Hallo Dr. Seltsam,

bei uns im Forum hat ein Benutzer folgendes berichtet, vielleicht könnt ihr das ja auch bestätigen:

:::::::::
Also ich habe das Problem einfach umgangen.
In der runvdr lade ich die Treiber einfach manuell.
Und lasse sie nicht mehr entladen.
Seit dieser Änderung läuft das System absolut stabil.

Einfach in
loaddriver() {
modprobe cx88_dvb &
OLDIFS=$IFS
........

eingetragen und keine Probleme mehr.
Wichtig ist das man den Treiber nicht entläd!
Das fürt bei mir IMMER zum kompletten einfrieren des Systems.
:::::::::

Danke nochmal für die ivtv-Unterstützung!!!!!!!

Gruß
Wolfgang

machst Du das dann für alle Treiber so (diverse modprobe-Aufrufe), oder geht es nach
OLDIFS=$IFS
noch weiter mit dem Laden der in MODULES eingetragenen Module?
cx88_dvb muss dann aus MODULES ja rausgenommen werden.

edit: ach so, war ja nur ein Zitat na ja, man kann es ja mal mit diesem einzelnen Modul probieren. Ansonsten wäre es ja auch einfacher, dass Entladen (für alle Module) in unloaddriver() rauszunehmen

wegen ivtv: ich habe da gerade noch etwas ergänzt:
HowTo: ivtv 0.8x in v4l-dvb-hg mergen

Danke erstmal!

Ich werde das heute Abend nochmal ausprobieren. Habe gestern einfach mal das modul aus der Liste herausgenommen und dann zu beginn der rundvdr ein modprobe cx88_dvb hizugefügt. Leider ist der Vdr dabei abgeschmiert (wieder beim beenden der Aufnahmen). Werden beim beenden des VDR eigentlich die zu beginn definierten Module entladen oder alle die geladen sind? Bei letzterem bringt der gesonderte modprobe aufruf ja nichts.

beim Beenden der Aufnahmen wird vdr ja nicht beendet. Der Aufruf von runvdr stop (mit Entladen aller Treiber, die in MODULES definiert sind) geschieht nur beim Neustart sowie beim Runterfahren (Shutdown)

In letzterem Fall kannst Du ja noch mal mit dem sleep in der /etc/init.d/rcShutdown experimentieren:

# VDR stoppen
/etc/init.d/runvdr stop
sleep 1
killall -9 vdr >/dev/null 2>/dev/null
#sleep 1
#/etc/init.d/runvdr unloaddriver

eigentlich sollte das Killen von vdr hier gar nicht zum Tragen kommen, da vdr ja schon über runvdr stop beendet sein sollte. Sicherheitshalber kannst Du da ja noch mal die Sekunden hochsetzen. Es wäre denkbar, dass der erste Aufruf von runvdr stop trotzdem nicht alle Module entlädt, so dass vdr anschließend bei noch geladenen Treibern gekillt wird - was die Module dann erst recht krumm nehmen, weil sie glauben, sie seien noch in Benutzung. (mal bildlich gesprochen :))

Du könntest auch mal versuchen, in der runvdr zwischen Beenden von vdr und Entladen der Module folgendes einzufügen:

fuser -k -TERM /dev/dvb/*/* > /dev/null

Die Frage ist sonst, was bei Dir eigentlich warum zuerst abschmiert (Treiber oder vdr). Vor allem: Warum crasht vdr beim Beeenden einer Aufnahme?

Hallo Mahlzeit!

wäre es möglich mir bitte den speedcontrol patch fürs DVD-Plugin in eine neue ISO einzubauen, vielleicht brauchen das auch noch andere! Bei mir dreht sich mein NEC einen WOLF. mit hdparm geht bei meinem DVD-Brenner nix. Anbei der Link zum Patch.

speedcontrol für dvd-0.3.5-b07 (DVD-Bremse)

Danke im voraus,
lg
Herby

Hi,

super danke Markus, daß reicht auch, wenn es funktioniert! Werd mir am Freitag dann mal linvdrupdate durchlaufenlassen, und danach probieren!

Noch eine blöde Frage: Gilt dieser Speed dann nur fürs lesen von DVD oder auch fürs schreiben? Möcht dann ned immer in der sysconfig den Speed ändern wenn ich mal DVD's brenne!

Danke im voraus Mahlzeit!
lg
Herby

Werde das Patch einbauen! Habe auch einen NEC DVD-Brenner!!

Wäre schonl Aufwand, weil die Sourcen schon ins Archiv gewandert sind! Denke nächste Woche bin ich mit dem 1.4.5 soweit, meinst du solange können wir warten?

Test das heute erstmal Zuhause "mit ohne" Repacker-Setup-Patch!

Wenn der Test heute läuft, gibt's vielleicht auch noch diese Woche in Paket!

Danke ihr beiden!!!!

*freu* Endlich ein leiser NEC Speedbrenner *gfg*

lg
Herby

Hi Leute,

ich hab jetzt viel mit den Modulen in der runvdr herumprobiert. Ich lade jetzt das cx88_dvb kurz bevor die Module definiert werden via modprobe cx88_dvb und habe nur noch das tt_dvb Modul in der Moduldefinition stehen. Seitdem bekomme ich keine DMA Buffer overflow, kernel oops oder device busy Meldungen mehr. Aber leider bestand nach wie vor das Problem wenn zwei Aufnahmen liefen und ich beide beendet habe beim Abbruch der zweiten Aufnahme (der letzten) der VDR aufgehangen oder Restartet hat. Im Log fand ich dann immer Meldungen die sich auf die "/usr/bin/recordinghooks.sh after" bezogen bzw. die Skripte die dadurch ausgeführt wurden. Oft war der letzte Eintrag im logread ein Fehler in der noad sh. Ich hab dann mal die recordinghooks.sh komplett geleert und siehe da seit dem hängt sich der VDR nicht mehr weg. Wenn ich das richtig verstehe werden ja neben noad auch skripte zur Konvertirerung geladen (z.B. in divx). Ich brauche nur noad und diese Skripte sind bei mir ja scheinbar auch Fehlerhaft. Ich werde das jetzt mal ein wenig weitertesten und dann wird sich ja zeigen ob es ein Problem mit der recordinghooks war oder es im moment nur Zufall ist, das es läuft. Wäre nett wenn jemand die Skripte in rec_before, rec_after, edited_d und eben die recordinghooks einmal hier veröffentlichen könnte falls sie bei ihm auf einem System mit zwei oder mehr Karten funktionieren. Evtl. vielleicht sogar welche die nur noad starten. In der Skriptprogrammierung blicke ich leider nicht durch. Der linvdrupdater hat leider kein Erfolg gezeigt.

Falls das System weiter so stabil läuft werde ich in meinem Thread zum se2 Problem einmal genau Erklären was ich gemacht habe um alle Probleme abzuschalten.

Gruß
Atech