USB Disconnect nach einstecken des MediaPro...

[Sundtek]

Das Problem ist der USB 2.0 Support bei USB 3.0 Ports (was ein Linux USB Controller Treiber Problem ist), nicht USB 3.0 im Allgemeinen.
USB 3.0 funktioniert mit USB 2.0 Geräten problemlos mit Windows und MacOSX.

[marc]

Gäbe es die Möglichkeit über die sundtek.conf den einzelnen Karten einen Namen für z.B TVHeadend mit zugeben? Um TVHeadend einen Namen der Karte zu erzwingen. Das würde das Problem zumindest temporär (wenn auch nicht wirklich und unsauber) lösen. Sonst muss ich immer wieder den mediaclient (oftmals reicht ein Neustart bzw. in der sundtek.conf device_detach... device_attach...) Neustarten bis TVHeadend die von mir Vergebenen Namen wieder Akzeptiert. Kann man da nicht eine Parameter in die Serial Section einbauen das TVHeadend den Adapter/Stick mit dem vergebenen Namen übergeben bekommt? z.B. initial_name=DVBS01, initial_name=DVBS02, initial_name=DVBT01, usw.

Grüße

[Sundtek]

Du meinst einen alternativen Gerätenamen?

Ich kann das für die nächsten Updates bei uns auf die Liste setzen damit das möglich sein wird

[SERIAL]
device_name="ABCD"

[marc]

Ja genau so :-)
Danke und ein schönes Wochenende euch.

[Immanuel]

Hallo zusammen,

Fernbedienung ist abgeschaltet:

Code: [Auswählen]

cat /etc/sundtek.conf
ir_disabled = 1

Der Stick steckt in einem USB 2.0 Port an der Rückseite und ist an das Netzteil angeschlossen.

Code: [Auswählen]

/opt/bin/mediaclient -e
**** List of Media Hardware Devices ****
device 0: [Sundtek SkyTV Ultimate V (2015)]  DVB-S/S2, ANALOG-TV, REMOTE-CONTROL, OSS-AUDIO
  [INFO]:
     STATUS: ACTIVE
  [BUS]:
     ID: 1-5.1
  [SERIAL]:
     ID: U160801154933
  [DVB-S/S2]:
     FESTATUS: ACTIVE
     LNBVOLTAGE: ENABLED
     LNBSUPPLY: ACADAPTER
     LNBSTATUS: OK
     FRONTEND: /dev/dvb/adapter0/frontend0
     DVR: /dev/dvb/adapter0/dvr0
     DMX: /dev/dvb/adapter0/demux0
  [ANALOG-TV]:
     VIDEO0: /dev/video0
     VBI0: /dev/vbi0
  [REMOTECONTROL]:
     INPUT0: /dev/mediainput0
  [OSS]:
     OSS0: /dev/dsp0



Wie erwähnt, wird der USB 2.0 Port vom XHCI Treiber bedient:

Code: [Auswählen]

lsusb -t
/:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/6p, 5000M
    |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/4p, 5000M
/:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/7p, 480M
    |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/4p, 480M
    |__ Port 5: Dev 3, If 0, Class=Hub, Driver=hub/4p, 480M
        |__ Port 1: Dev 14, If 0, Class=Vendor Specific Class, Driver=, 480M
        |__ Port 1: Dev 14, If 1, Class=Vendor Specific Class, Driver=, 480M
        |__ Port 1: Dev 14, If 2, Class=Vendor Specific Class, Driver=usbfs, 480M
        |__ Port 1: Dev 14, If 3, Class=Vendor Specific Class, Driver=, 480M
        |__ Port 1: Dev 14, If 4, Class=Vendor Specific Class, Driver=, 480M
        |__ Port 1: Dev 14, If 5, Class=Vendor Specific Class, Driver=, 480M
        |__ Port 1: Dev 14, If 6, Class=Vendor Specific Class, Driver=, 480M


Gibt es eine Möglichkeit, Linux anzuweisen, den EHCI Treiber für den SkyUlitmate-Stick zu nutzen?

Diese Woche konnte ich den Stick vor lauter disconnects fast nicht nutzen...

Dankeschön,
Immanuel

[Sundtek]

Für EHCI benötigst du einen USB 2.0 Controller.

Es können hier aber 2 Probleme auftreten:
1. entweder ist der XHCI / USB 3.0 Controller fehlerhaft (Asmedia ist wohl insbesondere bekannt dafür, bei Intel scheint es gemischte Erfahrungen mit USB 3.0 zu geben)
2. der Tuner hat ein Problem.

Um die Tuner zu überprüfen gibt es nur die Möglichkeit die nach Berlin zu schicken damit wir diese testen können, ich denke nicht das wir Dir bei dem Problem im Forum anders behilflich sein könnten.

Du kannst ja ein Ticket aufmachen, dann können wir das dort weiter besprechen, im Allgemeinen lässt sich sicherlich eine Lösung für Dein Problem finden:
http://sundtek.de/tickets

[Immanuel]

Hallo zusmmen,

habe das Problem jetzt dich ausschalten des USB powermanagements scheinbar gelöst.

Code: [Auswählen]

echo on > /sys/bus/usb/devices/1-5/power/control

VG,
Immanuel

[Sundtek]

Das wäre dann ein Bug im Linux USB Stack, berichte ob dass dein Problem wirklich behebt.

Welche Kernel Version verwendest du?

Wenn wir die ungefähre Version haben dann können wir den Workaround auch in den Treiber einbauen.

[Immanuel]

Hallo zusammen,

der Stick läuft nach wie vor stabil nach deaktivieren des USB-Powermanagements.
Keine Disconnects mehr.

uname -r liefert: 4.7.0-0.bpo.1-amd64
Wäre sicher gut, wenn das noch jemand bestätigen könnte. marc?

Muss nur nach jedem reboot (zum Glück selten) jetzt manuell ausführen:

Code: [Auswählen]

echo on > /sys/bus/usb/devices/1-5/power/control

Das müsste man mit irgendeinem Sundtek systemd-startup script automatisiert ausführen.

VG,
Immanuel

[Sundtek]

Kannst Du das System mal neu starten und den Autosuspend Wert sowie den Control Wert auslesen?

sudo cat /sys/module/usbcore/parameters/autosuspend

sudo cat /sys/bus/usb/devices/1-5/power/control

Wir könnten das in den Treiber stecken damit dieser die Parameter automatisch setzt, nicht alle Systeme verwenden udev (speziell Embedded Systeme)

[Immanuel]

Direkt nach Neustart erhalte ich:

Code: [Auswählen]


cat /sys/module/usbcore/parameters/autosuspend
2

cat /sys/bus/usb/devices/1-5/power/control
auto


Gruß,
Immanuel

[marc]

Hallo an alle,

so nach Diversen Tests konnte ich das Problem bei mir auf x84 64Bit (USB3) und ARM v7 (USB2) scheinbar lösen.
Das Problem macht wohl die Linux Kernel Version >= 4. Getestet habe ich:

Debian 8.6 x86-64Bit (Board und CPU aus diesem Thread) , Kernel 3.16, TVHeadend stable 4.16, mit 2x Sundtek DVBS2 und 1x MediaPro, USB 3 Controler = Keine bekannten Probleme. Probleme waren immer nur mit dem Kernel 4.x über die Backports.

HummingBoard 2 (ARMv7), Kernel 3.14, TVHeadend 4.0.8, mit 2x Sundtek DVBS2 und 1x MediaPro, USB 2 Controler mit einem Aktiven USB3-Hub zwischen = ebenfalls keine bekannten Probleme. Auch hier hatte ich die Probleme immer nur mit dem Kernel 4.x aus den Backports.

In beiden fällen kann ich sogar problemlos über DVBT2 HD schauen, was vorher so gut wie gar nicht ging (Ton lief aber Standbild).

Also scheint es eine Änderung am Kernel bezüglich USB im Allgemeinen gegeben zu haben, die diese Disconnects verursacht. Das problem hatte ich auch mit einem RPi3 (OSMC 17beta 5-7) Kernel 4.4.x, ODroid XU/XU4 und C1, Kernel 4.x unter Debian und Ubuntu Server (hier habe ich den Kernel 3.x nicht getestet).

Ich hoffe die Infos sind für euch von Relevanz und ich kann euch damit Helfen :-)

[Sundtek]

Danke für die Infos! Wir werden es im Auge behalten und ggf. einen Workaround einbauen damit das Standby vom USB Controller automatisch abgeschalten wird.