Neueste Treiber -> schlechter Scan

[rasta12]

Hallo,
ich wollte nur mal eine Resonanz geben, die zwar zugegebenermassen nicht positiv ist, aber vielleicht hilft es ja.
Also, ich hatte folgendes Problem:
Ein Senderscan unter Neutrino, eben mit der zapit, ergab bei:

Astra 63 Transponder /911 Kanäle Gesamt
Eutelsat 21 Transponder /gefundene Kanäle nicht erwähnenswert.

das Ganze mit SMATV Remote Tuning auf einer Philips.

So ging es dann eben nicht weiter, also habe ich ein wenig downgegraded und komme nun mit folgenden Treibern zu:

Astra 63 Transponder /911 Kanäle Gesamt
Eutelsat 84 Transponder /1023 Kanäle Gesamt
------------------------------------------------------
Overall 147 Transponder / 1934 Kanäle Gesamt

O.K. Meine Satellitenanlage ist eine 1 m Schüssel mit 2 schielenden LNC auf einer Schiene und folgendem Multischalter:
http://www.satshop2000.de/pd-1863991007.htm ( also nichts besonderes )

Das diff zu den jetzigen Treibern des CVS ( 30.10 ) mit denen es nun geht sieht so aus:

Ich habe das mal wieder rausgenommen, weil obi jetzt Bescheid weiss und ich immer dagegen bin, die Threads so zuzumüllen.

Ich hoffe hiermit alle benötigten Angaben gemacht zu haben und hoffe das es euch hilft.
Gruss
Rasta12

[obi]

die einzige evtl. relevante aenderung ist fuer dich:
-static int debug = 0;
+static int debug = 1;
(im tda0844.c)

probier mal bitte.

smatv remote tuning ist absolut falsch fuer ein normales 2 lnc setup.

[rasta12]

die einzige evtl. relevante aenderung ist fuer dich:
-static int debug = 0;
+static int debug = 1;
(im tda0844.c)

probier mal bitte.

smatv remote tuning ist absolut falsch fuer ein normales 2 lnc setup.

Glaub mir, anders geht es aber gar nicht.
Mini-DiSEqC, DiSEqC 1.0, oder DiSEqC 1.1 scannen z.T. gar nicht auf Eutelsat, bzw. nicht viel mehr. Ich musste bisher immer SMATV nehmen, damit ging es. Versteh ich zwar auch nicht, aber es ist eben erfahrungsgemäss so.
Ehrlich.
Also, diese Scannerei dauert ja immer "Stunden" <grins>, daher bin ich eigentlich zu faul die Debugmeldungen nochmal einzuschalten, aber wenn du möchtest, dann mach ich es natürlich, wenn es hilft. Ich schreib dir auch noch gerne mehr dort rein.....
Klar ist nur der tda0844 für mich relevant. Nur zum Zurückschrauben waren eben die anderen Sachen auch notwendig.

Gruss
Rasta12

[Sepp776]

Tatsächlich, bei mir funktioniert es auch mit SMATV Remote Tuning! *megafreu* (...aber auch nur mit den alten Treibern).

Total bescheuert, die einzige Option die ich nie ausprobiert habe

Thx rasta12!

Bye,
Sepp.

[obi]

mich interessieren keine debug ausgaben... es geht darum, ob bei debug=1 es besser funktioniert oder nicht.

wenn smatv zeugs geht, dann muss diseqc 1.0 auch gehen...
es wird dann lediglich ein zusaetzliches kommando gesendet, das euere schalter ignorieren. siehe diseqc spezifikationen auf http://www.eutelsat.com

[rasta12]

@obi,
dann klär mich doch mal bitte auf. Also für mich erreicht:
static int debug = 0;
zu
static int debug = 1;
das eben #define dprintk if (debug) printk
und das dann diese Ausgaben kommen.
dprintk("%s: writereg error ""(reg == 0x%02x, val == 0x%02x, ret == %i)\n",
dprintk("%s: readreg error (ret == %i)\n", __FUNCTION__, ret);
dprintk("%s: i2c xfer error (ret == %i)\n",__FUNCTION__, ret);
dprintk("%s: i2c xfer error (ret == %i)\n", __FUNCTION__, ret);

Ausser nem zusätzlichem delay durch die Ausgaben passiert da für mich nichts.

Bitte um Aufklärung, weil es mir zu dumm ist etwas blind zu machen und ich lernen will mir selber helfen zu können.. Sorry.
.. und der debug kann eben auch dem Modul beim Laden übergeben werden. Wenn ich also helfen soll, was ich möchte, dann bitte nicht als dummer hiwi <grins>, sondern mit etwas Aufklärung. Danke.

Manchmal muß ein Treiber eine sehr kurze Verzögerung berechnen, um sich mit der Hardware zu synchronisieren. In diesem Fall ist jiffies keine Lösung.
Die Kernel-Funktionen udelay und mdelay dienen diesem Zweck.[1] Ihre Prototypen lauten:
#include <linux/delay.h>
void udelay(unsigned long usecs);
void mdelay(unsigned long usecs);
Die Funktionen werden auf den meisten Architekturen inline kompiliert. Die erste Funktion verwendet eine Software-Schleife, um die angegebene Anzahl von Mikrosekunden zu warten, die zweite ist eine Schleife um udelay, die aus Bequemlichkeitsgründen eingeführt wurde. In udelay wird der BogoMips-Wert verwendet: Die Funktion benutzt den Integer-Wert loops_per_second, der wiederum das Ergebnis der BogoMips-Berechnung beim Booten ist. Der udelay-Aufruf sollte nur für sehr kurze Intervalle verwendet werden, weil die Präzision von loops_per_second nur 8 Bits beträgt und sich bei der Berechnung langer Verzögerungen spürbare Fehler ansammeln. Auch wenn die maximal zulässige Verzögerung fast eine Sekunde beträgt (weil die Berechnungen bei längeren Verzögerungen überlaufen), ist der empfohlene Maximalwert für udelay 1000 Mikrosekunden (eine Millisekunde). Die Funktion mdelay hilft, wenn die Verzögerung länger als eine Millisekunde dauern muß.
Es ist auch wichtig, nicht zu vergessen, daß udelay (und damit auch mdelay) eine Busy-Waiting-Funktion ist und da? andere Tasks in der Zwischenzeit nicht laufen können. Sie müssen daher (besonders mit mdelay) sehr vorsichtig sein und diese Funktionen nur verwenden, wenn Sie keine andere Möglichkeit haben.

Vielleicht liegt es eher hier.
@@ -150,7 +160,7 @@
#endif
tda8044_writereg(i2c, 0x00, 0x08); /* Reset AFC1 loop filter */

- mdelay(10);
+ udelay(10000);

tda8044_inittab[0x00] = 0x00; /* 0x04: request interrupt */
tda8044_inittab[0x0F] = 0x50;
Ich glaube nämlich nicht, dass nach o.g. Beschreibung
mdelay(10) = udelay(10000) ist. Nach milli und mikro eben.

MfG
p.s.: Bitte nicht falsch verstehen, aber man muss immer allen alles aus der Nase ziehen. Dann forscht man besser für sich selber bis es geht. Wenn man euren Weg einschlagen soll, dann muss auch von euch mehr kommen.

[Npq]

Hmm, also gehen wir mal kurz offtopic.

Die Erklärung oben ist etwas mißverständlich. Sie hört sich so an, als ob mdelay dafür da wäre, die Präzision zu erhöhen. Das stimmt nicht.

mdelay sorgt nur dafür, daß der an udelay übergebene Wert nicht zu groß wird, da er auf die loops_per_jiffies (nicht loops_per_second) bezogen wird und bei der Berechnung ansonsten ein Überlauf stattfinen könnte (wenn die BogoMIPS des Prozessors sehr groß sind, was sie bei der 2er leider nicht sind ).

mdelay ist wirklich nur eine Schleife von udelay, die man aber nehmen sollte, um sicherzugehen (Portabilität). Übrigens wird sie sogar wegoptimiert auf udelay, solange der Faktor kleiner gleich 5 ist. (Also spielt es z.Bsp. keine Rolle, ob man udelay(5000) oder mdelay(5) nimmt, es kommt das Gleiche raus)

Die Beschränkung der Präzision von jiffies_per_loop auf 8-Bit ist aber immer vorhanden. Genaueres siehe Kernelsourcen (init/main.c).

So, und wieder ontopic

Npq

[rasta12]

Nee, Danke Npq, ich fand, dass das nicht offtopic war. Ich will doch wissen, bzw. erforschen woran es liegen könnte, dass ich mit den neuen Treibern bei keiner Einstellung einen vernünftigen scan bekomme.

also ist es doch so das mdelay(10) = udelay(10000) ist.

Na gut, dann habe ich falsch vermutet, bzw. etwas Falsches gelesen..
MfG

[thegoodguy]

@rasta12:
Ich finde obi hat sich eindeutig ausgedrueckt.
Er versucht herauszufinden, wo genau der Fehler liegt (das diff ist doch recht lang).
Sein Tipp: Es sind die debug-Ausgaben.
Also solltest du versuchen den diff entweder selber zu reduzieren oder seinem Vorschlag folgen und die debug-Ausgaben anschalten und gucken ob es nun klappt.

[rasta12]

@rasta12:
Sein Tipp: Es sind die debug-Ausgaben.
Also solltest du versuchen den diff entweder selber zu reduzieren oder seinem Vorschlag folgen und die debug-Ausgaben anschalten und gucken ob es nun klappt.

Ich weiss aber nicht wozu es "nur" eines Tips bedarf, anstelle eines konkreten Hinweises, oder Fixes. Wenn ich es selber herrausbekommen soll, dann kann ich es mir eben demnächst sparen auf etwas aufmerksam zu machen.
Dann löse ich das Problem eben für mich allein. Wollte ja nur helfen und einen Austausch suchen, was ja wohl nicht gefragt zu sein scheint.
MfG

[thegoodguy]

Du schnallst es also immer noch nicht ...
Besorg' dir jemand, der fuer dich diesen Thread durchliest und dir erklaert, was dir Obi sagen will:

mich interessieren keine debug ausgaben... es geht darum, ob bei debug=1 es besser funktioniert oder nicht.

Wenn du keinen Bock hast konkrete Fragen zu beantworten (Austausch heisst nicht, dass der andere alles macht), dann bist du halt auf dich allein gestellt.

[rasta12]

Du schnallst es also immer noch nicht ...

mich interessieren keine debug ausgaben... es geht darum, ob bei debug=1 es besser funktioniert oder nicht.

gestellt.

Duu schnallst es nicht.
Meine Frage war: WARUM soll es dann besser funktionieren ????
Tut mir Leid, dass ich das nicht weiss.

Besorg' dir jemand, der fuer dich diesen Thread durchliest und dir erklaert, was dir Obi sagen will:

Den kannst du dir stecken. Ich glaube nicht, dass "ich" beleidigend geworden bin. Kann ich aber gerne: Noch so'n Besserwisser.

[thegoodguy]

Obi meint, dass der Rest deines diffs nicht die Ursache des Problems ist (und da du den diff geloescht hast, kann ich nur auf obi's aussage vertrauen - auch kennt er sich in seinem code viel besser aus):

die einzige evtl. relevante aenderung

Das ganze sieht doch nach 'nem timing-problem aus und auch Debugausgaben brauchen Zeit (die dbox ist schliesslich nicht sonderlich schnell).
Also aendert sich durch das rauswerfen der Debugausgaben das timing.
Deine Aufgabe ist es, herauszufinden, ob es daran liegen koennte - was hilft es stundenlang sich moegliche Erklaerungen aus den Fingern zu saugen und dann ist das Problem doch was ganz anderes???

[rasta12]

Danke schön .... ehrlich gemeint .....
Das ist eine Erklärung, mit der ich etwas anfangen kann.
Ich poste dann hier, was rausgekommen ist.
MfG

[Homar]

Rasta my friend...

Versuche doch zu verstehen, was oben gemeint ist, bevor du mit dem gemecker loslegst

Du gehst davon aus, das wenn ein Kommando an einen Treiber abgesetzt wird, dieser auch ausgeführt wird, bevor andere Userspace-Applikationen an der Codestelle weiter ausgeführt werden.
So ist es aber nicht !!!

Zapit gibt z.B. folgende Kommandos raus:
"Sende DiseqC kommando";
"Tuner tune auf eine Frequenz";
"Schaue nach, ob irgendein Signal anliegt"

Das Frontend ist aber vielleicht physikalisch gar nicht so weit, nachzuschauen ob schon ein Signal anliegt, weil es noch gar nicht hingetuned hat.
Genau an dieser Stelle greifen die Debugausgaben !!!
Diese Verzögern den Ablauf des ganzen.

Also was mit Debugausgaben funktioniert muss noch lange nicht richtig funzen, wenn mann diese Abschaltet.

??? Nun verstanden ???

Das einzig relevante an deinem diff sei, das die Debug-Ausgabe eingeschaltet ist.
Und damit könnte er recht haben.

MFG
Homar

[rasta12]

Danke,
ich habe es ja nun verstanden. Ich mecker doch gar nicht <unschuldig guck>

Ich will doch nur alles verstehen und obi hat ja recht. Es ist nur ein timing - Problem.

Also mit debug=1 mit den neuen Treibern.

SMATV
63/912
147/2032 beim 2ten Mal 1978 hmmmm. Meine Schüssel ist Sch.., oder es ist der Sonnensturm, oder was auch immer.

Mini-Diseque
48/111
49/112

Diseque1
63/912
147/denke das Selbe wie SMATV und Diseque1.1

Diseque1.1
63/912
147/1979

So, ich wollte doch nur helfen und verstehen. Menno. <grins>
..und ich zoll obi ersteinmal Respekt, dass er das sofort erkannt hat.
Gruss
rasta12

[Sepp776]

Hi rasta!
Verstehe ich das richtig, dass es bei dir immer beim 2. Mal funktioniert hat? Bei mir funktioniert es mit den Debug-Meldungen leider nicht - immer 63 Transponder, also nur Astra...

CU,
Sepp.

[obi]

ok, also der unterschied 1900 zu 2000 ist bestimmt auf zapits section handling zurueckzufuehren. probier mal enigma, ob das konstant scannt.

da die debugmeldungen zum erfolg fuehren, waere es jetzt schoen, wenn du stueck fuer stueck rausfinden koenntest, an welcher stelle welches printk() gebraucht wird (ist hoffentlich nur eine).

an der stelle kannst du dann udelay/mdelay einfuegen bis es stabil laeuft.

[rasta12]

Ich habe es jetzt so verändert......

Code: Alles auswählen

static int tda8044_write_buf(struct dvb_i2c_bus *i2c, u8 *buf, u8 len)
{
	int ret;
	struct i2c_msg msg = { .addr = 0x68, .flags = 0, .buf = buf, .len = len };

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

	if (ret != 1) {
		dprintk("%s: i2c xfer error (ret == %i)\n", __FUNCTION__, ret);
	}

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

So geht es bei der Philips.
------------------------------------------------
nach Neustart mit mdelay(5):
SMATV mit Wiederholungen 1
63/912
147/1807
-------------------------------------------------
nach Neustart mit mdelay(10):
SMATV mit Wiederholungen 1
63/912
147/1900 ( ist etwas wenig, aber das dürfte jetzt nicht am Treiber liegen, oder ?? )
Diseque1.1
63/912
147/1807 ( 2te Durchgang noch weniger )
-------------------------------------------------
nach Neustart mit mdelay(20):
SMATV mit Wiederholungen 0
63/912
147/1917
-------------------------------------------------
nach Neustart mit mdelay(30):
SMATV mit Wiederholungen 0
63/912
147/2050
-------------------------------------------------
Das lass ich jetzt so. Denke, dass das so O.K. ist und das Ergebnis auf Eutelsat eben aufgrund anderer Dinge noch differiert.

MfG
p.s.: 5 Stunden später. Jetzt versteh ich gar nichts mehr. Nachdem das so gut lief und immer höher ging wollte ich natürlich noch zur Absicherung mdelay(50) testen, um zu sehen, dass das eben nicht mehr besser wird und:
Es wurde nicht besser, also habe ich es zurückgestellt auf mdelay(30) und dann ergabe der erste Scan 109 Transponder und der 2te nur noch 86 Transponder. Also weiss ich jetzt gar nichts mehr. Habe die Box jetzt mal ganz aus gemacht und versuche es jetzt nochmal. Jetzt bekomme ich nur noch 84 Transponder auf Eutelsat. Bald habe ich gar keine mehr *lol* Jetzt 83. Ich hör jetzt auf. Das o.g. Ergebnis war heute vormittag. Wer weiss, was sich verändert hat.
21:23 Uhr
Nun geht es wieder. Das habe ich die letzte Zeit des öfteren gehabt. Am Tag schlecht und am Abend wieder besser. Lacht mich nicht aus, aber das muss wirklich mit dem Sonnensturm zusammenhängen. Sonne weg und gut.
Also nun wieder:
-------------------------------------------------
mit mdelay(30):
SMATV mit Wiederholungen 0
63/912
147/1997
-------------------------------------------------
Ich probier jetzt aber trotzdem
mit mdelay(50): -> Das muss ich wissen...
SMATV mit Wiederholungen 0
63/912
147/1986
Wird also nicht besser. Also mdelay(30) reicht.
Fettig

[Sepp776]

Edit:
nee, doch nicht. Ach alles Kappes hier


Ciao,
Sepp.

[rasta12]

Jetzt macht mich noch ein anderes Problem fertig. Ich kann keine Lautstärke mehr beim MP3-Player regeln.
Audio steht auf ost, weil avs gar nicht geht. Ausserdem kann man die Lautstärke nur im letzten drittel regeln.
Was kann ich da denn noch probieren.

Sorry, aber ich bin so ein Depp.
Wenn ich den Scartstecker auch im falschen Ausgang habe, dann soll das wohl so sein. So, jetzt geht auch avs wieder und der MP3-Player lässt sich auch regeln.
Nochmal Sorry.
MfG

[rasta12]

gelöscht