03:24 olivial: I'm trying to track down some panics triggered by failed ring tests, and am kinda confused by the drm_gpu_scheduler::ready design
03:26 olivial: drm_sched_job_arm assumes that at least one of the scheds in job->entity->sched_list is ready, and will deref a null pointer otherwise
03:27 olivial: is this a bug in drm_sched_job_arm, or is the caller responsible for guaranteeing that there will be a ready scheduler?
06:02 olivial: oh, https://lore.kernel.org/all/20250107140240.325899-1-philipp.reisner@linbit.com/ is this exact problem
07:19 kode54: hey
07:20 kode54: I want to tell that person what I know now
07:20 kode54: maybe you too
07:20 kode54: there's a recurring issue I've been having, affecting both 6000 but mostly 7000 and 9000 series cards
07:21 kode54: my issue is worked around either by reverting a specific commit, or disabling GFXOFF states if it's not possible to patch the kernel
07:21 kode54: a simple enough test is to boot with amdgpu.ppfeaturemask=0xfff73fff added to the commandline and trying to replicate the bugs
07:22 kode54: there may yet be even more issues with gfxoff than I've experienced
07:23 kode54: holy crap, someone found a bug with some VRR related code caused by a specific commit
07:23 kode54: and someone is suggesting disabling VRR altogether as a more permanent fix????