Hi Kim, On Sun, 30 Jan 2022 22:33:43 +0100, Kim Nilsson wrote: > I've recently been doing some suspend/resume testing related to an > s2idle bug in amdgpu > (https://gitlab.freedesktop.org/drm/amd/-/issues/1879) and I've come > across some problems with C-states. Preliminary remark: having read this bug report and the long list of kernel parameters you need to make it somewhat work, it seems that your system is having a lot more problems than just i2c-i801 hypothetically breaking ACPI. Kernel command line parameters are meant as ways to workaround or debug issues, you shouldn't need them for regular operation (in most cases). So for each command line parameter you need to pass, you should report to the respective kernel development list with enough details to have the problem investigated and fixed. It is likely that the solution which will make it no longer mandatory to pass the command line parameter will actually make the situation not the same, but better than what you have now. > After resuming from s2idle, Pkg(HW) will no longer enter any state C2 or > deeper. Suspending to s3 would not trigger this issue on 5.16.2, but > after trying out 5.16.4 I'm facing a similar problem where Pkg(HW) will > rarely if ever go deeper than C3. Now, the reason I am contacting you is > because I was playing around today and found that unloading i2c-i801 > seems to fix the issue. I'm no expert in power management, but to be honest I can't make much sense from the paragraph above. 1* How do you "resume from s2idle"? My understanding is that s2idle aka S0 is just the normal power state where the kernel tries to let the hardware go to low power run-time mode when possible. You would get in and out of that state all the time when using the laptop. So please explain what you mean exactly. Also my understanding is that s2idle is not really related to ACPI. 2* What does "Pkg(HW)" mean? 3* How do you check the C states? 4* Which issue exactly does unloading i2c-i801 fix? The s2idle one, the S3 one, both? 5* On which kernel did you try unloading the i2c-i801 module with the results above? Can you reproduce this behavior with other kernel versions? 6* You claim this is a regression, which implies this has worked at some point in the past. Which kernel did you test where having the i2c-i801 module loaded or not made no difference ? 7* Are you actually using the i2c-i801 module for anything? As a summary, we will need a lot more details in order to be able to investigate your report. Specifically, we need accurate data about what you tested and what were the results, and enough data point to actually draw conclusions. Something along the lines of: "I do <this> on kernel <x.y.z> with boot parameters <foo> <bar>, and <that> happens. If I do the same on kernel <x.a.b> with the same parameters, <something else> happens. Ideally you would narrow it to just one single change (kernel version, boot parameter, i2c-i801 being loaded or not...) so that we have somewhere to start investigating. > # CPU: Intel(R) Core(TM) i7-8665U CPU @ 1.90GHz > # GPU: Intel Corporation WhiskeyLake-U GT2 [UHD Graphics 620], Advanced > Micro Devices, Inc. [AMD/ATI] Lexa XT [Radeon PRO WX 3100] > # 00:15.0 Serial bus controller: Intel Corporation Cannon Point-LP > Serial IO I2C Controller #0 (rev 30) > # 00:15.1 Serial bus controller: Intel Corporation Cannon Point-LP > Serial IO I2C Controller #1 (rev 300:19.0 Serial bus controller: Intel > Corporation Cannon Point-LP Serial IO I2C Host Controller (rev 30) The line above is clearly corrupted. When reporting PCI device information, please use option -nn of lspci, so that the device IDs are included. This makes it easier to investigate. Either way, none of the devices listed are driven by i2c-i801. The device you are looking for would be named "Cannon Point-LP SMBus Controller". > dmesg output when loading the module after an unload: > > [ 1002.961091] i801_smbus 0000:00:1f.4: SPD Write Disable is set > [ 1002.961171] i801_smbus 0000:00:1f.4: SMBus using PCI interrupt > [ 1002.961321] iTCO_wdt iTCO_wdt: unable to reset NO_REBOOT flag, device > disabled by hardware/BIOS > [ 1002.975399] i801_smbus 0000:00:1f.4: Accelerometer lis3lv02d is > present on SMBus but its address is unknown, skipping registration > [ 1002.975406] i2c i2c-10: 2/2 memory slots populated (from DMI) > [ 1002.976713] ee1004 10-0050: 512 byte EE1004-compliant SPD EEPROM, > read-only > [ 1002.976808] i2c i2c-10: Successfully instantiated SPD at 0x50 Is this complete? The last 2 lines should repeat for the second memory slot. Anyway, none of these message show any ACPI-related problem. -- Jean Delvare SUSE L3 Support
