Yavdr 0.4-pre2 und Cinergy S2 USB HD Firmware Upload Problem

Torsten73 · 18. Oktober 2011

Es scheint aber wohl alle ds3000 Firmware abhängigen Devices zu betreffen. Meine bescheidenen Fähigkeiten reichten halt nicht aus um Igor klar zu machen, wo das Problem ist. Denn lt. seiner Tests gibt es keine Probleme diesbezüglich. Obs nun die Firmware oder der Treiber ist, ich weiß es nicht. Von der Symptomatik her scheint es für mich aber doch eher mit der Firmware zusammen zuhängen, da die Treiber bestimmt nicht gleich sind.

Vielleicht kommt ja doch noch mal ein Stein ins rollen, damit der durchaus lästige Fehler behoben werden kann, ohne ein workaround zu nutzen.

steffen_b · 18. Oktober 2011

Ich hatte damals mit meiner Tevii 470 Treiber und Firmware in die initrd verfrachtet - vielleicht ist das ein workaround ? Wenn jemand das Ausprobieren will - da war irgendwo ein Post der das Vorgehen beschreibt (find ich grad nicht)

s.krueger · 18. Oktober 2011

So hab mal nen Test gemacht:

Wenn ich die Box mit dynamite raus schmeiße, in dem Mom wird die Firmware geladen, füge ich die Box dann wieder mit dynamite wieder ein, funzt die Box

raus:

Code

Oct 18 17:45:28 hdvdr vdr: [2338] dynamite: deleted device for /dev/dvb/adapter2/frontend0
Oct 18 17:45:28 hdvdr vdr: [2338] dynamite: detached device /dev/dvb/adapter2/frontend0
Oct 18 17:45:28 hdvdr vdr: [2338] info: detached /dev/dvb/adapter2/frontend0
Oct 18 17:45:28 hdvdr vdr: [2744] Text2Skin: message display update thread started (pid=2338, tid=2744)
Oct 18 17:45:28 hdvdr vdr: [2338] closing SVDRP connection
Oct 18 17:45:28 hdvdr kernel: [  664.552300] dw2102: su3000_power_ctrl: 0, initialized 1
Oct 18 17:45:28 hdvdr kernel: [  664.552305]

rein:

Code

Oct 18 17:46:18 hdvdr vdr: [2338] dynamite: attached device /dev/dvb/adapter2/frontend0 to dynamic device slot 3
Oct 18 17:46:18 hdvdr vdr: [2338] info: attached /dev/dvb/adapter2/frontend0
Oct 18 17:46:18 hdvdr vdr: [2762] Text2Skin: message display update thread started (pid=2338, tid=2762)
Oct 18 17:46:18 hdvdr vdr: [2338] closing SVDRP connection
Oct 18 17:46:20 hdvdr vdr: [2762] Text2Skin: message display update thread ended (pid=2338, tid=2762)
Oct 18 17:46:15 hdvdr vdr: [2338] dynamite: udev cardindex is (null)
Oct 18 17:46:15 hdvdr vdr: [2338] new sub-device number 3
Oct 18 17:46:15 hdvdr kernel: [  711.363807] dw2102: su3000_power_ctrl: 1, initialized 1
Oct 18 17:46:15 hdvdr kernel: [  711.363811] 
Oct 18 17:46:15 hdvdr vdr: [2338] frontend 2/0 provides DVB-S2 with QPSK ("Montage Technology DS3000/TS2020")
Oct 18 17:46:15 hdvdr vdr: [2338] LNB-sharing: patch version 0.1.4
Oct 18 17:46:15 hdvdr vdr: [2338] LNB-sharing: setting device 3 to use LNB 3
Oct 18 17:46:15 hdvdr vdr: [2338] Device 3: will send signals (like 22kHz) to LNB nr. = -3 
Oct 18 17:46:15 hdvdr vdr: [2758] tuner on frontend 2/0 thread started (pid=2338, tid=2758)

Alles anzeigen

Tja... was machen wir?!

MFG SVen

mini73 · 18. Oktober 2011

Moin!

Wir wissen jetzt, dass die Box ihre Firmware nicht laden kann, wenn ein Programm das Frontend bzw. demux-Device geöffnet hat.
Das muss eigentlich ein Treiberproblem sein. D.h., die richtige Stelle, dies zu beheben, wäre, einen Bugreport an den Maintainer zu schreiben. Kann man vom Treiber noch ausführlichere Debug-Meldungen ausgeben lassen, z.B. per Modul-Option?

Bis das gelöst ist, hast du verschiedene Workarounds zur Auswahl:

vor dem vdr-Start mit irgendeinem Programm (z.B. dvbtune) kurz auf das Device zugreifen, damit die Firmware geladen wird (per udev-Regel oder upstart, wie's es dir besser gefällt)
nach dem vdr-Start mit einem Script über dynamite das Device aus- und wieder einhängen

Was mir gerade noch eingefallen ist: Probier mal ein SetIdle mit dynamite:

Code

svdrpsend plug dynamite SetIdle /dev/dvb/adapter2/frontend0

Das sorgt auch dafür, dass die Filehandles geschlossen werden, aber der vdr kann das Device von alleine wieder öffnen, falls es gebraucht wird.

Ist es eigentlich immer adapter2 oder wechselt das? Das musst du sonst ggf. anpassen.

Bei Treiberproblemen kann ich leider nicht helfen. Viel Glück auf der linux-media Mailinglist, das wäre die richtige Stelle dafür...

Lars.

s.krueger · 18. Oktober 2011

Hi,

Zitat

Ist es eigentlich immer adapter2 oder wechselt das? Das musst du sonst ggf. anpassen

Leider nicht, meist ist es adapter0, in dem Beispiel hab ich die Box nachträglich an gestöpselt, damit ich besser sehen kann welches dev das ist.
Eine udev-ergel würde denke ich passen, nur bräuchte ich Hilfe damit die Box immer der gleiche adapter ist und dann per SetIdle ausgehängt werden kann. Denke das müßte so klappen.
Dann würde ich auch gleich per udev ein Script starten mit sleep bis der VDR gestartet ist und dann per dynamite die Box schlafen legt und die Firmware dann geladen werden kann, denke so müsste das klappen!?! Mit fehlt jetzt nur die richtige Syntax für die udev-regel.
Dann kann das Upstartscript unangetastet bleiben und beim Treiberfix ist die regel fix gelöscht.

Danke für die Mithilfe, MFG SVen

Torsten73 · 18. Oktober 2011

Zitat von mini73

Wir wissen jetzt, dass die Box ihre Firmware nicht laden kann, wenn ein Programm das Frontend bzw. demux-Device geöffnet hat.

Das muss eigentlich ein Treiberproblem sein. D.h., die richtige Stelle, dies zu beheben, wäre, einen Bugreport an den Maintainer zu schreiben. Kann man vom Treiber noch ausführlichere Debug-Meldungen ausgeben lassen, z.B. per Modul-Option?

Der Maintainer ist in dem Fall igor. Vielleicht kannst Du ihm das verständlich in Englisch erklären warum es der Treiber ist?

steffen_b · 18. Oktober 2011

Access to the allready existing device nodes by an application is blocking the firmware upload. On the other hand the firmware is loaded on demand so at first access to the device. No matter what the application should not be able to block the driver or as an alternative it should be possible from the application perspective to find out what to do (try again ?). The situation as of now can be described as broken driver.

So in etwa ?

mini73 · 18. Oktober 2011

Moin!

Zitat von Torsten73

Der Maintainer ist in dem Fall igor. Vielleicht kannst Du ihm das verständlich in Englisch erklären warum es der Treiber ist?

Naja, der Firmware-Upload wird beim ersten Öffnen gestartet und hängt. Wird das Frontend geschlossen, geht's mit dem Upload weiter. Mehr ist es eigentlich nicht.
Ich würde mich bei der Diskussion mit dem Maintainer aber raushalten wollen, weil ich nicht die Hardware habe, um genauere Infos zu liefern bzw. irgendwas zu testen.

Eventuell könnte man das auch reproduzieren, wenn man dvbtune mit dem Monitor-Parameter -m startet. Dann sollte das Frontend auch nicht geschlossen werden und es wäre für ihn evtl. leichter nachzuvollziehen. Dann braucht er nicht erst vdr/dynamite usw. zu bemühen.

Lars.

mini73 · 18. Oktober 2011

Steffen,

Klingt gut. Und jetzt noch ein Testszenario mit Logs und "dvbtune -m" zur Dokumentation.

Lars.

steffen_b · 18. Oktober 2011

Was dann von einem der betroffenen geliefert werden müsste (Meine Tevii ist noch eingemottet und evtl nichtmal betroffen)

mini73 · 18. Oktober 2011

Moin!

Zitat von s.krueger

Mit fehlt jetzt nur die richtige Syntax für die udev-regel.

Hast du deine ursprüngliche Regel noch mal mit "0x" vor den Ids probiert? "udevadm test" hilft dir da auch weiter.

Zitat von s.krueger

Dann kann das Upstartscript unangetastet bleiben und beim Treiberfix ist die regel fix gelöscht.

Du kannst auch ein neues Upstart-Script schreiben, dass vor dem vdr gestartet wird und einfach mal bei allen Adaptern dvbtune aufruft. Ich muss aber gestehen, dass ich mich bei den Abhängigkeiten in upstart auch nicht so auskenne. Ich müsste also genauso wie du die Doku lesen...

Lars.

s.krueger · 18. Oktober 2011

Zitat von steffen_b

Was dann von einem der betroffenen geliefert werden müsste (Meine Tevii ist noch eingemottet und evtl nichtmal betroffen)

Was muß ich machen? reicht:

Code

dvbtune -f 11954000 -p H -s 27500 -v 110 -a 120 -t 130 -tone 1 -m

?

MFG SVen

mini73 · 19. Oktober 2011

Moin!

Probier's einfach mal aus und lese zur Not die manpage zu dvbtune. Ich hab nur DVB-C, da sieht das alles anders aus...
Es fehlt evtl. der Parameter "-c n", wobei n die Adapternummer ist. Müssen V, A, T nicht große Buchstaben sein?

Lars.

s.krueger · 19. Oktober 2011

Hm... Jungs wie muß die udev-Regel ausehen, wenn ich die Box einen Bestimmten Adapter zuordnen will!?

Code

KERNEL=="dvb*", DRIVERS=="dvb_usb_dw2102", PROGRAM="/bin/sh -c 'K=%k; K=$${K#dvb}; printf dvb/adapter3/%%s $${K#*.}", NAME="%c"

oder

Code

SUBSYSTEM=="dvb", ATTR{idProduct}=="0x0ccd", ATTR{idVendor}=="0x00a8", PROGRAM="/bin/sh -c 'K=%k; K=$${K#dvb}; printf dvb/adapter3/%%s $${K#*.}'", NAME="%c"

Nix vom dem geht!!!! Was mache ich falsch

hier mal udevinfo:

Code

udevadm info -a -p $(udevadm info -q path -n /dev/dvb/adapter1/frontend0) 


Udevadm info starts with the device specified by the devpath and then
walks up the chain of parent devices. It prints for every device
found, all possible attributes in the udev rules key format.
A rule to match, can be composed by the attributes of the device
and the attributes from one single parent device.


  looking at device '/devices/pci0000:00/0000:00:04.1/usb2/2-2/dvb/dvb1.frontend0':
	KERNEL=="dvb1.frontend0"
	SUBSYSTEM=="dvb"
	DRIVER==""


  looking at parent device '/devices/pci0000:00/0000:00:04.1/usb2/2-2':
	KERNELS=="2-2"
	SUBSYSTEMS=="usb"
	DRIVERS=="usb"
	ATTRS{configuration}=="Def"
	ATTRS{bNumInterfaces}==" 1"
	ATTRS{bConfigurationValue}=="1"
	ATTRS{bmAttributes}=="80"
	ATTRS{bMaxPower}=="500mA"
	ATTRS{urbnum}=="3817"
	ATTRS{idVendor}=="0ccd"
	ATTRS{idProduct}=="00a8"
	ATTRS{bcdDevice}=="0000"
	ATTRS{bDeviceClass}=="00"
	ATTRS{bDeviceSubClass}=="00"
	ATTRS{bDeviceProtocol}=="00"
	ATTRS{bNumConfigurations}=="1"
	ATTRS{bMaxPacketSize0}=="64"
	ATTRS{speed}=="480"
	ATTRS{busnum}=="2"
	ATTRS{devnum}=="5"
	ATTRS{devpath}=="2"
	ATTRS{version}==" 2.00"
	ATTRS{maxchild}=="0"
	ATTRS{quirks}=="0x0"
	ATTRS{avoid_reset_quirk}=="0"
	ATTRS{authorized}=="1"
	ATTRS{manufacturer}=="Max"
	ATTRS{product}=="USB Stick"
	ATTRS{serial}=="080116"


  looking at parent device '/devices/pci0000:00/0000:00:04.1/usb2':
	KERNELS=="usb2"
	SUBSYSTEMS=="usb"
	DRIVERS=="usb"
	ATTRS{configuration}==""
	ATTRS{bNumInterfaces}==" 1"
	ATTRS{bConfigurationValue}=="1"
	ATTRS{bmAttributes}=="e0"
	ATTRS{bMaxPower}=="  0mA"
	ATTRS{urbnum}=="88"
	ATTRS{idVendor}=="1d6b"
	ATTRS{idProduct}=="0002"
	ATTRS{bcdDevice}=="0206"
	ATTRS{bDeviceClass}=="09"
	ATTRS{bDeviceSubClass}=="00"
	ATTRS{bDeviceProtocol}=="00"
	ATTRS{bNumConfigurations}=="1"
	ATTRS{bMaxPacketSize0}=="64"
	ATTRS{speed}=="480"
	ATTRS{busnum}=="2"
	ATTRS{devnum}=="1"
	ATTRS{devpath}=="0"
	ATTRS{version}==" 2.00"
	ATTRS{maxchild}=="6"
	ATTRS{quirks}=="0x0"
	ATTRS{avoid_reset_quirk}=="0"
	ATTRS{authorized}=="1"
	ATTRS{manufacturer}=="Linux 2.6.38-11-generic ehci_hcd"
	ATTRS{product}=="EHCI Host Controller"
	ATTRS{serial}=="0000:00:04.1"
	ATTRS{authorized_default}=="1"


  looking at parent device '/devices/pci0000:00/0000:00:04.1':
	KERNELS=="0000:00:04.1"
	SUBSYSTEMS=="pci"
	DRIVERS=="ehci_hcd"
	ATTRS{vendor}=="0x10de"
	ATTRS{device}=="0x077e"
	ATTRS{subsystem_vendor}=="0x1043"
	ATTRS{subsystem_device}=="0x82e2"
	ATTRS{class}=="0x0c0320"
	ATTRS{irq}=="21"
	ATTRS{local_cpus}=="00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000003"
	ATTRS{local_cpulist}=="0-1"
	ATTRS{numa_node}=="0"
	ATTRS{dma_mask_bits}=="32"
	ATTRS{consistent_dma_mask_bits}=="32"
	ATTRS{enable}=="1"
	ATTRS{broken_parity_status}=="0"
	ATTRS{msi_bus}==""
	ATTRS{companion}==""


  looking at parent device '/devices/pci0000:00':
	KERNELS=="pci0000:00"
	SUBSYSTEMS==""
	DRIVERS==""

Alles anzeigen

Danke und MFG SVen

mini73 · 19. Oktober 2011

Moin!

Das geht nicht mehr mit dem aktuellen udev. Was der Kernel vorgibt als Device wird immer angelegt.
Eventuell bietet der Treiber einen Modulparameter.

Lars.

Yavdr 0.4-pre2 und Cinergy S2 USB HD Firmware Upload Problem

Jetzt mitmachen!

Teilen