[gelöst] DVB-T Stick T119 unter Debian Testing

[retabell]

Hallo
eigentlich sieht das bei juno doch gut aus,
probieren kannst noch nen Sendersuchlauf auf Konsole:

Code: Alles auswählen

# apt-get install w-scan 
$ w_scan -M > ~/channels.conf

und gucken ob sich da was ergibt.

noch nen Link zu dem Problem:
http://www.mail-archive.com/linux-media ... 66574.html

bei u ist das auch erst in 3.11.6 drin.

hab jetzt nicht ganz verstanden ob juno testing oder wheezy hat,
bei kanotix gäbe es den 3.11.0-13.20 + obige siano patches gegen wheezy gebaut.

gruss retabell

[dillo]

noch nen Link zu dem Problem:
http://www.mail-archive.com/linux-media ... 66574.html

Sehr gut, danke!

While its fix was already upstream, the "error" messages there doesn't
help, as it induced people to believe that it was a firmware related
error.

@habakug: ich denke damit wird klar, dass auch du (sehr wahrscheinlich durch den 'falschen' Titel des Bugreports) in die Irre geleitet wurdest.
Die Meldungen aus junos dmesg sind, wie von mir vermutet, reine Debugausgaben und besagen nicht, dass das Laden der Firmware scheitert.

Da bei juno auch keine Kernel Panik auftritt scheint damit ein Kernel/Treiber-Update zumindest vorerst nicht zwingend nötig.

Code: Alles auswählen

# apt-get install w-scan 
$ w_scan -M > ~/channels.conf

und gucken ob sich da was ergibt.

Ist sicher einen Versuch wert, aber

[...]Signal 100% SNR 0%[...]

bei einem Signal-Rausch-Verhältnis von 0% habe ich keine großen Hoffnungen, dass bei einem Scan etwas rauskommt. Es könnte aber natürlich sein, dass der Treiber SNR gar nicht oder nicht richtig ausliest!

IMHO würde vielleicht doch

Würdest du mal vor dem Einstecken des Sticks ein

Code: Alles auswählen

 watch 'dmesg -T | tail -n 25'

absetzen und mit der Ausgabe, die nach dem Einstecken des Sticks dazukommt (also insgesamt 50 Zeilen) hier oder besser bei nopaste reinstellen.

neue Erkenntnisse bringen. Aber vielleicht hat juno auch schon die Lust verloren.....

[habakug]

Hallo!

Im Moment wissen wir ja weder, ob es mit einem sehr aktuellen Kernel klappt, noch, was hier los war:

Einige Male ist der PC eingefroren (Mauszeiger starr, keine Reaktion auf Tastatureingaben) als ich unter Kaffeine auf "Sendersuchlauf" geklickt habe...

Ebenso besteht die Möglichkeit, das ich mit meinem Pushen in Richtung "sehr neuer Kernel", hier nur den Verkehr aufhalte.
Hier nochmal ein anderer Blickwinkel [1] [2], wo dieser Entwickler mit einem ganz großen zusammenrasselt .

Gruss, habakug

[1] http://www.theregister.co.uk/2013/01/04 ... _bug_rage/
[2] https://lkml.org/lkml/2012/12/23/75

[juno]

Kurze Zwischeninfo von mir: TV-Empfang läuft einwandfrei unter Xubuntu 13.10. Für andere Tests war leider noch keine Zeit, aber der Ehrgeiz, das auch in Debian ans Laufen zu bekommen, ist noch da.
Und Vielen Dank an die vielen interessierten Helfer!!

Gruß,
juno

[habakug]

Hallo!

Das ist gut und so wie ich es vermutet hatte. In Xubuntu ist ein Kernel basierend auf "3.11.3". Hier mal der Vergleich der Sources jeweils von "kernel.org" in der Datei "smsdvb-main" unter "devices/media/common/siano".
Kernel 3.10.11

Code: Alles auswählen

/* Legacy PER/BER */
	tmp = p->ets_packets * 65535;
	do_div(tmp, p->ts_packets + p->ets_packets);
	client->legacy_per = tmp;

Kernel 3.11.3

Code: Alles auswählen

/* Legacy PER/BER */
	tmp = p->ets_packets * 65535;
	if (p->ts_packets + p->ets_packets)
		do_div(tmp, p->ts_packets + p->ets_packets);
	client->legacy_per = tmp;

Gruss, habakug

[juno]

Guten Abend,

ich habe jetzt etwas Zeit, weitere Voerschlaege von euch zur Problemloesung auszuprobieren.
Sobald ich weitere Tests durchfuehren konnte, werde ich sie hier per Edit ergaenzen.
Aufgrund der Laenge der Bildschirmausgaben und zum Zwecke einer gewissen Uebersichtlichkeit, habe ich die
Ergebnisse in NoPaste eingetragen.

Code: Alles auswählen

# apt-get install w-scan
$ w_scan -M > ~/channels.conf

Ergebnis siehe 37454

Code: Alles auswählen

 watch 'dmesg -T | tail -n 25'

Ergebnis siehe 37455

Code: Alles auswählen

$ wget -c kernel.ubuntu.com/~kernel-ppa/mainline/v3.11.5-saucy/linux-headers-3.11.5-031105_3.11.5-031105.201310132235_all.deb
$ wget -c kernel.ubuntu.com/~kernel-ppa/mainline/v3.11.5-saucy/linux-headers-3.11.5-031105-generic_3.11.5-031105.201310132235_amd64.deb
$ wget -c kernel.ubuntu.com/~kernel-ppa/mainline/v3.11.5-saucy/linux-image-3.11.5-031105-generic_3.11.5-031105.201310132235_amd64.deb
# dpkg -i linux-image-3.11.5-031105-generic_3.11.5-031105.201310132235_amd64.deb

erfolgreich durchgefuehrt, Kaffeine gestartet, Sender gefunden (SNR uebrigens weiterhin bei 0%)
allerdings beim Versuch einen Sender zu starten die Meldung "kein passendes Geraet gefunden", neuer Sendersuchlauf nicht moeglich.
Einfach mal nen reboot und nach neuem Suchlauf habe ich gerade Empfang und TV in Kaffeine
Ich traue dem Braten aber noch nicht 100%, daher werde ich das mal wachsam im Auge behalten...

[dillo]

@habakug: selbst auf die Gefahr hin, dass ich dich nerve..
(sei versichert, das wird mein letzter Post zu diesem Thema sein, dann geb' ich endlich Ruhe, OK?)

mir ging es einzig und allein darum, dass ich diese Auffassung als nicht teile:

@dillo
Auch wenn es auf den ersten Blick nicht so aussieht, ist das hier

Code: Alles auswählen

[ 1005.628559] usb 1-1.6: firmware: agent loaded dvb_nova_12mhz_b0.inp into memory
[ 1005.678454] smscore_load_firmware_family2: line: 986: sending MSG_SMS_DATA_VALIDITY_REQ expecting 0x52dbbeb5
[ 1005.680571] smscore_onresponse: line: 1563: MSG_SMS_DATA_VALIDITY_RES, checksum = 0x52dbbeb5

ein Kernel-Bug

Wenn ich mir den entprechenden Code bzw Patch anschaue:

Code: Alles auswählen

-	sms_err("sending MSG_SMS_DATA_VALIDITY_REQ expecting 0x%x",
+	sms_debug("sending MSG_SMS_DATA_VALIDITY_REQ expecting 0x%x",
 		calc_checksum);
 	SMS_INIT_MSG(&msg->x_msg_header, MSG_SMS_DATA_VALIDITY_REQ,
 			sizeof(msg->x_msg_header) +
@@ -1562,7 +1562,7 @@ void smscore_onresponse(struct smscore_device_t *coredev,
 		{
 			struct sms_msg_data *validity = (struct sms_msg_data *) phdr;
 
-			sms_err("MSG_SMS_DATA_VALIDITY_RES, checksum = 0x%x",
+			sms_debug("MSG_SMS_DATA_VALIDITY_RES, checksum = 0x%x",

kann ich das nicht anders interpretieren, als dass es hier um reine Logausgaben geht, die irrtümlich als *error* klassifiziert waren und jetzt debug-status haben.
Die Funktion des Moduls oder der Ladevorgang der Firmware wird durch den Patch aber doch absolut nicht beeinflusst.
Wenn nur dieser Patch in 3.11.x eingeflossen wäre, hätte juno unter Xubuntu 13.10 die gleichen Probleme wie mit seinem wheezy. Die Meldungen im log wären zwar weg, aber im Hintergrund würde das Gleiche ablaufen wie vorher.

@juno, würdest du bitte bei Gelegenheit

Code: Alles auswählen

 watch 'dmesg -Tl debug | tail -n 25'

(Stick draußen-Stick rein) mit dem neuen Kernel machen?
mit 'dmesg -l debug' werden auch debug-Ausgaben angezeigt und somit auch mit nem 3.11er diese beiden Zeilen:

Code: Alles auswählen

[ 1005.678454] smscore_load_firmware_family2: line: 986: sending MSG_SMS_DATA_VALIDITY_REQ expecting 0x52dbbeb5
[ 1005.680571] smscore_onresponse: line: 1563: MSG_SMS_DATA_VALIDITY_RES, checksum = 0x52dbbeb5

Hier nochmal ein anderer Blickwinkel [1] [2], wo dieser Entwickler mit einem ganz großen zusammenrasselt .

Ist nicht neu für mich. Ich kann dazu nur sagen: Torvalds Verdienste und Anspruch auf sauberen Code in allen Ehren, aber......der Ton macht die Musik...

@juno: besser kann's ja nicht sein. Jetzt hast du sogar zwei 'Linuxe', mit denen der Stick läuft

[juno]

N`abend nochmal...

mit dem neuen Kernel hat dann auch meine RADEON-Grafikarte wieder ihren proprietaeren Treiber verloren, allerdings schaffe ich es jetzt nicht mehr, den Treiber zu installieren.
Bei der Installation hat ein so funktioniert (Auszug aus meiner Installations-Doku):

Code: Alles auswählen

verwendeter Treiber: amd-catalyst-13.11-beta6-linux-x86.x86_64.zip 
http://www2.ati.com/drivers/beta/amd-catalyst-13.11-beta6-linux-x86.x86_64.zip
benoetigte Pakete: gcc make
apt-get install gcc make
Kernel Headers installieren
sudo apt-get install linux-headers-$(uname -r)
ZIP entpacken
Treiberdatei ausfuehrbar machen:
chmod +x ./amd-catalyst-13.11-beta6-linux-x86.x86_64.run
Treiberdatei starten
./amd-catalyst-13.11-beta6-linux-x86.x86_64.run
Reboot

Der Treiber spuckte dieses Fehlerlog aus 37456 die fehlenden Kernel-Headers konnte ich aber mit sudo apt-get install linux-headers-$(uname -r) nachinstallieren
jetzt habe ich dieses Problem:

Code: Alles auswählen

sudo apt-get install linux-headers-$(uname -r)
Paketlisten werden gelesen... Fertig
Abhängigkeitsbaum wird aufgebaut.       
Statusinformationen werden eingelesen.... Fertig
Package linux-headers-3.11.5-031105-generic is not available, but is referred to by another package.
This may mean that the package is missing, has been obsoleted, or
is only available from another source

E: Package 'linux-headers-3.11.5-031105-generic' has no installation candidate

Zur Info: die sources.list ist noch die gleiche wie waehrend der Installation

[habakug]

Hallo!

@dillo
Ich weiß nicht genau was du von mir hören, willst. Der von dir (des öfteren) zitierte Code betrifft, wie von dir auch erklärt wird, Debug-Meldungen. Für mich ist die damit zusammenhängende Ausgabe in dmesg lediglich ein Indikator dafür, das der für diesen Fall entscheidende Code noch nicht in der jeweiligen Kernel-Version ist.

linux-headers-3.11.5-031105-generic

Du hast da gerade den Ubuntu-Kernel in der Mangel, da passen die Debian-Header nicht dazu.

Gruss, habakug

[juno]

Du hast da gerade den Ubuntu-Kernel in der Mangel, da passen die Debian-Header nicht dazu.

Wie bekomme ich das gefixt ? TV per Kaffeine ist super, aber der Luefterlaerm der Grafikkarte mit dem freien Treiber ist lauter als TV

[habakug]

Hallo!

Ich hatte die Links zu den Header-Paketen doch mitgeliefert. Schau nochmal nach.

Gruss, habakug

[retabell]

Hallo!

ist ein Kernel basierend auf "3.11.3". Hier mal der Vergleich der Sources

Da beziehst Dich auf den divide error on 0, da gibt es bei debian imho auch nen Bugreport.
https://linuxtv.org/patch/20075/
Der ist im 3.11.3 drin.

Weiterhin gibt es noch nen Bug, der bei u erst ab 3.11.6 ? gefixt ist,
der je nach verwendetem Siano-Chipsatz im Stick verschiedene Auswirkungen hat, bei mir
gab es nen Kernelcrash "kernel-panic, switching back to text console".

Wo bzw wie das gefixt wurde hab ich nicht gefunden, die oben angeführten Patches
lassen sich zusätzlich auch noch anwenden.

Schon merkwürdig irgendwie...

[juno]

Ich hatte die Links zu den Header-Paketen doch mitgeliefert. Schau nochmal nach.

Gruss, habakug

Ich hatte das exakt so nachvollzogen, leider mag der Radeon-Treiber nicht so richtig. In dem oben (bei NoPaste eingestellten) genannten Fehler-Log ist von fehlenden Kernel-Headers die Rede.

[dillo]

Der von dir (des öfteren) zitierte Code betrifft, wie von dir auch erklärt wird, Debug-Meldungen. Für mich ist die damit zusammenhängende Ausgabe in dmesg lediglich ein Indikator dafür, das der für diesen Fall entscheidende Code noch nicht in der jeweiligen Kernel-Version ist.

Nunja, etwas als 'Indikator' ansehen und es im Thread mit 'ist das hier (ich erspare mir das nochmalige Zitieren) ein Kernel-Bug' zu formulieren, ist schon etwas....nein Schluss jetzt! Ich weiß jetzt, was du eigentlich wolltest und damit ist gut. Danke

[dillo]

Ich hatte das exakt so nachvollzogen

wenn du exakt das gemacht hast, was habakug geschrieben hat, dann hast du nur das Kernelpaket installiert. Die anderen beiden hast du ja nur heruntergeladen und musst sie dann auch noch mit 'dpkg -i ........' installieren.

[habakug]

Hallo!

@dillo
Ich habe mich mißverständlich ausgedrückt, du hast Recht, das ich es nicht als "Kernel-Bug" hätte bezeichnen dürfen. Ich hätte es so formulieren müssen, das klar wird, das ich meine, dass bei Auftreten dieser Meldung, der Kernel immer noch den Bug beinhaltet. Ich hoffe, damit sind wir uns wieder einig (wenn wir es denn nicht waren).

@juno
Ja, du mußt die beiden Pakete noch mit "dpkg -i" nachinstallieren.

Gruss, habakug

[juno]

Guten Abend,

ich wuerde gerne das Thema fuer mich und andere zusammenfassen:
Aktuell habe ich die Loesung erhalten, einen Kernel aus einer Ubuntu-Quelle einzupflegen, um die DVB-T Karte ans Laufen zu bekommen.
Die Frage ist, ob diese Massnahme auch unerwuenschte Nebenwirkungen haben kann bzw. welche das sein koennen.
Weiter: Kann ein anderer Kernel, z.B. aus Debian Experimental, eine Loesung ohne Nebenwirkungen darstellen.
Sobald das klarer wird, ist dieses Thema fuer mich *geloest*.
Fuer jetzt: Super Vielen Dank an alle, die sich bisher schon an dem Problem ausgelassen haben und sich da so reingefummelt haben,
ein guter Start fuer mich in das Debian-Universum

[dillo]

Die Frage ist, ob diese Massnahme auch unerwuenschte Nebenwirkungen haben kann bzw. welche das sein koennen.

Fakt ist, dass dein System mit dem Ubuntu-Kernel läuft und dass auf dieser Ebene, wenn du bisher keine Probleme feststellen konntest, auch weiterhin keine Nebenwirkungen mehr zu erwarten sind.
Eine andere Sache ist, dass du mit dpkg quasi an den Debian-Repos vorbeiinstalliert hast. Da aber mit der Installation des Kernels und der Header keine weiteren Abhängigkeiten erfüllt werden mussten bzw verletzt wurden, ist auch in dieser Hinsicht alles 'in Butter'.

Weiter: Kann ein anderer Kernel, z.B. aus Debian Experimental, eine Loesung ohne Nebenwirkungen darstellen.

Das könnte dann schon etwas komlizierter sein, weil du dich dann mit pinning beschäftigen solltest, wenn du nicht ganz auf experimental oder unstable umsteigen willst bzw wie von mir vorgeschlagen, nur kurzfristig diese Repos einbindest und nach der Installation von Kernel und Headern (die in deinem Falle wegen des Grafiktreibers doch erforderlich sind) wieder entfernst.

Ich persönlich habe keine Erfahrung mit 'Mischsystemen'. Ich bin nach meinem Einstieg mit woody nach ein paar Wochen (und das nicht nur auf meinem eigenen Rechner) auf unstable umgestiegen und wundere mich seit inzwischen über zehn Jahren, warum da so eindrücklich vor gewarnt wird. Etwas Fingerspitzegefühl und sorgfältiges Lesen, was apt bei einem dist-upgrade so alles vorhat, lassen 'Katastrophen' vermeiden. Im rein privaten Bereich sehe ich da keinen Hinderungsgrund, es sei denn man hat wirklich absolut gar keine Lust auf Abenteuer....

Die 'sauberste' Lösung wäre IMHO, du holst dir die Debian-Kernel-Quellen in der Version, die du mindestens haben solltest bzw höher und baust den Kernel mit der mitgelieferten debian-config selbst. Hierfür gibt es haufenweise Anleitungen, die du nur per c&p in ein Terminal hauen musst, ein Linux-Guru muss man dafür nicht sein.

Also: wenn dein System gut läuft, besteht kein Handlungsbedarf. Wenn du es ganz eng sehen willst, baust du dir einen eigenen Debian-Kernel. Musst du selbst wissen.

Ich hoffe, damit sind wir uns wieder einig (wenn wir es denn nicht waren)

Nachdem ich weiß, was du ausdrücken wolltest, könnten wir uns nicht 'einiger' sein
Nochmal sorry, dass ich so penetrant darauf rumgehackt habe, aber in Anbetracht dessen, dass ich deine Aussage wörtlich genommen hatte, verstehst du vielleicht, warum ich so hartnäckig war.

[dirk11]

Eine andere Sache ist, dass du mit dpkg quasi an den Debian-Repos vorbeiinstalliert hast. Da aber mit der Installation des Kernels und der Header keine weiteren Abhängigkeiten erfüllt werden mussten bzw verletzt wurden, ist auch in dieser Hinsicht alles 'in Butter'.

Das ist sowieso vollkommen unerheblich. Eine Installation eines Paketes mittels dpkg ist absolut problemlos möglich, weil selbiges vom Paketmanagement erkannt und "vollintegriert" wird. Das ist überhaupt nicht zu vergleichen mit irgendeinem Paket, welches z.B. per make install ins System gestopft wird.
dpkg -i ist unterm Strich eine legitime und vor allem sichere Methode, Einzelpakete ohne Nutzung des üblichen Paketmanager (aptitude, synaptic) "händisch" zu installieren.

[dillo]

@dirk: vielleicht habe ich mich etwas schwammig ausgedrückt. Wichtig war mir:

Da aber mit der Installation des Kernels und der Header keine weiteren Abhängigkeiten erfüllt werden mussten bzw verletzt wurden [...]

sonst kann es nämlich schon etwas tückisch bzw zeitaufwendig werden, bis man, was das Paketmanagement betrifft, wieder ein konsistentes System hat...und dass apt etc. nur ein frontend für dpkg ist (sind) bzw darauf zurückgreift, ist mir schon auch klar

[dirk11]

sonst kann es nämlich schon etwas tückisch bzw zeitaufwendig werden, bis man, was das Paketmanagement betrifft, wieder ein konsistentes System hat...und dass apt etc. nur ein frontend für dpkg ist (sind) bzw darauf zurückgreift, ist mir schon auch klar

Da ist nichts "tückisch". Entweder installierste dann einfach mit dem Paketmanager deiner Wahl (oder weiterhin dpkg, falls es auch "fremde" Pakete sein müssen) die fehlenden Abhängigkeiten nach, oder du purged einfach das Paket, welches sich wegen der fehlenden Abhängigkeiten nicht richtig installieren lässt, mit ebendemselben Paketmanager. Gerade bei dpkg -i ist es überhaupt kein Problem, das Paket wieder loszuwerden und das System "sauber" zu halten.

[dillo]

Meine Güte, du willst mich offenbar nicht verstehen. Das ist mir doch alles klar!
Genauso klar ist aber auch, dass, wenn man bei unaufgelösten Abhängigkeiten zu einem händischen Nachinstallieren aus fremden Paketquellen gezwungen wird, das eben nicht so komfortabel ist 'wie ein apt-get install bla', bei dem Abhängigkeiten automatisch aufgelöst werden.....
....so jetzt hast du das letzte Wort und ich meine Ruhe ciao ciao

[dirk11]

Meine Güte, du willst mich offenbar nicht verstehen. Das ist mir doch alles klar!

Da geht es wohl kaum um wollen. Mir ist jedenfalls bisher nicht klar gewesen, dass dir das alles klar ist.

Genauso klar ist aber auch, dass, wenn man bei unaufgelösten Abhängigkeiten zu einem händischen Nachinstallieren aus fremden Paketquellen gezwungen wird, das eben nicht so komfortabel ist 'wie ein apt-get install bla', bei dem Abhängigkeiten automatisch aufgelöst werden.....

Äh - wieso schreibst du das nicht gleich? Damit ist doch alles gesagt.

[juno]

Guten Abend,

ich moechte an dieser Stelle den Weg zusammenfassen, der fuer dieses Problem letztlich die Loesung gebracht hat.
Hinweis: Der unten beschriebene Weg hat auf meinem System die Loesung gebracht, fuer andere System kann ich keine Gewaehr uebernehmen.
Danke an alle, die mir geholfen haben, insbesondere dillo & habakug

1. Identifikation des USB DVB-T Sticks
Gekauft wurde das Teil als Medion DVB-T Stick bei ALDI Nord, Herstelldatum 3/2012.
Medion Produktnummer: MD 86351 bzw. MSN 5004 1266
Der Stick wird aber auch unter folgenden Namen vermarktet:
MyGica T119 Mini USB DVB-T Stick
Geniatech T119 Mini HDTV USB Stick
Allen gemeinsam ist folgender Chipsatz: Siano Mobile Silicon Nice
lsusb nennt ausserdem die genaue Produkt-ID:

Code: Alles auswählen

Bus 001 Device 003: ID 187f:0202 Siano Mobile Silicon Nice

2. Treiber einbinden (Download und Umbenennen der Firmware-Datei)
cd /lib/firmware
wget http://steventoth.net/linux/sms1xxx/sms ... dvbt-02.fw
ln -s sms1xxx-hcw-55xxx-dvbt-02.fw dvb_nova_12mhz_b0.inp

3. Installation eines neueren Kernels (hier beispielhaft fuer AMD64)

Code: Alles auswählen

mkdir /tmp/nkernel
cd /tmp/nkernel
wget -c kernel.ubuntu.com/~kernel-ppa/mainline/v3.11.5-saucy/linux-headers-3.11.5-031105_3.11.5-031105.201310132235_all.deb
wget -c kernel.ubuntu.com/~kernel-ppa/mainline/v3.11.5-saucy/linux-headers-3.11.5-031105-generic_3.11.5-031105.201310132235_amd64.deb
wget -c kernel.ubuntu.com/~kernel-ppa/mainline/v3.11.5-saucy/linux-image-3.11.5-031105-generic_3.11.5-031105.201310132235_amd64.deb
dpkg -i *.deb

oder alternativ hier einen aktuellen Kernel aussuchen: ftp://ftp.kernel.org/pub/linux/kernel/v3.x/
in jedem Fall: reboot

4. Neustarten und TV gucken
Nach dem Reboot konnte ich in Kaffeine den Sendersuchlauf erfolgreich durchfuehren und die gefundenen Sender sehen.

Ich werde in meinem ersten Post einen Hinweis auf diese Loesung platzieren als auch das Thema mit [geloest] ergaenzen, wenn keinem in diesem Posting ein gravierender Fehler auffaellt !