mediasrv: page allocation failure: order:5, mode:0x40cc0(GFP_KERNEL|__GFP_COMP)

[MarkusEh]

Hallo,

Ich habe einen Raspberry Pi 4 Model B Rev 1.4 (DT) mit 8 GB RAM und erhalte diesen Fehler:

Code: [Auswählen]

mediasrv: page allocation failure: order:5, mode:0x40cc0(GFP_KERNEL|__GFP_COMP), nodemask=(null),cpuset=/,mems_allowed=0
CPU: 3 PID: 19763 Comm: mediasrv Tainted: G         C        5.4.51-v8+ #1333
Raspberry Pi OS, 64 bit Version.

8 GB RAM sollten doch reichen (?). Muss ich das System speziell konfigurieren, damit der RAM auch von mediasrv genutzt werden kann?

~Markus

[Sundtek]

Hast Du dazu mehr Informationen?

wir allokieren eigentlich keinen Speicher im Kernel (können wir auch überhaupt nicht direkt mit der Treiber-Applikation), wir stellen dem Kernel eine Anfrage er allokiert es intern und kopiert die Daten dann einfach zurück zu unserem Treiber.

Es gibt mittlerweile die memory mapping option in USB, ist bei uns im Treiber aber ausgeschalten da sie nicht auf allen Architekturen problemlos funktioniert. Wäre eventuell eine Möglichkeit das zu testen um noch weniger Speicher zu benötigen.
Ich weiß auch nicht welchen Tuner Du da verwendest (ältere und aktuelle fordern leicht unterschiedliche Paketgrößen an).

[MarkusEh]

Ich verwende ältere USB Sticks.

> Hast Du dazu mehr Informationen
Welche Informationen braucht ihr?

[Sundtek]

Den vollen Auszug von dmesg.

Ich denke unser Treiber für die alten Geräte versucht dort ca 61kbyte durchgängigen physikalischen Speicher zu erhalten und das System scheint zu fragmentiert zu sein sodass so ein durchgängiger Block nicht reserviert werden kann.
Das geht aber vor allem vom USB Controller Treiber aus, natürlich getriggert von unserem Applikationstreiber, die obere Ausgabe zeigt ja nur dass unsere Applikation zu dieser Zeit auf den USB Controller zugegriffen hat.

Man könnte da versuchen den Speicher etwas zu verkleinern, was in Deinem Fall am Besten ist müsstest Du schätze ich probieren.
Die aktuellen Standart-Werte im Treiber haben sich über die Jahre eigentlich für 99.9% der Systeme bewährt (Ausnahmen wird's wohl immer irgendwo geben).

[MarkusEh]

Hallo,

Hier mal die Log Einträge:

Code: [Auswählen]

Oct 30 22:23:00 rpi4s kernel: [543176.528745] mediasrv: page allocation failure: order:5, mode:0x40cc0(GFP_KERNEL|__GFP_COMP), nodemask=(null),cpuset=/,mems_allowed=0
Oct 30 22:23:00 rpi4s kernel: [543176.528764] CPU: 1 PID: 20689 Comm: mediasrv Tainted: G         C        5.4.51-v8+ #1333
Oct 30 22:23:00 rpi4s kernel: [543176.528766] Hardware name: Raspberry Pi 4 Model B Rev 1.4 (DT)
Oct 30 22:23:00 rpi4s kernel: [543176.528769] Call trace:
Oct 30 22:23:00 rpi4s kernel: [543176.528779]  dump_backtrace+0x0/0x150
Oct 30 22:23:00 rpi4s kernel: [543176.528782]  show_stack+0x24/0x30
Oct 30 22:23:00 rpi4s kernel: [543176.528787]  dump_stack+0xd8/0x13c
Oct 30 22:23:00 rpi4s kernel: [543176.528792]  warn_alloc+0xf4/0x158
Oct 30 22:23:00 rpi4s kernel: [543176.528796]  __alloc_pages_slowpath+0xc70/0xcc8
Oct 30 22:23:00 rpi4s kernel: [543176.528799]  __alloc_pages_nodemask+0x2b8/0x338
Oct 30 22:23:00 rpi4s kernel: [543176.528804]  kmalloc_order+0x30/0x90
Oct 30 22:23:00 rpi4s kernel: [543176.528807]  kmalloc_order_trace+0x3c/0x128
Oct 30 22:23:00 rpi4s kernel: [543176.528812]  __kmalloc+0x328/0x3a0
Oct 30 22:23:00 rpi4s kernel: [543176.528818]  proc_do_submiturb+0xcbc/0xe28
Oct 30 22:23:00 rpi4s kernel: [543176.528822]  usbdev_do_ioctl+0x1228/0x1af0
Oct 30 22:23:00 rpi4s kernel: [543176.528825]  usbdev_ioctl+0x34/0x48
Oct 30 22:23:00 rpi4s kernel: [543176.528831]  do_vfs_ioctl+0xc8/0xa08
Oct 30 22:23:00 rpi4s kernel: [543176.528835]  ksys_ioctl+0x50/0x80
Oct 30 22:23:00 rpi4s kernel: [543176.528839]  __arm64_sys_ioctl+0x28/0x38
Oct 30 22:23:00 rpi4s kernel: [543176.528843]  el0_svc_common.constprop.1+0xe0/0x1a8
Oct 30 22:23:00 rpi4s kernel: [543176.528847]  el0_svc_handler+0x34/0xa0
Oct 30 22:23:00 rpi4s kernel: [543176.528851]  el0_svc+0x8/0xc
Oct 30 22:23:00 rpi4s kernel: [543176.528854] Mem-Info:
Oct 30 22:23:00 rpi4s kernel: [543176.528863] active_anon:23250 inactive_anon:64746 isolated_anon:0
Oct 30 22:23:00 rpi4s kernel: [543176.528863]  active_file:449504 inactive_file:1377208 isolated_file:0
Oct 30 22:23:00 rpi4s kernel: [543176.528863]  unevictable:4 dirty:6585 writeback:0 unstable:0
Oct 30 22:23:00 rpi4s kernel: [543176.528863]  slab_reclaimable:33240 slab_unreclaimable:8987
Oct 30 22:23:00 rpi4s kernel: [543176.528863]  mapped:15529 shmem:2416 pagetables:785 bounce:0
Oct 30 22:23:00 rpi4s kernel: [543176.528863]  free:22390 free_pcp:1410 free_cma:2301
Oct 30 22:23:00 rpi4s kernel: [543176.528871] Node 0 active_anon:93000kB inactive_anon:258984kB active_file:1798016kB inactive_file:5508832kB unevictable:16kB isolated(anon):0kB isolated(file):0kB mapped:62116kB dirty:26340kB writeback:0kB shmem:9664kB writeback_tmp:0kB unstable:0kB all_unreclaimable? no
Oct 30 22:23:00 rpi4s kernel: [543176.528879] DMA free:32680kB min:1820kB low:2708kB high:3596kB active_anon:2640kB inactive_anon:33448kB active_file:521064kB inactive_file:276448kB unevictable:0kB writepending:44kB present:970752kB managed:889928kB mlocked:0kB kernel_stack:32kB pagetables:248kB bounce:0kB free_pcp:1464kB local_pcp:740kB free_cma:9204kB
Oct 30 22:23:00 rpi4s kernel: [543176.528882] lowmem_reserve[]: 0 3008 6947 6947
Oct 30 22:23:00 rpi4s kernel: [543176.528895] DMA32 free:31712kB min:25000kB low:28080kB high:31160kB active_anon:49076kB inactive_anon:68052kB active_file:713320kB inactive_file:2153960kB unevictable:0kB writepending:1328kB present:3080192kB managed:3080192kB mlocked:0kB kernel_stack:144kB pagetables:204kB bounce:0kB free_pcp:1580kB local_pcp:648kB free_cma:0kB
Oct 30 22:23:00 rpi4s kernel: [543176.528898] lowmem_reserve[]: 0 0 3939 3939
Oct 30 22:23:00 rpi4s kernel: [543176.528911] Normal free:25168kB min:32736kB low:36768kB high:40800kB active_anon:41284kB inactive_anon:157484kB active_file:563632kB inactive_file:3079008kB unevictable:16kB writepending:24968kB present:4194304kB managed:4033672kB mlocked:16kB kernel_stack:2944kB pagetables:2688kB bounce:0kB free_pcp:2724kB local_pcp:1372kB free_cma:0kB
Oct 30 22:23:00 rpi4s kernel: [543176.528914] lowmem_reserve[]: 0 0 0 0
Oct 30 22:23:00 rpi4s kernel: [543176.528922] DMA: 999*4kB (UMEC) 370*8kB (UMEC) 351*16kB (UMEC) 182*32kB (UME) 50*64kB (UE) 15*128kB (UM) 5*256kB (U) 2*512kB (ME) 1*1024kB (C) 1*2048kB (C) 1*4096kB (C) = 32988kB
Oct 30 22:23:00 rpi4s kernel: [543176.528955] DMA32: 116*4kB (ME) 161*8kB (E) 645*16kB (UE) 378*32kB (UE) 118*64kB (UE) 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 31720kB
Oct 30 22:23:00 rpi4s kernel: [543176.528979] Normal: 121*4kB (UM) 163*8kB (UME) 511*16kB (UME) 224*32kB (UME) 105*64kB (UME) 8*128kB (UM) 3*256kB (M) 0*512kB 0*1024kB 0*2048kB 0*4096kB = 25644kB
Oct 30 22:23:00 rpi4s kernel: [543176.529006] 1829221 total pagecache pages
Oct 30 22:23:00 rpi4s kernel: [543176.529011] 174 pages in swap cache
Oct 30 22:23:00 rpi4s kernel: [543176.529015] Swap cache stats: add 1264, delete 1090, find 1478/1565
Oct 30 22:23:00 rpi4s kernel: [543176.529018] Free swap  = 97532kB
Oct 30 22:23:00 rpi4s kernel: [543176.529021] Total swap = 102396kB
Oct 30 22:23:00 rpi4s kernel: [543176.529024] 2061312 pages RAM
Oct 30 22:23:00 rpi4s kernel: [543176.529027] 0 pages HighMem/MovableOnly
Oct 30 22:23:00 rpi4s kernel: [543176.529031] 60364 pages reserved
Oct 30 22:23:00 rpi4s kernel: [543176.529034] 65536 pages cma reserved


[Sundtek]

Welcher Tuner ist das genau? (damit wir den Treiber zuordnen können). Dem System ist der DMA Speicher ausgegangen, was auch wieder mehrere Ursachen haben kann.

Eine mögliche Lösung bzw. Workaround wäre eventuell den von uns angeforderten Speicher zu verkleinern.
Mit der Zeit fragmentiert das System, der Speicher ist zwar vorhanden aber nicht mehr in einem Stück/durchgehend in der angeforderten Blockgröße.

Es kommt drauf an welchen Tuner Du da verwendest, da wir 3 verschiedene Haupttreiber im Paket haben gibt es bei allen drei geringfügig unterschiedliche Parameter.

/opt/bin/mediaclient -e

[MarkusEh]

Hi,

Ich habe jetzt den Sundtek SkyTV Dual 2x (DVB-S/S2/S2X) gekauft, die ca. 9 Jahre alten Sticks haben zu viele Probleme gemacht.
Damit ist dieser Fehler nicht mehr aufgetreten.

~Markus

[Sundtek]

Habe mir das jetzt genauer angesehen, die neuen Tuner verwenden aktuell einen Puffer von 40KByte, die alten Tuner verwenden einen Puffer von 65 Kbyte.
Es geht hier um durchgängigen physikalischen Speicher den Linux hier reserviert, anscheinend führt das bei Deiner Konstellation zu einem Problem falls Du möchtest können wir Dir nen Test-Treiber mit 40-50Kbyte für die alten Tuner bereitstellen.
Mit den 65 KByte sind wir eigentlich fast 10 Jahre gut gefahren.

Unsere Schnittstelle ist lediglich ein Aufruf von ioctl() .. in der Logfile sieht man dann was Linux im Hintergrund macht und bei kmalloc wird versucht der Speicher zu reservieren.

[MarkusEh]

Hi,

Ich habe die Sticks jetzt auf meinem anderen Rechner, mit ubuntu focal.
/opt/bin/mediaclient -e

**** List of Media Hardware Devices ****
device 0: [Sundtek SkyTV Ultimate II (USB 2.0)]  DVB-S/S2, REMOTE-CONTROL
  [INFO]:
     STATUS: ACTIVE
  [BUS]:
     ID: 2-3
  [SERIAL]:
     ID: U110927104102
  [DVB-S/S2]:
     FESTATUS: STANDBY
     FRONTEND: /dev/dvb/adapter0/frontend0
     DVR: /dev/dvb/adapter0/dvr0
     DMX: /dev/dvb/adapter0/demux0
  [REMOTECONTROL]:
     INPUT0: /dev/mediainput0

device 1: [Sundtek SkyTV Ultimate II (USB 2.0)]  DVB-S/S2, REMOTE-CONTROL
  [INFO]:
     STATUS: ACTIVE
  [BUS]:
     ID: 2-6
  [SERIAL]:
     ID: U110927104037
  [DVB-S/S2]:
     FESTATUS: STANDBY
     FRONTEND: /dev/dvb/adapter1/frontend0
     DVR: /dev/dvb/adapter1/dvr0
     DMX: /dev/dvb/adapter1/demux0
  [REMOTECONTROL]:
     INPUT0: /dev/mediainput1

Einen Testtreiber würde ich ausprobieren.

~ Markus