Sundtek Support Forum
Deutsch => Sundtek MediaTV Pro => Treiber => Thema gestartet von: flo am Juni 11, 2017, 06:30:14 Nachmittag
-
NetInstall (alle Systeme): http://www.sundtek.de/media/sundtek_netinst.sh (empfohlen) (70 KByte)
Aktuell installiert.
Hi,
seit ein paar Tagen (ca. zwei Wochen) spinnen meine TV Aufnamen. Es "Ruckelt". Zeitweise scheint es so als wäre kein Empfang vorhanden. Auch streams via vdr stream.
Syslog meldet allerdings nun endlich mal etwas brauchbares [1].
System: rpi 2, sundtek dongels 1.2.1 und 1.3.1 via DVBC
[1]
Jun 11 17:54:05 pi2 recordingaction[2304]: executing /usr/share/vdr/recording-hooks/R90.custom before recording /media/recordings/vdr/test/ZDF2/2017-06-11.17.00.3-0.rec as shell script
Jun 11 17:54:05 pi2 vdr[2227]: [2227] record /media/recordings/vdr/test/ZDF2/2017-06-11.17.00.3-0.rec
Jun 11 17:54:07 pi2 vdr[2227]: [2306] executing '/usr/lib/vdr/vdr-recordingaction started "/media/recordings/vdr/test/ZDF2/2017-06-11.17.00.3-0.rec"'
Jun 11 17:54:07 pi2 recordingaction[2314]: executing /usr/share/vdr/recording-hooks/R90.custom as shell script
... some timer ....
Jun 11 17:54:20 pi2 kernel: mediasrv: page allocation failure: order:4, mode:0x24040c0(GFP_KERNEL|__GFP_COMP)
Jun 11 17:54:20 pi2 kernel: CPU: 3 PID: 2132 Comm: mediasrv Not tainted 4.9.24-v7+ #993
Jun 11 17:54:20 pi2 kernel: Hardware name: BCM2835
Jun 11 17:54:20 pi2 kernel: [<8010fb3c>] (unwind_backtrace) from [<8010c058>] (show_stack+0x20/0x24)
Jun 11 17:54:20 pi2 kernel: [<8010c058>] (show_stack) from [<80455200>] (dump_stack+0xd4/0x118)
Jun 11 17:54:20 pi2 kernel: [<80455200>] (dump_stack) from [<80214b3c>] (warn_alloc+0x10c/0x120)
Jun 11 17:54:20 pi2 kernel: [<80214b3c>] (warn_alloc) from [<8021504c>] (__alloc_pages_nodemask+0x450/0xdd0)
Jun 11 17:54:20 pi2 kernel: [<8021504c>] (__alloc_pages_nodemask) from [<80234cfc>] (kmalloc_order+0x28/0x78)
Jun 11 17:54:20 pi2 kernel: [<80234cfc>] (kmalloc_order) from [<80234d78>] (kmalloc_order_trace+0x2c/0xd0)
Jun 11 17:54:20 pi2 kernel: [<80234d78>] (kmalloc_order_trace) from [<8025ddd8>] (__kmalloc+0x218/0x274)
Jun 11 17:54:20 pi2 kernel: [<8025ddd8>] (__kmalloc) from [<80565fd8>] (proc_do_submiturb+0xd74/0xeac)
Jun 11 17:54:20 pi2 kernel: [<80565fd8>] (proc_do_submiturb) from [<80566978>] (usbdev_ioctl+0x868/0x1aa0)
Jun 11 17:54:20 pi2 kernel: [<80566978>] (usbdev_ioctl) from [<802831cc>] (do_vfs_ioctl+0xac/0x820)
Jun 11 17:54:20 pi2 kernel: [<802831cc>] (do_vfs_ioctl) from [<80283984>] (SyS_ioctl+0x44/0x6c)
Jun 11 17:54:20 pi2 kernel: [<80283984>] (SyS_ioctl) from [<801080c0>] (ret_fast_syscall+0x0/0x1c)
Jun 11 17:54:20 pi2 kernel: Mem-Info:
Jun 11 17:54:20 pi2 kernel: active_anon:48543 inactive_anon:15851 isolated_anon:0
active_file:86662 inactive_file:54272 isolated_file:0
unevictable:2 dirty:332 writeback:0 unstable:9000
slab_reclaimable:13600 slab_unreclaimable:7130
mapped:15962 shmem:11410 pagetables:567 bounce:0
free:5398 free_pcp:243 free_cma:0
Jun 11 17:54:20 pi2 kernel: Node 0 active_anon:194928kB inactive_anon:63404kB active_file:346656kB inactive_file:217076kB unevictable:8kB isolated(anon):0kB isolated(file):0kB mapped:63856kB dirty:1328kB writeback:0kB shmem:45640kB writeback_tmp:0kB unstable:36000kB pages_scanned:0 all_unreclaimable? no
Jun 11 17:54:20 pi2 kernel: Normal free:20844kB min:3868kB low:4832kB high:5796kB active_anon:194936kB inactive_anon:63404kB active_file:346676kB inactive_file:217256kB unevictable:8kB writepending:1624kB present:966656kB managed:945524kB mlocked:8kB slab_reclaimable:54400kB slab_unreclaimable:28520kB kernel_stack:1384kB pagetables:2268kB bounce:0kB free_pcp:600kB local_pcp:0kB free_cma:0kB
Jun 11 17:54:21 pi2 kernel: lowmem_reserve[]: 0 0
Jun 11 17:54:21 pi2 kernel: Normal: 388*4kB (MH) 196*8kB (UEH) 529*16kB (UH) 210*32kB (UEH) 4*64kB (H) 1*128kB (H) 0*256kB 0*512kB 1*1024kB (H) 0*2048kB 0*4096kB = 19712kB
Jun 11 17:54:21 pi2 kernel: 152624 total pagecache pages
Jun 11 17:54:21 pi2 kernel: 169 pages in swap cache
Jun 11 17:54:21 pi2 kernel: Swap cache stats: add 3875, delete 3706, find 806/911
Jun 11 17:54:21 pi2 kernel: Free swap = 1896652kB
Jun 11 17:54:21 pi2 kernel: Total swap = 1910780kB
Jun 11 17:54:21 pi2 kernel: 241664 pages RAM
Jun 11 17:54:21 pi2 kernel: 0 pages HighMem/MovableOnly
Jun 11 17:54:21 pi2 kernel: 5283 pages reserved
Jun 11 17:54:21 pi2 kernel: 2048 pages cma reserved
-- weitere vdr status logs ---
Danke für info, feedback zur möglichen Lösung :)
LG Florian
-
Hi,
schau dir den Speicherverbrauch an (z.B mit top)
In der Fehlermeldung tritt ja ein __kmalloc Fehler auf, sprich das System konnte dem Tuner keinen freien Speicher mehr geben.
-
Hi, danke für Info!
htop ist in Verwendung ~200M von 900M in use, swap 18MB von 2G.... ich tippe auf den kernel der vermutlich zu neu ist , kann es nicht einschätzen.
-
Du kannst folgenden Eintrag versuchen:
/etc/sundtek.conf
support_mmap=on
Wobei das auf ARM Systemen üblicherweise ausgeschalten ist da dort noch ein Bug im Linuxkernel ist.
Allokationsprobleme sind ausnahmslos Linux Kernel Probleme, an der Stelle haben wir ansonsten nicht viel Einfluss.
Ich sehe aber, dass du dort auch swap eingerichtet hast - das mag einerseits gut sein andererseits ist es aber auch nicht so gut.
Es geht hier um DMA-fähigen Speicher der nicht verfügbar ist. SWAP Speicher ist kein DMA-fähiger Speicher.
-
Hi!
Danke für Info, das hat meinen verdacht bestätigt :)
swap wurde von rasbian angelegt.. tiefergehend habe ich keine Erfahrungen/ Wissen. :(
Aber: Nach dem ich das gefährliche "rpi-update" durchführte und nun eine neue Kernel Version ist das verhalten ein wenig besser. Ich bleib drann!
LG Florian
-
Du kannst folgenden Eintrag versuchen:
/etc/sundtek.conf
support_mmap=on
Was tut das? Finde nichts in --help / hier im Forum ??
LG Florian
-
Es versucht mmap zu verwenden für USB, wobei das nicht auf allen Architekturen funktioniert daher ist es derzeit auch nicht dokumentiert. Wenn's mal stabil wird im Linux Kernel dann wird's by default eingeschalten.
-
Danke allen für Hinweise!
rpi-update auf f4cb84915874f32d88e2bfe793620d7afe25c755 hats gebracht. Kernel von ca. 03/2017 lässt wieder alles zu... für sundtek treiber und vdr zumindest :)
Kernel Linux pi2 4.9.13-v7+ #974 SMP Wed Mar 1 20:09:48 GMT 2017 armv7l GNU/Linux
Ticket kann geschlossen werden.
LG Florian
-
Sollte das Problem weiter auftreten melde dich einfach via Chat wir könnten die allokierten Speicherblöcke etwas kleiner machen (hat alles seine Vor- und Nachteile). Früher gab's da mal ein Limit von 16K das wurde aufgehoben da es die Performance verschlechtert hat.
Das Problem ist einfach das kein Speicherblock in der angeforderten Größe verfügbar war, kann also unter Umständen durchaus noch einmal auftreten wenn der DMA-fähige Speicher knapp wird.
-
Sollte das Problem weiter auftreten melde dich einfach via Chat...
Danke! Der Kernel tuts. Hab die rpi Leute in github via "issue" bereits informiert und wir gehen die kernels gerade durch :)
LG Florian
-
Wenn Du schon am Testen bist, kannst Du das auch testen:
support_mmap=on (in /etc/sundtek.conf)?
Führt das noch immer zu Störungen auf dem ARM? Auf Intel Systemen klappt's soweit.
-
Wenn Du schon am Testen bist, kannst Du das auch testen:
support_mmap=on (in /etc/sundtek.conf)?
Führt das noch immer zu Störungen auf dem ARM? Auf Intel Systemen klappt's soweit.
:)
Bisher find ich nichts was die Einstellung pro/contra bewirkt. Ist drin mit keiner Veränderung/ Auffälligkeit.
Teil 1:
https://github.com/Hexxeh/rpi-firmware/issues/151#issuecomment-307776323
:)
-
Wenn Du schon am Testen bist, kannst Du das auch testen:
support_mmap=on (in /etc/sundtek.conf)?
Führt das noch immer zu Störungen auf dem ARM? Auf Intel Systemen klappt's soweit.
Teil 1+2
https://github.com/Hexxeh/rpi-firmware/issues/151#issuecomment-307776323
Neuere Kernels machen es zickiger. Es sind zwar derzeit keine mem Fehler mehr aufgetreten aber das ist vermutlich eine Zeitfrage.
Ich bin raus mit testen. Der besagt Kernel, s.o. oder im link, läuft erst einmal.
LG
-
/dev/dvb/adapter0/frontend0 doesn't support the extended media API
entspricht soviel wie der Treiber ist nicht gestartet.
/etc/sundtek.conf
device_attach=service tvheadend restart
TVHeadend würde dann neu gestartet werden sobald der Tuner wirklich komplett initialisiert wurde.
-
/etc/sundtek.conf
device_attach=service tvheadend restart
Danke, guter Hinweis. Bringt aber nix in meinem Fall. (ich bleib aber beim VDR!)
Habe wieder eine weitere Version runter gespielt und HD ist derzeit zickig. Bild bleibt ein zwei sekunden stehen und wie immer: Nix in den syslog, dmesg etc. boa... das nervt :)
Langsam bekomme ich den Eindruck als würde einer meiner Dongels spinnen: 1.2.1 und 1.3.1 sind im Spiel.
Wie kann ich herausfinden welcher Dongel was macht? mediaclient --lc reicht nicht :/
Lg Florian
-
/opt/bin/mediaclient --readsignal=0 -d /dev/dvb/adapter0/frontend0 zeigt dir die Signalstatistik an.
-
/opt/bin/mediaclient --readsignal=0 -d /dev/dvb/adapter0/frontend0 zeigt dir die Signalstatistik an.
Danke
Was sagt mir das?:
SIGNAL: [............................. ] ( 88%) BER: 0 CNR: 36,70 FREQ: 114000000 Hz LOCKED: YES SYM: 6900000 MOD: QAM256
SIGNAL: [............................. ] ( 88%) BER: 1 CNR: 35,70 FREQ: 114000000 Hz LOCKED: YES SYM: 6900000 MOD: QAM256
Einziger grober unterschied hin und wieder BER 1 vs. 0
Bei 1 scheinen Fehler und das Ruckeln erkennbar zu sein. Beide dongels gleichzeitig. :?/
Nachtrag: Weder noch nicht zu 100% feststellbar... Woran denn? CNR?
Gibt es Hinweise wie ich dem auf die schliche kommen kann?
Gemäss der Empfangsstärke sollte alles klappen es sei denn das signal kommt von kabeldeutschland bereits so bei mir defekt an. Wie kann ich all diese Sachen testen? ???
Gruß Florian
-
Das ist doch n Raspberry PI? Nimm n längeres USB Kabel das du die Tuner weiter wegbekommst vom Raspberry.
Kommt wohl auf mehrere Faktoren an es wurde schon mehrfach erwähnt im Forum und ein längeres USB Kabel hat -- im Fehlerfall --
immer Abhilfe geschaffen bei Problemen auf 114 MHz.
-
Das ist doch n Raspberry PI? Nimm n längeres USB Kabel das du die Tuner weiter wegbekommst vom Raspberry.
Kommt wohl auf mehrere Faktoren an es wurde schon mehrfach erwähnt im Forum und ein längeres USB Kabel hat -- im Fehlerfall --
immer Abhilfe geschaffen bei Problemen auf 114 MHz.
Huch ??? ... danke, ich schau mal! melde mich :-D
-
Abhilfe geschaffen bei Problemen auf 114 MHz.
Gesagt, getan und für erledigt erklärt ;D
Andere frage: Metallgehäuse für de rpi ?
Mich wundert es dennoch das es ohne Änderungen des Standortes plötzlich deutliche Fehler gibt. Wenn auch Techniker, kein Elektroniker :)
-
Abhilfe geschaffen bei Problemen auf 114 MHz.
Gesagt, getan und für erledigt erklärt ;D
Andere frage: Metallgehäuse für de rpi ?
Mich wundert es dennoch das es ohne Änderungen des Standortes plötzlich deutliche Fehler gibt. Wenn auch Techniker, kein Elektroniker :)
Der Raspberry PI würde wohl den EMV Test nicht bestehen wenn dieser als TV Board im Massenmarkt benutzt werden würde.
Je nachdem für was man ein Board spezifiziert müssen gewisse Richtlinien eingehalten werden. Der Raspberry PI ist ja als Hobby oder Bastlerboard eingestuft.
Metallgehäuse und die Masse raufführen und das Ganze auch ordentlich erden, Ringkern um das USB Kabel kann alles helfen.
Zudem die Masse des TV Kabels eventuell auch ein anderes Potential haben kann oder es zu Masseschleifen kommen kann (das waren bei AnalogTV Zeiten die horizontal verlaufenden Streifen im Bild).
-
Leider immer noch nicht.
Der neuere Dongle (1.3.1) hat scheinbar ein technisches Problem das ich nicht finden kann.
Ich habe jetzt ein paar Tage die Dongels an einem rpi und einem normalen Rechner gehabt.
Der neuere Dongle will immer wieder mal zickig sein.
Mit sundek.conf oder ohne ist wurscht. Es Ruckelt nur an dem einem Dongel.
Was für Möglichkeiten habe ich oder sollte ich ihn zurück schicken?
LG Florian
cat /etc/sundtek.conf
-->--
# For rpi
# /opt/bin/mediaclient -P on -d /dev/dvb/adapter0/frontend0
# http://support.sundtek.com/index.php/topic,1573.0.html
use_hwpidfilter=on
# http://support.sundtek.com/index.php/topic,2215.0.html
support_mmap=on
device_attach=service vdr restart
--<--
-
support_mmap=on
schalte das aus, das bringt auf einigen Linux Systemen definitiv Störungen, kommt auf die Kernelversion drauf an (deshalb ist es by default auch aus).
Identifiziere genau welcher Sender das Problem hat, überprüfe die Signalstärke. Ist es nur eine Frequenz oder mehrere? Wenn nur eine Frequenz betroffen ist dann liegt eine Signalstörung / ev. Reflexion vor.