[gelöst] neue nova-t 90002: kein power-off

mw_183 · 28. April 2006

Moin,

seit kurzem habe ich eine neue Nova-t 90002 als Zweitkarte. Ich verwende linvdr 0.7, vdr 1.3.17, mit Dr. Seltsams Kernel 2.6.15 (28.2.2006) und ebendessen dxr3-Paket. Um die Karte verwenden zu können, habe ich in der runvdr als letzte Module cx88xx und cx88_dvb angefügt. Soweit läuft es prächtig, beide Karten liefern ein Bild, ich kann gleichzeitig zwei Frequenzen schauen/aufnehmen etc.

Beim Shutdown wird jetzt ca. jedes 2. Mal das Netzteil nicht abgeschaltet, daher fährt der Rechner dann natürlich auch nicht mehr automatisch hoch. Ich habe den Rechner ins Arbeitszimmer geschleppt, einen Monitor angeschlossen und folgendes (nach verunglücktem shutdown) abgeschrieben:

Code

vdr[(...)]: exiting
Unable to handle kernel NULL pointer dereference at virtual address 000001b0
printing eip:
c7d31bb3
*pde=00000000
Oops: 0002[#1]
Modules linked in: lirc_dev cx88_dvb cx8802 cx88xx ir_common (...)
CPU: 0
EIP: 0060: [c7d31bb3]
EFLAGS: 00010202 (2.6.15)
EIP is at dvb_frontend_release +0x34/0x49 [dvb_core]
eax: (...)

Alles anzeigen

An den Stellen (...) habe ich jeweils was gekürzt.
Danach fährt das System runter und sagt "system halted". Es gibt also keine "kernel panic", wie in einem anderen Thread berichtet. Nur geht eben der Strom nicht aus.

Ich habe dann damit experimentiert, verschiedene Module in der runvdr mit aufzulisten, bis hin zu der ganzen Liste

Code

cx88xx
cx8802
cx22702
video_buf_dvb
cx88_dvb

Das ändert aber gar nichts.

Beim Runterfahren sollten wohl eigentlich die Module schon entladen sein (?). Wenn ich "/etc/init.d/runvdr stop" aufrufe, kriege ich die Meldung

Code

Unknown HZ value! (84) Assume 100.
FATAL: Module cx88_dvb is in use.
FATAL: Module video_buf_dvb is in use.
FATAL: Module cx22702 is in use.
FATAL: Module cx8802 is in use.
FATAL: Module cx88xx is in use.
FATAL: Module dvb_core is in use.
FATAL: Module video_buf is in use.
FATAL: Module videodev is in use.

Die Module können also nicht entladen werden. Ich frage mich, warum. Nach einem "/etc/init.d/runvdr stop" konnte ich mit rmmod -f das cx88_dvb ohne Crash entladen. Trage ich diesen Aufruf in die runvdr als letzten Befehl unter "stop)" ein, steht das System sofort.

Wieso können die Module nicht in der runvdr entladen werden (Knackpunkt scheint cx88_dvb zu sein)?
Wer benutzt beim Shutdown cx88_dvb (Module cx88_dvb in use)?
Wieso geht das Entladen per Hand (kann allerdings ein Zufall gewesen sein)?
Hat das verpatzte Power-off vielleicht einen anderen Grund (und welchen)?

Für Hinweise aller Art dankt
Matthias

herbsl · 28. April 2006

hi,

versuche mal einen "sleep 5" vor dem entladen des treibers in der /etc/init.d/runvdr unter stop) .

gruesse
herbsl

mw_183 · 30. April 2006

Super - das wars scheinbar gewesen.

Mit "sleep 5" vor dem Aufruf von unloaddriver (allerdings unter "down)") hatte ich gleich eine Fehlermeldung weniger. Dann habe ich die Ausgabe von lsmod studiert und schließlich nur noch cx88_blackbird und cx88_dvb geladen. Jetzt wird alles ohne Probleme auch in der runvdr wieder entladen. Bis jetzt gabs auch keine Probleme beim Shutdown mehr.

Heißen Dank für den Tipp,
Matthias

Dr. Seltsam · 25. Mai 2006

wird beim Runterfahren über das poweroff.pl-Script denn überhaupt /etc/init.d/runvdr stop aufgerufen? m.E. nicht. Ich habe mit der tT 1500C Budget ein ähnliches Problem. Ein Runterfahren ohne vorheriges Entladen der Treiber führt zum Kernel oops

Dr. Seltsam · 25. Mai 2006

so, ich hab mir das mal genauer angesehen:

beim Runterfahren wird ein runvdr stop ausgelöst, und eine Sekunde später vdr bereits zwangsgekillt:

Code

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

Die Sekunde ist zu kurz, da bis dahin vdr nicht vollständig beendet ist bzw. die Treiber nicht entladen wurden.
Also habe ich mal 3 Sekunden daraus gemacht (sleep 3)

bei runvdr stop wird zunächst runvdr down ausgeführt. Dabei wird vdr beendet und ein sleep 1 abgewartet. Danach wird ggf. fbtv beendet; anschließend werden die dvb-Treiber entladen (unloaddriver).

Auch hier ist die Zeit zwischen Beeenden von vdr und Entladen der Treiber zu kurz. Man könnte jetzt den vorhandenen sleep 1 einfach erhöhen, bin mir aber nicht sicher, ob auch fbtv das Entladen der dvb-Treiber stören könnte. Also ist die Strategie, die hier schon beschrieben wurde, wohl sinnvoll. Also kommt ein sleep 5 vor unloaddriver:

Code

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

  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 	
  sleep 5
  unloaddriver

Alles anzeigen

jetzt sollte vdr beendet sein, so dass die Treiber sich besser entladen lassen.

Nun klappt auch bei mir der Shutdown ohne Kernel Oops

Das Problem ist wohl, dass einige dvb-Treiber es sehr übel nehmen, wenn man sie entladen will, solange sie noch in Benutzung sind. Vermutlich spielt dabei auch eine Rolle, dass bei einzelnen Modulen dass Entladen klappt, diese dann aber von einem anderen Modul noch benötigt würden.

mw_183 · 28. Mai 2006

Genau das glaube ich auch, deshalb hatte ich den "sleep 5" auch an genau dieser Stelle eingefügt. Probleme beim Entladen gibts jetzt nur noch, wenn noad mir die dxr3-Geschichte abwürgt (siehe hier). Was dabei genau passiert, habe ich nicht rausgefunden.

Übrigens: Seit Deinem Kernel 2.6.15 vom 2006-05-07 schreiben die cx88 Module mir offenbar auch nicht mehr das Log voll - super! Und die 90002 läuft mit den aktuellen Treibern und justierter Antenne supergut, mit BER fast konstant auf 0. Jetzt möchte ich nur noch mein noad wiederhaben, aber das ist ein anderer Thread ...

Viele Grüße,
Matthias

[gelöst] neue nova-t 90002: kein power-off

Jetzt mitmachen!

Teilen

Benutzer online in diesem Thema