• Re: Regression in Radeon driver in latest Debian Stable kernel

    From Michael =?utf-8?B?S2rDtnJsaW5n?=@21:1/5 to All on Wed May 15 22:00:01 2024
    On 15 May 2024 20:40 +0100, from piorunz@gmx.com (piorunz):
    I have reported a regression in latest Linux kernel in Debian Stable:

    segfault at amdgpu_dm_atomic_commit_tail https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1071080

    You made this bug report less than 48 hours ago. While I can certainly understand that you would like to see it fixed, that's not an
    inordinate amount of time to wait.

    What probably _would_ be helpful is to see whether you can recreate
    the same scenario with the vanilla kernel.org kernels of the same
    versions; confirming that the issue exists with the vanilla 6.1.90
    kernel _and_ that the issue goes away when booting the vanilla kernel
    of whatever exact version your earlier package is (I'm guessing
    6.1.85), both when built with the same configuration options as the
    kernels shipped by Debian. That would confirm whether what you are
    seeing is something somehow introduced by Debian, or an upstream bug.

    --
    Michael Kjörling 🔗 https://michael.kjorling.se “Remember when, on the Internet, nobody cared that you were a dog?”

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From piorunz@21:1/5 to All on Wed May 15 21:50:01 2024
    Hello,

    I have reported a regression in latest Linux kernel in Debian Stable:

    segfault at amdgpu_dm_atomic_commit_tail https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1071080

    It throws a lot of errors related to AMD GPU every day. I also
    experienced full desktop hang, where I had to restart my computer: https://bugs.kde.org/show_bug.cgi?id=486970

    This happens on 6.1.0-21-amd64. Booting previous version 6.1.0-20-amd64
    solves all problems.

    Can anyone help me with getting attention from some developers? KDE dev
    said this is downstream, not KDE problem. Debian bug reported, but no
    reply from anyone yet.

    --
    With kindest regards, Piotr.

    ⢀⣴⠾⠻⢶⣦⠀
    ⣾⠁⢠⠒⠀⣿⡁ Debian - The universal operating system ⢿⡄⠘⠷⠚⠋⠀ https://www.debian.org/
    ⠈⠳⣄⠀⠀⠀⠀

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From piorunz@21:1/5 to All on Thu May 16 12:40:01 2024
    On 15/05/2024 20:55, Michael Kjörling wrote:

    You made this bug report less than 48 hours ago. While I can certainly understand that you would like to see it fixed, that's not an
    inordinate amount of time to wait.

    What probably _would_ be helpful is to see whether you can recreate
    the same scenario with the vanilla kernel.org kernels of the same
    versions; confirming that the issue exists with the vanilla 6.1.90
    kernel _and_ that the issue goes away when booting the vanilla kernel
    of whatever exact version your earlier package is (I'm guessing
    6.1.85), both when built with the same configuration options as the
    kernels shipped by Debian. That would confirm whether what you are
    seeing is something somehow introduced by Debian, or an upstream bug.

    Thank you for your reply, I appreciate it.
    I found out that this error happened on previous version of the kernel
    as well, just found it in the logs. So, it's not an immediate regression
    in the latest version of the kernel in Debian. Maybe it's deeper than
    that. That lowers the possibility that this is the most recent update
    which brought this problem. I sent latest update to the bug report, I
    will wait for any reply from developer but no rush, of course.

    As much as I would like to try vanilla kernel, I don't want to break my
    system. I use Debian Stable, don't know if things would just work with
    vanilla kernel.

    --
    With kindest regards, Piotr.

    ⢀⣴⠾⠻⢶⣦⠀
    ⣾⠁⢠⠒⠀⣿⡁ Debian - The universal operating system ⢿⡄⠘⠷⠚⠋⠀ https://www.debian.org/
    ⠈⠳⣄⠀⠀⠀⠀

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From piorunz@21:1/5 to Max Nikulin on Thu May 16 18:00:02 2024
    On 16/05/2024 12:35, Max Nikulin wrote:
    On 16/05/2024 17:35, piorunz wrote:

    As much as I would like to try vanilla kernel, I don't want to break my
    system. I use Debian Stable, don't know if things would just work with
    vanilla kernel.

    You may try bookworm-backports kernel 6.6.13+bpo-amd64

    You may check https://bugzilla.kernel.org/ for reports similar to your one.

    Oh that's great solution, I will try that without risk of breaking my
    system, as I always can select previous kernel in the menu, thank you.

    https://bugzilla.kernel.org/ will they be interested in Debian specific
    error? I don't use vanilla kernel so maybe it's Debian only problem.

    --
    With kindest regards, Piotr.

    ⢀⣴⠾⠻⢶⣦⠀
    ⣾⠁⢠⠒⠀⣿⡁ Debian - The universal operating system ⢿⡄⠘⠷⠚⠋⠀ https://www.debian.org/
    ⠈⠳⣄⠀⠀⠀⠀

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Michael =?utf-8?B?S2rDtnJsaW5n?=@21:1/5 to All on Thu May 16 22:50:02 2024
    On 17 May 2024 00:12 +0700, from manikulin@gmail.com (Max Nikulin):
    Be realistic, to get the bug fixed, there should be affected persons motivated enough to try vanilla kernel or even to build custom kernels with provided patches. Developers time is limited and expensive resource. It may be directed to fixing other bugs. If you can compare Debian and upstream kernels you may get the issue fixed quicker. Direct communication with
    driver developers may be more effective.

    Indeed; that's why I suggested trying the vanilla kernels of the same
    versions, compiled with the same options, and seeing if the behavior
    can be reproduced with those. If the same behavior as seen with the Debian-packaged kernels can be reproduced with the vanilla kernel,
    that would very strongly suggest that whatever this is is either (a)
    an upstream issue in the kernel, or (b) not a kernel issue at all.
    There's a reason why many upstream maintainers, when faced with a bug
    report for a downstream potentially modified version of their code,
    will start by saying "try our version".

    Adding to the "be realistic", if the issue was an obvious one, it
    likely never would have made it into a released kernel at all. So
    whatever this is about is unlikely to be obvious. Thus some detective
    work is most likely going to be needed; and unless a kernel developer
    can reproduce the problem on their own hardware, they'll probably have
    to ask you to try things out and report back; whether with debug logs,
    more detailed system information, or as Max mentioned building a
    kernel with a proposed fix to see what effect, if any, a proposed fix
    has on the problem.

    Also, especially if you start installing backports kernels as well,
    you may want to add a version pin to the kernel you currently have
    installed and which does not exhibit the problem to the same degree,
    to reduce the risk that it gets purged for being among the older ones
    you have installed.

    --
    Michael Kjörling 🔗 https://michael.kjorling.se “Remember when, on the Internet, nobody cared that you were a dog?”

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)