Bugzilla – Bug 1213614
Mesa-dri/aarch64: Segmentation fault in freedreno [msi-dri.so] while running on Lenovo x13s laptop
Last modified: 2023-09-14 05:24:02 UTC
Created attachment 868409 [details] Lenovox13s-logs The Mesa-dri-23.1.3-353.1 package from Factory cannot run on Lenovo x13s [An aarch64-laptop. CPU: Qualcomm 8cx Gen3, GPU: Qualcomm Adreno 690], a segmentation fault always occurs when gdm tries to run Xorg.bin. The same symptom can be seen as well when trying to run Xwayland. The Mesa-dri was installed on my experimental JeOS built on OBS since x13s is not supported by openSUSE tumbleweed yet: https://build.opensuse.org/project/show/home:clin:branches:X13S This test kernel is based on upstream v6.4-final + some reviewing patches for x13s in upstream, and a GPU firmware "a690_gmu.bin" required by the Adreno kernel driver [adreno_device.c] is still missing from linux-firmware upstream although it should not crash GNOME initialization since the linaro-customized-debian for x13s can still work without loading GPU firmware blobs successfully. The attached log files include some basic logs [dmesg, journal, installed Mesa package list ] and a supportconfig tgz I collected from the laptop. gdm error log ============= Jul 24 11:11:58 localhost.localdomain /usr/libexec/gdm/gdm-x-session[1119]: MESA: error: get_param:232: get-param failed! -6 (No such device or address) Jul 24 11:11:58 localhost.localdomain /usr/libexec/gdm/gdm-x-session[1119]: MESA: error: get_param:232: get-param failed! -6 (No such device or address) Jul 24 11:11:58 localhost.localdomain /usr/libexec/gdm/gdm-x-session[1119]: MESA: error: get_param:232: get-param failed! -6 (No such device or address) Jul 24 11:11:58 localhost.localdomain /usr/libexec/gdm/gdm-x-session[1119]: MESA: error: get_param:232: get-param failed! -6 (No such device or address) Jul 24 11:11:58 localhost.localdomain /usr/libexec/gdm/gdm-x-session[1119]: MESA: error: fd_pipe_new2:52: allocation failed Jul 24 11:11:58 localhost.localdomain /usr/libexec/gdm/gdm-x-session[1119]: (EE) Jul 24 11:11:58 localhost.localdomain /usr/libexec/gdm/gdm-x-session[1119]: (EE) Backtrace: Jul 24 11:11:58 localhost.localdomain /usr/libexec/gdm/gdm-x-session[1119]: (EE) 0: /usr/bin/Xorg.bin (xorg_backtrace+0x68) [0xaaaac5def608] Jul 24 11:11:58 localhost.localdomain /usr/libexec/gdm/gdm-x-session[1119]: (EE) 1: /usr/bin/Xorg.bin (0xaaaac5c20000+0x1d8954) [0xaaaac5df8954] Jul 24 11:11:58 localhost.localdomain /usr/libexec/gdm/gdm-x-session[1119]: (EE) 2: linux-vdso.so.1 (__kernel_rt_sigreturn+0x0) [0xffffb29ae7a0] Jul 24 11:11:58 localhost.localdomain /usr/libexec/gdm/gdm-x-session[1119]: (EE) 3: /usr/lib64/dri/msm_dri.so (0xffffaf760000+0x94fb7c) [0xffffb00afb7c] Jul 24 11:11:58 localhost.localdomain /usr/libexec/gdm/gdm-x-session[1119]: (EE) 4: /usr/lib64/dri/msm_dri.so (0xffffaf760000+0xab6ae4) [0xffffb0216ae4] Jul 24 11:11:58 localhost.localdomain /usr/libexec/gdm/gdm-x-session[1119]: (EE) 5: /usr/lib64/dri/msm_dri.so (0xffffaf760000+0xecd0c) [0xffffaf84cd0c] Jul 24 11:11:58 localhost.localdomain /usr/libexec/gdm/gdm-x-session[1119]: (EE) 6: /usr/lib64/dri/msm_dri.so (0xffffaf760000+0x66fe08) [0xffffafdcfe08] Jul 24 11:11:58 localhost.localdomain /usr/libexec/gdm/gdm-x-session[1119]: (EE) 7: /usr/lib64/dri/msm_dri.so (0xffffaf760000+0xf4bf0) [0xffffaf854bf0] Jul 24 11:11:58 localhost.localdomain /usr/libexec/gdm/gdm-x-session[1119]: (EE) 8: /usr/lib64/dri/msm_dri.so (0xffffaf760000+0xe3470) [0xffffaf843470] Jul 24 11:11:58 localhost.localdomain /usr/libexec/gdm/gdm-x-session[1119]: (EE) 9: /lib64/libgbm.so.1 (0xffffb12a0000+0xe79c) [0xffffb12ae79c] Jul 24 11:11:58 localhost.localdomain /usr/libexec/gdm/gdm-x-session[1119]: (EE) 10: /lib64/libgbm.so.1 (0xffffb12a0000+0x109dc) [0xffffb12b09dc] Jul 24 11:11:58 localhost.localdomain /usr/libexec/gdm/gdm-x-session[1119]: (EE) 11: /lib64/libgbm.so.1 (0xffffb12a0000+0xe4c0) [0xffffb12ae4c0] Jul 24 11:11:58 localhost.localdomain /usr/libexec/gdm/gdm-x-session[1119]: (EE) 12: /lib64/libgbm.so.1 (gbm_create_device+0x130) [0xffffb12ae624] Jul 24 11:11:58 localhost.localdomain /usr/libexec/gdm/gdm-x-session[1119]: (EE) 13: /usr/lib64/xorg/modules/libglamoregl.so (glamor_egl_init+0x1d4) [0xffffb12e9078] Jul 24 11:11:58 localhost.localdomain /usr/libexec/gdm/gdm-x-session[1119]: (EE) 14: /usr/lib64/xorg/modules/drivers/modesetting_drv.so (0xffffb13a0000+0xfc3c) [0xffffb13afc3c] Jul 24 11:11:58 localhost.localdomain /usr/libexec/gdm/gdm-x-session[1119]: (EE) 15: /usr/bin/Xorg.bin (InitOutput+0x1084) [0xaaaac5ccbaf4] Jul 24 11:11:58 localhost.localdomain /usr/libexec/gdm/gdm-x-session[1119]: (EE) 16: /usr/bin/Xorg.bin (0xaaaac5c20000+0x4f558) [0xaaaac5c6f558] Jul 24 11:11:58 localhost.localdomain /usr/libexec/gdm/gdm-x-session[1119]: (EE) 17: /lib64/libc.so.6 (0xffffb1ed0000+0x2abc8) [0xffffb1efabc8] Jul 24 11:11:58 localhost.localdomain /usr/libexec/gdm/gdm-x-session[1119]: (EE) 18: /lib64/libc.so.6 (__libc_start_main+0x9c) [0xffffb1efaca0] Jul 24 11:11:58 localhost.localdomain /usr/libexec/gdm/gdm-x-session[1119]: (EE) 19: /usr/bin/Xorg.bin (_start+0x30) [0xaaaac5c701f0] Jul 24 11:11:58 localhost.localdomain /usr/libexec/gdm/gdm-x-session[1119]: (EE) Jul 24 11:11:58 localhost.localdomain /usr/libexec/gdm/gdm-x-session[1119]: (EE) Segmentation fault at address 0x10 Jul 24 11:11:58 localhost.localdomain /usr/libexec/gdm/gdm-x-session[1119]: (EE) Jul 24 11:11:58 localhost.localdomain /usr/libexec/gdm/gdm-x-session[1119]: Fatal server error: Jul 24 11:11:58 localhost.localdomain /usr/libexec/gdm/gdm-x-session[1119]: (EE) Caught signal 11 (Segmentation fault). Server aborting Jul 24 11:11:58 localhost.localdomain /usr/libexec/gdm/gdm-x-session[1119]: (EE) Jul 24 11:11:58 localhost.localdomain /usr/libexec/gdm/gdm-x-session[1119]: (EE)
/usr/lib64/dri/msm_dri.so Where is this coming from? rpm -qf /usr/lib64/dri/msm_dri.so
(In reply to Stefan Dirsch from comment #1) > /usr/lib64/dri/msm_dri.so > > Where is this coming from? > > rpm -qf /usr/lib64/dri/msm_dri.so localhost:~ # rpm -qf /usr/lib64/dri/msm_dri.so Mesa-dri-23.1.3-353.1.aarch64 localhost:~ # zypper se -s Mesa-dri Loading repository data... Reading installed packages... S | Name | Type | Version | Arch | Repository ---+------------------+---------+--------------+---------+------------------------ i+ | Mesa-dri | package | 23.1.3-353.1 | aarch64 | openSUSE-Tumbleweed-Oss i+ | Mesa-dri-devel | package | 23.1.3-353.1 | aarch64 | openSUSE-Tumbleweed-Oss | Mesa-dri-nouveau | package | 23.1.3-353.1 | aarch64 | openSUSE-Tumbleweed-Oss | Mesa-dri-vc4 | package | 23.1.3-353.1 | aarch64 | openSUSE-Tumbleweed-Oss
(In reply to Chester Lin from comment #2) > (In reply to Stefan Dirsch from comment #1) > > /usr/lib64/dri/msm_dri.so > > > > Where is this coming from? > > > > rpm -qf /usr/lib64/dri/msm_dri.so > > localhost:~ # rpm -qf /usr/lib64/dri/msm_dri.so > Mesa-dri-23.1.3-353.1.aarch64 > localhost:~ # zypper se -s Mesa-dri > Loading repository data... > Reading installed packages... > > S | Name | Type | Version | Arch | Repository > ---+------------------+---------+--------------+---------+------------------- > ----- > i+ | Mesa-dri | package | 23.1.3-353.1 | aarch64 | > openSUSE-Tumbleweed-Oss > i+ | Mesa-dri-devel | package | 23.1.3-353.1 | aarch64 | > openSUSE-Tumbleweed-Oss > | Mesa-dri-nouveau | package | 23.1.3-353.1 | aarch64 | > openSUSE-Tumbleweed-Oss > | Mesa-dri-vc4 | package | 23.1.3-353.1 | aarch64 | > openSUSE-Tumbleweed-Oss localhost:~ # zypper repos -u Repository priorities are without effect. All enabled repositories share the same priority. # | Alias | Name | Enabled | GPG Check | Refresh | URI --+---------------+----------------------------------------+---------+-----------+---------+----------------------------------------------------------------------- 1 | repo-debug | openSUSE-Tumbleweed-Debug | No | ---- | ---- | http://download.opensuse.org/ports/aarch64/debug/tumbleweed/repo/oss/ 2 | repo-openh264 | Open H.264 Codec (openSUSE Tumbleweed) | Yes | (r ) Yes | Yes | http://codecs.opensuse.org/openh264/openSUSE_Tumbleweed 3 | repo-oss | openSUSE-Tumbleweed-Oss | Yes | (r ) Yes | Yes | http://download.opensuse.org/ports/aarch64/tumbleweed/repo/oss/ 4 | repo-source | openSUSE-Tumbleweed-Source | No | ---- | ---- | http://download.opensuse.org/ports/aarch64/source/tumbleweed/repo/oss/ 5 | repo-update | openSUSE-Tumbleweed-Update | Yes | (r ) Yes | Yes | http://download.opensuse.org/ports/aarch64/update/tumbleweed/
Lenovo aarch64? OMG! Such a thing exists? Ok, this explains such a driver ...
You might be the first persion in the world trying this driver. I suggest to rename this DRI driver in the hope that things fall back to a more generic DRI driver (probably swrast/llvmpipe).
Created attachment 868425 [details] GNOME screenshot (In reply to Stefan Dirsch from comment #5) > You might be the first persion in the world trying this driver. I suggest to > rename this DRI driver in the hope that things fall back to a more generic > DRI driver (probably swrast/llvmpipe). Hi Stefan, I tried to remove the original msm_dri.so and then manually created a "msm_dri.so link file" points to swrast_dri.so but it still didn't work. However, I accidentally found a downstream firmware "a690_gmu.bin" from here: https://github.com/ironrobin/x13s-alarm/tree/trunk/x13s-firmware I copied the firmware blob and then GNOME works now. (See attached screenshot) Besides, I checked the main branch of mesa upstream and found that QCOM Adreno 690 has been supported although the commits are not yet included in any release tag: https://gitlab.freedesktop.org/mesa/mesa/-/commit/210c6c11cc61c8f53c2c5506e97084dc5f9f2270 https://gitlab.freedesktop.org/mesa/mesa/-/commit/64e93ca9a1744a81eb12a2c72de1aa8774c80ae2 Since not sure when the a690_gmu.bin will be upstreamed to linux-firmware, maybe I could try building mesa packages based on the latest mainline in order to ensure that the later release tags should be available for running mesa-dri on X13s?
(In reply to Chester Lin from comment #6) > Created attachment 868425 [details] > GNOME screenshot > > (In reply to Stefan Dirsch from comment #5) > > You might be the first persion in the world trying this driver. I suggest to > > rename this DRI driver in the hope that things fall back to a more generic > > DRI driver (probably swrast/llvmpipe). > > Hi Stefan, > > I tried to remove the original msm_dri.so and then manually created a > "msm_dri.so link file" points to swrast_dri.so but it still didn't work. > > However, I accidentally found a downstream firmware "a690_gmu.bin" from here: > > https://github.com/ironrobin/x13s-alarm/tree/trunk/x13s-firmware The original file source should be from linux-source aarch64-firmware repo: https://github.com/linux-surface/aarch64-firmware/tree/main/firmware/qcom > > I copied the firmware blob and then GNOME works now. (See attached > screenshot) > > Besides, I checked the main branch of mesa upstream and found that QCOM > Adreno 690 has been supported although the commits are not yet included in > any release tag: > > https://gitlab.freedesktop.org/mesa/mesa/-/commit/ > 210c6c11cc61c8f53c2c5506e97084dc5f9f2270 > > https://gitlab.freedesktop.org/mesa/mesa/-/commit/ > 64e93ca9a1744a81eb12a2c72de1aa8774c80ae2 > > Since not sure when the a690_gmu.bin will be upstreamed to linux-firmware, > maybe I could try building mesa packages based on the latest mainline in > order to ensure that the later release tags should be available for running > mesa-dri on X13s?
(In reply to Chester Lin from comment #7) > (In reply to Chester Lin from comment #6) > > Created attachment 868425 [details] > > GNOME screenshot > > > > (In reply to Stefan Dirsch from comment #5) > > > You might be the first persion in the world trying this driver. I suggest to > > > rename this DRI driver in the hope that things fall back to a more generic > > > DRI driver (probably swrast/llvmpipe). > > > > Hi Stefan, > > > > I tried to remove the original msm_dri.so and then manually created a > > "msm_dri.so link file" points to swrast_dri.so but it still didn't work. > > > > However, I accidentally found a downstream firmware "a690_gmu.bin" from here: > > > > https://github.com/ironrobin/x13s-alarm/tree/trunk/x13s-firmware > > The original file source should be from linux-source aarch64-firmware repo: "linux-surface" Sorry for the typo. > > https://github.com/linux-surface/aarch64-firmware/tree/main/firmware/qcom > > > > > I copied the firmware blob and then GNOME works now. (See attached > > screenshot) > > > > Besides, I checked the main branch of mesa upstream and found that QCOM > > Adreno 690 has been supported although the commits are not yet included in > > any release tag: > > > > https://gitlab.freedesktop.org/mesa/mesa/-/commit/ > > 210c6c11cc61c8f53c2c5506e97084dc5f9f2270 > > > > https://gitlab.freedesktop.org/mesa/mesa/-/commit/ > > 64e93ca9a1744a81eb12a2c72de1aa8774c80ae2 > > > > Since not sure when the a690_gmu.bin will be upstreamed to linux-firmware, > > maybe I could try building mesa packages based on the latest mainline in > > order to ensure that the later release tags should be available for running > > mesa-dri on X13s?
I don't know from where we pick up firmware files. Adding Takashi. Not sure about Mesa commits. There might be more, which is needed from git master.
Hm, we can't simply pick up for the standard package, I'm afraid. In the original github repo: https://github.com/linux-surface/aarch64-firmware/tree/main """ Licensing We do not have an explicit re-distribution license for some of the firmware files provided here, in particular the ones specific to the Microsoft Surface Pro X. These rights lie by Microsoft and/or Qualcomm. However, many of these files are signed in a way that make them usable only on the Surface Pro X. The files here are provided exclusively for convenience (especially allowing easy creation of distribution packages) as owners of the Surface Pro X can obtain these themselves via the provided script. """ IIRC, Arm takes action for "Linux on Arm Laptop", and TP X13s is exactly the primary target, so we can ping Arm people about upstreaming the GPU firmware. I suppose a690 stuff is rather the business of Arm. Meanwhile, a hackish downstream package to fetch the file at installation would be doable, too.
(In reply to Takashi Iwai from comment #10) > Hm, we can't simply pick up for the standard package, I'm afraid. I'm afraid so. > In the original github repo: > https://github.com/linux-surface/aarch64-firmware/tree/main > > """ > Licensing > > We do not have an explicit re-distribution license for some of the firmware > files provided here, in particular the ones specific to the Microsoft > Surface Pro X. These rights lie by Microsoft and/or Qualcomm. However, many > of these files are signed in a way that make them usable only on the Surface > Pro X. The files here are provided exclusively for convenience (especially > allowing easy creation of distribution packages) as owners of the Surface > Pro X can obtain these themselves via the provided script. > """ > > IIRC, Arm takes action for "Linux on Arm Laptop", and TP X13s is exactly the > primary target, so we can ping Arm people about upstreaming the GPU firmware. > I suppose a690 stuff is rather the business of Arm. > > Meanwhile, a hackish downstream package to fetch the file at installation > would be doable, too. Since Mesa's upstream master seems to support GPU Adreno 690, I will try running the latest freedreno driver without loading the proprietary firmware.
Created attachment 868479 [details] GNOME screenshot llvmpipe (In reply to Chester Lin from comment #11) > (In reply to Takashi Iwai from comment #10) > > Hm, we can't simply pick up for the standard package, I'm afraid. > > I'm afraid so. > > > In the original github repo: > > https://github.com/linux-surface/aarch64-firmware/tree/main > > > > """ > > Licensing > > > > We do not have an explicit re-distribution license for some of the firmware > > files provided here, in particular the ones specific to the Microsoft > > Surface Pro X. These rights lie by Microsoft and/or Qualcomm. However, many > > of these files are signed in a way that make them usable only on the Surface > > Pro X. The files here are provided exclusively for convenience (especially > > allowing easy creation of distribution packages) as owners of the Surface > > Pro X can obtain these themselves via the provided script. > > """ > > > > IIRC, Arm takes action for "Linux on Arm Laptop", and TP X13s is exactly the > > primary target, so we can ping Arm people about upstreaming the GPU firmware. > > I suppose a690 stuff is rather the business of Arm. > > > > Meanwhile, a hackish downstream package to fetch the file at installation > > would be doable, too. > > Since Mesa's upstream master seems to support GPU Adreno 690, I will try > running the latest freedreno driver without loading the proprietary firmware. I have tried compiling/running the latest mesa [23.3.0-devel 23a2b83639af] and GNOME can work although the renderer seems to be switched to llvmpipe. (See attached picture) Besides, I will reach ARM to see if they could contact Qualcomm for a690 fw upstreaming.
(In reply to Chester Lin from comment #12) > Created attachment 868479 [details] > GNOME screenshot llvmpipe > > (In reply to Chester Lin from comment #11) > > Since Mesa's upstream master seems to support GPU Adreno 690, I will try > > running the latest freedreno driver without loading the proprietary firmware. > > I have tried compiling/running the latest mesa [23.3.0-devel 23a2b83639af] > and GNOME can work although the renderer seems to be switched to llvmpipe. > (See attached picture) > Note: This time I removed the proprietary fw [a690_gmu.bin] and simply relied on Mesa. > Besides, I will reach ARM to see if they could contact Qualcomm for a690 fw > upstreaming.
Got more findings about llvmpie: 1. I traced the upstream and found that release tag 23.1.3 does have Adreno 690 patches so the llvmpie should be able to run on x13s. 2. The real problem is that Mesa packages collected via JeOS framework somehow cause the segmentation fault. For example, the default Mesa packages [version 23.1.5-355.1.aarch64] retrieved from the current openSUSE:Factory:ARM repo still have the same symptom. 3. Found that Mesa-* packages in openSUSE-Tumbleweed-Oss are older version 23.1.4-354.1.aarch64, so I tried downgrading to 23.1.4-354.1.aarch64 and then GNOME works. Not sure if any configuration could solve this question without re-installing Mesa packages. zypper log ========== S | Name | Type | Version | Arch | Repository ---+---------------------------+---------+--------------+---------+------------------------ i+ | Mesa | package | 23.1.5-355.1 | aarch64 | (System Packages) v | Mesa | package | 23.1.4-354.1 | aarch64 | openSUSE-Tumbleweed-Oss | Mesa-demo | package | 9.0.0-1.2 | aarch64 | openSUSE-Tumbleweed-Oss | Mesa-demo-egl | package | 9.0.0-1.2 | aarch64 | openSUSE-Tumbleweed-Oss | Mesa-demo-es | package | 9.0.0-1.2 | aarch64 | openSUSE-Tumbleweed-Oss | Mesa-demo-x | package | 9.0.0-1.2 | aarch64 | openSUSE-Tumbleweed-Oss | Mesa-devel | package | 23.1.4-354.1 | aarch64 | openSUSE-Tumbleweed-Oss i | Mesa-dri | package | 23.1.5-355.1 | aarch64 | (System Packages) v | Mesa-dri | package | 23.1.4-354.1 | aarch64 | openSUSE-Tumbleweed-Oss | Mesa-dri-devel | package | 23.1.4-354.1 | aarch64 | openSUSE-Tumbleweed-Oss | Mesa-dri-nouveau | package | 23.1.4-354.1 | aarch64 | openSUSE-Tumbleweed-Oss | Mesa-dri-vc4 | package | 23.1.4-354.1 | aarch64 | openSUSE-Tumbleweed-Oss i+ | Mesa-gallium | package | 23.1.5-355.1 | aarch64 | (System Packages) v | Mesa-gallium | package | 23.1.4-354.1 | aarch64 | openSUSE-Tumbleweed-Oss | Mesa-KHR-devel | package | 23.1.4-354.1 | aarch64 | openSUSE-Tumbleweed-Oss | Mesa-libd3d | package | 23.1.4-354.1 | aarch64 | openSUSE-Tumbleweed-Oss | Mesa-libd3d-devel | package | 23.1.4-354.1 | aarch64 | openSUSE-Tumbleweed-Oss | Mesa-libEGL-devel | package | 23.1.4-354.1 | aarch64 | openSUSE-Tumbleweed-Oss i | Mesa-libEGL1 | package | 23.1.5-355.1 | aarch64 | (System Packages) v | Mesa-libEGL1 | package | 23.1.4-354.1 | aarch64 | openSUSE-Tumbleweed-Oss | Mesa-libGL-devel | package | 23.1.4-354.1 | aarch64 | openSUSE-Tumbleweed-Oss i | Mesa-libGL1 | package | 23.1.5-355.1 | aarch64 | (System Packages) v | Mesa-libGL1 | package | 23.1.4-354.1 | aarch64 | openSUSE-Tumbleweed-Oss | Mesa-libglapi-devel | package | 23.1.4-354.1 | aarch64 | openSUSE-Tumbleweed-Oss i | Mesa-libglapi0 | package | 23.1.5-355.1 | aarch64 | (System Packages) v | Mesa-libglapi0 | package | 23.1.4-354.1 | aarch64 | openSUSE-Tumbleweed-Oss | Mesa-libGLESv1_CM-devel | package | 23.1.4-354.1 | aarch64 | openSUSE-Tumbleweed-Oss | Mesa-libGLESv2-devel | package | 23.1.4-354.1 | aarch64 | openSUSE-Tumbleweed-Oss | Mesa-libGLESv3-devel | package | 23.1.4-354.1 | aarch64 | openSUSE-Tumbleweed-Oss | Mesa-libOpenCL | package | 23.1.4-354.1 | aarch64 | openSUSE-Tumbleweed-Oss | Mesa-libRusticlOpenCL | package | 23.1.4-354.1 | aarch64 | openSUSE-Tumbleweed-Oss | Mesa-libva | package | 23.1.4-354.1 | aarch64 | openSUSE-Tumbleweed-Oss | Mesa-vulkan-device-select | package | 23.1.4-354.1 | aarch64 | openSUSE-Tumbleweed-Oss | Mesa-vulkan-overlay | package | 23.1.4-354.1 | aarch64 | openSUSE-Tumbleweed-Oss
A workaround patch can be found on v6.6-rc1, which uses a660_gmu.bin rather than a690_gmu.bin https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/gpu/drm/msm/adreno/adreno_device.c?id=18ff50e582a08eb365729b7c5507a8
Thanks. Since this patch is even already upstream, I think we should add it to our kernel. Takashi, what do you think?
Sure, Chester, feel free to backport to stable branch and send a PR :) The master branch will be switched to 6.6-rc1 soon later (likely in today), so you can leave it.
Sounds great! So let's reassign to him. ;-)
Pushed into users/clin/stable/for-next. Waiting for merge.
Code merged so let's close this issue. Thanks.
(In reply to Chester Lin from comment #21) > Code merged so let's close this issue. Thanks. The patch that switches to a660_gmu.bin has been merged into stable 6.5.3. But there's one more patch [since v6.6-rc1] required by X13s: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/gpu/drm/msm/adreno/adreno_device.c?h=v6.6-rc1&id=cb0aacde1e2c734119a53ecb313093e30b821f28 I have pushed this patch into a new PR.