Hallo Leute,
so einem Forum tut es sicher gut, wenn nicht nur bei Problemen was geschrieben wird, sondern auch gelöste Probleme mal geschildert werden.
Ich will das jetzt mal für meine Umgebung tun. Der Text ist sehr lang geworden, aber ich habe auch sehr viel Zeit und Arbeit in die Lösung der diversen Probleme gesteckt. Und vielleicht kann ja der eine oder andere davon profitieren. Also, schnell noch 'ne Tüte Chips und ein Bier oder eine Flasche Rotwein geholt, es geht los!
Das HW-Umfeld:
AMD Duron 1300 auf MB K7SOM+ Rev. 7.5A, TT DVB-S Rev. 1.6
Aufgabenstellung:
Dieses System mit einem VDR zu betreiben, und zwar sowohl mit nvram-wakeup als auch mit swsusp. Ausgangsgbasis ist SuSE 8.2, vdr 1.2.5, DVB 1.0/1.0.1
Vorgehensweise:
Nach der SuSE-Installation mit dem Orig-Kernel (2.4.20) und der VDR-Umgebung (zunächst ohne swsusp, ohne nvram-wakeup) nach "Sandmann" lief alles auf's erste Mal --> gut.
Dann wollte ich swsusp installieren, um die Boot-Zeiten zu verkürzen. Das "stable" Release ist derzeit 1.0, aber die aktuellen Release-Candidates für Version 1.1 sollen funktional schon wesentlich verbessert ggü. 1.0 sein. Also 1.1-rc9 runtergeladen. Das erfordert einen 2.4.22-Kernel --> Vanilla 2.4.22-Sourcen gezogen. Zusätzlich noch den neuesten acpi-Patch. Kernel gemäß swsusp-Anleitung konfiguriert und übersetzt --> Internal Compiler Error! Nachforschungen ergaben, dass SuSE mit der 8.2 einen gcc 3.3. "prerelease" ausgeliefert hat. Also den aktuellen gcc 3.3.1 geholt. Damit ließ sich der Kernel und die Module dann bauen.
Das "Hibernate" von swsusp blieb hängen. Debugging ergab, dass ein Kernel-Bug im Highmem-Modul der Auslöser war. Da ich bei 128MB auf Highmem getrost verzichten kann, habe ich es ausgeschaltet (gibt aber wohl auch einen Patch dafür) und den Kernel neu übersetzt. Dann ging Hibernate und das Wiederaufwachen (zunächst noch ohne VDR) super.
swsusp bei laufendem VDR machte dann Probleme dergestalt, dass beim Aufwachen zwar das Bild wieder da war, der Ton aber nicht. Auch die Bedienung des VDR klappte nur noch über Tastatur, über's Netz (vdradmin) ging nichts mehr. Die Logs wiesen auf einen Ressourcenkonflikt hin. Ein sauberer händischer Restart des VDR, inklusive entladen und laden der DVB-Treiber (wichtig!), dann war wieder alles im Lot. Also muss das automatisiert werden. Dem swsupend kann man mitteilen, dass es Services vor dem Hibernate stoppen und beim Resume wieder starten soll. Voraussetzung ist ein SystemV-konformes start/stop-Script in /etc/init.d. Nun, das hatte ich sowieso schon erstellt, damit der VDR beim "normalen" Hochfahren gestartet wird (die inittab-Methode gefällt mir nicht so). Also die /etc/suspend.conf entsprechend angepasst. Aber es hatte keine Wirkung :-(. Irgendwie wurde der VDR nicht gestoppt. ich hatte nach dem Resume zwar nicht immer, aber immer wieder (unregelmäßig) die beschriebenen Ressourcen-Konflikte. Nach Umschiffung diverser Klippen und Untiefen in den Weiten der Unix-Meere war der Auslöser gefunden: der Watchdog-Timer! Es gibt keine (mir bekannte) saubere Prozedur für das Beenden des VDR mit aktivem Watchdog. Da ja normalerweise ein shutdown oder reboot erfolgt, ist das normalerweise auch egal. Ich muss aber ja die Treiber entladen, und das geht nur bei beendetem VDR. Also killte ich in meinem VDR-Initscript die VDR-Prozesse raus, und machte danach einen "make rmmod". Aber gleich nach dem Killen schlug wohl meistens (nicht immer!) der Watchdog zu und verhinderte durch den Restart, dass die Treiber entladen werden konnten ("device or ressource busy"). So wurde beim Hibernate das Image des Systems wieder mit laufender VDR-Umgebung abgelegt--> Konflikt beim Resume. Andererseits wollte ich auf den Watchdog nicht verzichten. Die Lösung war schließlich, vor dem Killen der VDR-Prozesse auch den runvdr-Prozess (ich starte im init-Script diesen per nohup) explizit rauszuschmeißen. Seitdem klappt das mit dem Hibernate und dem Restart des VDR sauber.
Hochfahrzeit des VDR bis das Bild kommt ist ab Drücken des Einschaltknopfes incl. Selbsttest, BIOS etc. ca. 30 Sekunden.
Nächste Baustelle: nvram-wakeup. Mein Board wird unterstützt, braucht aber den (doofen) reboot. Also musste ich dem swsusp einen Reboot beibringen. Es sieht wohl so aus, als würde dies (bei meinem Board) nur in der Debug-Variante von swsusp gehen. Jedenfalls hat es ohne Debug-Opotion nicht auf das entspr. Flag reagiert und immer einen power-off gemacht. Im Debug-Modus geht's. Die Flags für Power-off oder Reboot stellt man über die /etc/suspend.conf ein. Das ist natürlich schwierig zu automatisieren. Es erschien mir deswegen elegant, das Hibernate-Script so zu "customizen", dass es einen entsprechenden Parameter "--reboot" mit bekommt. Dann noch das vdrshutdown-Script angepasst, damit es den Grub richtig behandelt, und das war's!
Also momentaner Stand der Dinge:
VDR mit swsusp und nvram-wakeup tut wie gewünscht. Nachdem dies ja die unbedingte Mindestvoraussetzung ist (ok, swsusp hätte man zugunsten längerer Anlaufzeiten weglassen können, aber der "Jagdistinkt" war geweckt), werde ich mich nun den Plugins widmen.
Achja, schön wäre noch die Möglichkeit, vielleicht über einen "Special Key" auf der FB die Kiste zu veranlassen, beim vdrshutdown wahlweise einen "ordentlichen" shutdown -h zu machen, damit man auch mal "von Grund auf" booten kann. Aber solange man über's Netz noch an die Büchse (bzw. eine Shell) kommt, geht ja alles. Zudem werde ich mir eine "Web-Console" (Terminalserver) an die serielle Schnittstelle anschließen. Damit habe ich auch Zugriff auf die Büchse, wenn sie nicht mehr ins Netz kommt .
So, das war lang, aber es steckt ja auch genug Arbeit drin. Vielleicht hilft's ja jemandem...
So long
Jürgen 
