Bug 216412
| Summary: | asus-ec-sensors causes the lid device is not compliant to SW_LID | ||
|---|---|---|---|
| Product: | Drivers | Reporter: | Gibeom Gwon (gb.gwon) |
| Component: | Hardware Monitoring | Assignee: | Eugene Shalygin (eugene.shalygin) |
| Status: | RESOLVED CODE_FIX | ||
| Severity: | normal | CC: | jdelvare, sovocoshka |
| Priority: | P1 | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Kernel Version: | 6.0-rc1 | Subsystem: | |
| Regression: | No | Bisected commit-id: | |
| Attachments: |
dmesg output
test-probe-patch test2-probe-patch test3 test4-probe.patch |
||
Thanks for the report. It's hard to believe that a driver which does not even load can cause problem. The suspect commit changes the module alias from DMI-based to ACPI-based. This most definitely causes the module loading to be attempted on your system (because you have the ACPI device named "PNP0C09") while it wasn't attempted before (because your DMI data doesn't match any entry in the driver). You could try loading the asus-ec-sensors driver explicitly (modprobe as root) on an old (working) kernel and see if this causes the same problem. If it does, then the problem was already present in the asus-ec-sensors driver before. It not, then the problem was introduced by the commit pointed out by your bisection. Hi Gibeom, I can't see an obvious reason for this bug, and thus want to ask you for a help to investigate, please. What's the board name (/sys/class/dmi/id/board_name)? Does an attempt to load the module after completely booting the system leads to the bug as well? Are you willing to recompile the asus_ec_sensors module with patches? Thank you for the responses. I could found "PNP0C09" device. /sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:08/PNP0C09:00. It looks like kernel attempted to load the module as "PNP0C09" exists, but get_board_info() returns NULL, module is not loaded in the end. I couldn't reproduce the bug with v5.18. The board_name is FX706HCB. I also tried this. 1) Blacklist the asus-ec-sensors 2) Reboot 3) Test lid switch <<< Worked as expected. 4) Remove blacklist and modprobe asus-ec-sensors 5) Test lid switch <<< Not worked and "ACPI: button: The lid device is not compliant to SW_LID." shown. I compiled kernel with archlinux-mainline which uses upstream git. Is there anything the kernel triggers on the ACPI side when attempting to load the module through the ACPI device match? Result of modprobe asus-ec-sensors: modprobe: ERROR: could not insert 'asus_ec_sensors': No such device Created attachment 301659 [details]
test-probe-patch
Thank you! Could you try the attached patch, please?
Tested the patch and the system was suspended when the lid was closed as expected. Thank you! By the way, asus_ec_sensors_platform_driver variable was never used, is it intended? I'm not familiar with the kernel module code, so I'm not sure if it's ok. Created attachment 301661 [details]
test2-probe-patch
Thank you! That was not a bug fix, but just a test. Could you test the next one, please?
The second patch also worked fine. (In reply to Gibeom Gwon from comment #8) > The second patch also worked fine. Thank you for testing that out! I shall test on a system where the module should be autoloaded and if that works, the patch will be submitted to the kernel. Please let me know if you need more tests. Thank you for your efforts! Well done Eugene, but I have to admit I don't understand how module_platform_driver_probe() was causing the reported problem. Can you explain? (In reply to Jean Delvare from comment #11) > Well done Eugene, but I have to admit I don't understand how > module_platform_driver_probe() was causing the reported problem. Can you > explain? Sorry, I can't. Was shooting at the only place related to the problem to fix the bug, which might have broke ACPI events on every single ASUS laptop, quickly. Still have no idea why does the ACPI subsystem reacts this way when we bind to the EC and return -ENODEV. Fair enough. Is it still OK for asus_ec_probe() to be __init? The compiler doesn't complain, but considering that it is now referenced by asus_ec_sensors_platform_driver_probe which isn't __init itself, that seems wrong. Same for many other functions, which are called by asus_ec_probe(), directly or indirectly. Created attachment 301737 [details]
test3
Hi Gibeom,
could you test this simple patch (test3), please?
(In reply to Eugene Shalygin from comment #14) > Created attachment 301737 [details] > test3 > > Hi Gibeom, > > could you test this simple patch (test3), please? Tested the patch, the problem still exists. Created attachment 301740 [details]
test4-probe.patch
(In reply to Gibeom Gwon from comment #15) > Tested the patch, the problem still exists. Thank you! That rejected one of the ideas what is causing the problem. Patch 2 broke the driver for cases where it has to be active, so here is test 4. I would appreciate if you could test it. (In reply to Eugene Shalygin from comment #17) > > Thank you! That rejected one of the ideas what is causing the problem. > Patch 2 broke the driver for cases where it has to be active, so here is > test 4. I would appreciate if you could test it. Tested the test 4, the problem still exists too. (In reply to Gibeom Gwon from comment #18) > Tested the test 4, the problem still exists too. Thanks a lot! Now I understand I have to redo module loading completely. Glad you found the cause of the problem! Thank you for your attention to this issue. So was this issue resolved as I am seeing the same behaviour on asus rog g15 up to kernel 5.19.5 (In reply to cuttlefish from comment #21) The fix should be in the next 5.19 release (5.19.9), until that please blacklist the module. (In reply to Eugene Shalygin from comment #22) > (In reply to cuttlefish from comment #21) > The fix should be in the next 5.19 release (5.19.9), until that please > blacklist the module. Thanks a lot for your reply! 5.19.9 was released with the fix. (In reply to Eugene Shalygin from comment #24) > 5.19.9 was released with the fix. The issue seemed to persist for me in 5.19.9. Was running Fedora 36 on Zephyrus g15. Wouldn't be able to show any logs or test anything, as I am running a different system now. (In reply to cuttlefish from comment #25) > The issue seemed to persist for me in 5.19.9. People from the Arch forum (https://bbs.archlinux.org/viewtopic.php?id=278933&p=5) confirm that the problem disappeared in 5.19.9. Since you can't provide any additional information, I don't know how to help, sorry. |
Created attachment 301658 [details] dmesg output Hello, I'm using an ASUS laptop FX706HC and as of v5.19, closing the lid doesn't suspend the system. Laptops from other manufacturers are not affected. "ACPI: button: The lid device is not compliant to SW_LID." printed in dmesg. No other useful logs are available. I did bisect and found out that this bug occurred after commit 5cd29012028d997f46518dae0a8133e0985713f3. This bug definitely related to asus-ec-sensors module, because it works as expected if I blacklist the module. Interestingly, asus-ec-sensors is never loaded as it doesn't currently support any laptops including mine. Here is the lsmod output: $ lsmod Module Size Used by snd_seq_dummy 16384 0 snd_hrtimer 16384 1 snd_seq 94208 7 snd_seq_dummy snd_seq_device 16384 1 snd_seq rfcomm 90112 16 snd_hda_codec_realtek 167936 1 snd_hda_codec_generic 98304 1 snd_hda_codec_realtek snd_sof_pci_intel_tgl 16384 0 snd_sof_intel_hda_common 180224 1 snd_sof_pci_intel_tgl soundwire_intel 53248 1 snd_sof_intel_hda_common soundwire_generic_allocation 16384 1 soundwire_intel soundwire_cadence 45056 1 soundwire_intel snd_sof_intel_hda 20480 1 snd_sof_intel_hda_common snd_sof_pci 24576 2 snd_sof_intel_hda_common,snd_sof_pci_intel_tgl cmac 16384 3 snd_sof_xtensa_dsp 20480 1 snd_sof_intel_hda_common algif_hash 16384 1 snd_sof 307200 2 snd_sof_pci,snd_sof_intel_hda_common algif_skcipher 16384 1 snd_sof_utils 20480 1 snd_sof af_alg 36864 6 algif_hash,algif_skcipher snd_soc_hdac_hda 28672 1 snd_sof_intel_hda_common bnep 32768 2 snd_hda_ext_core 36864 3 snd_sof_intel_hda_common,snd_soc_hdac_hda,snd_sof_intel_hda snd_soc_acpi_intel_match 69632 2 snd_sof_intel_hda_common,snd_sof_pci_intel_tgl snd_soc_acpi 16384 2 snd_soc_acpi_intel_match,snd_sof_intel_hda_common soundwire_bus 126976 3 soundwire_intel,soundwire_generic_allocation,soundwire_cadence hid_multitouch 32768 0 asus_nb_wmi 28672 0 snd_soc_core 393216 4 soundwire_intel,snd_sof,snd_sof_intel_hda_common,snd_soc_hdac_hda iTCO_wdt 16384 0 mei_pxp 20480 0 spi_nor 118784 0 asus_wmi 69632 1 asus_nb_wmi mei_hdcp 24576 0 intel_pmc_bxt 16384 1 iTCO_wdt ee1004 20480 0 ledtrig_audio 16384 2 snd_hda_codec_generic,asus_wmi snd_compress 28672 1 snd_soc_core mtd 90112 3 spi_nor iTCO_vendor_support 16384 1 iTCO_wdt intel_rapl_msr 20480 0 pmt_telemetry 16384 0 platform_profile 16384 1 asus_wmi wmi_bmof 16384 0 intel_tcc_cooling 16384 0 pmt_class 16384 1 pmt_telemetry snd_hda_codec_hdmi 86016 2 ac97_bus 16384 1 snd_soc_core snd_pcm_dmaengine 16384 1 snd_soc_core mt7921e 32768 0 x86_pkg_temp_thermal 20480 0 snd_hda_intel 61440 5 intel_powerclamp 20480 0 wireguard 98304 0 i915 3145728 57 mt7921_common 94208 1 mt7921e uvcvideo 163840 0 snd_intel_dspcfg 36864 3 snd_hda_intel,snd_sof,snd_sof_intel_hda_common btusb 65536 0 coretemp 20480 0 curve25519_x86_64 36864 1 wireguard mt76_connac_lib 69632 2 mt7921e,mt7921_common snd_intel_sdw_acpi 20480 2 snd_sof_intel_hda_common,snd_intel_dspcfg videobuf2_vmalloc 20480 1 uvcvideo btrtl 28672 1 btusb videobuf2_memops 20480 1 videobuf2_vmalloc libchacha20poly1305 16384 1 wireguard snd_hda_codec 188416 5 snd_hda_codec_generic,snd_hda_codec_hdmi,snd_hda_intel,snd_hda_codec_realtek,snd_soc_hdac_hda mt76 102400 3 mt7921e,mt7921_common,mt76_connac_lib processor_thermal_device_pci_legacy 16384 0 btbcm 24576 1 btusb videobuf2_v4l2 40960 1 uvcvideo chacha_x86_64 28672 1 libchacha20poly1305 vfat 24576 1 kvm_intel 389120 0 kvm 1138688 1 kvm_intel irqbypass 16384 1 kvm snd_hda_core 118784 9 snd_hda_codec_generic,snd_hda_codec_hdmi,snd_hda_intel,snd_hda_ext_core,snd_hda_codec,snd_hda_codec_realtek,snd_sof_intel_hda_common,snd_soc_hdac_hda,snd_sof_intel_hda btintel 45056 1 btusb intel_cstate 20480 0 intel_uncore 217088 0 pcspkr 16384 0 videobuf2_common 86016 4 videobuf2_vmalloc,videobuf2_v4l2,uvcvideo,videobuf2_memops processor_thermal_device 20480 1 processor_thermal_device_pci_legacy fat 98304 1 vfat btmtk 16384 1 btusb poly1305_x86_64 28672 1 libchacha20poly1305 snd_hwdep 16384 1 snd_hda_codec drm_buddy 20480 1 i915 mac80211 1298432 3 mt76,mt7921_common,mt76_connac_lib bluetooth 937984 46 btrtl,btmtk,btintel,btbcm,bnep,btusb,rfcomm processor_thermal_rfim 16384 1 processor_thermal_device snd_pcm 172032 13 snd_hda_codec_hdmi,snd_hda_intel,snd_hda_codec,soundwire_intel,snd_sof,snd_sof_intel_hda_common,snd_compress,snd_soc_core,snd_sof_utils,snd_hda_core,snd_pcm_dmaengine spi_intel_pci 16384 0 libcurve25519_generic 49152 2 curve25519_x86_64,wireguard videodev 315392 3 videobuf2_v4l2,uvcvideo,videobuf2_common ucsi_acpi 16384 0 intel_lpss_pci 28672 0 i2c_i801 45056 0 processor_thermal_mbox 16384 2 processor_thermal_rfim,processor_thermal_device ttm 94208 1 i915 mei_me 53248 2 libchacha 16384 1 chacha_x86_64 snd_timer 49152 3 snd_seq,snd_hrtimer,snd_pcm spi_intel 28672 1 spi_intel_pci typec_ucsi 53248 1 ucsi_acpi intel_lpss 16384 1 intel_lpss_pci processor_thermal_rapl 20480 1 processor_thermal_device i2c_smbus 20480 1 i2c_i801 ip6_udp_tunnel 16384 1 wireguard libarc4 16384 1 mac80211 mc 73728 4 videodev,videobuf2_v4l2,uvcvideo,videobuf2_common ecdh_generic 16384 2 bluetooth int3403_thermal 20480 0 joydev 28672 0 udp_tunnel 20480 1 wireguard mousedev 24576 0 mei 172032 5 mei_hdcp,mei_pxp,mei_me drm_display_helper 180224 1 i915 intel_rapl_common 32768 2 intel_rapl_msr,processor_thermal_rapl snd 126976 23 snd_hda_codec_generic,snd_seq,snd_seq_device,snd_hda_codec_hdmi,snd_hwdep,snd_hda_intel,snd_hda_codec,snd_hda_codec_realtek,snd_sof,snd_timer,snd_compress,snd_soc_core,snd_pcm idma64 20480 0 typec 90112 1 typec_ucsi int340x_thermal_zone 20480 2 int3403_thermal,processor_thermal_device cec 81920 2 drm_display_helper,i915 soundcore 16384 1 snd intel_gtt 28672 1 i915 intel_vsec 20480 0 i2c_hid_acpi 16384 0 roles 16384 1 typec_ucsi intel_soc_dts_iosf 20480 1 processor_thermal_device_pci_legacy wmi 45056 2 asus_wmi,wmi_bmof mac_hid 16384 0 i2c_hid 40960 1 i2c_hid_acpi cfg80211 1118208 4 mt76,mac80211,mt7921_common,mt76_connac_lib int3400_thermal 20480 0 intel_hid 28672 0 video 61440 2 asus_wmi,i915 acpi_pad 24576 0 acpi_thermal_rel 16384 1 int3400_thermal asus_wireless 20480 0 sparse_keymap 16384 2 intel_hid,asus_wmi rfkill 32768 8 asus_wmi,bluetooth,cfg80211 r8169 102400 0 realtek 36864 1 mdio_devres 16384 1 r8169 libphy 172032 3 r8169,mdio_devres,realtek br_netfilter 32768 0 bridge 364544 1 br_netfilter stp 16384 1 bridge llc 16384 2 bridge,stp crypto_user 24576 0 fuse 176128 5 ip_tables 36864 0 x_tables 57344 1 ip_tables ext4 1015808 1 crc32c_generic 16384 0 crc16 16384 2 bluetooth,ext4 mbcache 16384 1 ext4 jbd2 188416 1 ext4 dm_crypt 61440 1 cbc 16384 0 encrypted_keys 28672 1 dm_crypt trusted 49152 2 encrypted_keys,dm_crypt asn1_encoder 16384 1 trusted tee 36864 1 trusted usbhid 73728 0 dm_mod 188416 3 dm_crypt serio_raw 20480 0 atkbd 36864 0 crct10dif_pclmul 16384 1 crc32_pclmul 16384 0 crc32c_intel 24576 2 libps2 20480 1 atkbd tpm_crb 20480 0 nvme 61440 2 ghash_clmulni_intel 16384 0 vivaldi_fmap 16384 1 atkbd aesni_intel 393216 6 crypto_simd 16384 1 aesni_intel tpm_tis 16384 0 xhci_pci 20480 0 nvme_core 180224 3 nvme cryptd 24576 4 crypto_simd,ghash_clmulni_intel tpm_tis_core 36864 1 tpm_tis xhci_pci_renesas 24576 1 xhci_pci i8042 49152 1 asus_nb_wmi tpm 102400 4 tpm_tis,trusted,tpm_crb,tpm_tis_core serio 28672 4 serio_raw,atkbd,i8042 rng_core 20480 1 tpm I suspect the acpi device match, but I'm not familiar with the code so I'm not sure. Regards, Gibeom Gwon