-
Notifications
You must be signed in to change notification settings - Fork 20
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Atom/GMA3600-SGX545 questions #8
Comments
Hi. |
I've managed to get it running on Samsung S5PV210 (using the OMAP 4's SGX 540-120 blobs and hex-editing so it finds the correct DRM device). Not that this helps with x86 at all... I rather lucked out that OMAP4 has the same revision as S5PV210. |
Thanks for the explanation as said I'm not a linux expert but I am still using this SoC in a modern linux o.s. but the gma500 doesn't seem to use much of the gpu (beside at least it works) and ironically these boards went for the only old PCI external bus instead of the native PCIex one so the alternative options always have been limited. :) |
Seems to me the same situation of #5 |
I would like to build this kernel for my intel atom Z2580 SoC with pvr sgx544MP2 gpu. But an error says that it lacks Makefile in "driver/gpu/drm/pvrsgx/1.7.862890/pvr". Anyone can help? |
Hi,
Am 10.04.2024 um 09:15 schrieb SteveBetter ***@***.***>:
I would like to build this kernel for my intel atom Z2580 SoC with pvr sgx544MP2 gpu. But an error says that it lacks Makefile in "driver/gpu/drm/pvrsgx/1.7.862890/pvr". Anyone can help?
There seems to be an (also note the suffix "s" of "drivers"):
drivers/gpu/drm/pvrsgx/1.7.862890/pvr/INSTALL
It says that cd eurasiacon/build/linux/platform/kbuild should be done and them "make all".
Our generic Make file doesn't support it yet but with your help we might be able wrap this so that a CONFIG/make on top kernel top level works.
BR,
Nikolaus
|
@goldelico |
Am 11.04.2024 um 05:32 schrieb SteveBetter ***@***.***>:
@
I browsed that sub directory. There seems to be header files. Perhaps there is something wrong with this part of "drivers/gpu/drm/pvrsgx/1.7.862890". Impossible to compile it.
It also looks as if drivers/gpu/drm/pvrsgx/1.7.862890/pvr/eurasiacon/is empty...
So maybe we do not have complete code :(
It appears as if it came from: https://github.com/thomas001/cedarview-drm/tree/master/staging/cdv/pvr
where the eurasiacon subdirectory is also empty.
|
@goldelico |
Am 11.04.2024 um 12:18 schrieb SteveBetter ***@***.***>:
@goldelico
I found that not only 1.7.862890 can't be compiled. Other sub directories have the same problem too.
I found a Makefile in many of them, e.g.:
drivers/gpu/drm/pvrsgx/1.9.2188537/eurasia_km/Makefile
But that doesn't help :(
The problem is that these DDK versions are closely tied to specific processors and user-space code.
So they can neither be directly mixed between architectures nor different versions.
So, what should we do to drive this GPU?
Well, I just have some very generic ideas:
a) try to locate the missing files somewhere (on some Linux system that did have vendor support)
b) try to (back)port the missing files from a later DDK
c) knocking on Imagination's doors and begging for the entire pvrsgx code to be made open source...
|
I'm also looking around what's available for the PowerVR devices with regards to driver binaries to see if GMA3600 netbooks could be supported. The binaries from the vendor seem to have the following attributes:
For x86 there are only a few sets of binaries available. The main ones are from the Cedarview driver releases from Intel. Those are based on DDK version 1.7.862890 and provide X.org support. (Hacking X.org itself a bit allows me to run with slightly higher versions without running into a crash immediately.) These are meant for PowerVR SGX545 as common on netbooks and mainboards. Older binaries seem to be provided in an EMGD package. These seem to be for SGX535 devices, but I also see references to SGX545. These seem to be based on DDK 1.5.15.3226. The file names contain EMGD instead of PVR2D. There are also window system binaries for Wayland in addition to X.org. Other x86 binaries are provided for Android tablets based on PowerVR SGX544 and PowerVR series 6 chips. Notably Asus Zenphone 5. These are based on DDK 1.12.2701748 and only have a binary for the Android window system. The EGL libraries in a subdirectory explicitly have POWERVR-SGX544 in their filename. Maybe they are somehow tied to that model. There seems to be an Android DDK for the SGX540/544 available here: https://github.com/shaqfu786/GFX_Linux_DDK |
Hi Julius,
great stuff you have found!
Am 11.05.2024 um 11:12 schrieb Julius Schwartzenberg ***@***.***>:
I'm also looking around what's available for the PowerVR devices with regards to driver binaries to see if GMA3600 netbooks could be supported. The binaries from the vendor seem to have the following attributes:
• They contain numbers libraries, notably there is always a library like libpvr2d.so.1.7.862890. The version suffix relates to the DDK version and is the same for all included binaries.
This version seems to match the kernel driver tree we have.
• There are a bunch of libpvrPVR2D_*WSEGL.so.1.7.862890 libraries. Those provide support for different window systems.
• Configuration is done through powervr.ini which is typically in /etc/. It is possible to specify the WindowSystem there and supposedly EGL would use another windowing system.
Yes, this seems to be sort of a standard...
• Filenames of the included files generally contain PVR2D somewhere in the name.
For x86 there are only a few sets of binaries available.
The main ones are from the Cedarview driver releases from Intel. Those are based on DDK version 1.7.862890 and provide X.org support. (Hacking X.org itself a bit allows me to run with slightly higher versions without running into a crash immediately.) These are meant for PowerVR SGX545 as common on netbooks and mainboards.
Older binaries seem to be provided in an EMGD package. These seem to be for SGX535 devices, but I also see references to SGX545. These seem to be based on DDK 1.5.15.3226. The file names contain EMGD instead of PVR2D. There are also window system binaries for Wayland in addition to X.org.
For this DDK we also have some driver code.
Other x86 binaries are provided for Android tablets based on PowerVR SGX544 and PowerVR series 6 chips. Notably Asus Zenphone 5. These are based on DDK 1.12.2701748 and only have a binary for the Android window system. The EGL libraries in a subdirectory explicitly have POWERVR-SGX544 in their filename. Maybe they are somehow tied to that model.
There are also binaries for the ASUS MeMO Pad 7. These are based on DDK 1.12.3197934 and are otherwise similar.
There is also a Dell Venue 8 tablet. The binaries on it do not have a DDK version suffix and the EGL libraries have POWERVR_ROGUE in their name.
Rougue is not PVR SGX (PVR 5) but PVR 6.
Their seems to be an Android DDK for the SGX540/544 available here: https://github.com/shaqfu786/GFX_Linux_DDK
This seems to be a DDK 1.8.869593 compatible driver: https://github.com/shaqfu786/GFX_Linux_DDK/blob/master/eurasia_km/include4/pvrversion.h#L39C38-L39C44
which we do not yet have in our collection: https://github.com/openpvrsgx-devgroup/linux_openpvrsgx/branches/all?query=letux%2Fpvrsrvkm
I plan to add this for a future release.
BR and thanks,
Nikolaus
PS: maybe you can subscribe to https://lists.goldelico.com/mailman/listinfo.cgi/openpvrsgx-devgroup which is a mailing list with different audience.
|
This seems to be a DDK 1.8.869593 compatible driver:
https://github.com/shaqfu786/GFX_Linux_DDK/blob/master/eurasia_km/include4/pvrversion.h#L39C38-L39C44
which we do not yet have in our collection:
https://github.com/openpvrsgx-devgroup/linux_openpvrsgx/branches/all?query=letux%2Fpvrsrvkm
I plan to add this for a future release.
Ah interesting to see you have support for various versions. Does this also
include the code required to bridge the PVR parts to the Cedarview/GMA500
part? When using the source from Intel, it is necessary to enable Intel
Cedarview in the kernel's menuconfig (and disable the GMA500 driver). After
that all PowerVR stuff gets loaded and also `/proc/pvr` is available.
I think this is the code that's here:
https://github.com/thomas001/cedarview-drm/tree/master/staging/cdv/drv
And triggered by this configuration option:
https://github.com/thomas001/cedarview-drm/blob/master/staging/cdv/Kconfig
Would it be possible to introduce this in your tree(s)? I could test this.
It seems the GMA500 driver and Intel's sources are related in some ways. It
might also be possible to compare the two and see how Intel's variant hooks
into the PVR parts.
PS: maybe you can subscribe to
https://lists.goldelico.com/mailman/listinfo.cgi/openpvrsgx-devgroup
which is a mailing list with different audience.
Thanks, I tried to sign up, but did not receive a confirmation just yet.
Maybe somebody needs to approve?
… Message ID: <openpvrsgx-devgroup/linux_openpvrsgx/issues/8/2106735763@
github.com>
|
Hi Julius,
Am 14.05.2024 um 20:12 schrieb Julius Schwartzenberg ***@***.***>:
This seems to be a DDK 1.8.869593 compatible driver: https://github.com/shaqfu786/GFX_Linux_DDK/blob/master/eurasia_km/include4/pvrversion.h#L39C38-L39C44
which we do not yet have in our collection: https://github.com/openpvrsgx-devgroup/linux_openpvrsgx/branches/all?query=letux%2Fpvrsrvkm
I plan to add this for a future release.
Well, I have checked again and it turns out to be a copy of the leaked full DDK. There are a lot of files included with a confidentiality note... I was astonished that this leaked code is still around after 10 years which may mean that they are not really interested in keeping it secred. And it is DDK 1.8 while the latest one I am aware of is DDK 1.17. So there is a lot of development and improvement since back then.
Now, I am unsure if I should really integrate it... Or take only parts with a clear GPL from eurasia_km?
Ah interesting to see you have support for various versions.
Yes. We have collected all kernel driver variants we could find so far into a single tree and different CONFIG optioons allow to chose the right one. Some processors (mainly OMAP3 and siblings) are supported by two or 3 different variants.
Does this also include the code required to bridge the PVR parts to the Cedarview/GMA500 part?
Well, each variant usually contains code in the eurasia_km directory which ties the DDK to some specific hardware. In most cases this is only for OMAP. There is one case where it also supports the MIPS jz4780. But we have no MIPS compatible user space to make any use for it.
For the x86 drivers I am not sure. I have no compatible hardware soI myself didn't try more than some compile tests (which usually fail). So I don't know what works and what is missing.
When using the source from Intel, it is necessary to enable Intel Cedarview in the kernel's menuconfig (and disable the GMA500 driver). After that all PowerVR stuff gets loaded and also `/proc/pvr` is available.
Ok, this is already great!
I think this is the code that's here: https://github.com/thomas001/cedarview-drm/tree/master/staging/cdv/drv
And triggered by this configuration option: https://github.com/thomas001/cedarview-drm/blob/master/staging/cdv/Kconfig
Would it be possible to introduce this in your tree(s)?
Basically it should be possible. We just have to create a new letux/pvrsrvkm-$DDK_RELEASE branch based on linus/master, move the files to drivers/gpu/drm/pvrsgc/$DDK_RELEASE, add proper modifications to drivers/gpu/drm/pvrsgc/{Kconfig,Makefile} and start debugging...
What likely has happened is that header files have moved or APIs changed. Then there are usually examples from other DDK versions how to fix.
And, the build process may hang because of dependencies or even missing files.
I could test this. It seems the GMA500 driver and Intel's sources are related in some ways. It might also be possible to compare the two and see how Intel's variant hooks into the PVR parts.
Basically the architecture is that Imagnination did publish a DDK package in C that is agnostic to the processor the SGX is integrated in. This is the above mentioned leaked code.
The SoC vendor who has licensed the SGX module then added some code to wrap it and integrate into the OS. On kernel level and on user-space library level.
This has also been done by Microsoft for Windows or Apple for macOS. And in some cases for Linux/Android. Therefore there are many drivers around for different architectures and OS - and none is compatible to the other... And sometimes the Linux kernel driver is published but not always.
PS: maybe you can subscribe to https://lists.goldelico.com/mailman/listinfo.cgi/openpvrsgx-devgroup which is a mailing list with different audience.
Thanks, I tried to sign up, but did not receive a confirmation just yet. Maybe somebody needs to approve?
Have done recently.
Best regards,
Nikolaus
|
…PLES event" This reverts commit 7d1405c. This causes segfaults in some cases, as reported by Milian: ``` sudo /usr/bin/perf record -z --call-graph dwarf -e cycles -e raw_syscalls:sys_enter ls ... [ perf record: Woken up 3 times to write data ] malloc(): invalid next size (unsorted) Aborted ``` Backtrace with GDB + debuginfod: ``` malloc(): invalid next size (unsorted) Thread 1 "perf" received signal SIGABRT, Aborted. __pthread_kill_implementation (threadid=<optimized out>, signo=signo@entry=6, no_tid=no_tid@entry=0) at pthread_kill.c:44 Downloading source file /usr/src/debug/glibc/glibc/nptl/pthread_kill.c 44 return INTERNAL_SYSCALL_ERROR_P (ret) ? INTERNAL_SYSCALL_ERRNO (ret) : 0; (gdb) bt #0 __pthread_kill_implementation (threadid=<optimized out>, signo=signo@entry=6, no_tid=no_tid@entry=0) at pthread_kill.c:44 #1 0x00007ffff6ea8eb3 in __pthread_kill_internal (threadid=<optimized out>, signo=6) at pthread_kill.c:78 #2 0x00007ffff6e50a30 in __GI_raise (sig=sig@entry=6) at ../sysdeps/posix/ raise.c:26 #3 0x00007ffff6e384c3 in __GI_abort () at abort.c:79 #4 0x00007ffff6e39354 in __libc_message_impl (fmt=fmt@entry=0x7ffff6fc22ea "%s\n") at ../sysdeps/posix/libc_fatal.c:132 #5 0x00007ffff6eb3085 in malloc_printerr (str=str@entry=0x7ffff6fc5850 "malloc(): invalid next size (unsorted)") at malloc.c:5772 #6 0x00007ffff6eb657c in _int_malloc (av=av@entry=0x7ffff6ff6ac0 <main_arena>, bytes=bytes@entry=368) at malloc.c:4081 #7 0x00007ffff6eb877e in __libc_calloc (n=<optimized out>, elem_size=<optimized out>) at malloc.c:3754 #8 0x000055555569bdb6 in perf_session.do_write_header () #9 0x00005555555a373a in __cmd_record.constprop.0 () #10 0x00005555555a6846 in cmd_record () #11 0x000055555564db7f in run_builtin () #12 0x000055555558ed77 in main () ``` Valgrind memcheck: ``` ==45136== Invalid write of size 8 ==45136== at 0x2B38A5: perf_event__synthesize_id_sample (in /usr/bin/perf) ==45136== by 0x157069: __cmd_record.constprop.0 (in /usr/bin/perf) ==45136== by 0x15A845: cmd_record (in /usr/bin/perf) ==45136== by 0x201B7E: run_builtin (in /usr/bin/perf) ==45136== by 0x142D76: main (in /usr/bin/perf) ==45136== Address 0x6a866a8 is 0 bytes after a block of size 40 alloc'd ==45136== at 0x4849BF3: calloc (vg_replace_malloc.c:1675) ==45136== by 0x3574AB: zalloc (in /usr/bin/perf) ==45136== by 0x1570E0: __cmd_record.constprop.0 (in /usr/bin/perf) ==45136== by 0x15A845: cmd_record (in /usr/bin/perf) ==45136== by 0x201B7E: run_builtin (in /usr/bin/perf) ==45136== by 0x142D76: main (in /usr/bin/perf) ==45136== ==45136== Syscall param write(buf) points to unaddressable byte(s) ==45136== at 0x575953D: __libc_write (write.c:26) ==45136== by 0x575953D: write (write.c:24) ==45136== by 0x35761F: ion (in /usr/bin/perf) ==45136== by 0x357778: writen (in /usr/bin/perf) ==45136== by 0x1548F7: record__write (in /usr/bin/perf) ==45136== by 0x15708A: __cmd_record.constprop.0 (in /usr/bin/perf) ==45136== by 0x15A845: cmd_record (in /usr/bin/perf) ==45136== by 0x201B7E: run_builtin (in /usr/bin/perf) ==45136== by 0x142D76: main (in /usr/bin/perf) ==45136== Address 0x6a866a8 is 0 bytes after a block of size 40 alloc'd ==45136== at 0x4849BF3: calloc (vg_replace_malloc.c:1675) ==45136== by 0x3574AB: zalloc (in /usr/bin/perf) ==45136== by 0x1570E0: __cmd_record.constprop.0 (in /usr/bin/perf) ==45136== by 0x15A845: cmd_record (in /usr/bin/perf) ==45136== by 0x201B7E: run_builtin (in /usr/bin/perf) ==45136== by 0x142D76: main (in /usr/bin/perf) ==45136== ----- Closes: https://lore.kernel.org/linux-perf-users/23879991.0LEYPuXRzz@milian-workstation/ Reported-by: Milian Wolff <[email protected]> Tested-by: Milian Wolff <[email protected]> Cc: Adrian Hunter <[email protected]> Cc: Ian Rogers <[email protected]> Cc: Jiri Olsa <[email protected]> Cc: Kan Liang <[email protected]> Cc: Namhyung Kim <[email protected]> Cc: [email protected] # 6.8+ Link: https://lore.kernel.org/lkml/Zl9ksOlHJHnKM70p@x1 Signed-off-by: Arnaldo Carvalho de Melo <[email protected]>
We have been seeing crashes on duplicate keys in btrfs_set_item_key_safe(): BTRFS critical (device vdb): slot 4 key (450 108 8192) new key (450 108 8192) ------------[ cut here ]------------ kernel BUG at fs/btrfs/ctree.c:2620! invalid opcode: 0000 [#1] PREEMPT SMP PTI CPU: 0 PID: 3139 Comm: xfs_io Kdump: loaded Not tainted 6.9.0 #6 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-2.fc40 04/01/2014 RIP: 0010:btrfs_set_item_key_safe+0x11f/0x290 [btrfs] With the following stack trace: #0 btrfs_set_item_key_safe (fs/btrfs/ctree.c:2620:4) #1 btrfs_drop_extents (fs/btrfs/file.c:411:4) #2 log_one_extent (fs/btrfs/tree-log.c:4732:9) #3 btrfs_log_changed_extents (fs/btrfs/tree-log.c:4955:9) #4 btrfs_log_inode (fs/btrfs/tree-log.c:6626:9) #5 btrfs_log_inode_parent (fs/btrfs/tree-log.c:7070:8) #6 btrfs_log_dentry_safe (fs/btrfs/tree-log.c:7171:8) #7 btrfs_sync_file (fs/btrfs/file.c:1933:8) #8 vfs_fsync_range (fs/sync.c:188:9) #9 vfs_fsync (fs/sync.c:202:9) #10 do_fsync (fs/sync.c:212:9) #11 __do_sys_fdatasync (fs/sync.c:225:9) #12 __se_sys_fdatasync (fs/sync.c:223:1) #13 __x64_sys_fdatasync (fs/sync.c:223:1) #14 do_syscall_x64 (arch/x86/entry/common.c:52:14) #15 do_syscall_64 (arch/x86/entry/common.c:83:7) #16 entry_SYSCALL_64+0xaf/0x14c (arch/x86/entry/entry_64.S:121) So we're logging a changed extent from fsync, which is splitting an extent in the log tree. But this split part already exists in the tree, triggering the BUG(). This is the state of the log tree at the time of the crash, dumped with drgn (https://github.com/osandov/drgn/blob/main/contrib/btrfs_tree.py) to get more details than btrfs_print_leaf() gives us: >>> print_extent_buffer(prog.crashed_thread().stack_trace()[0]["eb"]) leaf 33439744 level 0 items 72 generation 9 owner 18446744073709551610 leaf 33439744 flags 0x100000000000000 fs uuid e5bd3946-400c-4223-8923-190ef1f18677 chunk uuid d58cb17e-6d02-494a-829a-18b7d8a399da item 0 key (450 INODE_ITEM 0) itemoff 16123 itemsize 160 generation 7 transid 9 size 8192 nbytes 8473563889606862198 block group 0 mode 100600 links 1 uid 0 gid 0 rdev 0 sequence 204 flags 0x10(PREALLOC) atime 1716417703.220000000 (2024-05-22 15:41:43) ctime 1716417704.983333333 (2024-05-22 15:41:44) mtime 1716417704.983333333 (2024-05-22 15:41:44) otime 17592186044416.000000000 (559444-03-08 01:40:16) item 1 key (450 INODE_REF 256) itemoff 16110 itemsize 13 index 195 namelen 3 name: 193 item 2 key (450 XATTR_ITEM 1640047104) itemoff 16073 itemsize 37 location key (0 UNKNOWN.0 0) type XATTR transid 7 data_len 1 name_len 6 name: user.a data a item 3 key (450 EXTENT_DATA 0) itemoff 16020 itemsize 53 generation 9 type 1 (regular) extent data disk byte 303144960 nr 12288 extent data offset 0 nr 4096 ram 12288 extent compression 0 (none) item 4 key (450 EXTENT_DATA 4096) itemoff 15967 itemsize 53 generation 9 type 2 (prealloc) prealloc data disk byte 303144960 nr 12288 prealloc data offset 4096 nr 8192 item 5 key (450 EXTENT_DATA 8192) itemoff 15914 itemsize 53 generation 9 type 2 (prealloc) prealloc data disk byte 303144960 nr 12288 prealloc data offset 8192 nr 4096 ... So the real problem happened earlier: notice that items 4 (4k-12k) and 5 (8k-12k) overlap. Both are prealloc extents. Item 4 straddles i_size and item 5 starts at i_size. Here is the state of the filesystem tree at the time of the crash: >>> root = prog.crashed_thread().stack_trace()[2]["inode"].root >>> ret, nodes, slots = btrfs_search_slot(root, BtrfsKey(450, 0, 0)) >>> print_extent_buffer(nodes[0]) leaf 30425088 level 0 items 184 generation 9 owner 5 leaf 30425088 flags 0x100000000000000 fs uuid e5bd3946-400c-4223-8923-190ef1f18677 chunk uuid d58cb17e-6d02-494a-829a-18b7d8a399da ... item 179 key (450 INODE_ITEM 0) itemoff 4907 itemsize 160 generation 7 transid 7 size 4096 nbytes 12288 block group 0 mode 100600 links 1 uid 0 gid 0 rdev 0 sequence 6 flags 0x10(PREALLOC) atime 1716417703.220000000 (2024-05-22 15:41:43) ctime 1716417703.220000000 (2024-05-22 15:41:43) mtime 1716417703.220000000 (2024-05-22 15:41:43) otime 1716417703.220000000 (2024-05-22 15:41:43) item 180 key (450 INODE_REF 256) itemoff 4894 itemsize 13 index 195 namelen 3 name: 193 item 181 key (450 XATTR_ITEM 1640047104) itemoff 4857 itemsize 37 location key (0 UNKNOWN.0 0) type XATTR transid 7 data_len 1 name_len 6 name: user.a data a item 182 key (450 EXTENT_DATA 0) itemoff 4804 itemsize 53 generation 9 type 1 (regular) extent data disk byte 303144960 nr 12288 extent data offset 0 nr 8192 ram 12288 extent compression 0 (none) item 183 key (450 EXTENT_DATA 8192) itemoff 4751 itemsize 53 generation 9 type 2 (prealloc) prealloc data disk byte 303144960 nr 12288 prealloc data offset 8192 nr 4096 Item 5 in the log tree corresponds to item 183 in the filesystem tree, but nothing matches item 4. Furthermore, item 183 is the last item in the leaf. btrfs_log_prealloc_extents() is responsible for logging prealloc extents beyond i_size. It first truncates any previously logged prealloc extents that start beyond i_size. Then, it walks the filesystem tree and copies the prealloc extent items to the log tree. If it hits the end of a leaf, then it calls btrfs_next_leaf(), which unlocks the tree and does another search. However, while the filesystem tree is unlocked, an ordered extent completion may modify the tree. In particular, it may insert an extent item that overlaps with an extent item that was already copied to the log tree. This may manifest in several ways depending on the exact scenario, including an EEXIST error that is silently translated to a full sync, overlapping items in the log tree, or this crash. This particular crash is triggered by the following sequence of events: - Initially, the file has i_size=4k, a regular extent from 0-4k, and a prealloc extent beyond i_size from 4k-12k. The prealloc extent item is the last item in its B-tree leaf. - The file is fsync'd, which copies its inode item and both extent items to the log tree. - An xattr is set on the file, which sets the BTRFS_INODE_COPY_EVERYTHING flag. - The range 4k-8k in the file is written using direct I/O. i_size is extended to 8k, but the ordered extent is still in flight. - The file is fsync'd. Since BTRFS_INODE_COPY_EVERYTHING is set, this calls copy_inode_items_to_log(), which calls btrfs_log_prealloc_extents(). - btrfs_log_prealloc_extents() finds the 4k-12k prealloc extent in the filesystem tree. Since it starts before i_size, it skips it. Since it is the last item in its B-tree leaf, it calls btrfs_next_leaf(). - btrfs_next_leaf() unlocks the path. - The ordered extent completion runs, which converts the 4k-8k part of the prealloc extent to written and inserts the remaining prealloc part from 8k-12k. - btrfs_next_leaf() does a search and finds the new prealloc extent 8k-12k. - btrfs_log_prealloc_extents() copies the 8k-12k prealloc extent into the log tree. Note that it overlaps with the 4k-12k prealloc extent that was copied to the log tree by the first fsync. - fsync calls btrfs_log_changed_extents(), which tries to log the 4k-8k extent that was written. - This tries to drop the range 4k-8k in the log tree, which requires adjusting the start of the 4k-12k prealloc extent in the log tree to 8k. - btrfs_set_item_key_safe() sees that there is already an extent starting at 8k in the log tree and calls BUG(). Fix this by detecting when we're about to insert an overlapping file extent item in the log tree and truncating the part that would overlap. CC: [email protected] # 6.1+ Reviewed-by: Filipe Manana <[email protected]> Signed-off-by: Omar Sandoval <[email protected]> Signed-off-by: David Sterba <[email protected]>
When creating a trace_probe we would set nr_args prior to truncating the arguments to MAX_TRACE_ARGS. However, we would only initialize arguments up to the limit. This caused invalid memory access when attempting to set up probes with more than 128 fetchargs. BUG: kernel NULL pointer dereference, address: 0000000000000020 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: Oops: 0000 [#1] PREEMPT SMP PTI CPU: 0 UID: 0 PID: 1769 Comm: cat Not tainted 6.11.0-rc7+ #8 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-1.fc39 04/01/2014 RIP: 0010:__set_print_fmt+0x134/0x330 Resolve the issue by applying the MAX_TRACE_ARGS limit earlier. Return an error when there are too many arguments instead of silently truncating. Link: https://lore.kernel.org/all/[email protected]/ Fixes: 035ba76 ("tracing/probes: cleanup: Set trace_probe::nr_args at trace_probe_init") Signed-off-by: Mikel Rychliski <[email protected]> Signed-off-by: Masami Hiramatsu (Google) <[email protected]>
The referenced commits introduced a two-step process for deleting FTEs: - Lock the FTE, delete it from hardware, set the hardware deletion function to NULL and unlock the FTE. - Lock the parent flow group, delete the software copy of the FTE, and remove it from the xarray. However, this approach encounters a race condition if a rule with the same match value is added simultaneously. In this scenario, fs_core may set the hardware deletion function to NULL prematurely, causing a panic during subsequent rule deletions. To prevent this, ensure the active flag of the FTE is checked under a lock, which will prevent the fs_core layer from attaching a new steering rule to an FTE that is in the process of deletion. [ 438.967589] MOSHE: 2496 mlx5_del_flow_rules del_hw_func [ 438.968205] ------------[ cut here ]------------ [ 438.968654] refcount_t: decrement hit 0; leaking memory. [ 438.969249] WARNING: CPU: 0 PID: 8957 at lib/refcount.c:31 refcount_warn_saturate+0xfb/0x110 [ 438.970054] Modules linked in: act_mirred cls_flower act_gact sch_ingress openvswitch nsh mlx5_vdpa vringh vhost_iotlb vdpa mlx5_ib mlx5_core xt_conntrack xt_MASQUERADE nf_conntrack_netlink nfnetlink xt_addrtype iptable_nat nf_nat br_netfilter rpcsec_gss_krb5 auth_rpcgss oid_registry overlay rpcrdma rdma_ucm ib_iser libiscsi scsi_transport_iscsi ib_umad rdma_cm ib_ipoib iw_cm ib_cm ib_uverbs ib_core zram zsmalloc fuse [last unloaded: cls_flower] [ 438.973288] CPU: 0 UID: 0 PID: 8957 Comm: tc Not tainted 6.12.0-rc1+ #8 [ 438.973888] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 [ 438.974874] RIP: 0010:refcount_warn_saturate+0xfb/0x110 [ 438.975363] Code: 40 66 3b 82 c6 05 16 e9 4d 01 01 e8 1f 7c a0 ff 0f 0b c3 cc cc cc cc 48 c7 c7 10 66 3b 82 c6 05 fd e8 4d 01 01 e8 05 7c a0 ff <0f> 0b c3 cc cc cc cc 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 90 [ 438.976947] RSP: 0018:ffff888124a53610 EFLAGS: 00010286 [ 438.977446] RAX: 0000000000000000 RBX: ffff888119d56de0 RCX: 0000000000000000 [ 438.978090] RDX: ffff88852c828700 RSI: ffff88852c81b3c0 RDI: ffff88852c81b3c0 [ 438.978721] RBP: ffff888120fa0e88 R08: 0000000000000000 R09: ffff888124a534b0 [ 438.979353] R10: 0000000000000001 R11: 0000000000000001 R12: ffff888119d56de0 [ 438.979979] R13: ffff888120fa0ec0 R14: ffff888120fa0ee8 R15: ffff888119d56de0 [ 438.980607] FS: 00007fe6dcc0f800(0000) GS:ffff88852c800000(0000) knlGS:0000000000000000 [ 438.983984] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 438.984544] CR2: 00000000004275e0 CR3: 0000000186982001 CR4: 0000000000372eb0 [ 438.985205] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 438.985842] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 438.986507] Call Trace: [ 438.986799] <TASK> [ 438.987070] ? __warn+0x7d/0x110 [ 438.987426] ? refcount_warn_saturate+0xfb/0x110 [ 438.987877] ? report_bug+0x17d/0x190 [ 438.988261] ? prb_read_valid+0x17/0x20 [ 438.988659] ? handle_bug+0x53/0x90 [ 438.989054] ? exc_invalid_op+0x14/0x70 [ 438.989458] ? asm_exc_invalid_op+0x16/0x20 [ 438.989883] ? refcount_warn_saturate+0xfb/0x110 [ 438.990348] mlx5_del_flow_rules+0x2f7/0x340 [mlx5_core] [ 438.990932] __mlx5_eswitch_del_rule+0x49/0x170 [mlx5_core] [ 438.991519] ? mlx5_lag_is_sriov+0x3c/0x50 [mlx5_core] [ 438.992054] ? xas_load+0x9/0xb0 [ 438.992407] mlx5e_tc_rule_unoffload+0x45/0xe0 [mlx5_core] [ 438.993037] mlx5e_tc_del_fdb_flow+0x2a6/0x2e0 [mlx5_core] [ 438.993623] mlx5e_flow_put+0x29/0x60 [mlx5_core] [ 438.994161] mlx5e_delete_flower+0x261/0x390 [mlx5_core] [ 438.994728] tc_setup_cb_destroy+0xb9/0x190 [ 438.995150] fl_hw_destroy_filter+0x94/0xc0 [cls_flower] [ 438.995650] fl_change+0x11a4/0x13c0 [cls_flower] [ 438.996105] tc_new_tfilter+0x347/0xbc0 [ 438.996503] ? ___slab_alloc+0x70/0x8c0 [ 438.996929] rtnetlink_rcv_msg+0xf9/0x3e0 [ 438.997339] ? __netlink_sendskb+0x4c/0x70 [ 438.997751] ? netlink_unicast+0x286/0x2d0 [ 438.998171] ? __pfx_rtnetlink_rcv_msg+0x10/0x10 [ 438.998625] netlink_rcv_skb+0x54/0x100 [ 438.999020] netlink_unicast+0x203/0x2d0 [ 438.999421] netlink_sendmsg+0x1e4/0x420 [ 438.999820] __sock_sendmsg+0xa1/0xb0 [ 439.000203] ____sys_sendmsg+0x207/0x2a0 [ 439.000600] ? copy_msghdr_from_user+0x6d/0xa0 [ 439.001072] ___sys_sendmsg+0x80/0xc0 [ 439.001459] ? ___sys_recvmsg+0x8b/0xc0 [ 439.001848] ? generic_update_time+0x4d/0x60 [ 439.002282] __sys_sendmsg+0x51/0x90 [ 439.002658] do_syscall_64+0x50/0x110 [ 439.003040] entry_SYSCALL_64_after_hwframe+0x76/0x7e Fixes: 718ce4d ("net/mlx5: Consolidate update FTE for all removal changes") Fixes: cefc235 ("net/mlx5: Fix FTE cleanup") Signed-off-by: Mark Bloch <[email protected]> Reviewed-by: Maor Gottlieb <[email protected]> Signed-off-by: Tariq Toukan <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]>
Hello,
I have a mini-itx board with the Atom SoC (x64/SSSE3) with the GMA3600/SGX545@400Mhz iGPU that usually works in modern linux with the gma500_gfx module but while it works there was of course no 3D/video acceleration beside the sofware rendering. I was reading about this project and some discussions of someone trying installing it on a similar SoC found on netbooks and I'd like to install it if it might work.
I'm not expert into kernel compilation so I'd just like to install asking some basic questions to understand how to possibly configure it and the steps.
The hope would simply have a functional lxde or lxqt ubuntu o.s. (from 18.04.x to the latest 22.04) just like the original old cedarview drivers worked on Ubuntu 12.04, not usable anymore cause too much old.
How would I need to configure the compilation for a x64 or x86 kernel? And do I specifically need a x86 32bit kernel compilation cause I remember every o.s. supporting this GPU only worked into 32bit o.s. is this the same situation? And what about Xorg, Mesa, video component, do I need some specific version?
I don't really well understand the steps but I always hoped to see the linux o.s. possibly supporting this gpu one day but after so much time I suppose it might be late considering how many old gpu are discontinued.
Bye
The text was updated successfully, but these errors were encountered: