Hello, On Fri, Mar 28, 2025 at 10:20:56AM +0100, @ wrote: > On 28/03/2025 01:02, Ben Hutchings wrote: > > In bug discussions, please always reply-all, don't just reply to the > > sender. > > > > I have another question below. > > > > On Thu, 2025-03-27 at 19:58 +0100, @ wrote: > > > On 27/03/2025 01:42, Ben Hutchings wrote: > > > > Control: tag -1 moreinfo > > > > > > > > On Mon, 24 Mar 2025 21:44:25 +0100 Joe<shanny...@yahoo.fr> wrote: > > > > [...] > > > > > I can't provide kernel log with the reportbug program due to how > > > > sudoer is set, I usually use pkexec or su . I there another way to > > > > transmit the logs if that's useful ? > > > > > Let me know if you need more informations. > > > > Please send the kernel log as an attachment. > > > > > > > > Also send the kernel log from the working kernel version. > > > > > > > Here's the dmesg outputs for 6.12.19 & 6.12.17 . > > > > > > I have no idea what's wrong, good luck and thank you. > > There's an obvious difference in the logs, which is that we have a lot > > of messages from the amdgpu driver on 6.12.17 and *none* on 6.12.19. > > That implies it isn't even being loaded, and the device information in > > your initial bug report agrees with that. (The GPU is at PCI address > > 0000:2d:00.0 and no driver is listed as bound to it.) > > > > I can't see any changes between these versions that would explain this. > > But this does look similar to<https://bugs.debian.org/1094767>. (We > > still don't know what actually triggered that but it wasn't a kernel > > change.) > > > > Please send the output of the command: > > > > grep -r amdgpu /etc/modprobe.* > > > $ grep -r amdgpu /etc/modprobe.* > > /etc/modprobe.d/blacklist-amdgpu.conf:blacklist amdgpu
You're not the first having such a blacklist entry. Do you have an idea
what created it? We tried to pinpoint how this file was created in
previous bug reports (e.g. #1094767), but didn't manage to identify the
component. Do you have any non-Debian packages on your system that might
be responsible?
> Commenting that blacklist out fixed the issue.
>
> Really odd it affected the new kernel but not the older one.
Probably it's relevant that the initramfs for the old kernel was created
before the blacklist entry. So I guess you can break the old kernel by
adding the blacklist again and then regenerating the initramfs, probably
using:
update-initramfs -u -k $oldversion
Best regards
Uwe
signature.asc
Description: PGP signature
