-
Notifications
You must be signed in to change notification settings - Fork 21
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
Missing directories #16
Comments
Hi,
Am 25.10.2024 um 13:20 schrieb Mighty ***@***.***>:
On 6.12.0-rc4 branch, build fails with
make[1]: Entering directory '/mnt/linux/.output'
GEN Makefile
CALL ../scripts/checksyscalls.sh
MAKE drivers/gpu/drm/pvrsgx: omap4430/60
CC [M] drivers/gpu/drm/pvrsgx/1.17.4948957/eurasia_km/services4/system/omap/sysconfig.o
cc1: warning: ../../drivers/gpu/drm/pvrsgx/1.17.4948957/eurasia_km/: No such file or directory [-Wmissing-include-dirs]
cc1: warning: ../../drivers/gpu/drm/pvrsgx/1.17.4948957/eurasia_km/include4: No such file or directory [-Wmissing-include-dirs]
cc1: warning: ../../drivers/gpu/drm/pvrsgx/1.17.4948957/eurasia_km/services4/include: No such file or directory [-Wmissing-include-dirs]
cc1: warning: ../../drivers/gpu/drm/pvrsgx/1.17.4948957/eurasia_km/services4/include/env/linux: No such file or directory [-Wmissing-include-dirs]
cc1: warning: ../../drivers/gpu/drm/pvrsgx/1.17.4948957/eurasia_km/services4/system/include: No such file or directory [-Wmissing-include-dirs]
cc1: warning: ../../drivers/gpu/drm/pvrsgx/1.17.4948957/eurasia_km/services4/srvkm/bridged: No such file or directory [-Wmissing-include-dirs]
cc1: warning: ../../drivers/gpu/drm/pvrsgx/1.17.4948957/eurasia_km/services4/srvkm/bridged/sgx: No such file or directory [-Wmissing-include-dirs]
cc1: warning: ../../drivers/gpu/drm/pvrsgx/1.17.4948957/eurasia_km/services4/srvkm/devices/sgx: No such file or directory [-Wmissing-include-dirs]
cc1: warning: ../../drivers/gpu/drm/pvrsgx/1.17.4948957/eurasia_km/services4/srvkm/env/linux: No such file or directory [-Wmissing-include-dirs]
cc1: warning: ../../drivers/gpu/drm/pvrsgx/1.17.4948957/eurasia_km/services4/srvkm/hwdefs: No such file or directory [-Wmissing-include-dirs]
cc1: warning: ../../drivers/gpu/drm/pvrsgx/1.17.4948957/eurasia_km/services4/srvkm/include: No such file or directory [-Wmissing-include-dirs]
cc1: warning: ../../drivers/gpu/drm/pvrsgx/1.17.4948957/eurasia_km/services4/3rdparty/bufferclass_example: No such file or directory [-Wmissing-include-dirs]
cc1: warning: ../../drivers/gpu/drm/pvrsgx/1.17.4948957/eurasia_km/services4/system/omap: No such file or directory [-Wmissing-include-dirs]
cc1: warning: ../../drivers/gpu/drm/pvrsgx/1.17.4948957/eurasia_km/services4/3rdparty/linux_drm: No such file or directory [-Wmissing-include-dirs]
../drivers/gpu/drm/pvrsgx/1.17.4948957/eurasia_km/services4/system/omap/sysconfig.c:44:10: fatal error: services_headers.h: No such file or directory
44 | #include "services_headers.h"
| ^~~~~~~~~~~~~~~~~~~~
compilation terminated.
make[8]: *** [../scripts/Makefile.build:229: drivers/gpu/drm/pvrsgx/1.17.4948957/eurasia_km/services4/system/omap/sysconfig.o] Error 1
make[7]: *** [../drivers/gpu/drm/pvrsgx/Makefile:69: drivers/gpu/drm/pvrsgx/pvr] Error 2
make[6]: *** [../scripts/Makefile.build:478: drivers/gpu/drm/pvrsgx] Error 2
make[5]: *** [../scripts/Makefile.build:478: drivers/gpu/drm] Error 2
make[4]: *** [../scripts/Makefile.build:478: drivers/gpu] Error 2
make[4]: *** Waiting for unfinished jobs....
make[3]: *** [../scripts/Makefile.build:478: drivers] Error 2
make[2]: *** [/mnt/linux/Makefile:1936: .] Error 2
make[1]: *** [/mnt/linux/Makefile:224: __sub-make] Error 2
make[1]: Leaving directory '/mnt/linux/.output'
make: *** [Makefile:224: __sub-make] Error 2
Thanks for the report. I'll check asap.
BR,
Nikolaus
|
|
Hi,
I have now checked and it works for me with the Letux kernel (and defconfig).
So I tried with omap2plus_defconfig (and 32 bit ARM).
There I had to add CONFIG_PREEMPT_VOLUNTARY=y.
Am 25.10.2024 um 13:20 schrieb Mighty ***@***.***>:
On 6.12.0-rc4 branch, build fails with
make[1]: Entering directory '/mnt/linux/.output'
GEN Makefile
CALL ../scripts/checksyscalls.sh
MAKE drivers/gpu/drm/pvrsgx: omap4430/60
CC [M] drivers/gpu/drm/pvrsgx/1.17.4948957/eurasia_km/services4/system/omap/sysconfig.o
cc1: warning: ../../drivers/gpu/drm/pvrsgx/1.17.4948957/eurasia_km/: No such file or directory [-Wmissing-include-dirs]
This is strange why you see ../.. as prefix of drivers. Did you "cd" into the kernel root tree when running make?
cc1: warning: ../../drivers/gpu/drm/pvrsgx/1.17.4948957/eurasia_km/include4: No such file or directory [-Wmissing-include-dirs]
cc1: warning: ../../drivers/gpu/drm/pvrsgx/1.17.4948957/eurasia_km/services4/include: No such file or directory [-Wmissing-include-dirs]
cc1: warning: ../../drivers/gpu/drm/pvrsgx/1.17.4948957/eurasia_km/services4/include/env/linux: No such file or directory [-Wmissing-include-dirs]
cc1: warning: ../../drivers/gpu/drm/pvrsgx/1.17.4948957/eurasia_km/services4/system/include: No such file or directory [-Wmissing-include-dirs]
cc1: warning: ../../drivers/gpu/drm/pvrsgx/1.17.4948957/eurasia_km/services4/srvkm/bridged: No such file or directory [-Wmissing-include-dirs]
cc1: warning: ../../drivers/gpu/drm/pvrsgx/1.17.4948957/eurasia_km/services4/srvkm/bridged/sgx: No such file or directory [-Wmissing-include-dirs]
cc1: warning: ../../drivers/gpu/drm/pvrsgx/1.17.4948957/eurasia_km/services4/srvkm/devices/sgx: No such file or directory [-Wmissing-include-dirs]
cc1: warning: ../../drivers/gpu/drm/pvrsgx/1.17.4948957/eurasia_km/services4/srvkm/env/linux: No such file or directory [-Wmissing-include-dirs]
cc1: warning: ../../drivers/gpu/drm/pvrsgx/1.17.4948957/eurasia_km/services4/srvkm/hwdefs: No such file or directory [-Wmissing-include-dirs]
cc1: warning: ../../drivers/gpu/drm/pvrsgx/1.17.4948957/eurasia_km/services4/srvkm/include: No such file or directory [-Wmissing-include-dirs]
cc1: warning: ../../drivers/gpu/drm/pvrsgx/1.17.4948957/eurasia_km/services4/3rdparty/bufferclass_example: No such file or directory [-Wmissing-include-dirs]
cc1: warning: ../../drivers/gpu/drm/pvrsgx/1.17.4948957/eurasia_km/services4/system/omap: No such file or directory [-Wmissing-include-dirs]
cc1: warning: ../../drivers/gpu/drm/pvrsgx/1.17.4948957/eurasia_km/services4/3rdparty/linux_drm: No such file or directory [-Wmissing-include-dirs]
../drivers/gpu/drm/pvrsgx/1.17.4948957/eurasia_km/services4/system/omap/sysconfig.c:44:10: fatal error: services_headers.h: No such file or directory
44 | #include "services_headers.h"
| ^~~~~~~~~~~~~~~~~~~~
It appears to be an effect of the cc1 search paths and build environment.
Can you check that drivers/gpu/drm/pvrsgx/1.17.4948957/eurasia_km/services4/srvkm/include/services_headers.h (without ../..) exists?
Maybe, some shell script plus magic which tries to locate the build root in a subdirectory is doing not the same thing as for me.
We should also verify that we try to build the same branch:
https://github.com/openpvrsgx-devgroup/linux_openpvrsgx/tree/pvrsrvkm-6.12-rc4
compilation terminated.
make[8]: *** [../scripts/Makefile.build:229: drivers/gpu/drm/pvrsgx/1.17.4948957/eurasia_km/services4/system/omap/sysconfig.o] Error 1
make[7]: *** [../drivers/gpu/drm/pvrsgx/Makefile:69: drivers/gpu/drm/pvrsgx/pvr] Error 2
make[6]: *** [../scripts/Makefile.build:478: drivers/gpu/drm/pvrsgx] Error 2
make[5]: *** [../scripts/Makefile.build:478: drivers/gpu/drm] Error 2
make[4]: *** [../scripts/Makefile.build:478: drivers/gpu] Error 2
make[4]: *** Waiting for unfinished jobs....
make[3]: *** [../scripts/Makefile.build:478: drivers] Error 2
make[2]: *** [/mnt/linux/Makefile:1936: .] Error 2
make[1]: *** [/mnt/linux/Makefile:224: __sub-make] Error 2
make[1]: Leaving directory '/mnt/linux/.output'
make: *** [Makefile:224: __sub-make] Error 2
Best,
Nikolaus
|
Hm, this isnt set on my config, which is indeed based on omap2plus https://gitlab.com/pvrports/pvrports/-/blob/v23.12/community/linux-openpvrsgx/config-openpvrsgx.armv7?ref_type=heads#L107
Ah yes, I'm using pmOS's envkernel for this (https://wiki.postmarketos.org/wiki/envkernel) since the normal cross compiler breaks the build with
I do think Best Regards |
Hey, quick update did a build on |
Great!!!
I am currently hunting some compile bugs in the ddk 1.14 code.
… Am 26.10.2024 um 18:56 schrieb Mighty ***@***.***>:
Hey, quick update did a build on 6.12.0-rc4 with CONFIG_PREEMPT_VOLUNTARY=y and it worked! Really bizarre
—
Reply to this email directly, view it on GitHub <#16 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAHOUPJJV4XH2UVRBBCYRVLZ5PCUXAVCNFSM6AAAAABQTB4S2CVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDIMZZGY2TINZUGQ>.
You are receiving this because you commented.
|
Hey, sorry seems like I had built 6.8 again by my mistake, even with |
64ba2f0#diff-a494205b8219139c0f662331e8252a23dbe70ecba7a17863b25dc4791372a860R508 |
Hi,
Am 27.10.2024 um 11:10 schrieb Mighty ***@***.***>:
Hey, sorry seems like I had built 6.8 again by my mistake, even with CONFIG_PREEMPT_VOLUNTARY, 6.12.0-rc4 fails with the same error
Ok, I see.
Well, then it likely has something to do with how your source tree is set up and how make is called.
I just git checkout pvrsrvkm and then in the root do "make omap2plus_defconfig".
Best, Nikolaus
|
Hi,
Am 27.10.2024 um 11:17 schrieb Mighty ***@***.***>:
64ba2f0#diff-a494205b8219139c0f662331e8252a23dbe70ecba7a17863b25dc4791372a860R508 <64ba2f0#diff-a494205b8219139c0f662331e8252a23dbe70ecba7a17863b25dc4791372a860R508>
Also why are we going back to 1.14 ddk now?
Well, it was always in this way in the omap2plus_defconfig, e.g.:
https://github.com/openpvrsgx-devgroup/linux_openpvrsgx/blob/letux-pvrsrvkm-6.0-rc7/arch/arm/configs/omap2plus_defconfig#L529
https://github.com/openpvrsgx-devgroup/linux_openpvrsgx/blob/pvrsrvkm-6.11-rc2/arch/arm/configs/omap2plus_defconfig#L508
It is just a feature of GitHub to hide the original date (18 Feb 2020) and show only the date of the last rebaseto v6.12-rc4 (21 Oct 2024) as "committed last week".
The reason for this "default" is that the DDK1.14 and DDK1.17 support different subsets of the OMAP family so it is not possible do it right for everyone.
Best,
Nikolaus
|
That is even more troubling considering how 6.8 just works
So as you said, I tried doing the omap2plus_defconfig but it fails with the same error - https://paste.debian.net/1333629/ BR |
Hi,
Am 27.10.2024 um 19:56 schrieb Mighty ***@***.***>:
Well, then it likely has something to do with how your source tree is set up and how make is called.
That is even more troubling considering how 6.8 just works
Well, there may be upstream changes to the Kernel build system in between. Or we have modified the
drivers/gpu/drm/pvrsgx.
Could you try to build the 6.10 tree and depending on its outcome 6.9 and 6.11? Sort of a manual bisect?
Then we know at which release this has changed.
I just git checkout pvrsrvkm and then in the root do "make omap2plus_defconfig".
So as you said, I tried doing the omap2plus_defconfig but it fails with the same error - https://paste.debian.net/1333629/
I have looked through it and this line
CALL ../scripts/checksyscalls.sh
is something I have never seen in my builds.
And
make: Entering directory '/mnt/linux' make[1]: Entering directory '/mnt/linux/.output'
means that the build process changes to some subdirectory ".output" in between.
This may be the reason for ../scripts being found and ../../drivers/gpu/drm/pvrsgx/ not found.
(and I have no idea what pmbootsrap and envkernel.sh are doing).
Of course we have some implicit assumptions in the pvrsgx Makefiles about directories
and associated -I. And this pmbootstrap envkernel.sh may break these.
Is it possible to run make outside of pmbootstrap without this "Entering directory"?
BR,
Nikolaus
|
Yep this seems to be the best method, I'll try and figure out what branch it breaks on and then the commits can be checked?
It most likely is https://github.com/torvalds/linux/blob/master/scripts/checksyscalls.sh
That just happens when an outdir is used right, like with -O=.output? I gave it a try with ubuntu 24.04 cc, but that gave me ld errors as mentioned above BR |
Am 27.10.2024 um 21:04 schrieb Mighty ***@***.***>:
Well, there may be upstream changes to the Kernel build system in between. Or we have modified the drivers/gpu/drm/pvrsgx. Could you try to build the 6.10 tree and depending on its outcome 6.9 and 6.11? Sort of a manual bisect? Then we know at which release this has changed.
Yep this seems to be the best method, I'll try and figure out what branch it breaks on and then the commits can be checked?
I have looked through it and this line CALL ../scripts/checksyscalls.sh is something I have never seen in my builds.
It most likely is https://github.com/torvalds/linux/blob/master/scripts/checksyscalls.sh
Sure. But on my builds never with ../ prefix.
And make: Entering directory '/mnt/linux' make[1]: Entering directory '/mnt/linux/.output' means that the build process changes to some subdirectory ".output" in between. This may be the reason for ../scripts being found and ../../drivers/gpu/drm/pvrsgx/ not found. (and I have no idea what pmbootsrap and envkernel.sh are doing). Of course we have some implicit assumptions in the pvrsgx Makefiles about directories and associated -I. And this pmbootstrap envkernel.sh may break these. Is it possible to run make outside of pmbootstrap without this "Entering directory"?
That just happens when an outdir is used right, like with -O=.output? I gave it a try with ubuntu 24.04 cc, but that gave me ld errors as mentioned above
Ok, this is a good hint. If you look at our Makefile:
https://github.com/openpvrsgx-devgroup/linux_openpvrsgx/blob/fd5f1bbea38779cd39a1a3b3d1443bb5bd9db5b4/drivers/gpu/drm/pvrsgx/Makefile#L15
It uses $(out) and $(srctree) which may be related to the -O flag.
So it might be that the Makefile isn't handling you situation well enough.
In fact the Makefile is a big hack to build multiple kernel modules from a single tree which is not easy to achieve with Kbuild.
But I have no idea how to change it and test for you...
|
Am 27.10.2024 um 21:19 schrieb H. Nikolaus Schaller ***@***.***>:
> Am 27.10.2024 um 21:04 schrieb Mighty ***@***.***>:
>
>
> Well, there may be upstream changes to the Kernel build system in between. Or we have modified the drivers/gpu/drm/pvrsgx. Could you try to build the 6.10 tree and depending on its outcome 6.9 and 6.11? Sort of a manual bisect? Then we know at which release this has changed.
> Yep this seems to be the best method, I'll try and figure out what branch it breaks on and then the commits can be checked?
> I have looked through it and this line CALL ../scripts/checksyscalls.sh is something I have never seen in my builds.
> It most likely is https://github.com/torvalds/linux/blob/master/scripts/checksyscalls.sh
Sure. But on my builds never with ../ prefix.
> And make: Entering directory '/mnt/linux' make[1]: Entering directory '/mnt/linux/.output' means that the build process changes to some subdirectory ".output" in between. This may be the reason for ../scripts being found and ../../drivers/gpu/drm/pvrsgx/ not found. (and I have no idea what pmbootsrap and envkernel.sh are doing). Of course we have some implicit assumptions in the pvrsgx Makefiles about directories and associated -I. And this pmbootstrap envkernel.sh may break these. Is it possible to run make outside of pmbootstrap without this "Entering directory"?
> That just happens when an outdir is used right, like with -O=.output? I gave it a try with ubuntu 24.04 cc, but that gave me ld errors as mentioned above
Ok, this is a good hint. If you look at our Makefile:
https://github.com/openpvrsgx-devgroup/linux_openpvrsgx/blob/fd5f1bbea38779cd39a1a3b3d1443bb5bd9db5b4/drivers/gpu/drm/pvrsgx/Makefile#L15
It uses $(out) and $(srctree) which may be related to the -O flag.
Indeed this makes the "Entering directory" visible:
make V=2 CONFIG_DEBUG_SECTION_MISMATCH=y letux_defconfig O=.output
make[1]: Entering directory '/Volumes/CaseSensitive/master/.output'
***
*** The source tree is not clean, please run 'make mrproper'
*** in /Volumes/CaseSensitive/master
***
/Volumes/CaseSensitive/master/Makefile:631: recipe for target 'outputmakefile' failed
make[2]: *** [outputmakefile] Error 1
/Volumes/CaseSensitive/master/Makefile:224: recipe for target '__sub-make' failed
…
So it might be that the Makefile isn't handling you situation well enough.
In fact the Makefile is a big hack to build multiple kernel modules from a single tree which is not easy to achieve with Kbuild.
But I have no idea how to change it and test for you...
|
Am 27.10.2024 um 21:35 schrieb H. Nikolaus Schaller ***@***.***>:
>
>
>
> So it might be that the Makefile isn't handling you situation well enough.
>
> In fact the Makefile is a big hack to build multiple kernel modules from a single tree which is not easy to achieve with Kbuild.
> But I have no idea how to change it and test for you...
A new idea:
it is not the master Makefile (drivers/gpu/drm/pvrsgx/Makefile)
but the one inside the DDK version tree:
drivers/gpu/drm/pvrsgx/1.14.3699939/eurasia_km/Makefile
or
drivers/gpu/drm/pvrsgx/1.14.3699939/eurasia_km/Makefile
There we find:
ccflags-y += \
...
-I$(srctree)/$(src)/services4/srvkm/include \
...
which should enable the compiler to find
drivers/gpu/drm/pvrsgx/1.17.4948957/eurasia_km/services4/srvkm/include/services_headers.h
But it doesn't. Rather your compiler complains:
cc1: warning: ../../drivers/gpu/drm/pvrsgx/1.17.4948957/eurasia_km/services4/srvkm/include: No such file or directory [-Wmissing-include-dirs]
This could mean that the $(srctree) prefix is ../.. if make O=.output is done.
And is either absolute or ./ if there is no O=.output.
And $(src) should be drivers/gpu/drm/pvrsgx/1.17.4948957/eurasia_km.
But I don't know and it might be different
Could you simply try to remove the $(srctree)/ prefix and check what happens?
Or alternatively remove $(src)/?
Or replace $(srctree)/$(src)/ by drivers/gpu/drm/pvrsgx/1.17.4948957/eurasia_km/?
If this works and compiles sysconfig.c (likely will still emit a lot of cc1 warnings),
we have a hint what we need to better understand and fix.
BR and thanks,
Nikolaus
|
Hey sorry for the late replies, but I followed as you said and it seems that may be the solution
So it seems these vars are badly defined in our makefile, I will check that they are in 6.8 and probably will try to fix it, since then a lot of makefiles would be affected due to some wrong definition :(
|
Ok, we are on the right track!
… Am 29.10.2024 um 15:35 schrieb Mighty ***@***.***>:
Hey sorry for the late replies, but I followed as you said and it seems that may be the solution
$srctree is [..]
$src is [../drivers/gpu/drm/pvrsgx/1.17.4948957/eurasia_km]
So it seems these vars are badly defined in our makefile, I will check that they are in 6.8 and probably will try to fix it, since then a lot of makefiles would be affected due to some wrong definition :(
Hardcoding the path also works like you mentioned above (the last option) but then some other makefile needs to be fixed xD
$srctree is [..]
$src is [../drivers/gpu/drm/pvrsgx/1.17.4948957/eurasia_km]
CC [M] drivers/gpu/drm/pvrsgx/1.17.4948957/eurasia_km/services4/system/omap/sysconfig.o
cc1: warning: include/linux: No such file or directory [-Wmissing-include-dirs]
cc1: warning: ../../drivers/gpu/drm/pvrsgx/1.17.4948957/eurasia_km/services4/3rdparty/linux_drm: No such file or directory [-Wmissing-include-dirs]
CC [M] drivers/gpu/drm/pvrsgx/1.17.4948957/eurasia_km/services4/system/omap/sysutils_linux.o
cc1: warning: include/linux: No such file or directory [-Wmissing-include-dirs]
cc1: warning: ../../drivers/gpu/drm/pvrsgx/1.17.4948957/eurasia_km/services4/3rdparty/linux_drm: No such file or directory [-Wmissing-include-dirs]
CC drivers/usb/phy/of.o
CC drivers/net/phy/stubs.o
../drivers/gpu/drm/pvrsgx/1.17.4948957/eurasia_km/services4/system/omap/sysutils_linux.c:157:10: warning: no previous prototype for 'SysGetSGXTimingInformation' [-Wmissing-prototypes]
157 | IMG_VOID SysGetSGXTimingInformation(SGX_TIMING_INFORMATION *psTimingInfo)
| ^~~~~~~~~~~~~~~~~~~~~~~~~~
CC [M] drivers/gpu/drm/pvrsgx/1.17.4948957/eurasia_km/../../pvr-drv.o
cc1: warning: include/linux: No such file or directory [-Wmissing-include-dirs]
cc1: warning: ../../drivers/gpu/drm/pvrsgx/1.17.4948957/eurasia_km/services4/3rdparty/linux_drm: No such file or directory [-Wmissing-include-dirs]
CC drivers/input/input-compat.o
CC drivers/usb/host/pci-quirks.o
AR drivers/mtd/nand/onenand/built-in.a
CC drivers/mtd/nand/raw/nand_base.o
CC [M] drivers/usb/common/common.o
CC [M] drivers/usb/phy/phy-generic.o
AR drivers/scsi/built-in.a
CC drivers/rtc/lib.o
CC [M] drivers/gpu/drm/pvrsgx/1.17.4948957/eurasia_km/services4/srvkm/bridged/bridged_pvr_bridge.o
cc1: warning: include/linux: No such file or directory [-Wmissing-include-dirs]
cc1: warning: ../../drivers/gpu/drm/pvrsgx/1.17.4948957/eurasia_km/services4/3rdparty/linux_drm: No such file or directory [-Wmissing-include-dirs]
../drivers/gpu/drm/pvrsgx/1.17.4948957/eurasia_km/services4/srvkm/bridged/bridged_pvr_bridge.c:46:10: fatal error: stddef.h: No such file or directory
46 | #include <stddef.h>
| ^~~~~~~~~~
compilation terminated.
—
Reply to this email directly, view it on GitHub <#16 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAHOUPMFAVTAGMDWNVXSP6DZ56MJRAVCNFSM6AAAAABQTB4S2CVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDINBUGQ2TEMZWHE>.
You are receiving this because you commented.
|
So on 6.8 it is and on 6.12 it becomes |
Just adding |
Am 29.10.2024 um 16:03 schrieb Mighty ***@***.***>:
Just adding src := drivers/gpu/drm/pvrsgx/1.17.4948957/eurasia_km to the makefile and it seems to work just fine now, no clue how and where src is defined though
So you can now compile it completely? That would be fine.
I am currently grepping through the source code to understand.
And it will be interesting what has changed between 6.8 and 6.12.
|
Yes it builds successfully using that hack! |
Am 29.10.2024 um 16:00 schrieb Mighty ***@***.***>:
So on 6.8 it is
$srctree is [..]
$src is [drivers/gpu/drm/pvrsgx/1.17.4948957/eurasia_km]
and on 6.12 it becomes
$srctree is [..]
$src is [../drivers/gpu/drm/pvrsgx/1.17.4948957/eurasia_km]
Well, then this must be a change in the Linux build system. Which changes the definition of $(src).
After some grepping and git blaming I found:
it is defined in scripts/Makefile.build (original code by Linus from before 2005).
It was changed in v6.10-rc1 by a patch from April 2024: b1992c3 ("kbuild: use $(src) instead of $(srctree)/$(src) for source directory")
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?h=b1992c3772e69a
This patch comments:
Consequently, $(srctree)/$(src) in upstream Makefiles need to be replaced with $(src).
So we have the reason and a solution...
find drivers/gpu/drm/pvrsgx -name Makefile -exec sed -i.bak 's|$(srctree)/$(src)|$(src)|' {} \;
I will add a patch to our tree.
BR,
Nikolaus
|
That is quite amazing! Thanks a lot for the efforts, they are very much appreciated! Best Regards |
This should be the patch that is working, it leads to a few warnings in build as well
But using this we have the kernel booting and working, I'll test kmscube and other things to verify and then send a mr as well. |
Indeed that is what already has been added to the Letux repos (but not yet pushed). So there is no need for a MR. |
Could you please merge them? The gpu is failing for me,
|
During the migration of Soundwire runtime stream allocation from the Qualcomm Soundwire controller to SoC's soundcard drivers the sdm845 soundcard was forgotten. At this point any playback attempt or audio daemon startup, for instance on sdm845-db845c (Qualcomm RB3 board), will result in stream pointer NULL dereference: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000020 Mem abort info: ESR = 0x0000000096000004 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x04: level 0 translation fault Data abort info: ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000 CM = 0, WnR = 0, TnD = 0, TagAccess = 0 GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 user pgtable: 4k pages, 48-bit VAs, pgdp=0000000101ecf000 [0000000000000020] pgd=0000000000000000, p4d=0000000000000000 Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP Modules linked in: ... CPU: 5 UID: 0 PID: 1198 Comm: aplay Not tainted 6.12.0-rc2-qcomlt-arm64-00059-g9d78f315a362-dirty #18 Hardware name: Thundercomm Dragonboard 845c (DT) pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : sdw_stream_add_slave+0x44/0x380 [soundwire_bus] lr : sdw_stream_add_slave+0x44/0x380 [soundwire_bus] sp : ffff80008a2035c0 x29: ffff80008a2035c0 x28: ffff80008a203978 x27: 0000000000000000 x26: 00000000000000c0 x25: 0000000000000000 x24: ffff1676025f4800 x23: ffff167600ff1cb8 x22: ffff167600ff1c98 x21: 0000000000000003 x20: ffff167607316000 x19: ffff167604e64e80 x18: 0000000000000000 x17: 0000000000000000 x16: ffffcec265074160 x15: 0000000000000000 x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000 x11: 0000000000000000 x10: 0000000000000000 x9 : 0000000000000000 x8 : 0000000000000000 x7 : 0000000000000000 x6 : ffff167600ff1cec x5 : ffffcec22cfa2010 x4 : 0000000000000000 x3 : 0000000000000003 x2 : ffff167613f836c0 x1 : 0000000000000000 x0 : ffff16761feb60b8 Call trace: sdw_stream_add_slave+0x44/0x380 [soundwire_bus] wsa881x_hw_params+0x68/0x80 [snd_soc_wsa881x] snd_soc_dai_hw_params+0x3c/0xa4 __soc_pcm_hw_params+0x230/0x660 dpcm_be_dai_hw_params+0x1d0/0x3f8 dpcm_fe_dai_hw_params+0x98/0x268 snd_pcm_hw_params+0x124/0x460 snd_pcm_common_ioctl+0x998/0x16e8 snd_pcm_ioctl+0x34/0x58 __arm64_sys_ioctl+0xac/0xf8 invoke_syscall+0x48/0x104 el0_svc_common.constprop.0+0x40/0xe0 do_el0_svc+0x1c/0x28 el0_svc+0x34/0xe0 el0t_64_sync_handler+0x120/0x12c el0t_64_sync+0x190/0x194 Code: aa0403fb f9418400 9100e000 9400102f (f8420f22) ---[ end trace 0000000000000000 ]--- 0000000000006108 <sdw_stream_add_slave>: 6108: d503233f paciasp 610c: a9b97bfd stp x29, x30, [sp, #-112]! 6110: 910003fd mov x29, sp 6114: a90153f3 stp x19, x20, [sp, #16] 6118: a9025bf5 stp x21, x22, [sp, #32] 611c: aa0103f6 mov x22, x1 6120: 2a0303f5 mov w21, w3 6124: a90363f7 stp x23, x24, [sp, #48] 6128: aa0003f8 mov x24, x0 612c: aa0203f7 mov x23, x2 6130: a9046bf9 stp x25, x26, [sp, #64] 6134: aa0403f9 mov x25, x4 <-- x4 copied to x25 6138: a90573fb stp x27, x28, [sp, #80] 613c: aa0403fb mov x27, x4 6140: f9418400 ldr x0, [x0, #776] 6144: 9100e000 add x0, x0, #0x38 6148: 94000000 bl 0 <mutex_lock> 614c: f8420f22 ldr x2, [x25, #32]! <-- offset 0x44 ^^^ This is 0x6108 + offset 0x44 from the beginning of sdw_stream_add_slave() where data abort happens. wsa881x_hw_params() is called with stream = NULL and passes it further in register x4 (5th argument) to sdw_stream_add_slave() without any checks. Value from x4 is copied to x25 and finally it aborts on trying to load a value from address in x25 plus offset 32 (in dec) which corresponds to master_list member in struct sdw_stream_runtime: struct sdw_stream_runtime { const char * name; /* 0 8 */ struct sdw_stream_params params; /* 8 12 */ enum sdw_stream_state state; /* 20 4 */ enum sdw_stream_type type; /* 24 4 */ /* XXX 4 bytes hole, try to pack */ here-> struct list_head master_list; /* 32 16 */ int m_rt_count; /* 48 4 */ /* size: 56, cachelines: 1, members: 6 */ /* sum members: 48, holes: 1, sum holes: 4 */ /* padding: 4 */ /* last cacheline: 56 bytes */ Fix this by adding required calls to qcom_snd_sdw_startup() and sdw_release_stream() to startup and shutdown routines which restores the previous correct behaviour when ->set_stream() method is called to set a valid stream runtime pointer on playback startup. Reproduced and then fix was tested on db845c RB3 board. Reported-by: Dmitry Baryshkov <[email protected]> Cc: [email protected] Fixes: 15c7fab ("ASoC: qcom: Move Soundwire runtime stream alloc to soundcards") Cc: Srinivas Kandagatla <[email protected]> Cc: Dmitry Baryshkov <[email protected]> Cc: Krzysztof Kozlowski <[email protected]> Cc: Pierre-Louis Bossart <[email protected]> Signed-off-by: Alexey Klimov <[email protected]> Tested-by: Steev Klimaszewski <[email protected]> # Lenovo Yoga C630 Reviewed-by: Krzysztof Kozlowski <[email protected]> Reviewed-by: Srinivas Kandagatla <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Mark Brown <[email protected]>
….9-rc1 With upstream commit b1992c3 ("kbuild: use $(src) instead of $(srctree)/$(src) for source directory") the logic of $(srctree) and $(src) has changed. Consequently, $(srctree)/$(src) in upstream Makefiles need to be replaced with $(src). Bug reported: #16 Signed-off-by: H. Nikolaus Schaller <[email protected]>
…v6.9-rc1 With upstream commit b1992c3 ("kbuild: use $(src) instead of $(srctree)/$(src) for source directory") the logic of $(srctree) and $(src) has changed. Consequently, $(srctree)/$(src) in upstream Makefiles need to be replaced with $(src). Bug reported: #16 Signed-off-by: H. Nikolaus Schaller <[email protected]>
…v6.9-rc1 With upstream commit b1992c3 ("kbuild: use $(src) instead of $(srctree)/$(src) for source directory") the logic of $(srctree) and $(src) has changed. Consequently, $(srctree)/$(src) in upstream Makefiles need to be replaced with $(src). Bug reported: #16 Signed-off-by: H. Nikolaus Schaller <[email protected]>
…v6.9-rc1 With upstream commit b1992c3 ("kbuild: use $(src) instead of $(srctree)/$(src) for source directory") the logic of $(srctree) and $(src) has changed. Consequently, $(srctree)/$(src) in upstream Makefiles need to be replaced with $(src). Bug reported: #16 Signed-off-by: H. Nikolaus Schaller <[email protected]>
Am 30.10.2024 um 16:38 schrieb Mighty ***@***.***>:
Could you please merge them?
I have pushed a patched version just some minutes ago.
The gpu is failing for me,
[ 26.444244] input: fbkeyboard as /devices/virtual/input/input3
[ 26.806579] ------------[ cut here ]------------
[ 26.807769] WARNING: CPU: 1 PID: 1849 at drivers/gpu/drm/drm_file.c:312 drm_open_helper+0x140/0x14c
[ 26.809051] Modules linked in: nft_reject_inet nf_reject_ipv6 nft_reject nft_ct nf_conntrack nf_defrag_ipv4 nf_defrag_ipv6 nf_tables nfnetlink ipv6 pvrsrvkm_omap4_sgx540_120 emif omap4_keypad omap_aes_driver omap_sham brcmfmac_wcc matrix_keymap omap_mailbox ohci_platform ohci_hcd ehci_omap brcmfmac brcmutil cfg80211 hci_uart btbcm omap_hdq bluetooth omap_des wire crypto_engine cn hwmon libdes omap_crypto ecdh_generic ecc mousedev pwm_twl_led joydev gpio_ir_tx rc_core cpufreq_dt gpio_keys usb_f_ncm u_ether libcomposite
[ 26.817382] CPU: 1 UID: 0 PID: 1849 Comm: pvrsrvinit Tainted: G W 6.12.0-rc4 #2
[ 26.819305] Tainted: [W]=WARN
[ 26.821105] Hardware name: Generic OMAP4 (Flattened Device Tree)
[ 26.822967] Call trace:
[ 26.822998] unwind_backtrace from show_stack+0x10/0x14
[ 26.826782] show_stack from dump_stack_lvl+0x60/0x84
[ 26.828704] dump_stack_lvl from __warn+0x80/0x154
[ 26.830596] __warn from warn_slowpath_fmt+0x1ac/0x1b4
[ 26.832458] warn_slowpath_fmt from drm_open_helper+0x140/0x14c
[ 26.834320] drm_open_helper from drm_open+0x8c/0x130
[ 26.836151] drm_open from drm_stub_open+0xa0/0xd0
[ 26.837982] drm_stub_open from chrdev_open+0xac/0x1f0
[ 26.839752] chrdev_open from do_dentry_open+0x140/0x4c0
[ 26.841400] do_dentry_open from vfs_open+0x24/0xe8
[ 26.842987] vfs_open from path_openat+0x65c/0x1124
[ 26.844451] path_openat from do_filp_open+0x7c/0x118
[ 26.845794] do_filp_open from do_sys_openat2+0xa0/0xd4
[ 26.847076] do_sys_openat2 from sys_open+0x98/0xbc
[ 26.848266] sys_open from ret_fast_syscall+0x0/0x54
[ 26.849456] Exception stack(0xf01f5fa8 to 0xf01f5ff0)
[ 26.850616] 5fa0: 00000000 00000000 bed76a60 000a0002 00000000 00000000
[ 26.851837] 5fc0: 00000000 00000000 00000000 00000005 b6eb6028 b6eb601c b6eb603c 0045f280
[ 26.853088] 5fe0: bed76a00 bed769f0 b6f478a7 b6f471e4
[ 26.854339] ---[ end trace 0000000000000000 ]---
[ 28.881744] ieee80211 phy0: brcmf_p2p_create_p2pdev: timeout occurred
[ 28.886138] ieee80211 phy0: brcmf_cfg80211_add_iface: add iface p2p-dev-wlan0 type 10 failed: err=-5
[ 33.048034] zram: Added device: zram0
kmscube
PVR:(Error): OpenServices: PVRDRMOpenRender failed [0, ]
PVR:(Error): PVRSRVConnect: Unable to open connection. [0, ]
PVR:(Error): Couldn't connect to services [0, ]
PVR:(Error): PVRDRIEGLGlobalDataInit: PVR Services initialisation failed [0, ]
PVR:(Error): PVRDRICreateScreenImpl: Couldn't create EGL global data [0, ]
PVR:(Error): OpenServices: PVRDRMOpenRender failed [0, ]
PVR:(Error): PVRSRVConnect: Unable to open connection. [0, ]
PVR:(Error): Couldn't connect to services [0, ]
PVR:(Error): PVRDRIEGLGlobalDataInit: PVR Services initialisation failed [0, ]
PVR:(Error): PVRDRICreateScreenImpl: Couldn't create EGL global data [0, ]
This looks like a different issue.
The strange thing is that the stack trace in itself is not linked to any pvrsgx code. The fail is outside.
But it is within the pvrsrvinit code in some do_sys_openat2() syscall.
Still it may be induced/related to the openpvrsgx code.
Maybe, can you strace yor pvrsrvinit and find out which file triggers the kernel warning?
kmscube and other applications need pvrsrvinit to succeed first.
Did it work with 6.8 kernel? We have fixed some parts of memory management but there may be bugs.
|
Not really sure what is breaking here, but the kernel just fails to work with 6.12, everything works flawlessly on 6.8 but I get no logs and the device gets stuck on framebuffer (mostly the kernel has panicked, I only see half a strace) and there is no way to access any logs |
Can you maybe disable / temporarily remove the pvrsrvkm kernel module to check if you can boot without?
|
So finally managed to get it booting and working, here is some logs that'd interest you
|
I suppose 6425bce#diff-4033cce15705ec9d3bce6ef544bd849d523a59a2df568e75c1569b0b04fcee4dR530 is a start? But you know better |
I have now installed Bullseye and the DDK 1.17 user space and get a similar missing initialization situation:
***@***.***:~# pvrsrvctl --no-module --start
PVR:(Error): OpenServices: PVRDRMOpenRender failed [0, ]
PVR:(Error): PVRSRVInitSrvConnect: PVRSRVConnect failed [0, ]
PVR:(Error): SrvInit: PVRSRVInitSrvConnect failed (4) [0, ]
pvrsrvctl: SrvInit failed (already initialized?) (err=PVRSRV_ERROR_INIT_FAILURE)
***@***.***:~#
But I have no vmalloc_node_range or issue to map SGX registers. Only
[ 25.038787] pvrsrvkm 50000000.gpu: Enabling quirks 00000000
Well, vibrator is different platform :)
[ 18.290771] input: twl4030:vibrator as ***@***.***:audio/twl4030-vibra/input/input4
Some system infos:
***@***.***:~# uname -a
Linux letux 6.12.0-rc5-letux+ #88 SMP PREEMPT Sat Nov 2 21:15:55 CET 2024 armv7l GNU/Linux
***@***.***:~# cat /proc/pvr/version
Version SGX_DDK sgxddk ***@***.*** (release) omap_sgx
System Version String: None
***@***.***:~# lsmod | fgrep pvrsrv
pvrsrvkm_omap3630_sgx530_125 299008 0
drm 385024 8 pvrsrvkm_omap3630_sgx530_125,panel_tpo_td028ttec1,display_connector,drm_display_helper,omapdrm,simple_bridge,drm_kms_helper
***@***.***:~#
… Am 02.11.2024 um 20:51 schrieb Mighty ***@***.***>:
So finally managed to get it booting and working, here is some logs that'd interest you
dmesg
[ 19.823730] gpio-vibrator vibrator: supply vcc not found, using dummy regulator
[ 19.844360] input: gpio-vibrator as /devices/platform/vibrator/input/input2
[ 19.907257] pvrsrvkm 56000000.gpu: Enabling quirks 00000001
[ 19.934631] vmalloc_node_range for size 33558528 failed: Address range restricted to 0xf6000000 - 0xff800000
[ 19.934661] PVR_K:(Error): SysLocateDevices: Failed to map SGX registers
[ 19.934692] PVR_K:(Error): SysInitialise: Failed to locate devices
[ 20.449401] NET: Registered PF_INET6 protocol family
sudo pvrsrvinit
PVR:(Error): OpenServices: PVRDRMOpenRender failed [0, ]
PVR:(Error): PVRSRVInitSrvConnect: PVRSRVConnect failed [0, ]
PVR:(Error): SrvInit: PVRSRVInitSrvConnect failed (4) [0, ]
failed to initialize server
kmscube
PVR:(Error): OpenServices: PVRDRMOpenRender failed [0, ]
PVR:(Error): PVRSRVConnect: Unable to open connection. [0, ]
PVR:(Error): Couldn't connect to services [0, ]
PVR:(Error): PVRDRIEGLGlobalDataInit: PVR Services initialisation failed [0, ]
PVR:(Error): PVRDRICreateScreenImpl: Couldn't create EGL global data [0, ]
PVR:(Error): OpenServices: PVRDRMOpenRender failed [0, ]
PVR:(Error): PVRSRVConnect: Unable to open connection. [0, ]
PVR:(Error): Couldn't connect to services [0, ]
PVR:(Error): PVRDRIEGLGlobalDataInit: PVR Services initialisation failed [0, ]
PVR:(Error): PVRDRICreateScreenImpl: Couldn't create EGL global data [0, ]
Using display 0xb60c9030 with EGL version 1.4
https://paste.debian.net/1334351/
—
Reply to this email directly, view it on GitHub <#16 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAHOUPNUAQ7FXY6WPDOHA2DZ6UUNZAVCNFSM6AAAAABQTB4S2CVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDINJTGEYTAMBRGY>.
You are receiving this because you commented.
|
Yeah the vibrator is just something that came along in the logs, but i think the main issue is The one you have put on Bullseye and DDK 1.17 seem to be different. Any clue where that vmalloc_node_range function is called, I assume it might be in the binaries? (like pvrsrvinit) |
I am also using https://github.com/maemo-leste/sgx-ddk-um/tree/maemo/beowulf-devel/ as the source |
https://pastebin.com/CaSZnSGD My config |
Am 03.11.2024 um 06:18 schrieb Mighty ***@***.***>:
Yeah the vibrator is just something that came along in the logs, but i think the main issue is
[ 19.934631] vmalloc_node_range for size 33558528 failed: Address range restricted to 0xf6000000 - 0xff800000
The one you have put on Bullseye and DDK 1.17 seem to be different.
Any clue where that vmalloc_node_range function is called, I assume it might be in the binaries? (like pvrsrvinit)
—
Reply to this email directly, view it on GitHub <#16 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAHOUPJ2MJ4BCG4EDM627VDZ6WWY5AVCNFSM6AAAAABQTB4S2CVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDINJTGMYDCMJZGU>.
You are receiving this because you commented.
My Bullseye packagefor omap3 is cloned from https://git.ti.com/cgit/graphics/omap5-sgx-ddk-um-linux/log/?h=ti-img-sgx/zeus/1.17.4948957 which may not be the latest one...
For vmalloc_node_range caller you could blacklist the pvrsrvkm in some /etc/modprobe/test.conf, then boot.
And then run modprobe to load the pvrsrvkm.so <http://pvrsrvkm.so/>. If the message appears then, it is called by our driver.
|
Am 03.11.2024 um 06:23 schrieb Mighty ***@***.***>:
https://git.ti.com/cgit/graphics/omap5-sgx-ddk-um-linux/commit/?h=1.17.4948957/mesa/glibc-2.35&id=84a396a4fb379f10931421e489ac8a199d6a9f2c also should we include this?
—
Reply to this email directly, view it on GitHub <#16 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAHOUPNS5Y37B4OATIUBKVTZ6WXM5AVCNFSM6AAAAABQTB4S2CVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDINJTGMYDEMJWHA>.
You are receiving this because you commented.
That are the user space libraries which are beyond the scope of this project.
But yes, they should be considered rather than your beowulf or my zeus branch.
|
Am 02.11.2024 um 20:58 schrieb Mighty ***@***.***>:
I suppose 6425bce#diff-4033cce15705ec9d3bce6ef544bd849d523a59a2df568e75c1569b0b04fcee4dR530 <6425bce#diff-4033cce15705ec9d3bce6ef544bd849d523a59a2df568e75c1569b0b04fcee4dR530> is a start? But you know better
—
Reply to this email directly, view it on GitHub <#16 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAHOUPJGIZCMICB2WVTBOF3Z6UVHFAVCNFSM6AAAAABQTB4S2CVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDINJTGEYTCNBZGQ>.
You are receiving this because you commented.
At least I could test 6.8, 6.10, 6.11 and they all report:
***@***.***:~# uname -a
Linux letux 6.11.5-letux+ #91 SMP PREEMPT Sun Nov 3 10:48:22 CET 2024 armv7l GNU/Linux
***@***.***:~# cat /proc/pvr/version
Version SGX_DDK sgxddk ***@***.*** (release) omap_sgx
System Version String: None
***@***.***:~# pvrsrvctl --no-module --start
[ 714.911254] PVR_K: UM DDK-(4948957) and KM DDK-(4948957) match. [ OK ]
***@***.***:~# cat /proc/pvr/version
Version SGX_DDK sgxddk ***@***.*** (release) omap_sgx
System Version String: SGX revision = 125
***@***.***:~#
So at least we now know for sure that the transision from 6.11 to 6.12 has damaged something.
|
Yes indeed that is the case, if i modprobe -r to stop it and start it again, this error appears again. So that is a lead we can track down. Also the error you've faced seems to be different than what I am facing, I will try building 6.11 and below to verify as well.
Since they have such a recent update I wondered it may help you as the branch says for glibc, im on musl and the older blobs were working fine so I guess its the kernel having some changes |
Yes, I can indeed confirm that 6.8, 6.10, 6.11 all work without issues, it is the transition to 6.12 that is breaking things :( |
I suppose 6425bce#diff-4033cce15705ec9d3bce6ef544bd849d523a59a2df568e75c1569b0b04fcee4dR530 is a start? But you know better
Well, this is was a patch for 6.11 and there it still works. And it removes an already dead #if 0 and adds a modification for 6.11 (and later).
Indeed this could have changed again for 6.12 since we use a deprecated call (no longer officially exported but by our "revert":
https://git.goldelico.com/?p=letux-kernel.git;a=blobdiff;f=mm/vmalloc.c;h=60f4e33265afc0a11d84664416ede6ea531eec13;hp=f41b54ecdf132c7fb55d6819e7fe7aa726f6c4fe;hb=5bc47f1159665af40c7c96efb229df7c996349e7;hpb=ed96388bb577868d03dda1ae17f7456bb4bcee34 <https://git.goldelico.com/?p=letux-kernel.git;a=blobdiff;f=mm/vmalloc.c;h=60f4e33265afc0a11d84664416ede6ea531eec13;hp=f41b54ecdf132c7fb55d6819e7fe7aa726f6c4fe;hb=5bc47f1159665af40c7c96efb229df7c996349e7;hpb=ed96388bb577868d03dda1ae17f7456bb4bcee34>
And, there are some changes to this upstream file:
git log --oneline v6.11..v6.12-rc1 mm/vmalloc.c
So this may be a reason for your vmalloc issue, even if the main change seems to replace (va->va_end - va->va_start)
by va_size(va) and introduce vrealloc_noprof() which we do not use.
There is only one new comment referring to __vmalloc_node_range_noprof():
https://elixir.bootlin.com/linux/v6.12-rc6/source/mm/vmalloc.c#L3643
For my failed overall initialization, I have also checked the diffs between 6.11 and 6.12 and only found this:
https://git.goldelico.com/?p=letux-kernel.git;a=blobdiff;f=drivers/gpu/drm/pvrsgx/1.17.4948957/eurasia_km/services4/srvkm/env/linux/osfunc.c;h=0da9de7c46969fbd9183bc3ddb3c6aa0df6c4ff2;hp=d86ece9894f28b5aafe1e2242d9656c3781a3c6e;hb=1f267ee25fe451742654ceecdd67bed948a13317;hpb=6425bce0d19e70f17da8eea7ec811d002d5b6db4 <https://git.goldelico.com/?p=letux-kernel.git;a=blobdiff;f=drivers/gpu/drm/pvrsgx/1.17.4948957/eurasia_km/services4/srvkm/env/linux/osfunc.c;h=0da9de7c46969fbd9183bc3ddb3c6aa0df6c4ff2;hp=d86ece9894f28b5aafe1e2242d9656c3781a3c6e;hb=1f267ee25fe451742654ceecdd67bed948a13317;hpb=6425bce0d19e70f17da8eea7ec811d002d5b6db4>
But it is not even called...
Next, I have compared "strace pvrsrvctl --no-module --start" on 6.11 and 6.12 and the main difference seems to be:
6.12:
openat(AT_FDCWD, "/dev/dri/renderD129", O_RDWR|O_LARGEFILE|O_CLOEXEC) = 3
ioctl(3, DRM_IOCTL_VERSION, 0x4d32e8) = 0
ioctl(3, DRM_IOCTL_VERSION, 0x4d32e8) = 0
fstat64(3, {st_mode=S_IFCHR|0660, st_rdev=makedev(0xe2, 0x81), ...}) = 0
fstat64(3, {st_mode=S_IFCHR|0660, st_rdev=makedev(0xe2, 0x81), ...}) = 0
close(3) = 0
6.11:
openat(AT_FDCWD, "/dev/dri/renderD128", O_RDWR|O_LARGEFILE|O_CLOEXEC) = 3
ioctl(3, DRM_IOCTL_VERSION, 0x4a32e8) = 0
ioctl(3, DRM_IOCTL_VERSION, 0x4a32e8) = 0
ioctl(3, DRM_IOCTL_I810_FLUSH or DRM_IOCTL_MGA_SWAP or DRM_IOCTL_R128_CCE_RESET or DRM_IOCTL_RADEON_CP_RESET, 0) = -1 EACCES (Permission denied)
fcntl64(3, F_SETFD, FD_CLOEXEC) = 0
ioctl(3, _IOC(_IOC_WRITE, 0x64, 0x40, 0x1c), 0xbe84d88c) = 0
getpid() = 3352
ioctl(3, _IOC(_IOC_WRITE, 0x64, 0x40, 0x1c), 0xbe84d8d4) = 0
ioctl(3, _IOC(_IOC_WRITE, 0x64, 0x40, 0x1c), 0xbe84d8d4) = 0
ioctl(3, _IOC(_IOC_WRITE, 0x64, 0x40, 0x1c), 0xbe84d81c) = 0
ioctl(3, _IOC(_IOC_WRITE, 0x64, 0x40, 0x1c), 0xbe84d82c) = 0
ioctl(3, _IOC(_IOC_WRITE, 0x64, 0x40, 0x1c), 0xbe84d534) = 0
openat(AT_FDCWD, "/etc/powervr.ini", O_RDONLY) = 4
Which means that the /dev/dri isn't fully recognised as the pvrsgx for firmware download.
So the second
ioctl(3, DRM_IOCTL_VERSION, 0x4d32e8) = 0
appears to fail and the third isn't even tried. This makes some /dev/dri* search
loop continue until no pvrsgx is found.
All this may boil down to something changed in DRM ioctl processing
outside of our code.
In summary we have two different issues with 6.12:
a) your vmalloc issue
b) my (and potentially your) pvrsrvctl init issue
|
On 6.12.0-rc4 branch, build fails with
The text was updated successfully, but these errors were encountered: