Seit ca. 14 tagen probleme. Ursache: Treiber problem?

[flo]

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]

Code: [Auswählen]

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

[Sundtek]

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.

[flo]

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.

[Sundtek]

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.

[flo]

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

[flo]

Du kannst folgenden Eintrag versuchen:
/etc/sundtek.conf
support_mmap=on

Was tut das? Finde nichts in --help / hier im Forum ??
LG Florian

[Sundtek]

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.

[flo]

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

[Sundtek]

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.

[flo]

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

[Sundtek]

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.

[flo]

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

[flo]

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

[Sundtek]

/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.

[flo]

/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