Hi Alex, On 2023-12-11 9:17 AM, Alex Deucher wrote: > On Sun, Dec 10, 2023 at 5:10 AM Samuel Holland > <samuel.holland@xxxxxxxxxx> wrote: >> >> Hi Arnd, >> >> On 2023-12-09 2:38 PM, Arnd Bergmann wrote: >>> On Fri, Dec 8, 2023, at 06:04, Samuel Holland wrote: >>>> On 2023-11-29 6:42 PM, Nathan Chancellor wrote: >>>>> On Thu, Nov 23, 2023 at 02:23:01PM +0000, Conor Dooley wrote: >>>>>> On Tue, Nov 21, 2023 at 07:05:15PM -0800, Samuel Holland wrote: >>>>>>> RISC-V uses kernel_fpu_begin()/kernel_fpu_end() like several other >>>>>>> architectures. Enabling hardware FP requires overriding the ISA string >>>>>>> for the relevant compilation units. >>>>>> >>>>>> Ah yes, bringing the joy of frame-larger-than warnings to RISC-V: >>>>>> ../drivers/gpu/drm/amd/amdgpu/../display/dc/dml/dcn32/display_mode_vba_32.c:58:13: warning: stack frame size (2416) exceeds limit (2048) in 'DISPCLKDPPCLKDCFCLKDeepSleepPrefetchParametersWatermarksAndPerformanceCalculation' [-Wframe-larger-than] >>>>> >>>>> :( >>>>> >>>>>> Nathan, have you given up on these being sorted out? >>>>> >>>>> Does your configuration have KASAN (I don't think RISC-V supports >>>>> KCSAN)? It is possible that dml/dcn32 needs something similar to commit >>>>> 6740ec97bcdb ("drm/amd/display: Increase frame warning limit with KASAN >>>>> or KCSAN in dml2")? >>>>> >>>>> I am not really interested in playing whack-a-mole with these warnings >>>>> like I have done in the past for the reasons I outlined here: >>>>> >>>>> https://lore.kernel.org/20231019205117.GA839902@dev-arch.thelio-3990X/ >>>> >>>> I also see one of these with clang 17 even with KASAN disabled: >>>> >>>> drivers/gpu/drm/amd/amdgpu/../display/dc/dml/dcn32/display_mode_vba_32.c:37:6: >>>> warning: stack frame size (2208) exceeds limit (2048) in 'dml32_recalculate' >>>> [-Wframe-larger-than] >>>> void dml32_recalculate(struct display_mode_lib *mode_lib) >>>> >>>> ^ >>>> 1532/2208 (69.38%) spills, 676/2208 (30.62%) variables >>>> >>>> So I'm in favor of just raising the limit for these files for clang, like you >>>> suggested in the linked thread. >>> >>> How about just adding a BUG_ON(IS_ENABLED(CONFIG_RISCV)) >>> in that function? That should also avoid the build failure >>> but give a better indication of where the problem is >>> if someone actually runs into that function and triggers >>> a runtime stack overflow. >> >> Won't that break actual users of the driver, trading an unlikely but >> theoretically possible stack overflow for a guaranteed crash? The intent of this >> series is that I have one of these GPUs plugged in to a RISC-V board, and I want >> to use it. > > Does this patch address the issue? > https://gitlab.freedesktop.org/agd5f/linux/-/commit/72ada8603e36291ad91e4f40f10ef742ef79bc4e No, I get the warning without any of these debugging options enabled. I can reproduce with just defconfig + CONFIG_DRM_AMDGPU=m when built with clang 17. Regards, Samuel