Re: [git pull] drm for 6.8
On Wed, Jan 24, 2024 at 10:23 AM Mario Limonciello wrote: > The test patch [1] posted to [2] works for me. I expect that Matthew > will post it to dri-devel and this can catch RC2 or RC3. > [1] > https://gitlab.freedesktop.org/drm/amd/uploads/ca8dfaa22d6f5d247c28acf6cf3eafd2/0001-Drain-all-entities-in-DRM-run-jon-worker.patch > [2] https://gitlab.freedesktop.org/drm/amd/-/issues/3124 I can also confirm the attached patch has resolved my woes; thank you peeps for the quick turn around time. Yours sincerely, Donald
Re: [git pull] drm for 6.8
On 1/24/2024 11:52, Mario Limonciello wrote: On 1/24/2024 11:51, Thorsten Leemhuis wrote: Linus, if you have a minute, I'd really like to know... On 24.01.24 17:41, Mario Limonciello wrote: On 1/24/2024 10:24, Vlastimil Babka wrote: On 1/24/24 16:31, Donald Carr wrote: On Wed, Jan 24, 2024 at 7:06 AM Vlastimil Babka wrote: When testing the rc1 on my openSUSE Tumbleweed desktop, I've started experiencing "frozen desktop" (KDE/Wayland) issues. The symptoms are that everything freezes including mouse cursor. After a while it either resolves, or e.g. firefox crashes (if it was actively used when it froze) or it's frozen for too long and I reboot with alt-sysrq-b. When it's frozen I can still ssh to the machine, and there's nothing happening in dmesg. The machine is based on Amd Ryzen 7 2700 and Radeon RX7600. [...] I am experiencing the exact same symptoms; Big thanks to Thorsten who suggested I look at the following: https://lore.kernel.org/all/20240123021155.2775-1-mario.limoncie...@amd.com/ https://lore.kernel.org/all/CABXGCsM2VLs489CH-vF-1539-s3in37=bwuowtoeee+q26z...@mail.gmail.com/ Instead of further bisection I've applied Mario's revert from the first link on top of 6.8-rc1 and the issue seems gone for me now. Thanks for confirming. I don't think we should jump right to the revert right now. I posted it in case that is the direction we need to go (simple git revert didn't work due to contextual changes). Let's give the folks who work on GPU scheduler some time to understand the failure and see if they can fix it. ...how you think about this and other situations like this. Given that we have * two affected people in this thread * one earlier thread about it * the machine that made Mario write the patch * and I have someone in #fedora-kernel that likely is affected as well it seems that this is not some corner case very few people run into. Hence I tend to say that this should be dealt with rather sooner than later. Maybe before rc2? Or is this asking too much? The thing from my point of view is, that each such problem might discourage testers from testing again or lead to thoughts like "I only start testing after -rc4". Not to mention that other people will try to bisect the problem like Vlastimil did, which will cost them quite some time and effort -- only to find out that we known about the problem already and did not quickly fix it. That is discouraging for them as well and thus bad for field testing I'd assume. Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat) -- Everything you wanna know about Linux kernel regression tracking: https://linux-regtracking.leemhuis.info/about/#tldr If I did something stupid, please tell me, as explained on that page. A test patch was just posted. I haven't gotten a chance to try it yet. I will this afternoon. The test patch [1] posted to [2] works for me. I expect that Matthew will post it to dri-devel and this can catch RC2 or RC3. [1] https://gitlab.freedesktop.org/drm/amd/uploads/ca8dfaa22d6f5d247c28acf6cf3eafd2/0001-Drain-all-entities-in-DRM-run-jon-worker.patch [2] https://gitlab.freedesktop.org/drm/amd/-/issues/3124
Re: [git pull] drm for 6.8
On Wed, Jan 24, 2024 at 7:31 AM Donald Carr wrote: > I am experiencing the exact same symptoms; sddm (on weston) starts > perfectly, launching a KDE wayland session freezes at various points > (leading to plenty of premature celebration), but normally on the > handoff from sddm to kde (replete with terminal cursor on screen) > > Working perfectly as of the end of 6.7 final release, broken as of 6.8 rc1. > Sometimes sddm can be successfully restarted via ssh, other times > restarting sddm is slow and fails to complete. This is against the Renoir GPU on the 7950x, but also reproduces consistently on my 7900 xtx. Yours sincerely, Donald -- --- °v° Donald Carr /(_)\ Chaos Reins ^ ^ http://chaos-reins.com/
Re: [git pull] drm for 6.8
On Wed, Jan 24, 2024 at 7:06 AM Vlastimil Babka wrote: > When testing the rc1 on my openSUSE Tumbleweed desktop, I've started > experiencing "frozen desktop" (KDE/Wayland) issues. The symptoms are that > everything freezes including mouse cursor. After a while it either resolves, > or e.g. firefox crashes (if it was actively used when it froze) or it's > frozen for too long and I reboot with alt-sysrq-b. When it's frozen I can > still ssh to the machine, and there's nothing happening in dmesg. > The machine is based on Amd Ryzen 7 2700 and Radeon RX7600. > > I've bisected the merge commits so far and now will try to dig into this > one. I've noticed there was also a drm fixes PR later in the merge window but > since it was also merged into rc1 and thus didn't prevent the issue for me, > I guess it's not relevant here? > > Because the reproduction wasn't very deterministic I considered a commit bad > even if it didn't lead to completely frozen desktop and a forced reboot. > Even the multi-second hangs that resolved were a regression compared to 6.7 > anyway. > > If there are known issues and perhaps candidate fixes already, please do tell. I am experiencing the exact same symptoms; sddm (on weston) starts perfectly, launching a KDE wayland session freezes at various points (leading to plenty of premature celebration), but normally on the handoff from sddm to kde (replete with terminal cursor on screen) Working perfectly as of the end of 6.7 final release, broken as of 6.8 rc1. Sometimes sddm can be successfully restarted via ssh, other times restarting sddm is slow and fails to complete. Yours sincerely, Donald
Re: [git pull] drm for 6.8
On 1/24/2024 11:51, Thorsten Leemhuis wrote: Linus, if you have a minute, I'd really like to know... On 24.01.24 17:41, Mario Limonciello wrote: On 1/24/2024 10:24, Vlastimil Babka wrote: On 1/24/24 16:31, Donald Carr wrote: On Wed, Jan 24, 2024 at 7:06 AM Vlastimil Babka wrote: When testing the rc1 on my openSUSE Tumbleweed desktop, I've started experiencing "frozen desktop" (KDE/Wayland) issues. The symptoms are that everything freezes including mouse cursor. After a while it either resolves, or e.g. firefox crashes (if it was actively used when it froze) or it's frozen for too long and I reboot with alt-sysrq-b. When it's frozen I can still ssh to the machine, and there's nothing happening in dmesg. The machine is based on Amd Ryzen 7 2700 and Radeon RX7600. [...] I am experiencing the exact same symptoms; Big thanks to Thorsten who suggested I look at the following: https://lore.kernel.org/all/20240123021155.2775-1-mario.limoncie...@amd.com/ https://lore.kernel.org/all/CABXGCsM2VLs489CH-vF-1539-s3in37=bwuowtoeee+q26z...@mail.gmail.com/ Instead of further bisection I've applied Mario's revert from the first link on top of 6.8-rc1 and the issue seems gone for me now. Thanks for confirming. I don't think we should jump right to the revert right now. I posted it in case that is the direction we need to go (simple git revert didn't work due to contextual changes). Let's give the folks who work on GPU scheduler some time to understand the failure and see if they can fix it. ...how you think about this and other situations like this. Given that we have * two affected people in this thread * one earlier thread about it * the machine that made Mario write the patch * and I have someone in #fedora-kernel that likely is affected as well it seems that this is not some corner case very few people run into. Hence I tend to say that this should be dealt with rather sooner than later. Maybe before rc2? Or is this asking too much? The thing from my point of view is, that each such problem might discourage testers from testing again or lead to thoughts like "I only start testing after -rc4". Not to mention that other people will try to bisect the problem like Vlastimil did, which will cost them quite some time and effort -- only to find out that we known about the problem already and did not quickly fix it. That is discouraging for them as well and thus bad for field testing I'd assume. Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat) -- Everything you wanna know about Linux kernel regression tracking: https://linux-regtracking.leemhuis.info/about/#tldr If I did something stupid, please tell me, as explained on that page. A test patch was just posted. I haven't gotten a chance to try it yet. I will this afternoon.
Re: [git pull] drm for 6.8
Linus, if you have a minute, I'd really like to know... On 24.01.24 17:41, Mario Limonciello wrote: > On 1/24/2024 10:24, Vlastimil Babka wrote: >> On 1/24/24 16:31, Donald Carr wrote: >>> On Wed, Jan 24, 2024 at 7:06 AM Vlastimil Babka wrote: When testing the rc1 on my openSUSE Tumbleweed desktop, I've started experiencing "frozen desktop" (KDE/Wayland) issues. The symptoms are that everything freezes including mouse cursor. After a while it either resolves, or e.g. firefox crashes (if it was actively used when it froze) or it's frozen for too long and I reboot with alt-sysrq-b. When it's frozen I can still ssh to the machine, and there's nothing happening in dmesg. The machine is based on Amd Ryzen 7 2700 and Radeon RX7600. >>> [...] >>> I am experiencing the exact same symptoms; >> >> Big thanks to Thorsten who suggested I look at the following: >> >> https://lore.kernel.org/all/20240123021155.2775-1-mario.limoncie...@amd.com/ >> https://lore.kernel.org/all/CABXGCsM2VLs489CH-vF-1539-s3in37=bwuowtoeee+q26z...@mail.gmail.com/ >> >> Instead of further bisection I've applied Mario's revert from the >> first link >> on top of 6.8-rc1 and the issue seems gone for me now. > > Thanks for confirming. I don't think we should jump right to the revert > right now. > > I posted it in case that is the direction we need to go > (simple git revert didn't work due to contextual changes). > > Let's give the folks who work on GPU scheduler some time to understand > the failure and see if they can fix it. ...how you think about this and other situations like this. Given that we have * two affected people in this thread * one earlier thread about it * the machine that made Mario write the patch * and I have someone in #fedora-kernel that likely is affected as well it seems that this is not some corner case very few people run into. Hence I tend to say that this should be dealt with rather sooner than later. Maybe before rc2? Or is this asking too much? The thing from my point of view is, that each such problem might discourage testers from testing again or lead to thoughts like "I only start testing after -rc4". Not to mention that other people will try to bisect the problem like Vlastimil did, which will cost them quite some time and effort -- only to find out that we known about the problem already and did not quickly fix it. That is discouraging for them as well and thus bad for field testing I'd assume. Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat) -- Everything you wanna know about Linux kernel regression tracking: https://linux-regtracking.leemhuis.info/about/#tldr If I did something stupid, please tell me, as explained on that page.
Re: [git pull] drm for 6.8
On 1/24/2024 10:24, Vlastimil Babka wrote: On 1/24/24 16:31, Donald Carr wrote: On Wed, Jan 24, 2024 at 7:06 AM Vlastimil Babka wrote: When testing the rc1 on my openSUSE Tumbleweed desktop, I've started experiencing "frozen desktop" (KDE/Wayland) issues. The symptoms are that everything freezes including mouse cursor. After a while it either resolves, or e.g. firefox crashes (if it was actively used when it froze) or it's frozen for too long and I reboot with alt-sysrq-b. When it's frozen I can still ssh to the machine, and there's nothing happening in dmesg. The machine is based on Amd Ryzen 7 2700 and Radeon RX7600. I've bisected the merge commits so far and now will try to dig into this one. I've noticed there was also a drm fixes PR later in the merge window but since it was also merged into rc1 and thus didn't prevent the issue for me, I guess it's not relevant here? Because the reproduction wasn't very deterministic I considered a commit bad even if it didn't lead to completely frozen desktop and a forced reboot. Even the multi-second hangs that resolved were a regression compared to 6.7 anyway. If there are known issues and perhaps candidate fixes already, please do tell. I am experiencing the exact same symptoms; sddm (on weston) starts perfectly, launching a KDE wayland session freezes at various points (leading to plenty of premature celebration), but normally on the handoff from sddm to kde (replete with terminal cursor on screen) Working perfectly as of the end of 6.7 final release, broken as of 6.8 rc1. Sometimes sddm can be successfully restarted via ssh, other times restarting sddm is slow and fails to complete. Big thanks to Thorsten who suggested I look at the following: https://lore.kernel.org/all/20240123021155.2775-1-mario.limoncie...@amd.com/ https://lore.kernel.org/all/CABXGCsM2VLs489CH-vF-1539-s3in37=bwuowtoeee+q26z...@mail.gmail.com/ Instead of further bisection I've applied Mario's revert from the first link on top of 6.8-rc1 and the issue seems gone for me now. Thanks for confirming. I don't think we should jump right to the revert right now. I posted it in case that is the direction we need to go (simple git revert didn't work due to contextual changes). Let's give the folks who work on GPU scheduler some time to understand the failure and see if they can fix it. Vlastimil Yours sincerely, Donald
Re: [git pull] drm for 6.8
On 1/24/24 16:31, Donald Carr wrote: > On Wed, Jan 24, 2024 at 7:06 AM Vlastimil Babka wrote: >> When testing the rc1 on my openSUSE Tumbleweed desktop, I've started >> experiencing "frozen desktop" (KDE/Wayland) issues. The symptoms are that >> everything freezes including mouse cursor. After a while it either resolves, >> or e.g. firefox crashes (if it was actively used when it froze) or it's >> frozen for too long and I reboot with alt-sysrq-b. When it's frozen I can >> still ssh to the machine, and there's nothing happening in dmesg. >> The machine is based on Amd Ryzen 7 2700 and Radeon RX7600. >> >> I've bisected the merge commits so far and now will try to dig into this >> one. I've noticed there was also a drm fixes PR later in the merge window but >> since it was also merged into rc1 and thus didn't prevent the issue for me, >> I guess it's not relevant here? >> >> Because the reproduction wasn't very deterministic I considered a commit bad >> even if it didn't lead to completely frozen desktop and a forced reboot. >> Even the multi-second hangs that resolved were a regression compared to 6.7 >> anyway. >> >> If there are known issues and perhaps candidate fixes already, please do >> tell. > > I am experiencing the exact same symptoms; sddm (on weston) starts > perfectly, launching a KDE wayland session freezes at various points > (leading to plenty of premature celebration), but normally on the > handoff from sddm to kde (replete with terminal cursor on screen) > > Working perfectly as of the end of 6.7 final release, broken as of 6.8 rc1. > Sometimes sddm can be successfully restarted via ssh, other times > restarting sddm is slow and fails to complete. Big thanks to Thorsten who suggested I look at the following: https://lore.kernel.org/all/20240123021155.2775-1-mario.limoncie...@amd.com/ https://lore.kernel.org/all/CABXGCsM2VLs489CH-vF-1539-s3in37=bwuowtoeee+q26z...@mail.gmail.com/ Instead of further bisection I've applied Mario's revert from the first link on top of 6.8-rc1 and the issue seems gone for me now. Vlastimil > Yours sincerely, > Donald
Re: [git pull] drm for 6.8
On 1/10/24 20:49, Dave Airlie wrote: > Hi Linus, > > This is the main drm pull request for 6.8. When testing the rc1 on my openSUSE Tumbleweed desktop, I've started experiencing "frozen desktop" (KDE/Wayland) issues. The symptoms are that everything freezes including mouse cursor. After a while it either resolves, or e.g. firefox crashes (if it was actively used when it froze) or it's frozen for too long and I reboot with alt-sysrq-b. When it's frozen I can still ssh to the machine, and there's nothing happening in dmesg. The machine is based on Amd Ryzen 7 2700 and Radeon RX7600. I've bisected the merge commits so far and now will try to dig into this one. I've noticed there was also a drm fixes PR later in the merge window but since it was also merged into rc1 and thus didn't prevent the issue for me, I guess it's not relevant here? Because the reproduction wasn't very deterministic I considered a commit bad even if it didn't lead to completely frozen desktop and a forced reboot. Even the multi-second hangs that resolved were a regression compared to 6.7 anyway. If there are known issues and perhaps candidate fixes already, please do tell. Thanks, Vlastimil git bisect start '--first-parent' # status: waiting for both good and bad commits # bad: [6613476e225e090cc9aad49be7fa504e290dd33d] Linux 6.8-rc1 git bisect bad 6613476e225e090cc9aad49be7fa504e290dd33d # status: waiting for good commit(s), bad commit known # good: [0dd3ee31125508cd67f7e7172247f05b7fd1753a] Linux 6.7 git bisect good 0dd3ee31125508cd67f7e7172247f05b7fd1753a # bad: [b4442cadca2f97239c8b80f64af7937897b867b1] Merge tag 'x86_tdx_for_6.8' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip git bisect bad b4442cadca2f97239c8b80f64af7937897b867b1 # bad: [c4c6044d35f06a93115e691e79436839962c203e] Merge tag 'for-linus' of git://git.armlinux.org.uk/~rmk/linux-arm git bisect bad c4c6044d35f06a93115e691e79436839962c203e # bad: [42bff4d0f9b9c8b669c5cef25c5116f41eb45c6b] Merge tag 'pwm/for-6.8-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/thierry.reding/linux-pwm git bisect bad 42bff4d0f9b9c8b669c5cef25c5116f41eb45c6b # good: [32720aca900b226653c843bb4e06b8125312f214] Merge tag 'fsnotify_for_v6.8-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/jack/linux-fs git bisect good 32720aca900b226653c843bb4e06b8125312f214 # good: [5bad490858c3ebdbb47e622e8f9049f828d2abba] Merge tag 'soc-defconfig-6.8' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc git bisect good 5bad490858c3ebdbb47e622e8f9049f828d2abba # good: [70d201a40823acba23899342d62bc2644051ad2e] Merge tag 'f2fs-for-6.8-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/jaegeuk/f2fs git bisect good 70d201a40823acba23899342d62bc2644051ad2e # bad: [141d9c6e003b806d8faeddeec7053ee2691ea61a] Merge tag 'firewire-updates-6.8' of git://git.kernel.org/pub/scm/linux/kernel/git/ieee1394/linux1394 git bisect bad 141d9c6e003b806d8faeddeec7053ee2691ea61a # bad: [61f4c3e6711477b8a347ca5fe89e5e6613e0a147] Merge tag 'linux-watchdog-6.8-rc1' of git://www.linux-watchdog.org/linux-watchdog git bisect bad 61f4c3e6711477b8a347ca5fe89e5e6613e0a147 # bad: [7912a6391f3ee7eb9f9a69227a209d502679bc0c] Merge tag 'sound-6.8-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound git bisect bad 7912a6391f3ee7eb9f9a69227a209d502679bc0c # bad: [cf65598d5909acf5e7b7dc9e21786e386356bc81] Merge tag 'drm-next-2024-01-10' of git://anongit.freedesktop.org/drm/drm git bisect bad cf65598d5909acf5e7b7dc9e21786e386356bc81 # first bad commit: [cf65598d5909acf5e7b7dc9e21786e386356bc81] Merge tag 'drm-next-2024-01-10' of git://anongit.freedesktop.org/drm/drm
Re: [git pull] drm for 6.8
On Sat, 13 Jan 2024 at 05:33, Linus Torvalds
wrote:
>
> On Wed, 10 Jan 2024 at 11:49, Dave Airlie wrote:
> >
> > Let me know if there are any issues,
>
> Your testing is seriously lacking.
>
> This doesn't even build. The reason seems to be that commit
> b49e894c3fd8 ("drm/i915: Replace custom intel runtime_pm tracker with
> ref_tracker library") changed the 'intel_wakeref_t' type from a
> 'depot_stack_handle_t' to 'unsigned long', and as a result did this:
>
> - drm_dbg(>drm, "async_put_wakeref %u\n",
> + drm_dbg(>drm, "async_put_wakeref %lu\n",
> power_domains->async_put_wakeref);
>
> meanwhile, the Xe driver has this:
>
> drivers/gpu/drm/xe/compat-i915-headers/intel_wakeref.h:
> typedef bool intel_wakeref_t;
>
> which has never been valid, but now the build fails with
This was a bad cross of trees, the fix was in a pull request in my
inbox about an hour after I sent the PR, it just wasn't marked urgent
and it passes all my usual test builds.
It turns out there is a Kconfig bug without EXPERT that was masking
this in my builds, hope to get that fix in soon.
>
> drivers/gpu/drm/i915/display/intel_display_power.c: In function
> ‘print_async_put_domains_state’:
> drivers/gpu/drm/i915/display/intel_display_power.c:408:29: error:
> format ‘%lu’ expects argument of type ‘long unsigned int’, but
> argument 5 has type ‘int’ [-Werror=format=]
>
> because the drm header files have this disgusting thing where a
> *header* file includes a *C* file:
>
> In file included from ./include/drm/drm_mm.h:51,
> from drivers/gpu/drm/xe/xe_bo_types.h:11,
> from drivers/gpu/drm/xe/xe_bo.h:11,
> from
> ./drivers/gpu/drm/xe/compat-i915-headers/gem/i915_gem_object.h:11,
> from ./drivers/gpu/drm/xe/compat-i915-headers/i915_drv.h:15,
> from drivers/gpu/drm/i915/display/intel_display_power.c:8:
>
> nasty.
>
> I made it build by fixing that broken Xe compat header file, but this
> is definitely *NOT* how things should have worked. How did this ever
> get to me without any kind of build testing?
>
> And why the %^!@$% does a header file include a C file? That's wrong
> regardless of this bug.
Huh? display_power.c includes i915_drv.h includes i915_gem_object.h
include xe_bo.h include xe_bo_types.h include drm_mm.h?
I'm not seeing the c in h, you reading that backtrace correctly?
It was built test in a few scenarios by different people and in CI,
but it does appear the Kconfig screwup was masking people from seeing
the actual bug. We had a report a few days ago and a fix was posted,
just not marked as urgent and since I never saw the build fails here I
didn't escalate it.
Dave.
Re: [git pull] drm for 6.8
The pull request you sent on Thu, 11 Jan 2024 05:49:21 +1000: > git://anongit.freedesktop.org/drm/drm tags/drm-next-2024-01-10 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/cf65598d5909acf5e7b7dc9e21786e386356bc81 Thank you! -- Deet-doot-dot, I am a bot. https://korg.docs.kernel.org/prtracker.html
Re: [git pull] drm for 6.8
On Wed, 10 Jan 2024 at 11:49, Dave Airlie wrote:
>
> Let me know if there are any issues,
Your testing is seriously lacking.
This doesn't even build. The reason seems to be that commit
b49e894c3fd8 ("drm/i915: Replace custom intel runtime_pm tracker with
ref_tracker library") changed the 'intel_wakeref_t' type from a
'depot_stack_handle_t' to 'unsigned long', and as a result did this:
- drm_dbg(>drm, "async_put_wakeref %u\n",
+ drm_dbg(>drm, "async_put_wakeref %lu\n",
power_domains->async_put_wakeref);
meanwhile, the Xe driver has this:
drivers/gpu/drm/xe/compat-i915-headers/intel_wakeref.h:
typedef bool intel_wakeref_t;
which has never been valid, but now the build fails with
drivers/gpu/drm/i915/display/intel_display_power.c: In function
‘print_async_put_domains_state’:
drivers/gpu/drm/i915/display/intel_display_power.c:408:29: error:
format ‘%lu’ expects argument of type ‘long unsigned int’, but
argument 5 has type ‘int’ [-Werror=format=]
because the drm header files have this disgusting thing where a
*header* file includes a *C* file:
In file included from ./include/drm/drm_mm.h:51,
from drivers/gpu/drm/xe/xe_bo_types.h:11,
from drivers/gpu/drm/xe/xe_bo.h:11,
from
./drivers/gpu/drm/xe/compat-i915-headers/gem/i915_gem_object.h:11,
from ./drivers/gpu/drm/xe/compat-i915-headers/i915_drv.h:15,
from drivers/gpu/drm/i915/display/intel_display_power.c:8:
nasty.
I made it build by fixing that broken Xe compat header file, but this
is definitely *NOT* how things should have worked. How did this ever
get to me without any kind of build testing?
And why the %^!@$% does a header file include a C file? That's wrong
regardless of this bug.
Linus
