Regression found on arm gcc-11 built with multi_v5_defconfig
Following build warnings / errors reported on linux next 20211025.
metadata:
git_describe: next-20211025
git_repo: https://gitlab.com/Linaro/lkft/mirrors/next/linux-next
git_short_log: 9ae1fbdeabd3 (\"Add linux-next specific files for 20211025\")
target_arch: arm
toolchain: gcc-11
config: multi_v5_defconfig
build error :
--------------
arm-linux-gnueabihf-ld: drivers/gpu/drm/drm_fb_cma_helper.o: in
function `drm_fb_cma_get_gem_obj':
drivers/gpu/drm/drm_fb_cma_helper.c:46: undefined reference to
`drm_gem_fb_get_obj'
arm-linux-gnueabihf-ld: drivers/gpu/drm/drm_fb_cma_helper.c:46:
undefined reference to `drm_gem_fb_get_obj'
arm-linux-gnueabihf-ld: drivers/gpu/drm/drm_fb_cma_helper.c:46:
undefined reference to `drm_gem_fb_get_obj'
arm-linux-gnueabihf-ld: drivers/gpu/drm/drm_fb_cma_helper.o: in
function `drm_fb_cma_sync_non_coherent':
drivers/gpu/drm/drm_fb_cma_helper.c:133: undefined reference to
`drm_atomic_helper_damage_iter_init'
arm-linux-gnueabihf-ld: drivers/gpu/drm/drm_fb_cma_helper.c:135:
undefined reference to `drm_atomic_helper_damage_iter_next'
make[1]: *** [Makefile:1252: vmlinux] Error 1
make[1]: Target '__all' not remade because of errors.
make: *** [Makefile:226: __sub-make] Error 2
Reported-by: Linux Kernel Functional Testing <redacted>
build link:
-----------
https://builds.tuxbuild.com/1zzgFZBGjpQ5R0lawQFW9iJ39Hp/build.log
build config:
-------------
https://builds.tuxbuild.com/1zzgFZBGjpQ5R0lawQFW9iJ39Hp/config
# To install tuxmake on your system globally
# sudo pip3 install -U tuxmake
tuxmake --runtime podman --target-arch arm --toolchain gcc-11
--kconfig multi_v5_defconfig
--
Linaro LKFT
https://lkft.linaro.org
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
On Mon, 25 Oct 2021 at 17:43, Naresh Kamboju [off-list ref] wrote:
Regression found on arm gcc-11 built with multi_v5_defconfig
Following build warnings / errors reported on linux next 20211025.
metadata:
git_describe: next-20211025
git_repo: https://gitlab.com/Linaro/lkft/mirrors/next/linux-next
git_short_log: 9ae1fbdeabd3 (\"Add linux-next specific files for 20211025\")
target_arch: arm
toolchain: gcc-11
config: multi_v5_defconfig
build error :
--------------
arm-linux-gnueabihf-ld: drivers/gpu/drm/drm_fb_cma_helper.o: in
function `drm_fb_cma_get_gem_obj':
drivers/gpu/drm/drm_fb_cma_helper.c:46: undefined reference to
`drm_gem_fb_get_obj'
arm-linux-gnueabihf-ld: drivers/gpu/drm/drm_fb_cma_helper.c:46:
undefined reference to `drm_gem_fb_get_obj'
arm-linux-gnueabihf-ld: drivers/gpu/drm/drm_fb_cma_helper.c:46:
undefined reference to `drm_gem_fb_get_obj'
arm-linux-gnueabihf-ld: drivers/gpu/drm/drm_fb_cma_helper.o: in
function `drm_fb_cma_sync_non_coherent':
drivers/gpu/drm/drm_fb_cma_helper.c:133: undefined reference to
`drm_atomic_helper_damage_iter_init'
arm-linux-gnueabihf-ld: drivers/gpu/drm/drm_fb_cma_helper.c:135:
undefined reference to `drm_atomic_helper_damage_iter_next'
make[1]: *** [Makefile:1252: vmlinux] Error 1
make[1]: Target '__all' not remade because of errors.
make: *** [Makefile:226: __sub-make] Error 2
Reported-by: Linux Kernel Functional Testing <redacted>
The bisection script pointed to the first bad commit,
commit 4b2b5e142ff499a2bef2b8db0272bbda1088a3fe
drm: Move GEM memory managers into modules
From: Thomas Zimmermann <tzimmermann@suse.de> Date: 2021-10-26 17:59:44
Hi
Am 25.10.21 um 16:01 schrieb Naresh Kamboju:
On Mon, 25 Oct 2021 at 17:43, Naresh Kamboju [off-list ref] wrote:
quoted
Regression found on arm gcc-11 built with multi_v5_defconfig
Following build warnings / errors reported on linux next 20211025.
metadata:
git_describe: next-20211025
git_repo: https://gitlab.com/Linaro/lkft/mirrors/next/linux-next
git_short_log: 9ae1fbdeabd3 (\"Add linux-next specific files for 20211025\")
target_arch: arm
toolchain: gcc-11
config: multi_v5_defconfig
build error :
--------------
arm-linux-gnueabihf-ld: drivers/gpu/drm/drm_fb_cma_helper.o: in
function `drm_fb_cma_get_gem_obj':
drivers/gpu/drm/drm_fb_cma_helper.c:46: undefined reference to
`drm_gem_fb_get_obj'
arm-linux-gnueabihf-ld: drivers/gpu/drm/drm_fb_cma_helper.c:46:
undefined reference to `drm_gem_fb_get_obj'
arm-linux-gnueabihf-ld: drivers/gpu/drm/drm_fb_cma_helper.c:46:
undefined reference to `drm_gem_fb_get_obj'
arm-linux-gnueabihf-ld: drivers/gpu/drm/drm_fb_cma_helper.o: in
function `drm_fb_cma_sync_non_coherent':
drivers/gpu/drm/drm_fb_cma_helper.c:133: undefined reference to
`drm_atomic_helper_damage_iter_init'
arm-linux-gnueabihf-ld: drivers/gpu/drm/drm_fb_cma_helper.c:135:
undefined reference to `drm_atomic_helper_damage_iter_next'
make[1]: *** [Makefile:1252: vmlinux] Error 1
make[1]: Target '__all' not remade because of errors.
make: *** [Makefile:226: __sub-make] Error 2
Reported-by: Linux Kernel Functional Testing <redacted>
The bisection script pointed to the first bad commit,
commit 4b2b5e142ff499a2bef2b8db0272bbda1088a3fe
drm: Move GEM memory managers into modules
From: Thomas Zimmermann <tzimmermann@suse.de> Date: 2021-10-25 18:25:15
Hi
Am 25.10.21 um 14:13 schrieb Naresh Kamboju:
Regression found on arm gcc-11 built with multi_v5_defconfig
Following build warnings / errors reported on linux next 20211025.
metadata:
git_describe: next-20211025
git_repo: https://gitlab.com/Linaro/lkft/mirrors/next/linux-next
git_short_log: 9ae1fbdeabd3 (\"Add linux-next specific files for 20211025\")
target_arch: arm
toolchain: gcc-11
config: multi_v5_defconfig
build error :
--------------
arm-linux-gnueabihf-ld: drivers/gpu/drm/drm_fb_cma_helper.o: in
function `drm_fb_cma_get_gem_obj':
drivers/gpu/drm/drm_fb_cma_helper.c:46: undefined reference to
`drm_gem_fb_get_obj'
arm-linux-gnueabihf-ld: drivers/gpu/drm/drm_fb_cma_helper.c:46:
undefined reference to `drm_gem_fb_get_obj'
arm-linux-gnueabihf-ld: drivers/gpu/drm/drm_fb_cma_helper.c:46:
undefined reference to `drm_gem_fb_get_obj'
arm-linux-gnueabihf-ld: drivers/gpu/drm/drm_fb_cma_helper.o: in
function `drm_fb_cma_sync_non_coherent':
drivers/gpu/drm/drm_fb_cma_helper.c:133: undefined reference to
`drm_atomic_helper_damage_iter_init'
arm-linux-gnueabihf-ld: drivers/gpu/drm/drm_fb_cma_helper.c:135:
undefined reference to `drm_atomic_helper_damage_iter_next'
make[1]: *** [Makefile:1252: vmlinux] Error 1
make[1]: Target '__all' not remade because of errors.
make: *** [Makefile:226: __sub-make] Error 2
Reported-by: Linux Kernel Functional Testing <redacted>
That's probably from moving some of the functions into separate modules.
Will be fixed soon.
Best regards
Thomas
From: Thomas Zimmermann <tzimmermann@suse.de> Date: 2021-10-26 18:21:53
Hi
Am 25.10.21 um 14:13 schrieb Naresh Kamboju:
Regression found on arm gcc-11 built with multi_v5_defconfig
Following build warnings / errors reported on linux next 20211025.
metadata:
git_describe: next-20211025
git_repo: https://gitlab.com/Linaro/lkft/mirrors/next/linux-next
git_short_log: 9ae1fbdeabd3 (\"Add linux-next specific files for 20211025\")
target_arch: arm
toolchain: gcc-11
config: multi_v5_defconfig
build error :
--------------
arm-linux-gnueabihf-ld: drivers/gpu/drm/drm_fb_cma_helper.o: in
function `drm_fb_cma_get_gem_obj':
drivers/gpu/drm/drm_fb_cma_helper.c:46: undefined reference to
`drm_gem_fb_get_obj'
arm-linux-gnueabihf-ld: drivers/gpu/drm/drm_fb_cma_helper.c:46:
undefined reference to `drm_gem_fb_get_obj'
arm-linux-gnueabihf-ld: drivers/gpu/drm/drm_fb_cma_helper.c:46:
undefined reference to `drm_gem_fb_get_obj'
arm-linux-gnueabihf-ld: drivers/gpu/drm/drm_fb_cma_helper.o: in
function `drm_fb_cma_sync_non_coherent':
drivers/gpu/drm/drm_fb_cma_helper.c:133: undefined reference to
`drm_atomic_helper_damage_iter_init'
arm-linux-gnueabihf-ld: drivers/gpu/drm/drm_fb_cma_helper.c:135:
undefined reference to `drm_atomic_helper_damage_iter_next'
make[1]: *** [Makefile:1252: vmlinux] Error 1
make[1]: Target '__all' not remade because of errors.
make: *** [Makefile:226: __sub-make] Error 2
Reported-by: Linux Kernel Functional Testing <redacted>
build link:
-----------
https://builds.tuxbuild.com/1zzgFZBGjpQ5R0lawQFW9iJ39Hp/build.log
build config:
-------------
https://builds.tuxbuild.com/1zzgFZBGjpQ5R0lawQFW9iJ39Hp/config
Looking at this config, there is:
CONFIG_DRM=y
# CONFIG_DRM_DP_AUX_CHARDEV is not set
# CONFIG_DRM_DEBUG_MM is not set
# CONFIG_DRM_DEBUG_SELFTEST is not set
CONFIG_DRM_KMS_HELPER=m
# CONFIG_DRM_LOAD_EDID_FIRMWARE is not set
# CONFIG_DRM_DP_CEC is not set
CONFIG_DRM_GEM_CMA_HELPER=y
CONFIG_DRM_KMS_CMA_HELPER=y
GEM_CMA_HELPER depends on KMS_HELPER, but the latter is a module. That's
probably the cause of the problem. Is it intentionally set this way?
Best regards
Thomas
# To install tuxmake on your system globally
# sudo pip3 install -U tuxmake
tuxmake --runtime podman --target-arch arm --toolchain gcc-11
--kconfig multi_v5_defconfig
--
Linaro LKFT
https://lkft.linaro.org
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Felix Imendörffer
From: Randy Dunlap <hidden> Date: 2021-10-27 00:58:56
On 10/26/21 11:21 AM, Thomas Zimmermann wrote:
Hi
Am 25.10.21 um 14:13 schrieb Naresh Kamboju:
quoted
Regression found on arm gcc-11 built with multi_v5_defconfig
Following build warnings / errors reported on linux next 20211025.
metadata:
git_describe: next-20211025
git_repo: https://gitlab.com/Linaro/lkft/mirrors/next/linux-next
git_short_log: 9ae1fbdeabd3 (\"Add linux-next specific files for 20211025\")
target_arch: arm
toolchain: gcc-11
config: multi_v5_defconfig
build error :
--------------
arm-linux-gnueabihf-ld: drivers/gpu/drm/drm_fb_cma_helper.o: in
function `drm_fb_cma_get_gem_obj':
drivers/gpu/drm/drm_fb_cma_helper.c:46: undefined reference to
`drm_gem_fb_get_obj'
arm-linux-gnueabihf-ld: drivers/gpu/drm/drm_fb_cma_helper.c:46:
undefined reference to `drm_gem_fb_get_obj'
arm-linux-gnueabihf-ld: drivers/gpu/drm/drm_fb_cma_helper.c:46:
undefined reference to `drm_gem_fb_get_obj'
arm-linux-gnueabihf-ld: drivers/gpu/drm/drm_fb_cma_helper.o: in
function `drm_fb_cma_sync_non_coherent':
drivers/gpu/drm/drm_fb_cma_helper.c:133: undefined reference to
`drm_atomic_helper_damage_iter_init'
arm-linux-gnueabihf-ld: drivers/gpu/drm/drm_fb_cma_helper.c:135:
undefined reference to `drm_atomic_helper_damage_iter_next'
make[1]: *** [Makefile:1252: vmlinux] Error 1
make[1]: Target '__all' not remade because of errors.
make: *** [Makefile:226: __sub-make] Error 2
Reported-by: Linux Kernel Functional Testing <redacted>
build link:
-----------
https://builds.tuxbuild.com/1zzgFZBGjpQ5R0lawQFW9iJ39Hp/build.log
build config:
-------------
https://builds.tuxbuild.com/1zzgFZBGjpQ5R0lawQFW9iJ39Hp/config
Looking at this config, there is:
CONFIG_DRM=y
# CONFIG_DRM_DP_AUX_CHARDEV is not set
# CONFIG_DRM_DEBUG_MM is not set
# CONFIG_DRM_DEBUG_SELFTEST is not set
CONFIG_DRM_KMS_HELPER=m
# CONFIG_DRM_LOAD_EDID_FIRMWARE is not set
# CONFIG_DRM_DP_CEC is not set
CONFIG_DRM_GEM_CMA_HELPER=y
CONFIG_DRM_KMS_CMA_HELPER=y
GEM_CMA_HELPER depends on KMS_HELPER, but the latter is a module. That's probably the cause of the problem. Is it intentionally set this way?
The only drivers that select DRM_KMS_HELPER are both =m, so that's how
DRM_KMS_HELPER is set also.
Symbol: DRM_KMS_HELPER [=m]
Type : tristate
Defined at drivers/gpu/drm/Kconfig:82
Depends on: HAS_IOMEM [=y] && DRM [=y]
Selected by [m]:
- DRM_ATMEL_HLCDC [=m] && HAS_IOMEM [=y] && DRM [=y] && OF [=y] && COMMON_CLK [=y] && MFD_ATMEL_HLCDC [=y] && ARM [=y]
- DRM_ASPEED_GFX [=m] && HAS_IOMEM [=y] && DRM [=y] && OF [=y] && (COMPILE_TEST [=n] || ARCH_ASPEED [=y]) && MMU [=y]
I did the ARM cross-build and also see the linker error.
I didn't understand why -- and still don't, but here is a little
speculation:
In the past (e.g. 10 years ago), we have to move some .o files
in lib/ from lib-y to obj-y so that they would always be included
in the final object file and not cause their user/caller object
files to suffer from undefined references.
These happened because unused functions(?) in lib-y files are
stripped out of the final object files.
The same thing could be happening here (still just guessing).
Does that help any? I dunno.
Adding Arnd to Cc: to see if he has any ideas...
quoted
# To install tuxmake on your system globally
# sudo pip3 install -U tuxmake
tuxmake --runtime podman --target-arch arm --toolchain gcc-11
--kconfig multi_v5_defconfig
--
Linaro LKFT
https://lkft.linaro.org
On Wed, Oct 27, 2021 at 2:58 AM Randy Dunlap [off-list ref] wrote:
quoted
Looking at this config, there is:
CONFIG_DRM=y
# CONFIG_DRM_DP_AUX_CHARDEV is not set
# CONFIG_DRM_DEBUG_MM is not set
# CONFIG_DRM_DEBUG_SELFTEST is not set
CONFIG_DRM_KMS_HELPER=m
# CONFIG_DRM_LOAD_EDID_FIRMWARE is not set
# CONFIG_DRM_DP_CEC is not set
CONFIG_DRM_GEM_CMA_HELPER=y
CONFIG_DRM_KMS_CMA_HELPER=y
GEM_CMA_HELPER depends on KMS_HELPER, but the latter is a module. That's probably the cause of the problem. Is it intentionally set this way?
The only drivers that select DRM_KMS_HELPER are both =m, so that's how
DRM_KMS_HELPER is set also.
Symbol: DRM_KMS_HELPER [=m]
Type : tristate
Defined at drivers/gpu/drm/Kconfig:82
Depends on: HAS_IOMEM [=y] && DRM [=y]
Selected by [m]:
- DRM_ATMEL_HLCDC [=m] && HAS_IOMEM [=y] && DRM [=y] && OF [=y] && COMMON_CLK [=y] && MFD_ATMEL_HLCDC [=y] && ARM [=y]
- DRM_ASPEED_GFX [=m] && HAS_IOMEM [=y] && DRM [=y] && OF [=y] && (COMPILE_TEST [=n] || ARCH_ASPEED [=y]) && MMU [=y]
I did the ARM cross-build and also see the linker error.
I didn't understand why -- and still don't, but here is a little
speculation:
In the past (e.g. 10 years ago), we have to move some .o files
in lib/ from lib-y to obj-y so that they would always be included
in the final object file and not cause their user/caller object
files to suffer from undefined references.
These happened because unused functions(?) in lib-y files are
stripped out of the final object files.
The same thing could be happening here (still just guessing).
Does that help any? I dunno.
Adding Arnd to Cc: to see if he has any ideas...
From all I can tell, the problem is that DRM_KMS_CMA_HELPER is a 'bool'
symbol, so if it gets selected by a '=m' driver, it turns into '=y', which
then selects DRM_GEM_CMA_HELPER=y, but that one cannot link
against DRM_KMS_HELPER=m code.
This trivial change makes it all build:
but this needs some more testing to make sure it doesn't add
any other regressions.
Interestingly, I never hit the problem in randconfig testing since
there is always some '=y' driver that selects DRM_KMS_HELPER.
Arnd
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
From: Randy Dunlap <hidden> Date: 2021-10-27 06:26:20
On 10/26/21 11:19 PM, Arnd Bergmann wrote:
quoted hunk
On Wed, Oct 27, 2021 at 2:58 AM Randy Dunlap [off-list ref] wrote:
quoted
quoted
Looking at this config, there is:
CONFIG_DRM=y
# CONFIG_DRM_DP_AUX_CHARDEV is not set
# CONFIG_DRM_DEBUG_MM is not set
# CONFIG_DRM_DEBUG_SELFTEST is not set
CONFIG_DRM_KMS_HELPER=m
# CONFIG_DRM_LOAD_EDID_FIRMWARE is not set
# CONFIG_DRM_DP_CEC is not set
CONFIG_DRM_GEM_CMA_HELPER=y
CONFIG_DRM_KMS_CMA_HELPER=y
GEM_CMA_HELPER depends on KMS_HELPER, but the latter is a module. That's probably the cause of the problem. Is it intentionally set this way?
The only drivers that select DRM_KMS_HELPER are both =m, so that's how
DRM_KMS_HELPER is set also.
Symbol: DRM_KMS_HELPER [=m]
Type : tristate
Defined at drivers/gpu/drm/Kconfig:82
Depends on: HAS_IOMEM [=y] && DRM [=y]
Selected by [m]:
- DRM_ATMEL_HLCDC [=m] && HAS_IOMEM [=y] && DRM [=y] && OF [=y] && COMMON_CLK [=y] && MFD_ATMEL_HLCDC [=y] && ARM [=y]
- DRM_ASPEED_GFX [=m] && HAS_IOMEM [=y] && DRM [=y] && OF [=y] && (COMPILE_TEST [=n] || ARCH_ASPEED [=y]) && MMU [=y]
I did the ARM cross-build and also see the linker error.
I didn't understand why -- and still don't, but here is a little
speculation:
In the past (e.g. 10 years ago), we have to move some .o files
in lib/ from lib-y to obj-y so that they would always be included
in the final object file and not cause their user/caller object
files to suffer from undefined references.
These happened because unused functions(?) in lib-y files are
stripped out of the final object files.
The same thing could be happening here (still just guessing).
Does that help any? I dunno.
Adding Arnd to Cc: to see if he has any ideas...
From all I can tell, the problem is that DRM_KMS_CMA_HELPER is a 'bool'
symbol, so if it gets selected by a '=m' driver, it turns into '=y', which
then selects DRM_GEM_CMA_HELPER=y, but that one cannot link
against DRM_KMS_HELPER=m code.
This trivial change makes it all build:
but this needs some more testing to make sure it doesn't add
any other regressions.
Interestingly, I never hit the problem in randconfig testing since
there is always some '=y' driver that selects DRM_KMS_HELPER.
Arnd
Hi Arnd,
Thomas had posted a patch that also fixes the problem.
Somehow I missed seeing that the first time around.
Thanks.
--
~Randy
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
- bool
+ tristate
depends on DRM
select DRM_GEM_CMA_HELPER
help
but this needs some more testing to make sure it doesn't add
any other regressions.
Interestingly, I never hit the problem in randconfig testing since
there is always some '=y' driver that selects DRM_KMS_HELPER.
Thomas had posted a patch that also fixes the problem.
Somehow I missed seeing that the first time around.
Ah right, I missed that as well. That patch seems reasonable
to me, but I think we may want both of them in this case, as
it does not address DRM_GEM_CMA_HELPER being set to =y
when it is only used from modules.
Arnd
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
- bool
+ tristate
depends on DRM
select DRM_GEM_CMA_HELPER
help
but this needs some more testing to make sure it doesn't add
any other regressions.
Interestingly, I never hit the problem in randconfig testing since
there is always some '=y' driver that selects DRM_KMS_HELPER.
Thomas had posted a patch that also fixes the problem.
Somehow I missed seeing that the first time around.
Ah right, I missed that as well. That patch seems reasonable
to me, but I think we may want both of them in this case, as
it does not address DRM_GEM_CMA_HELPER being set to =y
when it is only used from modules.
Yes, the bool state was indeed the problem. The patch I posted resolves
the issue for now. For later, I have a patchset that improves CMA helper
usage a bit and resolves the Kconfig problem.
Best regards
Thomas
Arnd
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Felix Imendörffer