Systemcrash mit Sundtek MediaTV Digital Home III

[schlumf.thomas@web.de]

Hallo,
ich habe den neuen MediaTV Digital Home III Stick jetzt seit ca. einer Woche im Einsatz. Das Problem des Systemcrashs war zunächst nur zu sehen, wenn ich mit w_scan die aktuelle Kanalbelegung ermittelt habe. Mittlerweile friert mein System aber nach 30 min bis 5 Stunden zuverlässig ein, wenn ich den Stick angeschlossen und den vdr laufen habe.
Es sieht so aus, als ob das meistens während des epg scans passiert. Wenn das System es schafft noch eine crash meldung zu produzieren taucht der mediasrv als letzter Prozess auf. Nach dem Einfrieren geht gar nichts mehr, also nicht der magic sqsrequest.
Mein System ist ubuntu, kernel 3.13.0-8-generic (problem trat auch mit 3.13.0-7-generic auf) und der Teriber sundtek_installer_140207.202855.sh (problem trat auch mit sundtek_installer_140204.195739.sh auf). Es ist auch egal, ob ich den Stick über einen usb2 oder einen usb3 port anschließe.
Habt Ihr eine Idee, was ich einstellen könnte, damit mir der Rechner nicht ständig einfriert (außer den Stick nicht einzusetzen, was ich im Moment mache).
Danke
Christoph

[Sundtek]

Verwende falls möglich einen USB 2.0 Port, falls möglich schicke uns die Meldungen welche du dort bekommst wir werden diese dann soweit erst mal an Intel weiterleiten.
Eine Angestellte bei Intel sieht sich die Problemfälle derzeit genauer an.

Unser Treiber kann das System nicht crashen da dieser nur eine Applikation ist (im schlechtesten Fall kann der Treiber abstürzen, aber das wäre dann schon alles und dies würde das System aber nicht beeinflussen), es handelt sich hier um einen Allgemeinen Systembug mit USB 3.0 unter Linux.

Eine Alternative wäre den Stick via einem Raspberry PI zu betreiben und das Device dann via Netzwerkmodus in das System zu reichen
http://support.sundtek.com/index.php/topic,178.0.html

[schlumf.thomas@web.de]

Verwende falls möglich einen USB 2.0 Port

Bei den letzten 5 Abstürzen war der Stick an einem USB2 Port
lsusb:
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 003 Device 008: ID 2659:1401 Sundtek
lspci:
00:1d.0 USB controller: Intel Corporation 8 Series/C220 Series Chipset Family USB EHCI #1 (rev 05)
00:1a.0 USB controller: Intel Corporation 8 Series/C220 Series Chipset Family USB EHCI #2 (rev 05)
00:14.0 USB controller: Intel Corporation 8 Series/C220 Series Chipset Family USB xHCI (rev 05)

falls möglich schicke uns die Meldungen welche du dort bekommst wir werden diese dann soweit erst mal an Intel weiterleiten.

Mein Board ist von Asus (mit Intel Chipsatz). Im Systemlog findet man da nichts wirklich hilfreiches:
Feb  7 23:17:46 vesuv1 vdr: [8986] epg data writer thread started (pid=8714, tid=8986, prio=low)
Feb  7 23:17:46 vesuv1 vdr: [8986] epg data writer thread ended (pid=8714, tid=8986)
Feb  7 23:27:47 vesuv1 vdr: [9102] epg data writer thread started (pid=8714, tid=9102, prio=low)
Feb  7 23:27:47 vesuv1 vdr: [9102] epg data writer thread ended (pid=8714, tid=9102)
^@^@^@^@^@ (das Zeichen taucht dann noch ein paar mal auf).

Unser Treiber kann das System nicht crashen da dieser nur eine Applikation ist (im schlechtesten Fall kann der Treiber abstürzen, aber das wäre dann schon alles und dies würde das System aber nicht beeinflussen), es handelt sich hier um einen Allgemeinen Systembug mit USB 3.0 unter Linux.

Ich habe ja auch nicht gesagt, dass es an Eurem Treiber liegt. Hilft ja nichts, ich sehe mich jetzt mal nach einem anderen Gerät um. Eigentlich schade, wenn der Stick mal für kurze Zeit läuft hat er ein echt klasse Bild und HD funktioniert 1A.

[Sundtek]

Wie sieht es mit dem Speicherverbrauch aus?
Das sieht nach einem Kernel Memory Leak aus, einige Linux 2.6.32er Kernel Versionen waren davon betroffen; nach einiger Zeit stürzte das System ab da allmählich der Speicher ausging.

Wie erwähnt es liegt weder am Stick noch an unserer Software, das Problem sollte bei dir somit auch mit anderen Geräten auftreten. Lediglich der TV Stick transferriert konstant Daten.

Versuche eventuell eine andere Kernelversion zu verwenden, oder versuche erst mal rauszufinden woher das Problem stammt. Es ist ein Linux Kernel Problem das den Kernel Entwicklern mitgeteilt werden sollte.
Um das Problem an die Kernel Mailingliste zu senden wäre es sinnvoll Logfiles zu haben, es ist auch egal ob unsere Treiber-Applikation dort steht (eventuell steht dort ja das der Speicher ausging)
Unser Treiber ist soweit bezüglich Leaks gecheckt, da sollte nichts weiteres möglich sein.


Es wird wohl 2 Möglichkeiten geben dein Problem nachzuvollziehen:

/opt/bin/mediaclient -m DVBC -f 121000000 -M Q256 -S 6900000 #eventuell frequenz anpassen
while :; do timeout 1 cat /dev/dvb/adapter0/dvr0 > /dev/null; sleep 1; done

oder

/opt/bin/mediaclient --cat /dev/dvb/adapter0/dvr0 | /opt/bin/mediaclient --pipecount=1000
in einem anderen Fenster "top"

ersteres schaltete den Datentransfer konstant ein/aus (in etwa das was w_scan USB mäßig verursacht), mit zweiterem lässt sich überprüfen ob ein Kernel Leak existiert

[schlumf.thomas@web.de]

Versuche eventuell eine andere Kernelversion zu verwenden, oder versuche erst mal rauszufinden woher das Problem stammt.

Gute Idee. Ich habe auch noch mal im Internet gesucht. Mit dem xhci_hcd treiber scheint es öfter mal Probleme zu geben (bei den Problemkerneln 3.13.0-[78] ist xhci_hcd fest einkompiliert und lässt sich nicht abschalten). Den xhci_hcd modus konnte ich allerdings im BIOS deaktivieren - auch ein Tipp aus dem Netz. Für den nächsten Test habe ich jetzt erst mal den Kernel 3.2.0-23 installiert. Der spricht den Stick im ehci_hcd modus an. Wenn ich das richtig verstanden habe kann der xhci_hcd USB 2 und 3 der alte ehci_hcd dagegen nur USB 2. Parallel beobachte ich mal den Speicherverbrauch. Wenn es funktioniert gebe ich in 2-3 Tagen noch mal ein Update.

[Sundtek]

XHCI ist der Linux USB 3.0 Treiber, bei dem neuen XHCI USB Treiber wird USB 2.0 durch USB 3.0 durchgeschleift und das bereitet derzeit wohl die Probleme im Linux Kernel.

[schlumf.thomas@web.de]

XHCI ist der Linux USB 3.0 Treiber, bei dem neuen XHCI USB Treiber wird USB 2.0 durch USB 3.0 durchgeschleift und das bereitet derzeit wohl die Probleme im Linux Kernel.

An der Stelle noch einmal ein Feedback. Der Fehler tritt jetzt bei mir nicht mehr auf.

Falls jemand anders ein ähnliches Problem hat hier noch einmal die wichtigsten Punkte:
Das Problem kann bei dem Chipsatz Intel H87 (C2) auftreten. Das Stepping 1 (C1) wird dann wahrscheinlich auch betroffen sein. Intel hat eine Change Notification veröffentlicht (die einen anderen Fehler beschreibt), aus der man schließen kann, dass auch weitere aktuelle Chipsätze von Intel betroffen sein könnten. Falls es sich (wie von Sundtek beschrieben) um ein Hardware Problem handelt könnten auch andere Betriebssysteme betroffen sein.
https://qdms.intel.com/dm/d.aspx/C79FC2E6-6B75-4063-8687-660F4668FFC8/PCN112101-00.pdf

Unter Linux kann man das Problem in syslog (/var/log/syslog) erkennen. Wenn man folgende Einträge findet (die Nummern 3-13 und 8 sind individuell unterschiedlich), ist der xhci_hcd die Ursache.

usb 3-13: new high-speed USB device number 8 using xhci_hcd
usb 3-13: New USB device found, idVendor=2659, idProduct=1401
usb 3-13: New USB device strings: Mfr=1, Product=2, SerialNumber=3
usb 3-13: Product: MediaTV Pro Digital Home (EU)
usb 3-13: Manufacturer: Sundtek

Die einfachste Option ist xhci_hcd im Bios zu deaktivieren (damit hat man dann nur noch USB2 High speed zur Verfügung). Das hatte bei mir den netten Nebeneffekt, dass ein USB3 Kartenleser wenigstens als USB2 high-speed (60MB/sec.) erkannt wurde. Der xhci_hcd Treiber hatte diesen als USB2 full-speed (12MB/sec.) angesprochen (ja der Kartenleser ist über ein USB3 Kabel verbunden!).

Gibt es im Bios nicht die Möglichkeit xhci_hcd zu deaktivieren (auto und smart bringt da nichts, im Zweifel mal m Internet suchen...), kann man probieren, ob ein Bios update die Option hinzufügt.

Funktioniert auch das nicht, kann man versuchen den xhci_hcd in die Blacklist aufzunehmen: Dazu die Datei 
/etc/modprobe.d/blacklist-xhci_hcd.conf anlegen und
"blacklist xhci_hcd" eintragen.
Das geht allerdings nur, wenn der Treiber xhci_hcd als Modul compiliert wurde (ist im aktuellen Ubuntu Kernel leider nicht der Fall).

Gelöst ist das Problem, wenn man im syslog folgenden Eintrag findet:

aktueller Kernel (wie oben 2-1.7 und 9 ist uncharakteristisch):
usb 2-1.7: new high-speed USB device number 9 using ehci-pci
usb 2-1.7: New USB device found, idVendor=2659, idProduct=1401
usb 2-1.7: New USB device strings: Mfr=1, Product=2, SerialNumber=3
usb 2-1.7: Product: MediaTV Pro Digital Home (EU)
usb 2-1.7: Manufacturer: Sundtek

alter Kernel (wie oben 1-1.5, 4 und 14 ist uncharakteristisch):
usb 1-1.5: new high-speed USB device number 4 using ehci_hcd
input: Sundtek Ltd. Remote Control as /devices/virtual/input/input14

Viel Erfolg & vielen Dank an Sundtek für die wertvollen Hinweise!
Christoph