kernel 2.6 und frontend at76c651

[gmo18t]

Hi,

@npq: kann man das das "probing" für sagem-C in "dbox2_napi_core.c" wie folgt proggen ?

Code: Alles auswählen

int dbox2_probe_sagem_C_frontend(struct dbox2_fe *state){
        struct at76c651_config *cfg = kmalloc(sizeof(struct at76c651_config),GF
        if (!cfg)
                return -ENOMEM;

        cfg->demod_address = 0x1a>>1;
        cfg->pll_init = dbox2_napi_pll_init;
        cfg->pll_set  = dbox2_napi_pll_set;

        if ((state->dvb_fe = at76c651_attach(cfg,state->i2c_adap))==0){
                kfree(cfg);
                return -ENODEV;
        }

        state->fe_config = cfg;
        return 0;
}

- GMo -

[Npq]

Ja, allerdings fehlen dann die PLL-Routinen.

Ist aber jetzt im CVS drin, fehlt noch das Ganze für Nokia Kabel.

Ob es spielt weiß ich nicht, beim ves-Treiber ist den Jungs von LinuxTV.org zum Beispiel noch ein Bug reingewandert, der - natürlich - nur für die dbox2 eine Relevanz hatte.

Also im Zweifelsfall nochmal genau mit dem alten Treiber vergleichen.

[gmo18t]

Hi,

in meinem coding hat ja noch ein enig gefehlt - zum Glück. Denn so hatte das frondend noch nicht funktioniert...

Wer demnächst mal das aus dem CVS ausprobieren.

- GMo -

[gmo18t]

Hi,

so, hab jetzt den neusten CVS Kram getestet. Aber leider nur "ein Kanal nicht verfügbar" geerntet.

Die Treiber wurden alle erfolgreich geladen und das "attach" durch "dbox2_napi" ist auch durchgelaufen.

Jetzt bräuchte ich ein paar Tips zur weiteren Vorgehensweise, wie ich dem Problem am Besten auf die Spur komme, z.B.:
- kann ich zapit oder Ähnliches zum Testen verwenden (wie) ?
- welche Logs könnten was hergeben ?
- kann ich irgendwo sinnvolle "debug -prints" aktivieren / einbauen ?
- mach ich sonst noch was falsch, evtl. passt neutrino-Kram noch nicht zum 2.6er frontend ?
- usw.

- GMO -

[Npq]

Naja, ich verwende da eigentlich nur Enigma, aber mit Neutrino funktioniert es auch.

Ich hab mich selber noch nie mit Kabel-Frontends beschäftigt, das Datenblatt zum Demod gibt's ja von AMD (URL steht in der Headerdatei).

Aber eigentlich braucht man ja "nur" zu vergleichen was gegenüber vorher anders ist. Denn der 2.4er Treiber spielt ja sicherlich.

Am einfachsten wäre es wohl, erstmal den I2C-Bus Mitschnitt verglichen.

[gmo18t]

hab nun mal den at76c651er Kram mit dem aus 2.4er Kernel verglichen.

Für den 2.6er wurden ja die pll-Funktionen aus at76c561.c herausgenommen und
in "dbox2_pll.c" in etwas anderer Form wieder eingebaut.

Damit fehlen aber an bestimmten Stellen in "dbox2_pll_i2c_write()" 2 Aufrufe von "at76c651_writereg()",
die im 2.4er Treiber innerhalb der korrespondierenden Funktion "at76c651_pll_write()"
noch gemacht werden.

Ich will das hier mal mit entsprechenden Codeauszügen deutlich machen, wobei im 2.6er Kernel
bis zum Ende der Funktion "dbox2_pll_tua6010_set_freq()", genau das gleiche gemacht wird wie
in der korrespondierenden Funktion "tua6010_setfreq()" des 2.4er Kernels.

Am Ende der jeweiligen Funktion wird dann das entsprechende "pll_write" aufgerufen.

Und so sieht nun die 2.4er Version davon aus ("at76c561_pll_write()"):

Code: Alles auswählen

static int at76c651_pll_write(struct dvb_i2c_bus *i2c, u8 *buf, size_t len)
{
	int ret;
	struct i2c_msg msg =
		{ .addr = 0xc2 >> 1, .flags = 0, .buf = buf, .len = len };

	at76c651_writereg(i2c, 0x0c, 0xc3);  <---------------------

	ret = i2c->xfer(i2c, &msg, 1);

	at76c651_writereg(i2c, 0x0c, 0xc2);  <----------------------

	return (ret != 1) ? -EREMOTEIO : 0;
}

und hier die "generische" 2.6er Version ("dbox2_pll_i2c_write()"):

Code: Alles auswählen

int dbox2_pll_i2c_write(int i2c_addr, char *buf, int len)
{
	int ret;
	struct i2c_msg msg = {
		.addr = i2c_addr,
		.flags = 0,
		.buf = buf,
		.len = len
	};
	if (!adap){
		printk(KERN_ERR "dbox2_napi_pll: no i2c_adapter set\n");
		return -EIO;
	}
	ret = i2c_transfer(adap,&msg,1);
	if (ret!=1){
		printk(KERN_ERR "dbox2_napi_pll: error writing to i2c client\n");
		return -EIO;
	}
	return 0;	
}

wobei hier augenscheinlich vor und hinter "i2c_transfer()" jeweils ein Funktionsaufruf fehlt !

Da nun aber die pll-Funktionen nicht mehr in "at76c651.c" drin sind, läßt sich die fehlende Funktion "at76c651_writereg()"
innerhalb von "dbox2_pll.c" nicht mehr so einfach verwenden, da sie ja von "extern" nicht zugreifbar ist.

Ist das nun überhaupt relevant oder wird da was an anderer Stelle getrickst, um das wieder auszugleichen ???

- GMo -

[gmo18t]

hab jetzt doch ne Stelle gefunden, wo die Aufrufe noch gemacht werden, nämlich in Funktion "at76c651_set_parameters()".

Das macht das obige Posting wohl hinfällig

- GMo -

[Npq]

Das ist das was in dem PLL-Source-File ganz oben beschrieben steht. Die Demods reichen quasi den I2C-Bus (sind ja nur 2 Drähte) an das PLL-IC weiter (in der Box liegt das PLL-IC normalerweise unter dem silbenen Blechmantel des Frontends und damit in direkter Nähe zum Demod).

Der I2C-Bus ist so konzipiert, daß immer alle Geräte (Clients) mithorchen. Da der PLL-IC-Bereich aber relativ kritisch ist was hochfrequente Schwingungen angeht (der I2C-Bus wird nur mit 100 kHz betrieben, aber Rechteckschwingungen produzieren ja bekanntlich ein Spektrum analog der sinc-Funktion), schaltet man den Bus nur während der Programmierung des PLL-ICs frei.

Wenn das übrigens schief gehen würde, dann wären Einträge im Log, daß das PLL-IC nicht programmiert werden konnte, weil der I2C-Bus-Treiber merkt, wenn ein Client nicht antwortet.

Wenn PLL programmiert wird und trotzdem nix geht, dann kann eigentlich nur irgendwo ein Parameter fehlen/falsch sein.

Es sieht wohl auch so aus, daß der atmel-Treiber bislang nur von der dbox2 überhaupt benutzt wird. Also wenn da ein grundsätzlicher Fehler drin wäre, dann wärst du momentan der einzige, der ihn überhaupt bemerken würde.

[gmo18t]

Hi,

so, hab mein code-review nun beendet, dabei ist mir nur eine Fehler aufgefallen (ohne den es leider auch nicht geht):

Code: Alles auswählen

struct dvb_frontend* at76c651_attach(const struct at76c651_config* config,
                                     struct i2c_adapter* i2c)
{
        struct at76c651_state* state = NULL;

        /* allocate memory for the internal state */
        state = (struct at76c651_state*) kmalloc(sizeof(struct at76c651_state),
        if (state == NULL) goto error;

        /* setup the state */
        state->config = config;
        state->qam = 0;

        /* check if the demod is there */ <----- "state->ic2" noch nicht initialisiert !!!
        if (at76c651_readreg(state, 0x0e) != 0x65) goto error;

        /* finalise state setup */
        state->i2c = i2c;   <-------- muss schon früher sein (siehe oben)
        state->revision = at76c651_readreg(state, 0x0f) & 0xfe;
        memcpy(&state->ops, &at76c651_ops, sizeof(struct dvb_frontend_ops));

wie im Code Ausschnitt zu sehen mußte "state->ic2 = ic2" schon vor dem 1. "at76c651_readreg()" kommen, anstelle vor dem 2.
Das kann eien "error" situation ergeben...

Das hab ich dann verbessert und auch ne Menge "printk's" scharf gemacht. Die Initilaisierung beim Laden der Treiber wird korrekt in allen Bereichen gemacht.
Deshalb hier nur mal der Log-Auszug für's Kanalumschalten (das dprintk für IC2-Interrupt hatte ich deaktiviert, um die Log-Flut einzudämmen):

Code: Alles auswählen

...
at76c651: at76c651_get_tune_settings
at76c651: at76c651_set_parameters: pll-set
[i2c-8xx]: addr:=d, flags:=0, len:=2 num:=1
[i2c-8xx]: LAST SEND
[i2c-8xx]: PARSE SEND MSG OK
[i2c-8xx]: intrspeed:=0
dbox2_pll_tua6010_set_freq: freq=394000000
dbox2_pll_i2c_write
[i2c-8xx]: addr:=61, flags:=0, len:=4 num:=1
[i2c-8xx]: LAST SEND
[i2c-8xx]: PARSE SEND MSG OK
[i2c-8xx]: intrspeed:=5
[i2c-8xx]: addr:=d, flags:=0, len:=2 num:=1
[i2c-8xx]: LAST SEND
[i2c-8xx]: PARSE SEND MSG OK
[i2c-8xx]: intrspeed:=2
at76c651: at76c651_set_symbol_rate: 6900000
[i2c-8xx]: addr:=d, flags:=0, len:=2 num:=1
[i2c-8xx]: LAST SEND
[i2c-8xx]: PARSE SEND MSG OK
[i2c-8xx]: intrspeed:=0
[i2c-8xx]: addr:=d, flags:=0, len:=2 num:=1
[i2c-8xx]: LAST SEND
[i2c-8xx]: PARSE SEND MSG OK
[i2c-8xx]: intrspeed:=1
[i2c-8xx]: addr:=d, flags:=0, len:=2 num:=1
[i2c-8xx]: LAST SEND
[i2c-8xx]: PARSE SEND MSG OK
[i2c-8xx]: intrspeed:=1
[i2c-8xx]: addr:=48, flags:=1, len:=1 num:=1
[i2c-8xx]: LAST RECV
[i2c-8xx]: intrspeed:=0
at76c651: at76c651_set_qam: quam = 3
[i2c-8xx]: addr:=d, flags:=0, len:=2 num:=1
[i2c-8xx]: LAST SEND
[i2c-8xx]: PARSE SEND MSG OK
[i2c-8xx]: intrspeed:=0
[i2c-8xx]: addr:=d, flags:=0, len:=1 num:=2
[i2c-8xx]: PARSE SEND MSG OK
[i2c-8xx]: addr:=d, flags:=1, len:=1 num:=2
[i2c-8xx]: LAST RECV
[i2c-8xx]: intrspeed:=0
at76c651: at76c651_set_inversion: inversion = 2
[i2c-8xx]: addr:=d, flags:=0, len:=2 num:=1
[i2c-8xx]: LAST SEND
[i2c-8xx]: PARSE SEND MSG OK
[i2c-8xx]: intrspeed:=1
at76c651: at76c651_set_auto_config: revision=0x10
[i2c-8xx]: addr:=d, flags:=0, len:=2 num:=1
[i2c-8xx]: LAST SEND
[i2c-8xx]: PARSE SEND MSG OK
[i2c-8xx]: intrspeed:=1
[i2c-8xx]: addr:=d, flags:=0, len:=2 num:=1
[i2c-8xx]: LAST SEND
[i2c-8xx]: PARSE SEND MSG OK
[i2c-8xx]: intrspeed:=1
[i2c-8xx]: addr:=d, flags:=0, len:=2 num:=1
[i2c-8xx]: LAST SEND
[i2c-8xx]: PARSE SEND MSG OK
[i2c-8xx]: intrspeed:=0
[i2c-8xx]: addr:=d, flags:=0, len:=2 num:=1
[i2c-8xx]: LAST SEND
[i2c-8xx]: PARSE SEND MSG OK
[i2c-8xx]: intrspeed:=0
[i2c-8xx]: addr:=d, flags:=0, len:=2 num:=1
[i2c-8xx]: LAST SEND
[i2c-8xx]: PARSE SEND MSG OK
[i2c-8xx]: intrspeed:=0
[i2c-8xx]: addr:=48, flags:=1, len:=1 num:=1
[i2c-8xx]: LAST RECV
[i2c-8xx]: intrspeed:=0
[i2c-8xx]: addr:=d, flags:=0, len:=2 num:=1
[i2c-8xx]: LAST SEND
[i2c-8xx]: PARSE SEND MSG OK
[i2c-8xx]: intrspeed:=0
[i2c-8xx]: addr:=d, flags:=0, len:=2 num:=1
[i2c-8xx]: LAST SEND
[i2c-8xx]: PARSE SEND MSG OK
[i2c-8xx]: intrspeed:=0
at76c651: at76c651_disable_interrupts
[i2c-8xx]: addr:=d, flags:=0, len:=2 num:=1
[i2c-8xx]: LAST SEND
[i2c-8xx]: PARSE SEND MSG OK
[i2c-8xx]: intrspeed:=0
at76c651: at76c651_reset
[i2c-8xx]: addr:=d, flags:=0, len:=2 num:=1
[i2c-8xx]: LAST SEND
[i2c-8xx]: PARSE SEND MSG OK
[i2c-8xx]: intrspeed:=1
at76c651: at76c651_read_status
[i2c-8xx]: addr:=d, flags:=0, len:=1 num:=2
[i2c-8xx]: PARSE SEND MSG OK
[i2c-8xx]: addr:=d, flags:=1, len:=1 num:=2
[i2c-8xx]: LAST RECV
[i2c-8xx]: intrspeed:=1
[i2c-8xx]: addr:=48, flags:=1, len:=1 num:=1
[i2c-8xx]: LAST RECV
[i2c-8xx]: intrspeed:=0
...

Da taucht überhaupt keine Fehlermeldung auf, alles prima - aber es geht einfach NICHT !

Ich hab auch so weit wie möglich den Ablauf der einzelnen Funktionen von 2.4 und 2.6 verglichen. Da geht eigentlich dasselbe ab. Auch der at76c651 Treiber ist hinter seinem "Interface" genauso wie der vom 2.4er, keine andere Registerwerte, keine unterschiedlichen I2C Kommandos ...

... ich fass es nicht

Ja, daß der at76c651 sonst nirgendwo benutzt wird hab ich auch schon festgestellt, somit scheint auch niemand zu wissen, ob der Treiber in Zusammenhang mit 2.6 - egal mit welcher Archiitektur - überhaupt geht !?

Und mit der CPU-Load bei Netz I/O hab ich bis jetzt auch keinen blassen Schimmer

- GMo -

[gmo18t]

Beitrag wieder gelöscht, da ich mich geirrt habe ...

- GMo -

[Npq]

Bist du sicher, daß kein Lock erfolgt oder leitest du das nur aus dem nicht-vorhandenen Bild ab?

Weil, ich hatte am Anfang auch mal einen Lock aber kein Bild, wobei das dann an einem Problem im Demux-Treiber lag (RISC stürzte dank nicht initialisierter Werte ab).

Das mit dem i2c->state ist allerdings ein offensichtlicher Bug und ich wundere mich, daß das keinen Oops gegeben hat.

[gmo18t]

Bist du sicher, daß kein Lock erfolgt oder leitest du das nur aus dem nicht-vorhandenen Bild ab?
...

bin mir eben nicht sicher, ich leite das nur aus dem nicht-vorhandnen Bild
und der neutrino Meldung "Kanal zur Zeit nicht verfügbar" ab !

Ich gehe davon aus, daß durch die Funktion "at76c652_read_status()"
ermittelt wird, in welchem Zustand sich der Tuner befindet, also ob er wirklich "lockt".

Also hab ich mir mal den dort per "at76c651_readreg()" gelieferten Wert (sync)
anzeigen lassen ...
... und siehe da, er hat die Bits "HAS_SIGNAL:HAS_CARRIER:HAS_VITERBI:HAS_SYNC:HAS_LOCK"
alle gesetzt - also full house !!!

Das sollte doch eindeutig Empfang vorhanden bedeuten - oder nicht ?

Und wenn Du schon sagst, daß dies auch evtl. am Demux o.ä. liegen könnte ...
Ich weiß nur nicht recht wie das Zusammenspiel funktioniert.
Vielleicht kannst Du mir noch einige Fragen dazu beantwortden, damit
ich mein Wissen etwas erweitern kann.

Zuerst will ich aber mal resümieren, was ich bisher für ein Bild von der Funktions-
weise habe, was du dann - falls erforderlich - korrigieren kannst.

1. Es gibt einen "PLL" und einen "Demod", beides Clients am i2c-Bus des MPC821,
wobei die beiden aber in punkto "Nutzsignal" fest verdrahtet sind
(da gibt's Nichts an/aus o.ä. zu schalten).

2. Das Tunen läuft nun so (alles per i2c-Kommandos), daß zuerst der PLL seine Frequenz
bekommt (der weitergereichte i2c-Bus wird nur dazu kurzzeitig aktiviert),
dann wird Symbolrate, QAM, Inversion usw. an den Demod gesendet (i2c-Bus
dorthin ist immer aktiv), dann erfolget "Autoconfig" auf den Demod mit
"disable interrupts" (warum ?) und "reset" (warum ?).

3. Danach sollte "getuned" sein, was durch Aufruf von "read_status" überprüft wird.

Nun zu meinen Fragen:

1. Die Steuerung habe ich ja so grob durch, wie sieht es nun mit den "Nutzdaten" aus ?
Der Weg von Antenne zum PLL und weiter zum Demod scheint klar !?
Jetzt sollten aber doch digitale Daten aus dem Demod raussprudeln (sofern richtig getuned) ?

2. Ist es nun der Demux, der diese Daten anfordert und wie verläuft der Austausch (über DMA ins
RAM, über I/O-Register oder wie) ?

3. Wenn der Demux keine Daten braucht, was passiert dann mit den "Nutzdaten",
die per Antenne in den Tuner "reinschießen" ?

4. In welchen source files soll ich jetzt mal reinschauen, um das mit dem demux zu prüfen ?

Ich hoffe, daß es Dir nicht zuviel Mühe macht, mich noch weiter zu unterstützen. Aber leider kenn
ich mich mit DVB noch nicht so arg gut aus (aber beim Rumwurschteln lern ich schon einiges
dazu, wenn auch meist Frust vorherrscht).

- GMo -

[gmo18t]

Hi,

was mir noch so nebenbei aufgefallen ist:

manchmal, wenn ich "top" auf der Box mit 2.6er kernel starte, wird kurz eine Zeile wie
"unknown HZ value! (90) assuming 100" ausgegeben !
(der Wert in Klammern variert und ist nicht jedesmal 90).

Dieses "HZ" ist eigentlich in "include/asm-ppc/param.h" und kann entweder "1000" (#if __KERNEL__) oder "100" sein - oder gibt's da noch en andres include ...

In den dbox-Treibern wird ja reichlich Gebrauch von HZ gemacht. Und gerade mit dem 2.6er Kernel wurde ja auch dieser HZ Wert von 100 (im 2.4er) auf 1000 geändert.

Hab mal den Wert für HZ in einem dbox-Treiber ausgegeben -> der ist 1000 !

Ob nun noch alle Timings passen ?

- GMo -

[Npq]

Ich gehe davon aus, daß durch die Funktion "at76c652_read_status()"
ermittelt wird, in welchem Zustand sich der Tuner befindet, also ob er wirklich "lockt".

Korrekt, wenn da "lock" kommt, dann ist alles OK.

Und wenn Du schon sagst, daß dies auch evtl. am Demux o.ä. liegen könnte ...

Das sollte nur ein Hinweis sein, daß man aus einer Aussage der GUI nicht schließen kann, daß der FE-Treiber nicht spielt.

Die Zusammenfassung des Lock-Vorgangs ist so auch korrekt, gerade hier ist alles aber extrem hardwareabhängig, im Zweifelsfall sollte das im Datenblatt stehen, allerdings wollen die Firmen dir natürlich ihre SDK verkaufen, so daß Infos meist spärlich sind und/oder mit NDA verbunden.

1. Die Steuerung habe ich ja so grob durch, wie sieht es nun mit den "Nutzdaten" aus ?
Der Weg von Antenne zum PLL und weiter zum Demod scheint klar !?
Jetzt sollten aber doch digitale Daten aus dem Demod raussprudeln (sofern richtig getuned) ?

Demod -> Alphacam -> Demux über ein 8-Bit Interface. Das wird nirgends mehr zwischengespeichert. Der Alphachip muß allerdings funktionieren.

Der Demux hat einen Teil, der sich "Framer" nennt. Der liefert dem ucode die Daten formatiert. Eigentlich geht alles durch den ucode, wenn der aber eine PID bekommt, die ihn nicht interessiert, dann verwirft er einfach den Rest des TS-Pakets.

Die genaue Funktion des Framers kennt nur C-Cube, das ist direkt in Hardware gegossen.

Prüf aber lieber erstmal, ob die Anwendungen auch wirklich das "Lock"-Signal bekommen!

Die DVB API speichert die Events vom FE in einem Puffer und die Anwendung liest diese Daten aus. Mir ist nicht ganz klar was da schiefgehen sollte aber man weiß nie.

Ich hab damit allerdings keine Probleme und der Fehler im Demuxcode ist schon lange gefixt.

[Npq]

manchmal, wenn ich "top" auf der Box mit 2.6er kernel starte, wird kurz eine Zeile wie
"unknown HZ value! (90) assuming 100" ausgegeben !

Guck mal in den Source von den pstools, da ist nen Kommentar drin zu den HZ. Das wird über eine aufwendige Funktion errechnet. Daß es schiefgeht, liegt sicherlich daran, daß das aus 2.4er Zeiten stammt.

Aber selbst beim 2.4er ging das schon schief, weil die /proc/cpuinfo beim powerpc etwas anders formatiert war als beim i386.

[gmo18t]

Hi,

weiteres "debuggen" zeigt nun folgendes Bild:

Code: Alles auswählen

zapit.cpp:parse_command:551] cmd 8 (version 7) received
[zapit.cpp:zapit:204] tuned_transponder_id:  e10044d0001
[audio.cpp:stop:100] ioctl(fd, AUDIO_STOP)
[video.cpp:stop:87] ioctl(fd, VIDEO_STOP)
[frontend.cpp:setFrontend:190] ioctl(fd, FE_SET_FRONTEND, feparams)
[frontend.cpp:getEvent:221] ioctl(fd, FE_GET_EVENT, &event)
[frontend.cpp:getEvent:221] ioctl(fd, FE_GET_EVENT, &event)
[frontend.cpp:getEvent:226] FE_HAS_LOCK: freq 394000000
[zapit.cpp:zapit:332] looking up pids for channel_id      43700016d66
[dmx.cpp:sectionFilter:149] ioctl(fd, DMX_SET_FILTER, &sctFilterParams)
[dmx.cpp:read:184] read(fd, buf, n): Connection timed out
[zapit.cpp:zapit:337] pat parsing failed
[zapit.cpp:parse_command:1294] cmd 8 processed

Tuner Treiber sollte somit ja ok sein, den auch BER, SNR usw. sehen wie erwartet (und wie mit 2.4) aus.

Daß mit dem "ves1x93" alles läuft, hatte mich halt annehmen lassen: "der at76c561-Treiber
passt noch nicht , aber das Drumherum ist ja schon ok !"

Nur macht sich bei den Sagem C-Boxen scheinbar ein Fehler bemerkbar, der im Zusammenhang mit
dem Demuxer stehen könnte ?

Vielleicht hängt das ja auch vom Typ (eNX oder GTX) und/oder ucode ab.

Ich habe 3x Sagem-C mit eNX und benutze die interne ucode ohne "hwsection filtering"
und ohne watchdog -> bei allen das gleiche (Miss-)Verhalten (spielen mit 2.4er aber einwandfrei).

Wie sieht es bei Dir aus NPQ ?
Hast du die Kombination eNX und interne ucode auch prüfen können ?

Da der Demuxer ja ein ziemliches "Biest" ist, glaub ich kaum, daß ich da jetzt weiter komme,
obwohl ja nur noch eine "kleine Lücke" zu kitten wäre. Denn das TS-Abspielen mit dem Movieplayer
geht ja und der Tuner liefert soch auch an !?

- GMo -

[gmo18t]

Guck mal in den Source von den pstools, da ist nen Kommentar drin zu den HZ. Das wird über eine aufwendige Funktion errechnet. Daß es schiefgeht, liegt sicherlich daran, daß das aus 2.4er Zeiten stammt.

Aber selbst beim 2.4er ging das schon schief, weil die /proc/cpuinfo beim powerpc etwas anders formatiert war als beim i386.

daß "top" eventuell nicht ganz so geschmeidig ist, wie erwartet, war weniger mein Anliegen.

Ich wollte nur mal wissen, inwieweit die Timings der dbox-Treiber von HZ abhängig sind. Da ja im 2.4er "HZ=100" war und jetzt für die 2.6er Treiber mit "HZ=1000" gerechnet wird !
(An den entsprechendn Formeln innerhalb der dbox-Treiber hat sich ja nix geändert bzw. ist nix angepasst worden -> wäre das nicht nötig ?)

EDIT: mittlerweile hab ich raus, daß HZ die DBox-Treiber Timings nicht beinflußt ...

Also verstärkt sich nun meine Vermutung, daß keine Daten in den/die Demuxbuffer reinkommen, folglich auch nix gelesen werden kann und ein read-Timeout erfolgt ...
Nur wie hängt das zusammen - Frontend spuckt was aus, aber es kommt im Demux nix an - ich versteh's nicht.

- GMo -

[Npq]

Mir fällt auf die Schnelle leider auch nichts ein. Die Hardware von C-Cube ist recht anspruchsvoll, speziell der eNX. Manchmal hilft alles nichts und man muß wirklich Schritt für Schritt vergleichen wo genau der Unterschied liegt.

Leider würde es auch nicht helfen, wenn ich eine Sagem-C hier hätte, weil der nächste Kabelanschluß hunderte von Metern wegliegt.

Ich habe mit dem Framer da keine Probleme (0014er ucode), weder auf dem GTX noch auf dem eNX.

[gmo18t]

Hi,

//ahh - "Posten" geht ja wieder //

werd mir mal noch die Sachen mit dem CAM anschauen, aber dann ist Schluß ...

@NPQ:
danke nochmals für die Unterstützung, bin weiterhin für jede Idee dankbar.

- GMo -

[gmo18t]

Hi,

leider auch keine Unregelmäßigkeiten beim CAM zu entdecken.
Firmware wird geladen, auch ohne Fehler "geschrieben" und der camd2 läuft vor sich
hin und meldet schön , wenn Karte gezogen/gesteckt wird !

Dann noch mit "dvbsnoop" rumgespielt ...

damit läßt sich alles aus dem Transponder rausziehen, ohne Probleme:
PAT, PMTs, BAT, NIT, Audio, Video, EPG ... alles da !!!

Wieso gibt's dann "Kanal nicht verfügbar" in neutrino. Das ist doch auch nur APP-Software
genau wie dvbsnoop ???

- GMo -

[Npq]

Hast du sections- oder TS-basiert gefiltert?

Möglicherweise betrifft es die ucode sections-Filter.

[gmo18t]

Hast du sections- oder TS-basiert gefiltert?

Möglicherweise betrifft es die ucode sections-Filter.

hab nur mit default (-s sec) gespielt, also nicht TS-basiert gefiltert !
Könnte das die ucode Problematik erhärten ?!
Soll ich mal verschiedene ucodes ausprobieren ?

- GMo -

[gmo18t]

Es geeeht !!!!

Nachdem ich festgestellt habe, daß zapit zum Einlesen von PAT/PMT im Grunde nix anderes macht wie dvbsnoop, außer defaultmäßig die Filter mit "ONESHOT und CRC" anlegt, hab ich dem zapit in "apps/dvb/zapit/src/zapit/zapost/dmx.cpp" einfach mal die Filter flags gestutzt:

Code: Alles auswählen

int CDemux::sectionFilter(const unsigned short pid, const unsigned char * const
{
        struct dmx_sct_filter_params sctFilterParams;

        memset(&sctFilterParams, 0, sizeof(struct dmx_sct_filter_params));
        memcpy(&sctFilterParams.filter.filter, filter, DMX_FILTER_SIZE);
        memcpy(&sctFilterParams.filter.mask, mask, DMX_FILTER_SIZE);

        sctFilterParams.pid = pid;
//      sctFilterParams.flags = DMX_ONESHOT | DMX_CHECK_CRC | DMX_IMMEDIATE_STA
        sctFilterParams.flags = DMX_IMMEDIATE_START;  // <----------
...

ja - nun spielt es ...
Das ONESHOT ist nicht an dem Problem beteiligt, soweit ich das getestet hab, ist es ganz allein das CRC-Flag !

@npq:
Hab jetzt noch nicht viel mehr ausprobiert, ob's Nebenwirkungen hat o.ä.
Aber vielleicht fällt Dir ja jetzt ein, wo da in den Treibern was fehlinterpretiert wird. Kenn mich halt nicht genug aus mit diesem CRC im Zusammenhang mit dem Tuner ...

- GMo -

[gmo18t]

und immer weiter wird der Fehler eingekreist ...

scheinbar verwenden alle (außer mir) das "hardware section filtering". Denn mit einem "ungepatchten" zapit geht jetzt auch alles, wenn ich eben "hardware section filtering" verwende (was ich bisher nie gemacht habe).

Hätte doch gleich jemand sagen sollen, daß man das mit 2.6er nicht abschalten darf

Nun deutet das darauf hin - soweit ich die Sourcen dahingehend überflogen habe - daß bei "software section filtering" die Funktion "crc32_be()" des Kernels (scheinbar wird ja i.d. Fall diese verwendet) der Übeltäter ist.

Inwieweit, die sich nun im Vgl. zum 2.4er anders verhält, müßte man mal nachschauen.

- GMo-

[ChakaZulu]

hi,

auch wenn ich nichts zur Lösung dieser Probleme beitragen kann:
schön, dass Du solche Fortschritte machst und am Ball bleibst!

ciao,

ChakaZulu