Probleme mit Odroid C1 / SkyTV Ultimate IV

[m.kuehner]

Hallo zusammen,

ich hatte meinen TV-Tuner SkyTV Ultimate IV eine ganze Weile völlig problemlos in Verbindung mit einem RasPI als TV-Aufnahmegerät und NAS genutzt, dann aber die "Idee" mit einem Odroid C1 mehr Tempo ins Spiel zu bringen.

Der ODROID läuft ohne TV-Karte stabil, mit TV-Karte friert er unberechenbar nach ein paar Stunden einfach ein, ohne im Syslog eine sinnvolle Info zu hinterlassen:

Code: [Auswählen]

Apr 16 06:25:57 orion vdr: [2101] [xine..put] cXinelibOsd::CanHandleAreas(): Device does not support ARGB
Apr 16 06:27:17 orion vdr: [3234] epg data writer thread started (pid=2101, tid=3234, prio=low)
Apr 16 06:27:22 orion vdr: [3234] epg data writer thread ended (pid=2101, tid=3234)
Apr 16 06:30:57 orion vdr: [2101] executing '-E 0 0 0 "" 0'
Apr 16 06:30:57 orion vdr: [2101] saved setup to /var/lib/vdr/setup.conf
Apr 16 06:31:58 orion vdr: [2101] [xine..put] cXinelibOsd::CanHandleAreas(): Device does not support ARGB
Apr 16 06:36:00 orion vdr: [2139] EPGSearch: timer conflict check started
Apr 16 06:36:00 orion vdr: [2139] EPGSearch: timer conflict check finished
Apr 16 06:36:23 orion vdr: [2137] read incomplete section - len = 4098, r = 4096
Apr 16 06:36:58 orion vdr: [2101] executing '-E 0 0 0 "" 0'
Apr 16 06:36:58 orion vdr: [2101] saved setup to /var/lib/vdr/setup.conf
Apr 16 06:37:18 orion vdr: [3251] epg data writer thread started (pid=2101, tid=3251, prio=low)
Apr 16 06:37:22 orion vdr: [3251] epg data writer thread ended (pid=2101, tid=3251)
Apr 16 06:37:59 orion vdr: [2101] [xine..put] cXinelibOsd::CanHandleAreas(): Device does not support ARGB
Apr 16 06:38:51 orion vdr: [2136] frontend 0/0 timed out while tuning to channel 44, tp 210847
Apr 16 06:39:15 orion vdr: [2136] frontend 0/0 timed out while tuning to channel 43, tp 110802
Apr 16 06:39:33 orion vdr: [2136] frontend 0/0 timed out while tuning to channel 45, tp 210847
Apr 16 06:42:59 orion vdr: [2101] executing '-E 0 0 0 "" 0'
Apr 16 06:42:59 orion vdr: [2101] saved setup to /var/lib/vdr/setup.conf
Apr 16 06:44:00 orion vdr: [2101] [xine..put] cXinelibOsd::CanHandleAreas(): Device does not support ARGB
Apr 16 06:47:19 orion vdr: [3265] epg data writer thread started (pid=2101, tid=3265, prio=low)
Apr 16 06:47:23 orion vdr: [3265] epg data writer thread ended (pid=2101, tid=3265)
Apr 16 06:49:00 orion vdr: [2101] executing '-E 0 0 0 "" 0'
Apr 16 06:49:00 orion vdr: [2101] saved setup to /var/lib/vdr/setup.conf
Apr 16 06:49:35 orion vdr: [2137] changing pids of channel 1019 from 1023+1023=2:1024=deu@3,1025=eng@3:0:32 to 1023+1023=2:1024=deu@3:0:32
Apr 16 06:50:01 orion vdr: [2101] [xine..put] cXinelibOsd::CanHandleAreas(): Device does not support ARGB
Apr 16 06:51:42 orion vdr: [2137] changing pids of channel 1050 from 767+767=27:0;771=deu@106:0:32 to 767+767=27:0;771=deu@106,772=eng@106:0:32
Apr 16 06:52:02 orion vdr: [2137] creating new channel '396 - 06:30,;' on S19.2E transponder 111758 with id 133-17-321-0
Apr 16 06:52:02 orion vdr: [2137] changing name of channel 1057 from '239 - 02:45,;' to '241 - 06:30,;'
Apr 16 06:52:02 orion vdr: [2137] creating new channel '241 - 06:45,;' on S19.2E transponder 111797 with id 133-2-251-0
Apr 16 06:52:02 orion vdr: [2137] linking channel 1054 from 1057 to 2251 1057 2252
Apr 16 06:52:23 orion vdr: [2137] changing pids of channel 1060 from 767+767=2:768=deu@3:0:32 to 767+767=2:768=deu@3,769=eng@3:0:32
Apr 16 06:54:30 orion vdr: [2137] changing pids of channel 1475 from 511+511=27:0;515=deu@106,516=eng@106:0:32 to 511+511=27:0;515=deu@106:0:32
Apr 16 06:55:01 orion vdr: [2101] executing '-E 0 0 0 "" 0'
Apr 16 06:55:01 orion vdr: [2101] saved setup to /var/lib/vdr/setup.conf
Apr 16 06:56:02 orion vdr: [2101] [xine..put] cXinelibOsd::CanHandleAreas(): Device does not support ARGB
Apr 16 06:56:43 orion vdr: [2136] frontend 0/0 timed out while tuning to channel 53, tp 112574
Apr 16 06:57:03 orion vdr: [2137] read incomplete section - len = 4098, r = 4096
Apr 16 06:57:20 orion vdr: [3282] epg data writer thread started (pid=2101, tid=3282, prio=low)
Apr 16 06:57:25 orion vdr: [3282] epg data writer thread ended (pid=2101, tid=3282)
Apr 16 06:57:36 orion vdr: [2137] changing pids of channel 1557 from 0+0=0:0:0:0 to 0+0=0:358=deu@3:0:0
Jan  1 01:00:14 orion rsyslogd: [origin software="rsyslogd" swVersion="7.4.4" x-pid="897" x-info="http://www.rsyslog.com"] start


Konfiguration:

ODROID C1 mit Ubuntu Trusty 14.04.2 frisch installiert
VDR mit Plugins epgsearch xineliboutput live
NFS
USB-HDD fest gemounted
Mediatomb DLNA

In diesem Thread wird von einem Sundtek-Mitarbeiter ein Zusammenhang mit dem CPU-Handling vermutet:
http://forum.odroid.com/viewtopic.php?f=112&t=10878#p79695

Der Sheduler steht aber bereits auf "Performance".


Den C1 hatte ich bereits beim Händler zur Prüfung und habe Ihn "ohne Befund" zurückbekommen. D. h. keine Rücknahme des C1 wegen "Fehlfunktion". Gebrauchen kann ich ihn aber ohne Nutzung des TV-Tuners auch nicht. Nahezu sicher bin ich mir, dass der Fehler erst in Verbindung mit dem TV-Tuner auftaucht. Ist nun der Tuner bzw. der Treiber nicht i.O. oder ist der Odroid C1 das Problem?

Hat jemand eine Idee für mich, wie ich mich einer Lösung annähern kann, z. B. indem ich nachweise, dass der C1 nicht sauber läuft? in den Logs kann ich leider nichts erkennen. Bitte melden, wenn Ihr ein anderes Logfile braucht.

Ach ja: Hatte bereits vor der Rücksendung auch debian wheezy und lenny sowie auch andere Netzteile mit gleichem Resultat ausprobiert. Daran sollte es also nicht liegen.

Besten Dank im Voraus für alle Ideen!

Viele Grüße
M. Kuehner

[Sundtek]

Hallo,

falls es Probleme mit dem SkyTV IV gibt bitte eine Email an kontakt at sundtek de schicken, wir registrieren die Mail und werden diese dann im Laufe der kommenden Woche beantworten.

Es kommt sehr stark darauf an wie viel Strom der LNB zieht, daher sind wir derzeit auch dabei ein Extension Board für den Tuner mit einer erweiterten LNB Versorgung herzustellen.
Wenn der LNB zu viel Strom zieht schaltet der Tuner sich aus (=Vorsichtsmaßnahme), mit dem Extensionboard kann mehr Power bereitgestellt werden.

[m.kuehner]

Danke für die schnelle Antwort. Mail ist erledigt.

[Sundtek]

Oh, ein Kernel Crash hat mit dem USB Controller Treiber zu tun! Das hat mit Sicherheit nichts mit dem Tuner zu tun.

Du hattest erwähnt das du einen Raspberry PI hast mit dem alles funktioniert?


Der Treiber hat einen Netzwerkmodus damit könntest du den Stack vom Raspberry PI verwenden:
http://support.sundtek.com/index.php/topic,178.0.html

Laut Deiner Logfile liegt der Fehler nicht in der Hardware sondern bei der USB Controller Treibersoftware welche im Linux integriert ist, da müsste sich wirklich Odroid drum kümmern.

Du kannst als Workaround mal folgendes versuchen:

/opt/bin/mediaclient --cat /dev/dvb/adapter0/dvr0 > /dev/null

das hält den Tuner aktiv und verhindert das beim USB Controller der Daten Transfer abgeschalten wird -- und genau dort vermute ich die Probleme das der USB Controller Treiber für dieses System einfach noch nicht ausgereift ist.
Da ist eigentlich der Händler in der Pflicht diesen Fehler zu beheben - oder diesen Fehler an den Hersteller weiterzuleiten und Dir Service zu bieten. Die meisten Händler haben aber kein so tiefes technisches Knowhow und testen nur oberflächlich...

[m.kuehner]

Danke für die Tipps!

Das Thema Netzwerkmodus habe ich mir angesehen. Dort steht aber leider

Vorerst ist diese Funktionalität auf DVB-T sowie DVB-C beschränkt, es werden lediglich die ausgewählten Sender über das Netzwerk übertragen.

Nachdem ich DVB-S2 nutze, habe ich nun mal stattdessen den vorgeschlagenen Workaround umgesetzt und warte nun mal, ob es hilft. Rückmeldung kommt!

Außerdem gebe ich Dir natürlich Recht mit der Einschätzung zum Support durch den Händler. Welten entfernt von Eurer Unterstützung - Danke!

[m.kuehner]

So, kurze Statusmeldung wie versprochen: Der Odroid macht immer noch Zicken, auch mit dem vorgeschlagenen Workaround bleibt er irgendwann einfach stehen.

Habe mich nun mit dem Händer geeinigt, dass das Gerät zurück geht. Werde mir einen Raspberry PI 2 besorgen und mit der langsameren Netzwerkanbindung leben ...

Danke für den Support!

[Sundtek]

Hattest du schon mal überprüft ob das Odroid System überhitzt?

So nebenbei wir arbeiten auch an unserem eigenen Mediacenter für die Tuner, sobald das fertig ist werden wir es auch auf diversen Systemen testen und dann können wir die Systeme auch besser unterstützen und den Systemherstellern Bugreports liefern.

Der neue Player wird Smart-TV ähnlich werden, aber auch ganz einfach und regulär mit normalen Linux Systemen funktionieren.

[m.kuehner]

Hallo nochmal,

kurzes Update: Hatte den Odroid C1 zurückgeschickt mit Vereinbarung für Tausch in RasbPi 2. Stattdessen erhielt ich ohne weitere Rückinfo ein Austauschgerät. Hat mich zwar geärgert, trotzdem wollte ich dem neuen Gerät eine Chance geben und habe dieses nun mit frischer Installation von Ubuntu  Trusty Tahr (Image von Hardkernel) sowie Debian Wheezy (Image aus Odroid-Forum) getestet. Leider stelle ich bei beiden OS wieder die gleichen Abstürze fest wie eingangs beschrieben.

Code: [Auswählen]

May  8 14:08:05 orion vdr: [939] warning: 2 Timer-Konflikte! Erster am 10.05. 10:24. Anzeigen?
May  8 14:08:13 orion vdr: [955] EPGSearch: check for timer conflicts - done
May  8 14:09:29 orion vdr: [2240] epg data writer thread started (pid=939, tid=2240, prio=low)
May  8 14:09:30 orion vdr: [2240] epg data writer thread ended (pid=939, tid=2240)
May  8 14:11:36 orion vdr: [943] frontend 0/0 timed out while tuning to channel 39, tp 211817
May  8 14:14:17 orion vdr: [944] channel 1 (Das Erste HD) event Fre 08.05.2015 14:10-15:00 (VPS: 08.05. 14:10) 'Rote Rosen (1953)' status 4
May  8 14:14:58 orion vdr: [944] channel 46 (Das Erste) event Fre 08.05.2015 14:10-15:00 (VPS: 08.05. 14:10) 'Rote Rosen (1953)' status 4
May  8 14:15:20 orion vdr: [944] channel 47 (KiKA) event Fre 08.05.2015 14:10-14:35 (VPS: 08.05. 14:10) 'Schloss Einstein - Erfurt' status 4
May  8 14:17:01 orion rsyslogd-2007: action 'action 17' suspended, next retry is Fri May  8 14:18:31 2015 [try http://www.rsyslog.com/e/2007 ]
May  8 14:17:01 orion CRON[2251]: (root) CMD (   cd / && run-parts --report /etc/cron.hourly)
May  8 14:19:30 orion vdr: [2256] epg data writer thread started (pid=939, tid=2256, prio=low)
May  8 14:19:32 orion vdr: [2256] epg data writer thread ended (pid=939, tid=2256)
May  8 14:19:40 orion vdr: [943] frontend 0/0 timed out while tuning to channel 39, tp 211817
May  8 14:27:43 orion vdr: [943] frontend 0/0 timed out while tuning to channel 39, tp 211817
May  8 14:29:31 orion vdr: [2268] epg data writer thread started (pid=939, tid=2268, prio=low)
May  8 14:29:33 orion vdr: [2268] epg data writer thread ended (pid=939, tid=2268)
May  8 14:35:46 orion vdr: [943] frontend 0/0 timed out while tuning to channel 39, tp 211817
^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@
^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@
^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@
^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@
^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@
^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@
^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@
^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@
^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@
^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@
^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@
^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@
^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@
^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@
^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@
^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@Jan  1 01:01:47 orion rsyslogd: [origin software="rsyslogd" swVersion="8.4.2" x-pid="605" x-info="http://www.rsyslog.com"] start
Jan  1 01:01:47 orion systemd[1]: Mounted Configuration File System.
Jan  1 01:01:47 orion systemd[1]: Started udev Coldplug all Devices.
Jan  1 01:01:47 orion systemd[1]: Started Load/Save Random Seed.
Jan  1 01:01:47 orion systemd[1]: Started Create Static Device Nodes in /dev.

Es scheint also kein Problem des einzelnen Gerätes zu sein. Habe das Gerät nun erneut zurückgeschickt. Bin gespannt, was nun passiert ...

@ Sundtek: Bis wann ist mit Eurem im letzten Posting angesprochenen Gerät zu rechnen?

Beste Grüße
Markus

[Sundtek]

Was zeigt "dmesg" an?

Das Odroid System hatte definitiv ein anderes Problem. Welchen LNB hast du?
Wenn der LNB zu viel Strom benötigt kann's Probleme geben - sollte das der Fall sein können wir den Tuner gegen ein neues Modell austauschen das wird aber noch ca 1 1/2 Wochen andauern da diese jetzt in Produktion sind.

Die neue Version verwendet einen anderen Chip für die LNB Stromversorgung und kann deutlich mehr Strom ausgeben.

[m.kuehner]

Danke für die Info. "dmesg" auf dem ODROID geht jetzt nicht mehr - habe das Gerät erneut retour geschickt, um Gutschrift gebeten und mir unabhängig davon einen Raspberry Pi 2 besorgt.
Der läuft nun schon wieder einige Tage völlig unauffällig unter Raspbian.

Nachfolgend trotzdem mal aktuelle Ausgabe von dmesg auf dem Pi2.
Stick und LNB sind ja noch die selben. Vielleicht gibt es ja Hinweise?

Code: [Auswählen]

[77421.081957] Mem-info:
[77421.081969] Normal per-cpu:
[77421.081982] CPU    0: hi:  186, btch:  31 usd:   0
[77421.081996] CPU    1: hi:  186, btch:  31 usd:   0
[77421.082009] CPU    2: hi:  186, btch:  31 usd:   0
[77421.082022] CPU    3: hi:  186, btch:  31 usd:   0
[77421.082052] active_anon:13033 inactive_anon:13489 isolated_anon:0
[77421.082052]  active_file:35608 inactive_file:155797 isolated_file:0
[77421.082052]  unevictable:0 dirty:28 writeback:0 unstable:0
[77421.082052]  free:5690 slab_reclaimable:7569 slab_unreclaimable:2817
[77421.082052]  mapped:4880 shmem:1255 pagetables:306 bounce:0
[77421.082052]  free_cma:0
[77421.082119] Normal free:22760kB min:8192kB low:10240kB high:12288kB active_anon:52132kB inactive_anon:53956kB active_file:142432kB inactive_file:623188kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:966656kB managed:949408kB mlocked:0kB dirty:112kB writeback:0kB mapped:19520kB shmem:5020kB slab_reclaimable:30276kB slab_unreclaimable:11268kB kernel_stack:1120kB pagetables:1224kB unstable:0kB bounce:0kB free_cma:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? no
[77421.082134] lowmem_reserve[]: 0 0
[77421.082157] Normal: 4677*4kB (UE) 7*8kB (ER) 0*16kB 2*32kB (R) 2*64kB (R) 1*128kB (R) 1*256kB (R) 1*512kB (R) 1*1024kB (R) 1*2048kB (R) 0*4096kB = 22924kB
[77421.082262] 193757 total pagecache pages
[77421.082277] 1030 pages in swap cache
[77421.082290] Swap cache stats: add 26872, delete 25842, find 7085/7450
[77421.082301] Free swap  = 86572kB
[77421.082311] Total swap = 102396kB
[77421.101684] 241664 pages of RAM
[77421.101714] 6053 free pages
[77421.101726] 4312 reserved pages
[77421.101736] 6020 slab pages
[77421.101746] 301583 pages shared
[77421.101756] 1030 pages swap cached
[77424.843560] mediasrv: page allocation failure: order:4, mode:0x40d0
[77424.843596] CPU: 2 PID: 682 Comm: mediasrv Not tainted 3.18.11-v7+ #781
[77424.843651] [<800172bc>] (unwind_backtrace) from [<80012f7c>] (show_stack+0x20/0x24)
[77424.843681] [<80012f7c>] (show_stack) from [<80520970>] (dump_stack+0x98/0xd8)
[77424.843712] [<80520970>] (dump_stack) from [<800f0e7c>] (warn_alloc_failed+0xd0/0x128)
[77424.843742] [<800f0e7c>] (warn_alloc_failed) from [<800f39f0>] (__alloc_pages_nodemask+0x6bc/0x970)
[77424.843765] [<800f39f0>] (__alloc_pages_nodemask) from [<800f3d78>] (alloc_kmem_pages+0x20/0x28)
[77424.843792] [<800f3d78>] (alloc_kmem_pages) from [<8010c1f4>] (kmalloc_order+0x20/0x48)
[77424.843820] [<8010c1f4>] (kmalloc_order) from [<8010c248>] (kmalloc_order_trace+0x2c/0xd4)
[77424.843848] [<8010c248>] (kmalloc_order_trace) from [<8012f028>] (__kmalloc+0x228/0x230)
[77424.843879] [<8012f028>] (__kmalloc) from [<803b373c>] (usbdev_ioctl+0x1840/0x20d4)
[77424.843907] [<803b373c>] (usbdev_ioctl) from [<8014dfe0>] (do_vfs_ioctl+0x3e0/0x5ac)
[77424.843931] [<8014dfe0>] (do_vfs_ioctl) from [<8014e1f0>] (SyS_ioctl+0x44/0x6c)
[77424.843956] [<8014e1f0>] (SyS_ioctl) from [<8000eac0>] (ret_fast_syscall+0x0/0x48)
[77424.843968] Mem-info:
[77424.843980] Normal per-cpu:
[77424.843994] CPU    0: hi:  186, btch:  31 usd:   0
[77424.844008] CPU    1: hi:  186, btch:  31 usd:   0
[77424.844021] CPU    2: hi:  186, btch:  31 usd:   0
[77424.844034] CPU    3: hi:  186, btch:  31 usd:   0
[77424.844063] active_anon:13031 inactive_anon:13489 isolated_anon:0
[77424.844063]  active_file:35619 inactive_file:155530 isolated_file:0
[77424.844063]  unevictable:0 dirty:14 writeback:0 unstable:0
[77424.844063]  free:5886 slab_reclaimable:7599 slab_unreclaimable:2872
[77424.844063]  mapped:4880 shmem:1255 pagetables:306 bounce:0
[77424.844063]  free_cma:0
[77424.844128] Normal free:23544kB min:8192kB low:10240kB high:12288kB active_anon:52124kB inactive_anon:53956kB active_file:142476kB inactive_file:622120kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:966656kB managed:949408kB mlocked:0kB dirty:56kB writeback:0kB mapped:19520kB shmem:5020kB slab_reclaimable:30396kB slab_unreclaimable:11488kB kernel_stack:1120kB pagetables:1224kB unstable:0kB bounce:0kB free_cma:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? no
[77424.844143] lowmem_reserve[]: 0 0
[77424.844166] Normal: 4897*4kB (UEM) 6*8kB (UER) 0*16kB 2*32kB (R) 2*64kB (R) 0*128kB 1*256kB (R) 1*512kB (R) 1*1024kB (R) 1*2048kB (R) 0*4096kB = 23668kB
[77424.844266] 193491 total pagecache pages
[77424.844281] 1030 pages in swap cache
[77424.844294] Swap cache stats: add 26872, delete 25842, find 7085/7450
[77424.844305] Free swap  = 86572kB
[77424.844315] Total swap = 102396kB
[77424.865188] 241664 pages of RAM
[77424.865216] 6218 free pages
[77424.865227] 4312 reserved pages
[77424.865237] 6042 slab pages
[77424.865247] 301605 pages shared
[77424.865257] 1030 pages swap cached
[77425.104222] mediasrv: page allocation failure: order:4, mode:0x40d0
[77425.104259] CPU: 3 PID: 682 Comm: mediasrv Not tainted 3.18.11-v7+ #781
[77425.104314] [<800172bc>] (unwind_backtrace) from [<80012f7c>] (show_stack+0x20/0x24)
[77425.104343] [<80012f7c>] (show_stack) from [<80520970>] (dump_stack+0x98/0xd8)
[77425.104374] [<80520970>] (dump_stack) from [<800f0e7c>] (warn_alloc_failed+0xd0/0x128)
[77425.104404] [<800f0e7c>] (warn_alloc_failed) from [<800f39f0>] (__alloc_pages_nodemask+0x6bc/0x970)
[77425.104427] [<800f39f0>] (__alloc_pages_nodemask) from [<800f3d78>] (alloc_kmem_pages+0x20/0x28)
[77425.104454] [<800f3d78>] (alloc_kmem_pages) from [<8010c1f4>] (kmalloc_order+0x20/0x48)
[77425.104482] [<8010c1f4>] (kmalloc_order) from [<8010c248>] (kmalloc_order_trace+0x2c/0xd4)
[77425.104510] [<8010c248>] (kmalloc_order_trace) from [<8012f028>] (__kmalloc+0x228/0x230)
[77425.104540] [<8012f028>] (__kmalloc) from [<803b373c>] (usbdev_ioctl+0x1840/0x20d4)
[77425.104568] [<803b373c>] (usbdev_ioctl) from [<8014dfe0>] (do_vfs_ioctl+0x3e0/0x5ac)
[77425.104592] [<8014dfe0>] (do_vfs_ioctl) from [<8014e1f0>] (SyS_ioctl+0x44/0x6c)
[77425.104617] [<8014e1f0>] (SyS_ioctl) from [<8000eac0>] (ret_fast_syscall+0x0/0x48)
[77425.104629] Mem-info:
[77425.104641] Normal per-cpu:
[77425.104655] CPU    0: hi:  186, btch:  31 usd:   0
[77425.104668] CPU    1: hi:  186, btch:  31 usd:   0
[77425.104682] CPU    2: hi:  186, btch:  31 usd:   0
[77425.104695] CPU    3: hi:  186, btch:  31 usd:   0
[77425.104724] active_anon:13031 inactive_anon:13489 isolated_anon:0
[77425.104724]  active_file:35619 inactive_file:155827 isolated_file:0
[77425.104724]  unevictable:0 dirty:14 writeback:0 unstable:0
[77425.104724]  free:5624 slab_reclaimable:7599 slab_unreclaimable:2856
[77425.104724]  mapped:4880 shmem:1255 pagetables:306 bounce:0
[77425.104724]  free_cma:0
[77425.104788] Normal free:22496kB min:8192kB low:10240kB high:12288kB active_anon:52124kB inactive_anon:53956kB active_file:142476kB inactive_file:623308kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:966656kB managed:949408kB mlocked:0kB dirty:56kB writeback:0kB mapped:19520kB shmem:5020kB slab_reclaimable:30396kB slab_unreclaimable:11424kB kernel_stack:1120kB pagetables:1224kB unstable:0kB bounce:0kB free_cma:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? no
[77425.104803] lowmem_reserve[]: 0 0
[77425.104827] Normal: 4627*4kB (UEM) 5*8kB (UMR) 1*16kB (R) 1*32kB (R) 1*64kB (R) 1*128kB (R) 1*256kB (R) 1*512kB (R) 1*1024kB (R) 1*2048kB (R) 0*4096kB = 22628kB
[77425.104936] 193787 total pagecache pages
[77425.104951] 1030 pages in swap cache
[77425.104964] Swap cache stats: add 26872, delete 25842, find 7085/7450
[77425.104975] Free swap  = 86572kB
[77425.104985] Total swap = 102396kB
[77425.123866] 241664 pages of RAM
[77425.123894] 5937 free pages
[77425.123906] 4312 reserved pages
[77425.123916] 6041 slab pages
[77425.123926] 301630 pages shared
[77425.123936] 1030 pages swap cached

 

[Sundtek]

--> Der DMA fähige Speicher ist ausgegangen, was läuft denn noch da drauf?

Das Problem sollte sich lösen lassen, du musst aber wissen oder rausfinden was dort "amok" gelaufen ist und den Speicher vollgeschrieben hat.
Das hat jetzt mit dem LNB bzw. Stick nichts zu tun.


Wir hatten den RPI2 auch testeweise laufen, und das eine Woche lang ohne Probleme (bis wir ihn wieder ausgeschalten haben).

....
usbdev_ioctl) from [<8014dfe0>] (do_vfs_ioctl+0x3e0/0x5ac)
....

wenn den Steuerbefehlen schon mal der Speicher ausgeht dann war der RPI an der Stelle tatsächlich vom Speicher her absolut am Ende (irgendwelche Applikationen haben zu viel Speicher vom System reserviert)

Wenn du dir diese Meldungen genauer ansiehst findest du dort immer etwas mit *kmalloc* oder *alloc* was soviel bedeutet wie "System gib mir bitte etwas Speicher". Das Schlug fehl weil der Speicher nicht mehr frei war und dadurch konnte die Kommunikation mit dem Gerät nicht durchgeführt werden. Also hier liegt kein Treiberproblem vor.