Bugzilla – Bug 1193064
Elan Touchpad doesn't work on Lenovo Yoga Slim7
Last modified: 2023-01-18 17:17:33 UTC
Touchpad doesn't work on Lenovo Yoga Slim7 That problem on Leap 15.3 and Tumbleweed (also in RHEL 9 beta) And some bugs on Fedora (it failed to start after sleep, but at all is working), so probably problem more on kernel side
Created attachment 854025 [details] dmesg -l err
Created attachment 854026 [details] lsmod
Created attachment 854027 [details] lspci
Created attachment 854030 [details] hwinfo --all
Seems probably Intel Corporation Tiger Lake-LP Thunderbolt 4 PCI Express doesn't work too
Created attachment 854041 [details] xinput --list
Please give the full dmesg output after the fresh boot, not only about errors, too.
Created attachment 854042 [details] dmesg
Created attachment 854044 [details] inxi -v 2
This sounds like the case: https://bugzilla.kernel.org/show_bug.cgi?id=211553 Does the workaround suggested there work with yours? (either the dynamic re-binding or blacklisting).
(In reply to Takashi Iwai from comment #10) > This sounds like the case: > https://bugzilla.kernel.org/show_bug.cgi?id=211553 > > Does the workaround suggested there work with yours? (either the dynamic > re-binding or blacklisting). echo -n "i2c-ELAN0000:00" > /sys/bus/i2c/drivers/elan_i2c/unbind echo -n "i2c-ELAN0000:00" > /sys/bus/i2c/drivers/i2c_hid/bind No, but I will try blacklisting Also I would like to mention that it works on fedora35
Created attachment 854049 [details] dmesg on fedora
(In reply to Takashi Iwai from comment #10) > This sounds like the case: > https://bugzilla.kernel.org/show_bug.cgi?id=211553 > > Does the workaround suggested there work with yours? (either the dynamic > re-binding or blacklisting). Dynamic re-binding didn't help, but blacklisting did :) Thanks!
But touchpad not working after suspending laptop # modprobe -r psmouse modprobe: FATAL: Module psmouse is builtin. # rmmod i2c_hid rmmod: ERROR: Module i2c_hid is in use by: i2c_hid_acpi
How about rebinding? echo -n "i2c-ELAN0000:00" > /sys/bus/i2c/drivers/i2c_hid/unbind echo -n "i2c-ELAN0000:00" > /sys/bus/i2c/drivers/i2c_hid/bind You can try the above while the touchpad is working, and verify that the first call stops the touchpad and the second restores. If that works, try the same after the resume. It might be a different file name than i2c_hid on the recent system, so check the path beforehand. (e.g. on my 5.16-rc kernel, it's i2c_hid_acpi).
(In reply to Takashi Iwai from comment #15) > How about rebinding? > > echo -n "i2c-ELAN0000:00" > /sys/bus/i2c/drivers/i2c_hid/unbind > echo -n "i2c-ELAN0000:00" > /sys/bus/i2c/drivers/i2c_hid/bind > > You can try the above while the touchpad is working, and verify that the > first call stops the touchpad and the second restores. If that works, try > the same after the resume. It might be a different file name than i2c_hid > on the recent system, so check the path beforehand. (e.g. on my 5.16-rc > kernel, it's i2c_hid_acpi). bash: /sys/bus/i2c/drivers/i2c_hid/unbind: No such file or directory localhost:/ # echo -n "i2c-ELAN0000:00" > /sys/bus/i2c/drivers/i2c_hid_acpi/unbind localhost:/ # echo -n "i2c-ELAN0000:00" > /sys/bus/i2c/drivers/i2c_hid_acpi/bind (In reply to Takashi Iwai from comment #15) > How about rebinding? > > echo -n "i2c-ELAN0000:00" > /sys/bus/i2c/drivers/i2c_hid/unbind > echo -n "i2c-ELAN0000:00" > /sys/bus/i2c/drivers/i2c_hid/bind > > You can try the above while the touchpad is working, and verify that the > first call stops the touchpad and the second restores. If that works, try > the same after the resume. It might be a different file name than i2c_hid > on the recent system, so check the path beforehand. (e.g. on my 5.16-rc > kernel, it's i2c_hid_acpi). When touchpad is working (blacklisted elan) echo -n "i2c-ELAN0000:00" > /sys/bus/i2c/drivers/i2c_hid_acpi/unbind Disables echo -n "i2c-ELAN0000:00" > /sys/bus/i2c/drivers/i2c_hid_acpi/bind Restores (on my 5.15.3 kernel, it's i2c_hid_acpi too) When touchpad is not working (delete blacklist) localhost:/ # echo -n "i2c-ELAN0000:00" > /sys/bus/i2c/drivers/i2c_hid_acpi/unbind bash: echo: write error: No such device localhost:/ # echo -n "i2c-ELAN0000:00" > /sys/bus/i2c/drivers/i2c_hid_acpi/bind bash: echo: write error: Device or resource busy
Without the blacklist, you need to unbind the elantech driver at first, then bind to the hid_i2c_acpi. echo -n "i2c-ELAN0000:00" > /sys/bus/i2c/drivers/elan_i2c/unbind echo -n "i2c-ELAN0000:00" > /sys/bus/i2c/drivers/i2c_hid_acpi/bind But check whether elan_i2c is the correct path, too. And, my question was: what happens if you re-bind the i2c-hid-acpi driver after the resume where the touchpad doesn't work any longer. Does it make the touchpad working again?
(In reply to Takashi Iwai from comment #17) > Without the blacklist, you need to unbind the elantech driver at first, then > bind to the hid_i2c_acpi. > > echo -n "i2c-ELAN0000:00" > /sys/bus/i2c/drivers/elan_i2c/unbind > echo -n "i2c-ELAN0000:00" > /sys/bus/i2c/drivers/i2c_hid_acpi/bind Yes, that fixed, thanks (unbind elan and bind i2c_hid) (In reply to Takashi Iwai from comment #17) > And, my question was: what happens if you re-bind the i2c-hid-acpi driver > after the resume where the touchpad doesn't work any longer. Does it make > the touchpad working again? Seems rebinding is working, but after every rebind it resets touchpad settings
OK, then it's about the PM problem of i2c-hid stuff. I'm building a test kernel to ignore wakeup capability of the device to enforce the power up at resume. The test kernel is being built in OBS home:tiwai:bsc1193064 repo. Once after the build finishes, it'll be available at http://download.opensuse.org/repositories/home:/tiwai:/bsc1193064/standard/ Please check it out later. Note that it's an unofficial build, hence it won't boot with Secure Boot.
(In reply to Takashi Iwai from comment #19) > OK, then it's about the PM problem of i2c-hid stuff. > > I'm building a test kernel to ignore wakeup capability of the device to > enforce the power up at resume. The test kernel is being built in OBS > home:tiwai:bsc1193064 repo. Once after the build finishes, it'll be > available at > http://download.opensuse.org/repositories/home:/tiwai:/bsc1193064/standard/ > > Please check it out later. Note that it's an unofficial build, hence it > won't boot with Secure Boot. I did: rpm -ivh kernel-default-5.15.5-1.1.gafe3127.x86_64.rpm, reboot, uname -r 5.15.5-1.gafe3127-default But seems that problem still there ..
On that kernel I did rebinding (for fixing touchpad) and seems natural scrolling doesnt work (checked this setting multiple times)
I installed all .rpm's > rpm -qa | grep gafe3127 kernel-devel-5.15.5-1.1.gafe3127.noarch kernel-default-devel-5.15.5-1.1.gafe3127.x86_64 kernel-default-5.15.5-1.1.gafe3127.x86_64 kernel-source-vanilla-5.15.5-1.1.gafe3127.noarch I seems still no result grub.cfg: linuxefi /boot/vmlinuz-5.15.5-1.gafe3127-default root=/dev/mapper/system-root ${extra_cmdline} splash=silent quiet mitigations=auto initrdefi /boot/initrd-5.15.5-1.gafe3127-default (automatically generated by first rpm file, which is kernel-default-5.15.5-1.1.gafe3127.x86_64.rpm)
Hrm, my kernel merely changed the suspend/resume functions and nothing else, so the behavior change except for suspend/resume isn't expected. And, it doesn't change the binding, so the blacklist is still necessary. It was asked only for testing the suspend/resume problem. You should install only kernel-default.rpm, nothing else. At easiest, download kernel-default-5.15*.rpm from the URL and install it manually via zypper install.
(In reply to Takashi Iwai from comment #23) > Hrm, my kernel merely changed the suspend/resume functions and nothing else, > so the behavior change except for suspend/resume isn't expected. And, it > doesn't change the binding, so the blacklist is still necessary. It was > asked only for testing the suspend/resume problem. > > You should install only kernel-default.rpm, nothing else. At easiest, > download kernel-default-5.15*.rpm from the URL and install it manually via > zypper install. Oh, my bad... My current fix is disabling touchpad service on startup (backgroud services on kde) - then it doesn't disable after suspend :) but fix for that would be too cool because in my case touchpad is enabled in suspend mode (it still consume electricity), also it's not possible to run this service manually (failed to start touchpad service) Also there strange enabled status when it broken For fixing after suspend/resume needs (maybe your kernel unbind elan_i2c?) # echo -n "i2c-ELAN0000:00" > /sys/bus/i2c/drivers/i2c_hid_acpi/unbind # echo -n "i2c-ELAN0000:00" > /sys/bus/i2c/drivers/i2c_hid_acpi/bind Maybe problem with touchpad service ?
Created attachment 854095 [details] failed to start touchpad service if it not started at boot
Created attachment 854096 [details] strange touchpad enabled status
(In reply to Artyom from comment #24) > (In reply to Takashi Iwai from comment #23) > > Hrm, my kernel merely changed the suspend/resume functions and nothing else, > > so the behavior change except for suspend/resume isn't expected. And, it > > doesn't change the binding, so the blacklist is still necessary. It was > > asked only for testing the suspend/resume problem. > > > > You should install only kernel-default.rpm, nothing else. At easiest, > > download kernel-default-5.15*.rpm from the URL and install it manually via > > zypper install. > > Oh, my bad... > My current fix is disabling touchpad service on startup (backgroud services > on kde) - then it doesn't disable after suspend :) but fix for that would be > too cool because in my case touchpad is enabled in suspend mode (it still > consume electricity), also it's not possible to run this service manually > (failed to start touchpad service) > Also there strange enabled status when it broken > For fixing after suspend/resume needs (maybe your kernel unbind elan_i2c?) > # echo -n "i2c-ELAN0000:00" > /sys/bus/i2c/drivers/i2c_hid_acpi/unbind > # echo -n "i2c-ELAN0000:00" > /sys/bus/i2c/drivers/i2c_hid_acpi/bind > Maybe problem with touchpad service ? Is this behavior (jumping pointer?) with the unpatched kernel? I expected that the patch may influence on this. In anyway, if not done yet, please check the following with the patched kernel: - Boot with the blacklist - Try suspend / resume without re-binding and let me know which problem is present. FWIW, Fedora kernel "works" because the device is bound with i2c-hid, not elantech. Maybe they have some workaround in it or it's just a matter of device binding order that casually worked. But the suspend/resume problem should remain with them unless any fix is applied.
(In reply to Takashi Iwai from comment #27) > (In reply to Artyom from comment #24) > > (In reply to Takashi Iwai from comment #23) > > > Hrm, my kernel merely changed the suspend/resume functions and nothing else, > > > so the behavior change except for suspend/resume isn't expected. And, it > > > doesn't change the binding, so the blacklist is still necessary. It was > > > asked only for testing the suspend/resume problem. > > > > > > You should install only kernel-default.rpm, nothing else. At easiest, > > > download kernel-default-5.15*.rpm from the URL and install it manually via > > > zypper install. > > > > Oh, my bad... > > My current fix is disabling touchpad service on startup (backgroud services > > on kde) - then it doesn't disable after suspend :) but fix for that would be > > too cool because in my case touchpad is enabled in suspend mode (it still > > consume electricity), also it's not possible to run this service manually > > (failed to start touchpad service) > > Also there strange enabled status when it broken > > For fixing after suspend/resume needs (maybe your kernel unbind elan_i2c?) > > # echo -n "i2c-ELAN0000:00" > /sys/bus/i2c/drivers/i2c_hid_acpi/unbind > > # echo -n "i2c-ELAN0000:00" > /sys/bus/i2c/drivers/i2c_hid_acpi/bind > > Maybe problem with touchpad service ? > > Is this behavior (jumping pointer?) with the unpatched kernel? I expected > that the patch may influence on this. > > In anyway, if not done yet, please check the following with the patched > kernel: > - Boot with the blacklist > - Try suspend / resume without re-binding > and let me know which problem is present. > > FWIW, Fedora kernel "works" because the device is bound with i2c-hid, not > elantech. Maybe they have some workaround in it or it's just a matter of > device binding order that casually worked. But the suspend/resume problem > should remain with them unless any fix is applied. No, this on both kernels, but this was not the case in Fedora (there it were a easy way to rebind) The problems is present :( At the moment I have not noticed the difference between the kernels Yes, looks like that, but all (including fedora) have a problem with touchpad service
Created attachment 854100 [details] strange touchpad start/stop
I still have this problem on TW, but currently see in dmesg ("d" instead of "0") elan_i2c i2c-ELAN0000:00: invalid report id data (d) So, blocking in modprobe is still needed
OK, I'm building another test kernel in the same OBS repo home:tiwai:bsc1193064. At this time, it's a test patch to avoid binding with elan-i2c, so it should work without blacklist. Please give it a try once after the build finishes. It'll be based on 5.16.4.
(In reply to Takashi Iwai from comment #31) > OK, I'm building another test kernel in the same OBS repo > home:tiwai:bsc1193064. > At this time, it's a test patch to avoid binding with elan-i2c, so it should > work without blacklist. Please give it a try once after the build finishes. > It'll be based on 5.16.4. It's still binding with elan-i2c :(
There was a wrong DMI matching field, hence it didn't hit the list. Now a new test kernel (5.16.5) is being built in the same OBS repo with the revised patch. Please check it later.
(In reply to Takashi Iwai from comment #31) > OK, I'm building another test kernel in the same OBS repo > home:tiwai:bsc1193064. > At this time, it's a test patch to avoid binding with elan-i2c, so it should > work without blacklist. Please give it a try once after the build finishes. > It'll be based on 5.16.4. It still binding with elan-i2c(In reply to Takashi Iwai from comment #33) > There was a wrong DMI matching field, hence it didn't hit the list. > Now a new test kernel (5.16.5) is being built in the same OBS repo with the > revised patch. Please check it later. Yay! Thank you, it works correctly now Will this patch get into the TW and Leap (15.4) default kernel?
OK, I pushed the workaround patch to stable branch, while asking upstream about a more proper fix (if any). Let's see.
SUSE-SU-2022:2520-1: An update that solves 49 vulnerabilities, contains 26 features and has 207 fixes is now available. Category: security (important) Bug References: 1055117,1061840,1065729,1071995,1089644,1103269,1118212,1121726,1137728,1156395,1157038,1157923,1175667,1179439,1179639,1180814,1183682,1183872,1184318,1184924,1187716,1188885,1189998,1190137,1190208,1190336,1190497,1190768,1190786,1190812,1191271,1191663,1192483,1193064,1193277,1193289,1193431,1193556,1193629,1193640,1193787,1193823,1193852,1194086,1194111,1194191,1194409,1194501,1194523,1194526,1194583,1194585,1194586,1194625,1194765,1194826,1194869,1195099,1195287,1195478,1195482,1195504,1195651,1195668,1195669,1195775,1195823,1195826,1195913,1195915,1195926,1195944,1195957,1195987,1196079,1196114,1196130,1196213,1196306,1196367,1196400,1196426,1196478,1196514,1196570,1196723,1196779,1196830,1196836,1196866,1196868,1196869,1196901,1196930,1196942,1196960,1197016,1197157,1197227,1197243,1197292,1197302,1197303,1197304,1197362,1197386,1197501,1197601,1197661,1197675,1197761,1197817,1197819,1197820,1197888,1197889,1197894,1197915,1197917,1197918,1197920,1197921,1197922,1197926,1198009,1198010,1198012,1198013,1198014,1198015,1198016,1198017,1198018,1198019,1198020,1198021,1198022,1198023,1198024,1198027,1198030,1198034,1198058,1198217,1198379,1198400,1198402,1198410,1198412,1198413,1198438,1198484,1198577,1198585,1198660,1198802,1198803,1198806,1198811,1198826,1198829,1198835,1198968,1198971,1199011,1199024,1199035,1199046,1199052,1199063,1199163,1199173,1199260,1199314,1199390,1199426,1199433,1199439,1199482,1199487,1199505,1199507,1199605,1199611,1199626,1199631,1199650,1199657,1199674,1199736,1199793,1199839,1199875,1199909,1200015,1200019,1200045,1200046,1200144,1200205,1200211,1200259,1200263,1200284,1200315,1200343,1200420,1200442,1200475,1200502,1200567,1200569,1200571,1200599,1200600,1200608,1200611,1200619,1200692,1200762,1200763,1200806,1200807,1200808,1200809,1200810,1200812,1200813,1200815,1200816,1200820,1200821,1200822,1200824,1200825,1200827,1200828,1200829,1200830,1200845,1200882,1200925,1201050,1201080,1201160,1201171,1201177,1201193,1201196,1201218,1201222,1201228,1201251,1201381,1201471,1201524 CVE References: CVE-2021-26341,CVE-2021-33061,CVE-2021-4204,CVE-2021-44879,CVE-2021-45402,CVE-2022-0264,CVE-2022-0494,CVE-2022-0617,CVE-2022-1012,CVE-2022-1016,CVE-2022-1184,CVE-2022-1198,CVE-2022-1205,CVE-2022-1462,CVE-2022-1508,CVE-2022-1651,CVE-2022-1652,CVE-2022-1671,CVE-2022-1679,CVE-2022-1729,CVE-2022-1734,CVE-2022-1789,CVE-2022-1852,CVE-2022-1966,CVE-2022-1972,CVE-2022-1974,CVE-2022-1998,CVE-2022-20132,CVE-2022-20154,CVE-2022-21123,CVE-2022-21125,CVE-2022-21127,CVE-2022-21166,CVE-2022-21180,CVE-2022-21499,CVE-2022-2318,CVE-2022-23222,CVE-2022-26365,CVE-2022-26490,CVE-2022-29582,CVE-2022-29900,CVE-2022-29901,CVE-2022-30594,CVE-2022-33740,CVE-2022-33741,CVE-2022-33742,CVE-2022-33743,CVE-2022-33981,CVE-2022-34918 JIRA References: SLE-13513,SLE-13521,SLE-15442,SLE-17855,SLE-18194,SLE-18234,SLE-18375,SLE-18377,SLE-18378,SLE-18382,SLE-18385,SLE-18901,SLE-18938,SLE-18978,SLE-19001,SLE-19026,SLE-19242,SLE-19249,SLE-19253,SLE-19924,SLE-21315,SLE-23643,SLE-24072,SLE-24093,SLE-24350,SLE-24549 Sources used: openSUSE Leap 15.4 (src): dtb-aarch64-5.14.21-150400.24.11.1, kernel-64kb-5.14.21-150400.24.11.1, kernel-debug-5.14.21-150400.24.11.1, kernel-default-5.14.21-150400.24.11.1, kernel-default-base-5.14.21-150400.24.11.1.150400.24.3.6, kernel-docs-5.14.21-150400.24.11.1, kernel-kvmsmall-5.14.21-150400.24.11.1, kernel-obs-build-5.14.21-150400.24.11.1, kernel-obs-qa-5.14.21-150400.24.11.1, kernel-source-5.14.21-150400.24.11.1, kernel-syms-5.14.21-150400.24.11.1, kernel-zfcpdump-5.14.21-150400.24.11.1 SUSE Linux Enterprise Workstation Extension 15-SP4 (src): kernel-default-5.14.21-150400.24.11.1 SUSE Linux Enterprise Module for Live Patching 15-SP4 (src): kernel-default-5.14.21-150400.24.11.1, kernel-livepatch-SLE15-SP4_Update_1-1-150400.9.5.3 SUSE Linux Enterprise Module for Legacy Software 15-SP4 (src): kernel-default-5.14.21-150400.24.11.1 SUSE Linux Enterprise Module for Development Tools 15-SP4 (src): kernel-docs-5.14.21-150400.24.11.1, kernel-obs-build-5.14.21-150400.24.11.1, kernel-source-5.14.21-150400.24.11.1, kernel-syms-5.14.21-150400.24.11.1 SUSE Linux Enterprise Module for Basesystem 15-SP4 (src): kernel-64kb-5.14.21-150400.24.11.1, kernel-default-5.14.21-150400.24.11.1, kernel-default-base-5.14.21-150400.24.11.1.150400.24.3.6, kernel-source-5.14.21-150400.24.11.1, kernel-zfcpdump-5.14.21-150400.24.11.1 SUSE Linux Enterprise High Availability 15-SP4 (src): kernel-default-5.14.21-150400.24.11.1 NOTE: This line indicates an update has been released for the listed product(s). At times this might be only a partial fix. If you have questions please reach out to maintenance coordination.
SUSE-SU-2022:2615-1: An update that solves 48 vulnerabilities, contains 26 features and has 202 fixes is now available. Category: security (important) Bug References: 1055117,1061840,1065729,1071995,1089644,1103269,1118212,1121726,1137728,1156395,1157038,1157923,1175667,1179439,1179639,1180814,1183682,1183872,1184318,1184924,1187716,1188885,1189998,1190137,1190208,1190336,1190497,1190768,1190786,1190812,1191271,1191663,1192483,1193064,1193277,1193289,1193431,1193556,1193629,1193640,1193787,1193823,1193852,1194086,1194111,1194191,1194409,1194501,1194523,1194526,1194583,1194585,1194586,1194625,1194765,1194826,1194869,1195099,1195287,1195478,1195482,1195504,1195651,1195668,1195669,1195775,1195823,1195826,1195913,1195915,1195926,1195944,1195957,1195987,1196079,1196114,1196130,1196213,1196306,1196367,1196400,1196426,1196478,1196514,1196570,1196723,1196779,1196830,1196836,1196866,1196868,1196869,1196901,1196930,1196942,1196960,1197016,1197157,1197227,1197243,1197292,1197302,1197303,1197304,1197362,1197386,1197501,1197601,1197661,1197675,1197761,1197817,1197819,1197820,1197888,1197889,1197894,1197915,1197917,1197918,1197920,1197921,1197922,1197926,1198009,1198010,1198012,1198013,1198014,1198015,1198016,1198017,1198018,1198019,1198020,1198021,1198022,1198023,1198024,1198027,1198030,1198034,1198058,1198217,1198379,1198400,1198402,1198412,1198413,1198438,1198484,1198577,1198585,1198660,1198802,1198803,1198806,1198811,1198826,1198835,1198968,1198971,1199011,1199024,1199035,1199046,1199052,1199063,1199163,1199173,1199260,1199314,1199390,1199426,1199433,1199439,1199482,1199487,1199505,1199507,1199605,1199611,1199626,1199631,1199650,1199657,1199674,1199736,1199793,1199839,1199875,1199909,1200015,1200019,1200045,1200046,1200144,1200205,1200211,1200259,1200263,1200284,1200315,1200343,1200420,1200442,1200475,1200502,1200567,1200569,1200571,1200572,1200599,1200600,1200608,1200611,1200619,1200692,1200762,1200763,1200806,1200807,1200808,1200809,1200810,1200812,1200815,1200816,1200820,1200822,1200824,1200825,1200827,1200828,1200829,1200830,1200845,1200882,1200925,1201050,1201160,1201171,1201177,1201193,1201196,1201218,1201222,1201228,1201251,150300 CVE References: CVE-2021-26341,CVE-2021-33061,CVE-2021-4204,CVE-2021-44879,CVE-2021-45402,CVE-2022-0264,CVE-2022-0494,CVE-2022-0617,CVE-2022-1012,CVE-2022-1016,CVE-2022-1184,CVE-2022-1198,CVE-2022-1205,CVE-2022-1508,CVE-2022-1651,CVE-2022-1652,CVE-2022-1671,CVE-2022-1679,CVE-2022-1729,CVE-2022-1734,CVE-2022-1789,CVE-2022-1852,CVE-2022-1966,CVE-2022-1972,CVE-2022-1974,CVE-2022-1998,CVE-2022-20132,CVE-2022-20154,CVE-2022-21123,CVE-2022-21125,CVE-2022-21127,CVE-2022-21166,CVE-2022-21180,CVE-2022-21499,CVE-2022-2318,CVE-2022-23222,CVE-2022-26365,CVE-2022-26490,CVE-2022-29582,CVE-2022-29900,CVE-2022-29901,CVE-2022-30594,CVE-2022-33740,CVE-2022-33741,CVE-2022-33742,CVE-2022-33743,CVE-2022-33981,CVE-2022-34918 JIRA References: SLE-13513,SLE-13521,SLE-15442,SLE-17855,SLE-18194,SLE-18234,SLE-18375,SLE-18377,SLE-18378,SLE-18382,SLE-18385,SLE-18901,SLE-18938,SLE-18978,SLE-19001,SLE-19026,SLE-19242,SLE-19249,SLE-19253,SLE-19924,SLE-21315,SLE-23643,SLE-24072,SLE-24093,SLE-24350,SLE-24549 Sources used: openSUSE Leap 15.4 (src): kernel-azure-5.14.21-150400.14.7.1, kernel-source-azure-5.14.21-150400.14.7.1, kernel-syms-azure-5.14.21-150400.14.7.1 SUSE Linux Enterprise Module for Public Cloud 15-SP4 (src): kernel-azure-5.14.21-150400.14.7.1, kernel-source-azure-5.14.21-150400.14.7.1, kernel-syms-azure-5.14.21-150400.14.7.1 NOTE: This line indicates an update has been released for the listed product(s). At times this might be only a partial fix. If you have questions please reach out to maintenance coordination.
(In reply to Takashi Iwai from comment #35) > OK, I pushed the workaround patch to stable branch, while asking upstream > about a more proper fix (if any). Let's see. Any replies there? This is likely still not fixed upstream. At least not by the proposed patch.
My RFC patch wasn't taken, as we wanted a different approach: https://lore.kernel.org/all/s5hleyqwowl.wl-tiwai@suse.de/ It's a question whether the same situation still remains with the latest upstream. Artyom, could you check whether the problem still appears when you install and boot with kernel-vanilla package?
(In reply to Takashi Iwai from comment #55) > My RFC patch wasn't taken, as we wanted a different approach: > https://lore.kernel.org/all/s5hleyqwowl.wl-tiwai@suse.de/ > > It's a question whether the same situation still remains with the latest > upstream. > > Artyom, could you check whether the problem still appears when you install > and boot with kernel-vanilla package? This problem is still appears on kernel-vanilla (6.0.7-1-vanilla) TW package :(
Thanks for confirmation. So we still need to work on the proper fix. This has to be discussed with the upstream again. Meanwhile we can keep the downstream fix patch for now; it's pretty safe and has been working.