Hallo,

Seit cdk/Makefile.am 1.197.2.51.2.107 wird libfx2.so zwar wieder installiert, aber 2 Zeilen spaeter schon wieder von einem dangling link ueberschrieben. Ich wuerde den angehaengten patch vorschlagen.

Jetzt endlich weiss ich, was den Fehler ausloest. Das Problem ist leicht reproduzierbar, wenn man die Festplatte mit einer Aufnahme vollkommen fuellt. Sodann kann die epg.dat nur noch erfolgreich geschrieben werden, wenn die Groesse der epg.dat abnimmt. Ist die epg.dat beim Auffuellen der Platte zufaellig schon relativ klein, dann schlaegt das schreiben der aktualisierten epg.dat spaeter fehl (es wird zu wenig geschrieben). Aus den von mir bereits erlaeuterten Gruenden wird die .md5 Pruefsumme trotzdem "valide" erstellt und beim naechsten Start kommt der fatale Fehler.

Es gibt einen kruden Test im Quellcode, ob noch genuegend Platz auf der Platte ist. Dieser funktioniert offensichtlich nicht und das kann ich leider nicht erklaeren. Aber ich wuerde trotzdem dafuer plaedieren, den angehaengten patch anzuwenden damit das Szenario wie oben beschrieben nicht passieren kann.

Ja, laut hdparm ist DMA aktiv.
Sonst wären im übrigen noch deutlich schlechtere Werte zu erwarten.

Kann gut 5MB/sec Plattenperformance für ein IDE interface mit DMA denn wirklich "normal" sein?

Ich fühle mich technisch um mehr als ein Jahrzehnt zurückversetzt!

Man hat normalerweise zum IBM STBx25xx chipsatz keinen Zugang zu data sheets. Könnte bitte jemand, der diesen Zugang hat, nachsehen, ob wirklich nur 5MB/sec die zugesicherte Eigenschaft ist? Ich kann mir das eigentlich nicht vorstellen, und tippe auf einen Firmware-Bug. Leider ist der ohne Chipsatz-Doku praktisch nicht zu beheben.

Zitat

Originally posted by Kat-CeDe
hast Du es mehrfach hintereinander ausgeführt? Bei meiner 7020 ist es beim 1. Aufruf auch 5MB/sec weil sie wohl geweckt werden muß und danach ist es ca. 17MB/sec.
Ralf

Ja, natuerlich, mindestens 5 mal hintereinander ausgeführt; es kommt aber immer der nahezu gleiche Wert. Aus dem Platten-Standby habe ich es nicht probiert.

Hallo,

Ich denke, die IDE-performance meiner dm600pvr ist fragwuerdig. Wenn ich auf der box "hdparm -t /dev/ide/.../disc" ausführe, erhalte ich jediglich Werte zwischen 5,0 und 5,2 MByte/sec. Koennte das bitte jemand verifizieren, ob das normal ist? (Ich meine die reine Plattenperformance ohne irgendeine Beteiligung des Netzwerks.)

Meine Platte ist eine Samsung HM120JC.

Mein kernel enstpricht dem folgenden:

http://ghost.dream-multimedia-…12_2.6.12-r4_dm600pvr.ipk

Ich habe mir auch die Muehe gemacht und diesen kernel selber kompiliert. Dabei ist mir aufgefallen, dass das CONFIG_BLK_DEV_IDE_VULCAN (default aus arch/ppc/configs/dm600pvr_defconfig) beim bauen (im 'make oldconfig' Schritt) durch CONFIG_BLK_DEV_IDE_STB2500 ersetzt wird (ist das gewollt?).

Erzwingen von CONFIG_BLK_DEV_IDE_VULCAN (und damit verwendung von vulcan.c statt stbxxxxx.c) hat jedoch absolut keine Aenderung gebracht -- hdparm -t zeigt immer noch ca. 5MB/sec an.

Zitat

Originally posted by dre
der fehler tritt in den gespeicherten daten (epg.dat) auf und ist nicht in der epgcache.cpp zu finden.

Das kann schon sein, ich habe mir das noch nicht genauer angeschaut.
Ich habe leider die md5 Pruefsumme des epg.dat nicht ueberprueft, sondern die Datei gleich geloescht. Beim naechsten Mal werde ich sie aufheben.

Zitat

der eFatal wird beim aufruf der funktion const eit_event_struct* eventData::get() const oder eventData::~eventData() (also dem destructor) geschmissen.

der fehler dürfte aber wohl eher mit fehlerhaften daten zu tun haben.

Auch das mag durchaus sein. Da aber die Daten doch von aussen kommen sollte man sich keinesfalls auf irgendwelche Konsistenz verlassen (siehe letzten Oktober ;)).

Gerade bemerke ich, dass der md5-Check in epgcache.cpp ungeeignet ist, um etwaige Plattenfehler auszuschliessen, da das md5 erst durch ruecklesen der Datei bestimmt wird. Angenommen, es tritt beim Schreiben ein Fehler auf, die Datei kann aber ohne I/O error wieder gelesen werden, dann stimmt die md5 wunderbar, es kommen aber trotzdem fehlerhafte Daten an...

Ich bleibe dabei: wenn dieser fatale Fehler auftritt, sollte die epg.dat auf jeden Fall prophylaktisch geloescht werden. Sonst wird die Box ohne Netzwerkzugriff unbenutzbar.

Zitat

vielleicht solltest du mal noch deine image-version angeben.

CVS, Stand von Ende Dezember

FATAL error: 147 descriptor not found in descriptor cache ...:

Diese Meldung bekam ich gestern erstmals zu sehen. Nach dem betaetigen irgendeiner Taste wird die Box neu gestartet. Nur leider bleibt das Problem bestehen, die box wird unbenutzbar!

Es handelt sich um Zeile 147 in epgcache.cpp.

Also habe ich den epgcache manuell von der Platte geloescht.
Danach geht alles wieder bestens, aber ohne Netzwerk und PC waere die Sache sehr schwer geworden.

Zunaechst sollte die Fehlermeldung meiner Meinung nach das Wort "epgcache" enthalten. Und zweitens sollte der Cache vor dem reboot automatisch geloescht werden, wenn dieser Fehler (aus welchem Grund auch immer) aufgetreten ist.

rmie

"Endlich" ist das Problem bei mir wieder aufgetreten.

"rmmod head" (geht nur nach terminieren von enigma und dccamd)
und nachfolgendes "modprobe head" behebt die Tonverzerrungen nicht.

Es muss irgendwas anderes beim Bootvorgang passieren, was
das Problem behebt.

Ich habe eine DM 600 von Mai 2007 mit dem "verbesserten" Netzteil,
und habe auch das Problem mit dem verzerrten Ton (geschaetzt
bei jedem 3-6ten Kaltstart; reboot behebt das Problem soweit
ich mich erinnern kann immer).

Das Problem hat uebrigends auch beobachtbare Effekte: Wenn der Ton in dieser Weise verzerrt ist und man von Festplatte eine Aufnahme ansieht, dann gibt es alle paar Sekunden Freezes im Bild; der Ton laeuft also zu langsam und die Bilddarstellung muss durch duplizierte Frames gebremst werden um Synchronizitaet zu halten. Es ist meiner Meinung nach so, dass ein fuer die Audioausgabe massgebliches Register verstellt ist bzw. dass der mp2-Dekoder mit einer falschen Sample rate gefahren wird. Das muss doch eigentlich per Software korrigierbar sein!?

Aber es gibt auch einen eindeutigen Hardware-Aspekt:
Nach dem Hinweis von klausk bzgl. Stromkreis habe ich die Box seit gut 1 Woche an einem guten Labornetzteil (an der selben Steckdose wie zuvor, und auch ansonsten alles unverändert), und siehe da, das Problem ist kein einziges Mal aufgetreten (habe bestimmt an die 30mal kalt-gestartet)!

Es wäre also interessant, ob alle, die das Problem haben, das "verbesserte" Netzteil (CWT PAG024F) haben. Hat vielleicht noch jemand ein anderes Netzteil (z.B. das ganz am Anfang mit der DM 600 ausgelieferte) und das Problem nicht?