Jump to content


Photo

[SOLVED] Problems watching broadcast being recorded (gbue4k)


  • Please log in to reply
3 replies to this topic

#1 meatop

  • Member
  • 13 posts

0
Neutral

Posted 22 December 2019 - 23:04

On my gbue4k with freshly installed OpenPLi 7.2, I got distortions (artifacts, short stops) when watching a broadcast while it was recorded. Watching a recording while a different broadcast was being recorded didn't show any problems.

 

For each distortion, I found basically these messages in the log:

 

gbue4k user.warn kernel: [24938.598392] enigma2: page allocation failure: order:5, mode:0x2040d0                                                             
gbue4k user.warn kernel: [24938.604789] CPU: 1 PID: 6503 Comm: enigma2 Tainted: P           O    4.1.20-1.9 #1                                               
gbue4k user.warn kernel: [24938.612369] Hardware name: Broadcom STB (Flattened Device Tree)                                                                  
gbue4k user.warn kernel: [24938.618315] [<c001795c>] (unwind_backtrace) from [<c001323c>] (show_stack+0x10/0x14)                                             
gbue4k user.warn kernel: [24938.626079] [<c001323c>] (show_stack) from [<c065fb8c>] (dump_stack+0x84/0x98)                                                   
gbue4k user.warn kernel: [24938.633317] [<c065fb8c>] (dump_stack) from [<c00a8218>] (warn_alloc_failed+0xe4/0x120)                                           
gbue4k user.warn kernel: [24938.641248] [<c00a8218>] (warn_alloc_failed) from [<c00ab158>] (__alloc_pages_nodemask+0x558/0x84c)                              
gbue4k user.warn kernel: [24938.650308] [<c00ab158>] (__alloc_pages_nodemask) from [<c00ddd34>] (cache_alloc_refill+0x364/0x59c)                             
gbue4k user.warn kernel: [24938.659454] [<c00ddd34>] (cache_alloc_refill) from [<c00de024>] (__kmalloc_track_caller+0xb8/0xec)  
gbue4k user.warn kernel: [24938.668425] [<c00de024>] (__kmalloc_track_caller) from [<c00b9818>] (memdup_user+0x1c/0xa4)         
gbue4k user.warn kernel: [24938.676790] [<c00b9818>] (memdup_user) from [<c049ad44>] (dvbdmx_write+0x30/0xb8)                                    
gbue4k user.warn kernel: [24938.684308] [<c049ad44>] (dvbdmx_write) from [<bf63d750>] (dev_dmx_demux_write_hook+0xa0/0xd0 [dvb])                 
gbue4k user.warn kernel: [24938.693481] [<bf63d750>] (dev_dmx_demux_write_hook [dvb]) from [<bf63da3c>] (dev_dmx_dvr_write_hook+0xfc/0x41c [dvb])
gbue4k user.warn kernel: [24938.704118] [<bf63da3c>] (dev_dmx_dvr_write_hook [dvb]) from [<c00e2fe8>] (__vfs_write+0x1c/0xd8)                    
gbue4k user.warn kernel: [24938.713002] [<c00e2fe8>] (__vfs_write) from [<c00e37f0>] (vfs_write+0x90/0x170)                                      
gbue4k user.warn kernel: [24938.720319] [<c00e37f0>] (vfs_write) from [<c00e4010>] (SyS_write+0x3c/0x90)                                         
gbue4k user.warn kernel: [24938.727378] [<c00e4010>] (SyS_write) from [<c000ff40>] (ret_fast_syscall+0x0/0x3c)                                   
gbue4k user.warn kernel: [24938.735375] Mem-Info:                                                                                                
gbue4k user.warn kernel: [24938.737755] active_anon:23895 inactive_anon:101 isolated_anon:0                                                      
gbue4k user.warn kernel: [24938.737755]  active_file:82159 inactive_file:83463 isolated_file:24                                                  
gbue4k user.warn kernel: [24938.737755]  unevictable:0 dirty:25028 writeback:21977 unstable:0                                                    
gbue4k user.warn kernel: [24938.737755]  slab_reclaimable:8555 slab_unreclaimable:3144                                                           
gbue4k user.warn kernel: [24938.737755]  mapped:1347 shmem:3296 pagetables:713 bounce:0                                                                      
gbue4k user.warn kernel: [24938.737755]  free:2881 free_pcp:150 free_cma:65                                                                                  
gbue4k user.warn kernel: [24938.772425] DMA free:8500kB min:2732kB low:3412kB high:4096kB active_anon:34792kB inactive_anon:260kB active_file:158908kB inacti
gbue4k user.warn kernel: [24938.818678] lowmem_reserve[]: 0 0 428 428                                                                                        
gbue4k user.warn kernel: [24938.823584] HighMem free:2888kB min:428kB low:1068kB high:1712kB active_anon:60788kB inactive_anon:144kB active_file:169344kB ina
gbue4k user.warn kernel: [24938.868991] lowmem_reserve[]: 0 0 0 0                                                                                            
gbue4k user.warn kernel: [24938.873261] DMA: 1848*4kB (UEM) 234*8kB (UMR) 34*16kB (UMR) 3*32kB ® 0*64kB 1*128kB ® 0*256kB 0*512kB 0*1024kB 0*2048kB 0*409
gbue4k user.warn kernel: [24938.889174] HighMem: 479*4kB (MRC) 67*8kB ® 10*16kB ® 0*32kB 1*64kB ® 0*128kB 1*256kB ® 0*512kB 0*1024kB 0*2048kB 0*4096k
gbue4k user.warn kernel: [24938.908771] 168589 total pagecache pages                                                                                         
gbue4k user.warn kernel: [24938.913452] 0 pages in swap cache                                                                                                
gbue4k user.warn kernel: [24938.917438] Swap cache stats: add 0, delete 0, find 0/0                                                                          
gbue4k user.warn kernel: [24938.923274] Free swap  = 0kB                                                                                                     
gbue4k user.warn kernel: [24938.926618] Total swap = 0kB                                                                                                     
gbue4k user.warn kernel: [24938.930039] 524288 pages RAM                                                                                                     
gbue4k user.warn kernel: [24938.932952] 400896 pages HighMem/MovableOnly                                                                                     
gbue4k user.warn kernel: [24938.938089] 293632 pages reserved                                                                                                
gbue4k user.warn kernel: [24938.942179] 4096 pages cma reserved                                                                                              
 

This thread (https://www.opena.tv...-haengt-19.html) discusses the issue at length. It comes down to memory being fragmented in such a way that a buffer of the required size cannot be allocated. The thread ends with settings that didn't fix the problem (neither for me nor in the context of the thread).

 

However, I found that these "more aggressive" values:

 

vm.min_free_kbytes = 129072
vm.dirty_ratio = 60
vm.vfs_cache_pressure = 110
 

fix the problem. I know that the settings may be a bit "exaggerated", I didn't test them individually. It may well be that adjusting only e.g. vm.min_free_kbytes is sufficient.

 

Maybe this information helps if somebody encounters the same problem.

 

 - Michael

 

 

 

 

 

 



Re: [SOLVED] Problems watching broadcast being recorded (gbue4k) #2 WanWizard

  • PLi® Core member
  • 70,400 posts

+1,807
Excellent

Posted 23 December 2019 - 00:04

I doubt they fix the problem, if anything it might take a bit longer before the issue comes up again.

 

Smells like a driver bug...


Currently in use: VU+ Duo 4K (2xFBC S2), VU+ Solo 4K (1xFBC S2), uClan Usytm 4K Ultimate (S2+T2), Octagon SF8008 (S2+T2), Zgemma H9.2H (S2+T2)

Due to my bad health, I will not be very active at times and may be slow to respond. I will not read the forum or PM on a regular basis.

Many answers to your question can be found in our new and improved wiki.


Re: [SOLVED] Problems watching broadcast being recorded (gbue4k) #3 meatop

  • Member
  • 13 posts

0
Neutral

Posted 23 December 2019 - 10:07

In general, I agree with you. A driver with real-time requirements should allocate all required resources initially. I'd consider anything else a design bug unless there is a very good reason to do otherwise. Nevertheless, if you have a driver that does allocate buffers dynamically, the observed behavior is easily explainable and you have the vm tuning parameters to adapt the environment to the behavior.

 

I've used the recording/watching successfully for 1.5 hours, which is what I usually need. I kept watching /proc/buddyinfo during this time and it always returned to "basic" values. So I'm very positive that thing would keep going for a longer time as well.

 

The thread that I have referenced is from 2014. I have doubts that anybody starts looking at the driver code after all this time to find another solution.



Re: [SOLVED] Problems watching broadcast being recorded (gbue4k) #4 WanWizard

  • PLi® Core member
  • 70,400 posts

+1,807
Excellent

Posted 23 December 2019 - 18:13

If you use a lot of network, that might accellerate the problem.

 

The NIC drivers are very simple, and don't support scatter/gather, which means they need continuous memory blocks for buffers. The longer the box is on, and the more you use the network, the bigger this problem becomes. Low memory boxes like a DM8000 can even already crash within a day because of this.

 

Using mounts with a large rsize/wsize accellerates the problem too...


Currently in use: VU+ Duo 4K (2xFBC S2), VU+ Solo 4K (1xFBC S2), uClan Usytm 4K Ultimate (S2+T2), Octagon SF8008 (S2+T2), Zgemma H9.2H (S2+T2)

Due to my bad health, I will not be very active at times and may be slow to respond. I will not read the forum or PM on a regular basis.

Many answers to your question can be found in our new and improved wiki.



1 user(s) are reading this topic

0 members, 1 guests, 0 anonymous users