+- PINE64 (https://forum.pine64.org)
+-- Forum: Pinebook Pro (https://forum.pine64.org/forumdisplay.php?fid=111)
+--- Forum: General Discussion on Pinebook Pro (https://forum.pine64.org/forumdisplay.php?fid=112)
+--- Thread: Panfrost Changelog (/showthread.php?tid=10484)
RE: Panfrost Changelog - Idaho - 10-12-2020
I see the new mesa-git fixed this issue I was having with RetroArch, thx for taking care of it.
RE: Panfrost Changelog - as400 - 11-03-2020
@icecream95 do you have any reports of memory leak in mesa-git when using kernels 5.9 and 5.10-rc ?
I get it when using FF with webrender and some other people observed it also with playing videos with mpv.
The memory is allocated in "buff/cached" and never released as it should in case it's needed for OS.
Edit:
Ok, so I compiled debug kernel with kmemleak but wasn't able to catch any leaks. But I cought nice taint/coredump while surfing internet with just FF running.
[ 1048.685835] Web Content: page allocation failure: order:7, mode:0x40dc0(GFP_KERNEL|__GFP_COMP|__GFP_ZERO), nodemask=(null),cpuset=/,mems_allowed=0
[ 1048.686996] CPU: 5 PID: 2778 Comm: Web Content Tainted: G C 5.9.3-as400-aarch64 #2
[ 1048.687766] Hardware name: Pine64 Pinebook Pro (DT)
[ 1048.688192] Call trace:
[ 1048.688422] dump_backtrace+0x0/0x1a0
[ 1048.688743] show_stack+0x18/0x30
[ 1048.689044] dump_stack+0xc0/0x11c
[ 1048.689348] warn_alloc+0xf0/0x160
[ 1048.689647] __alloc_pages_slowpath.constprop.0+0x9dc/0xa10
[ 1048.690132] __alloc_pages_nodemask+0x1f8/0x260
[ 1048.690529] kmalloc_order+0x44/0xc0
[ 1048.690843] __kmalloc+0x42c/0x4f0
[ 1048.691144] __regset_get+0x98/0x100
[ 1048.691457] regset_get_alloc+0x14/0x20
[ 1048.691796] fill_note_info.isra.0+0x340/0x8f0
[ 1048.692183] elf_core_dump+0x7c/0x810
[ 1048.692503] do_coredump+0x44c/0xbf0
[ 1048.692818] get_signal+0x134/0x790
[ 1048.693126] do_notify_resume+0x204/0x660
[ 1048.693476] work_pending+0x8/0x30c
[ 1048.693800] Mem-Info:
[ 1048.694007] active_anon:5365 inactive_anon:7052 isolated_anon:50
active_file:11613 inactive_file:9336 isolated_file:83
unevictable:743524 dirty:0 writeback:0
slab_reclaimable:8711 slab_unreclaimable:58131
mapped:58992 shmem:745443 pagetables:4318 bounce:0
free:10682 free_pcp:717 free_cma:0
[ 1048.696947] Node 0 active_anon:21460kB inactive_anon:27808kB active_file:46292kB inactive_file:37344kB unevictable:2974096kB isolated(anon):200kB isolated(file):332kB mapped:235968kB dirty:0kB writeback:0kB shmem:2981772kB writeback_tmp:0kB kernel_stack:9296kB all_unreclaimable? no
[ 1048.699124] DMA free:15224kB min:1932kB low:2884kB high:3836kB reserved_highatomic:2048KB active_anon:584kB inactive_anon:696kB active_file:1164kB inactive_file:1920kB unevictable:907188kB writepending:0kB present:1046528kB managed:955148kB mlocked:0kB pagetables:860kB bounce:0kB free_pcp:872kB local_pcp:0kB free_cma:0kB
[ 1048.701589] lowmem_reserve[]: 0 2852 2852 2852
[ 1048.701991] DMA32 free:29128kB min:23600kB low:26520kB high:29440kB reserved_highatomic:4096KB active_anon:20420kB inactive_anon:27956kB active_file:44392kB inactive_file:35720kB unevictable:2067248kB writepending:0kB present:3014656kB managed:2933680kB mlocked:0kB pagetables:16412kB bounce:0kB free_pcp:872kB local_pcp:0kB free_cma:0kB
[ 1048.704569] lowmem_reserve[]: 0 0 0 0
[ 1048.704899] DMA: 461*4kB (UMEH) 236*8kB (UMEH) 143*16kB (UMEH) 83*32kB (UMEH) 38*64kB (UMEH) 19*128kB (UMEH) 8*256kB (UEH) 2*512kB (E) 0*1024kB 0*2048kB 0*4096kB = 16612kB
[ 1048.706270] DMA32: 1868*4kB (ME) 1977*8kB (UME) 234*16kB (UM) 3*32kB (U) 0*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 27128kB
[ 1048.707385] Node 0 hugepages_total=0 hugepages_free=0 hugepages_surp=0 hugepages_size=1048576kB
[ 1048.708143] Node 0 hugepages_total=0 hugepages_free=0 hugepages_surp=0 hugepages_size=32768kB
[ 1048.708889] Node 0 hugepages_total=0 hugepages_free=0 hugepages_surp=0 hugepages_size=2048kB
[ 1048.709622] Node 0 hugepages_total=0 hugepages_free=0 hugepages_surp=0 hugepages_size=64kB
[ 1048.710339] 767583 total pagecache pages
[ 1048.710693] 748 pages in swap cache
[ 1048.711001] Swap cache stats: add 879902, delete 879933, find 60781/565899
[ 1048.711604] Free swap = 4840472kB
[ 1048.711903] Total swap = 5833240kB
[ 1048.712201] 1015296 pages RAM
[ 1048.712461] 0 pages HighMem/MovableOnly
[ 1048.712794] 43089 pages reserved
[ 1048.713076] 16384 pages cma reserved
RE: Panfrost Changelog - poVoq - 11-04-2020
https://www.collabora.com/news-and-blog/blog/2020/11/03/from-panfrost-to-production-a-tale-of-open-source-graphics/
RE: Panfrost Changelog - as400 - 11-05-2020
@icecream95 - nevermind - 5.9.5 has panfrost patch and it's not leaking.
RE: Panfrost Changelog - as400 - 11-11-2020
@icecream95 I noticed this on 5.9.5:
[ 2600.709672] panfrost ff9a0000.gpu: gpu sched timeout, js=0, config=0x3300, status=0x8, head=0x3c583c0, tail=0
x3c583c0, sched_job=00000000d4e48cd1
[ 2602.815290] panfrost ff9a0000.gpu: js fault, js=1, status=OUT_OF_MEMORY, head=0x3bb5000, tail=0x3bb5000
[ 2602.816184] panfrost ff9a0000.gpu: gpu sched timeout, js=1, config=0x3300, status=0x60, head=0x3bb5000, tail=
0x3bb5000, sched_job=0000000015081e3a
[ 2603.319576] panfrost ff9a0000.gpu: gpu sched timeout, js=0, config=0x3300, status=0x8, head=0x3bb53c0, tail=0
x3bb53c0, sched_job=00000000a969a039
[ 2603.879578] panfrost ff9a0000.gpu: gpu sched timeout, js=0, config=0x3300, status=0x8, head=0x3c6e3c0, tail=0
x3c6e3c0, sched_job=00000000770910a3
I've seen some patch in 5.9.7 but I'm not sure if it's relevant to this error.
EDIT:
It also happens on 5.9.8.
RE: Panfrost Changelog - as400 - 11-25-2020
@icecream95 - another bug with recent frequency scaling changes to panfrost it's from 5.9.9 up. And manifests itself only when panfrost is baked into the kernel.
The frequencies are not registered correctly.
Kernel with frequency patches reverted:
Code:
cat /sys/devices/platform/ff9a0000.gpu/devfreq/ff9a0000.gpu/available_frequencies
200000000 297000000 400000000 500000000 600000000 800000000Mainline kernel:
Code:
cat /sys/devices/platform/ff9a0000.gpu/devfreq/ff9a0000.gpu/available_frequencies
3472328296228218214 7094142619989800238 3472328296365385280 499974192 600000000 800000000Errors:
Code:
[ 18.139041] devfreq ff9a0000.gpu: Couldn't update frequency transition information.GPU gets stuck in one frequency and does not scale properly.
RE: Panfrost Changelog - xyzzy - 11-26-2020
(11-25-2020, 04:19 AM)as400 Wrote: @icecream95 - another bug with recent frequency scaling changes to panfrost it's from 5.9.9 up. And manifests itself only when panfrost is baked into the kernel.I've figured this one out and have a working built in panfrost with kernel 5.9.10.
The frequencies are not registered correctly.
In order to register the frequencies the driver for the regulator that supplies the GPU power must be probed. Since the OPPs have both frequencies and also the voltage to the GPU. If it's baked in, that doesn't happen like it should.
There is a patch in linux-next, "drm/panfrost: add regulators to devfreq", that will insure the regulators are probed. It's also necessary to compile the fan53555 regulator driver into the kernel too.
RE: Panfrost Changelog - as400 - 11-26-2020
Great. Thx for the info.
I'll try your patch.
RE: Panfrost Changelog - as400 - 12-02-2020
@xyzzy - can you point me to the proper patches that apply cleanly to 5.9 tree ? There are multiple versions.
RE: Panfrost Changelog - xyzzy - 12-02-2020
I've got the Manjaro 5.9.10-3 kernel in git here, https://github.com/xyzzy42/linux/tree/pbp
This has all the patches from Manjaro ARM (5.9.10-3) applied, plus additional patches to make panfrost built-in work, plus some stuff to getting WBS working with USB BT adapters.
Also attached is a defconfig that produces a (more) minimal kernel with (I think) full PBP support. I turned off support for non-RK3399 SoCs, assumed that the only PCI-e devices added would be NVMe SSDs and so turned off all other PCI-e and PCI cards, etc. This doesn't just result in a smaller kernel that uses less memory, and megabytes of fewer modules, it also compiles far faster!
defconfig.txt (Size: 45.72 KB / Downloads: 2,487)
You could extract the patches or build the tree from git. I find dealing with the "pile of patches" version control system that the manjaro pkgbuild uses to be a PITA. And extremely slow when building on the PBP.
With the manjaro system, to change the patch series, or fix a patch, or move to a new stable release like 5.9.11, you basically have to wipe the kernel source tree and re-extract the kernel tar, re-apply to the stable series megapatch, re-apply the manjaro patch series, and rebuild from scratch. It takes literally hours on a PBP.
With git, you can modify the patch series or edit patches with rebase -i, without needing to wipe the kernel tree, and then only the files that changed need to be recompiled. It takes a minute or two to rebuild.