Lenovo Yoga Slim 7 Gen 8 14APU8 with AMD Ryzen 7 7840S immediately wakes up from suspend.
Brief summary of the problem:
Trying to suspend the system, it immediately wakes up again. This happens all the time, no exceptions, always same behavior. Did already try to block GPIO 8 with kernel parameters, disabled the EC wakeup, disabled all devices in /proc/acpi/wakeup, disabled /sys/bus/i2c/devices/i2c-IDEA5002:00/power/wakeup and /sys/bus/i2c/devices/i2c-SYNA2BA6:00/power/wakeup. Nothing helped so far.
Hardware description:
- amd_s2idle report: s2idle_report-2023-08-26.txt
System information:
- Arch Linux running with latest rc kernel - 6.5.0-rc7, but also happens on Linux Arch kernel 6.4.12-arch1-1
- Kernel version: Linux archlinux 6.5.0-rc7-1-git-00185-g28f20a19294d #1 (closed) SMP PREEMPT_DYNAMIC Sat, 26 Aug 2023 19:05:32 +0000 x86_64 GNU/Linux
How to reproduce the issue:
- Close the lid, systems wakes up immediately, screen goes on while lid is closed.
- Push the power button, screen goes black and after 1 second lock screen is shown again
- Debugging with pm-suspend, system goes into suspend but comes back immediately.
Attached files:
Activity
Please try to pick this change to see if it improves things.
Hi Mario, Thank you, but that didn't help. Is there anything else what I can do?
The weird thing is that I also have a Lenovo Yoga Slim 6 Gen8 (also 14APU8) with a Ryzen 7840U processor and that laptop does sleep with Arch Linux. Just guessing the Yoga Slim 7 also have these i2c "smart" amps. I already compiled a patch from Texas Instruments for these amps. Is it possible that these prevents suspend? Sound doesn't really bother me but I really want the laptop to suspend so that I don't have to shutdown all apps every time.
Here is the log with the patch in place. s2idle_report-2023-08-28.txt
I will test again with 6.5 final
Here is the full dump acpidump.txt
s2idle report on 6.5 final, still same behavior s2idle_report-2023-08-28.txt
Looks like it's this I2C-HID device:
Scope (_SB.I2CC) { Device (SHUB) { Name (_ADR, 0x00) // _ADR: Address Name (_HID, "ITE8350") // _HID: Hardware ID Name (_CID, "PNP0C50" /* HID Protocol Device (I2C bus) */) // _CID: Compatible ID Method (_CRS, 0, NotSerialized) // _CRS: Current Resource Settings { Name (SBUF, ResourceTemplate () { I2cSerialBusV2 (0x005C, ControllerInitiated, 0x00061A80, AddressingMode7Bit, "\\_SB.I2CC", 0x00, ResourceConsumer, , Exclusive, ) GpioInt (Level, ActiveLow, Exclusive, PullUp, 0x0000, "\\_SB.GPIO", 0x00, ResourceConsumer, , ) { // Pin list 0x0008 } }) Return (SBUF) /* \_SB_.I2CC.SHUB._CRS.SBUF */ }Can you experiment with unbinding it from
/sys/bus/i2c/drivers/i2c_hid_acpi?It seems like it's some kind of sensor hub, and it's causing a bunch of data that's not getting serviced properly.
I first unbind the ITE8350 with
echo "i2c-ITE8350:00" >unbindin/sys/bus/i2c/drivers/i2c_hid_acpi, suspend still doesn't work. I unbinded all i2c hid devices (also the trackpad) and the suspend still doesn't work, here is the s2idle report with all unbinded i2c devices.s2idle_report-2023-08-28-unbind.txt
Edit: I put the wrong command here in the message, it was incorrectly noted that I unbinded the i2c-ITE8350:00 device, but it was
echo "i2c-ITE8350:00" >unbindEdited by Marcus A2023-08-28 21:43:16,757 DEBUG: #9 (closed)
Something is wrong here - why is your GPIO 9 masked and unserviced? Make sure you only unbind the problematic device on GPIO 8.
My mistake, the previous s2idle report was also with unbinded trackpad. Here is the s2idle report with only unbinded ITE8350, according the DSDT that is connected to GPIO 8.
2023-08-29 09:19:18,306 DEBUG: 2023-08-29T09:19:15,412255+02:00 ACPI: \_SB_.PCI0.GP19.XHC2: LPI: required min power state:D3hot current power state:D0 2023-08-29 09:19:18,306 DEBUG: 2023-08-29T09:19:15,412258+02:00 ACPI: \_SB_.PCI0.GP19.XHC2: LPI: Constraint not met; min power state:D3hot current power state:D0With that last log, Do you have anything plugged in over USB? Or anything related to USB disabled in BIOS?
No all tests are done without any peripherals or devices connected. I looked in BIOS and Always On USB is disabled, USB ports are disabled during low power states. There is no other configuration option for USB in the BIOS.
Don't know if does matter with s2idle, but XHC2 is already disabled on
/proc/acpi/wakeup.No all tests are done without any peripherals or devices connected. I looked in BIOS and Always On USB is disabled, USB ports are disabled during low power states. There is no other configuration option for USB in the BIOS.
If possible; can you reset everything to BIOS default settings and see if it helps? This would reset any hidden options too if something changed them.
Don't know if does matter with s2idle, but XHC2 is already disabled on
/proc/acpi/wakeup.OK so XHC2 is pointing to this device:
2023-08-29 09:19:10,632 DEBUG: 0000:c5:00.0 : Non-Essential Instrumentation Advanced Micro Devices, Inc. [AMD] [1022:14EC] : \_SB_.PCI0.GP19.XHC2Can you see if anything is actually binding to that with
lspci -vv?A bit of a long shot; but can you try
pcie_port_pm=offon the kernel command line?
Have reset all values in BIOS/UEFI settings to defaults. And tried with
pcie_port_pm=offas kernel parameter, still no luck. Here is the s2idle report (with unbinded GPIO 8) s2idle_report-2023-08-29-pcie-port-pm-off.txt I saw that GPIO 9 was active, so I unbinded the trackpad also and tested again, still not working, here is the reports2idle-2023-08-29-unbinded-gpio9.txtThis is the PCIe device:
c4:00.0 Non-Essential Instrumentation [1300]: Advanced Micro Devices, Inc. [AMD] Device 14ec Subsystem: Advanced Micro Devices, Inc. [AMD] Device 14ec Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- IOMMU group: 21 Capabilities: [48] Vendor Specific Information: Len=08 <?> Capabilities: [50] Power Management version 3 Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot+,D3cold+) Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME- Capabilities: [64] Express (v2) Endpoint, MSI 00 DevCap: MaxPayload 256 bytes, PhantFunc 0, Latency L0s <4us, L1 unlimited ExtTag+ AttnBtn- AttnInd- PwrInd- RBE+ FLReset- SlotPowerLimit 0W DevCtl: CorrErr- NonFatalErr- FatalErr- UnsupReq- RlxdOrd+ ExtTag+ PhantFunc- AuxPwr- NoSnoop+ MaxPayload 128 bytes, MaxReadReq 512 bytes DevSta: CorrErr- NonFatalErr- FatalErr- UnsupReq- AuxPwr- TransPend- LnkCap: Port #0, Speed 16GT/s, Width x16, ASPM L0s L1, Exit Latency L0s <64ns, L1 <1us ClockPM- Surprise- LLActRep- BwNot- ASPMOptComp+ LnkCtl: ASPM Disabled; RCB 64 bytes, Disabled- CommClk+ ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt- LnkSta: Speed 16GT/s, Width x16 TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt- DevCap2: Completion Timeout: Range ABCD, TimeoutDis+ NROPrPrP- LTR- 10BitTagComp+ 10BitTagReq- OBFF Not Supported, ExtFmt+ EETLPPrefix+, MaxEETLPPrefixes 1 EmergencyPowerReduction Not Supported, EmergencyPowerReductionInit- FRS- TPHComp- ExtTPHComp- DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis- LTR- 10BitTagReq- OBFF Disabled, AtomicOpsCtl: ReqEn- LnkCap2: Supported Link Speeds: 2.5-16GT/s, Crosslink- Retimer+ 2Retimers+ DRS- LnkCtl2: Target Link Speed: 16GT/s, EnterCompliance- SpeedDis- Transmit Margin: Normal Operating Range, EnterModifiedCompliance- ComplianceSOS- Compliance Preset/De-emphasis: -6dB de-emphasis, 0dB preshoot LnkSta2: Current De-emphasis Level: -3.5dB, EqualizationComplete+ EqualizationPhase1+ EqualizationPhase2+ EqualizationPhase3+ LinkEqualizationRequest- Retimer- 2Retimers- CrosslinkRes: unsupported Capabilities: [a0] MSI: Enable- Count=1/4 Maskable- 64bit+ Address: 0000000000000000 Data: 0000 Capabilities: [d0] SATA HBA v1.0 InCfgSpace Capabilities: [100 v1] Vendor Specific Information: ID=0001 Rev=1 Len=010 <?> Capabilities: [270 v1] Secondary PCI Express LnkCtl3: LnkEquIntrruptEn- PerformEqu- LaneErrStat: 0 Capabilities: [2a0 v1] Access Control Services ACSCap: SrcValid- TransBlk- ReqRedir- CmpltRedir- UpstreamFwd- EgressCtrl- DirectTrans- ACSCtl: SrcValid- TransBlk- ReqRedir- CmpltRedir- UpstreamFwd- EgressCtrl- DirectTrans- Capabilities: [410 v1] Physical Layer 16.0 GT/s <?> Capabilities: [450 v1] Lane Margining at the Receiver <?>I think it's a red herring. I just double checked a reference platform and have that same PCI endpoint and nothing binds to it. It's also got
power/controlason.Do you have Windows available as a dual boot or another NVME? I would like to see if Windows reproduces this problem as well. If you can please do a sleep cycle in Windows that is at least 30 minutes and then a sleep study.
Also in Windows - what is binding to that I2C device? Is there a separate driver? I wonder if we're missing somethign in Linux for this.
@mpearson any ideas on this one? Is this something you guys cover?
Sorry - this isn't in the Linux program
Too bad.
If it really is an issue with
ITE8350(as it seems) I hope we can figure it out before that device eventually shows up in a device that is in the Linux program.f there's a specific question I can try and track down an answer - but I don't know the FW or HW team for this platform unfortunately so no promises.
@mpearson I think the specific question is whether there is any other software that communicates with the
ITE8350device in Windows. If there is; what commands does it send, particularly at suspend time.My current suspicion is that there is some model/vendor specific command that tells it to start/stop reporting data that should be called at appropriate times.
@mpearson can you please ping again about any vendor commands to this stop it/start it? It seems to be at least one cause of this issue. We could just blacklist it from kernel side, but I don't know if it actually has a functional purpose that might ruin.
@mpearson with the things have transpired over the last few days let me summarize.
-
There are 3 problems. 2 of them are with I2C-HID devices. 1 is with modern standby entry ASL.
-
We have a kernel series that will avoid the two HID problems. I would still prefer that we have a way to talk to this device though and put it into the low power mode properly. Otherwise we're going to see the same thing again when there is an
IDEA5003device a few years from now that works similarly. -
There is still no solution to the NVME issue from the kernel side, and I don't think this is actually feasible.
Let me try to explain it to you so you can talk to your BIOS team about this.
During s2idle this function 0x07 is called during the Modern Standby entry step.
Case (0x07) { M000 (0x3E07) M460 (" Return (0x00)\n", 0x00, 0x00, 0x00, 0x00, 0x00, 0x00) \_SB.PCI0.LPC0.EC0.ECMO = 0x01 Notify (\_SB.PCI0.GPP8.NVME, 0x02) // Device Wake Return (0x00) }-
M000- this updates the postcode -
M460- this outputs to a serial log if present -
\_SB.PCI0.LPC0.EC0.ECMO = 0x0- notifies the EC -
Notify (\_SB.PCI0.GPP8.NVME, 0x02)sends a wake event to the NVME device
The SSDT patches that have been created in this thread remove the NVME wakeup notification and that fixes the 3rd issue. Without this every single entry into s2idle will send a wakeup event to the NVME and wake the system.
-
@mpearson any updates on this? The two kernel workarounds are picked up. All that's missing is the SSDT fix now.
I have also installed Windows on this machine, I had to check if the hardware is working correctly
I will do the sleep study and post the report here. On the I2C devices. The amplifiers for the speakers is also on the I2C bus, but that is not the ITE8350. I'm not really a Windows guy, so where do I check for the I2C devices? Is that also Device Manager?
I have also installed Windows on this machine, I had to check if the hardware is working correctly
Well that's good news that the hardware can work. It sounds like we probably have Linux not doing something right then.
pcie_port_pm=offis the big one that Windows and Linux do differently.I will do the sleep study and post the report here.
OK.
On the I2C devices. The amplifiers for the speakers is also on the I2C bus, but that is not the ITE8350.
HDA bus, and then from HDA to I2S, no?
I'm not really a Windows guy, so where do I check for the I2C devices? Is that also Device Manager?
Yeah it should be in device manager. What you can do is start out by picking the mouse
Then switch to by connection.
Then it will swap around with the I2C stuff picked. A local system of mine has this:
If you can find the device that corresponds to that ACPI device maybe we can better understand this.
HDA bus, and then from HDA to I2S, no?
About the speakers amplifiers. These are amplifiers that are connected to the I2C bus and HDA. They are not controlled through the HDA codec on I2S bus. For this laptop (and others) this patch is pending. The firmware loading and initialization of the amplifiers happens on the I2C bus.
On my previous laptop (Lenovo Legion 7 16ACHg6) as one of the first Lenovo laptops that had this construction (with Cirrus Logic amps). The devs at Cirrus Logic split their ASoC driver so that the drivers could be reused on I2C/HDA. I don't think that this will prevent the laptop to suspend because on my previous laptop I had no issues with suspend without loading the amp drivers, but as said before. This Yoga Slim is the first laptop that I own that only supports s2idle suspend and not S3 so it might be different.
Has nothing to do with this issue and offtopic, but check this thread on Lenovo Community https://forums.lenovo.com/t5/Ubuntu/Ubuntu-and-legion-pro-7-16IRX8H-audio-issues/m-p/5210709 . It's another laptop but they link to the firmwares and linux patches. I tried some patches and loaded the firmware. Very loud buzz on boot and the speakers was kind of hit and miss. For now I just wait the patches and firmwares land in mainline. I do have some sound (only top tweeters) that is enough for notifications :-)
Edited by Marcus A
This is the sleep sdtudy report from Windows sleepstudy-report.html
The ACPI\ITE8350\1 device in Windows (ACPI\ITE8350, BIOS device name: _SB.I2CC.SHUB) has a Microsoft driver from 21-4-2009 with the INF-name SensorsHidClassDriver.inf, looks like a generic driver.
The other I2C device (the speaker amps) has ACPI\TIAS2781\0 as path. (ACPI\TIAS2781, BIOS device name: _SB.I2CD.AMP0) has drivers from Texas Instruments with the name TI Smart Amplifier Driver for Speakers.
Screenshot of devices:
Is it possible to use a patched DSDT to do some try-and-error to exclude these devices, or wouldn't work that because the hardware will trigger a wakeup?
edit: mentioned wrong driver of the HID sensors. edit2: updated screenshot
Edited by Marcus AMay be useless information but I took my Yoga Slim 6 gen 8 (with AMD Phoenix 7840U APU), that laptop has an ITE8353 sensor hub device on _SB.I2CD.SHUB. That laptop did suspend on regular kernel. I did some Linux testing and it did what it should do so was actually surprised that this Slim 7 didn't work.
The ACPI\ITE8350\1 device in Windows (ACPI\ITE8350, BIOS device name: _SB.I2CC.SHUB) has a Microsoft driver from 21-4-2009 with the INF-name SensorsHidClassDriver.inf, looks like a generic driver.
Yeah this shows up in your other sleep study too:
| Instance Path | | ACPI\ITE8350\1 | |---------------|--|----------------| | Service Name | | hidi2c | | Unique ID | | \_SB.I2CC.SHUB |Is it possible to use a patched DSDT to do some try-and-error to exclude these devices, or wouldn't work that because the hardware will trigger a wakeup?
What we're trying to rule out here is anything that triggers an interrupt that's "unserviced". Unserviced interrupts before suspend prevent getting into the deepest state, and interrupts while in suspend will cause the system to wake. I don't think ruling it out will help as it would behave like an unserviced interrupt. You're not going to do any harm with this experiment, worst that happens is it doesn't help.
May be useless information but I took my Yoga Slim 6 gen 8 (with AMD Phoenix 7840U APU), that laptop has an ITE8353 sensor hub device on _SB.I2CD.SHUB. That laptop did suspend on regular kernel. I did some Linux testing and it did what it should do so was actually surprised that this Slim 7 didn't work.
On the presumption that this issue is caused by that I2C device and Linux not handling it properly, I think the next debugging step is likely a little bit out of your reach. It would be connecting a logic analyzer to the I2C bus and capturing a trace from Windows and Linux while attempting to enter suspend. Then we could see if there is a sequence of events that the Windows HID-I2C driver is responding differently than the linux hid-i2c driver does.
As it's production hardware, there probably isn't a header to connect the logic analyzer to, so it would also mean soldering some jumper cables to the correct probe points.
If I'm right this is out of reach for you is it set to wakeup in sysfs (
power/wakeup)? If so, can you leave it bound and turn that off? This will let the hid core calli2c_hid_core_power_down. Maybe this helps. The i2c-hid core does try to put it to sleep viai2c_hid_core_suspendalready.Maybe @bentiss has some other ideas from the software side what could be missing from hid-i2c that at suspend this device is triggering the GPIO ATTN pin.
But if the same exact I2C hub is in your other Phoenix laptop and working properly we might be barking up the wrong tree. Do you know what's different between these two models?
What we're trying to rule out here is anything that triggers an interrupt that's "unserviced". Unserviced interrupts before suspend prevent getting into the deepest state, and interrupts while in suspend will cause the system to wake. I don't think ruling it out will help as it would behave like an unserviced interrupt. You're not going to do any harm with this experiment, worst that happens is it doesn't help.
Check, I got the point.
On the presumption that this issue is caused by that I2C device and Linux not handling it properly, I think the next debugging step is likely a little bit out of your reach. It would be connecting a logic analyzer to the I2C bus and capturing a trace from Windows and Linux while attempting to enter suspend. Then we could see if there is a sequence of events that the Windows HID-I2C driver is responding differently than the linux hid-i2c driver does. As it's production hardware, there probably isn't a header to connect the logic analyzer to, so it would also mean soldering some jumper cables to the correct probe points. Indeed out of reach sadly.
If I'm right this is out of reach for you is it set to wakeup in sysfs (
power/wakeup)? If so, can you leave it bound and turn that off? This will let the hid core calli2c_hid_core_power_down. Maybe this helps. The i2c-hid core does try to put it to sleep viai2c_hid_core_suspendalready.I'm in
/sys/devices/LNXSYSTM:00/LNXSYBUS:00/AMDI0010:02/ITE8350:00/wakeup/wakeup50and have these optionsactive_count device expire_count max_time_ms prevent_suspend_time_ms total_time_ms wakeup_count active_time_ms event_count last_change_ms name subsystem ueventand the power in
/sys/devices/LNXSYSTM:00/LNXSYBUS:00/AMDI0010:02/ITE8350:00/powerhasautosuspend_delay_ms control runtime_active_time runtime_status runtime_suspended_timedon't really know what to control at this moment. Do you have an idea if you see this?
But if the same exact I2C hub is in your other Phoenix laptop and working properly we might be barking up the wrong tree. Do you know what's different between these two models?
I found out that this (Slim 7 with 7840S) is using ITE8350 and the other one (Slim 6 with 7840U) is using ITE8353, it is an another chip, also other dimensions but according the ITE site they have similar functionality, but also looks that the information is not complete. I have to look at the (chinese) datasheet to figure it out how they are connected etc...
Edited by Marcus Adon't really know what to control at this moment. Do you have an idea if you see this?
Try
/sys/bus/i2c/drivers/i2c_hid_acpi/$(NODE)/power/wakeupI found out that this (Slim 7 with 7840S) is using ITE8350 and the other one (Slim 6 with 7840U) is using ITE8353, it is an another chip, also other dimensions but according the ITE site they have similar functionality, but also looks that the information is not complete. I have to look at the (chinese) datasheet to figure it out how they are connected etc...
Got it; so they might actually be working slightly differently and have different driver expectations then too.
It looks like the same power folder as above.
/sys/bus/i2c/drivers/i2c_hid_acpi/i2c-ITE8350:00/power [root@slim7 power]# ls autosuspend_delay_ms control runtime_active_time runtime_status runtime_suspended_timeThere is no wakeup control node in this sysfs path.
Could we monkey patch the driver module from the kernel sources? Was just trying
rmmod i2c_hid_acpibut that didn't work either.I finally got access to AMD CBS and PBS settings, I tried different S0ix settings. There is also an option S0i3 with workaround but that doesn't seems to work either. There are also I2C settings. Is there maybe a settings what I can change to possibly to make it work? I tried S3 suspend, but Linux doesn't see the 'deep' option in
/sys/power/mem_sleep, I guess this is due missing DSDT entries....There is no wakeup control node in this sysfs path. Could we monkey patch the driver module from the kernel sources? Was just trying
rmmod i2c_hid_acpibut that didn't work either.In that case it sounds like the device doesn't support wakeup, and is instead being powered down. Which makes me wonder if the powering down is where the issue is. If that GPIO polarity is triggering by the pull up/pull down when the device goes into reset? We could try to make a quirk to skip the power down and see if it helps.
I finally got access to AMD CBS and PBS settings
How?
I tried different S0ix settings. There is also an option S0i3 with workaround but that doesn't seems to work either. There are also I2C settings. Is there maybe a settings what I can change to possibly to make it work?
If you have access to the I2C settings, you can try to turn off that I2C controller. I suppose it's I2C3.
I tried S3 suspend, but Linux doesn't see the 'deep' option in
/sys/power/mem_sleep, I guess this is due missing DSDT entries....Phoenix mobile platforms don't support S3. It's just some crufty menu items. I wouldn't expect this to work.
I used this to access AMD PBS https://github.com/DavidS95/Smokeless_UMAF.
If you have access to the I2C settings, you can try to turn off that I2C controller. I suppose it's I2C3. I don't see any way to disable I2C controller sadly.
Here are the configuration options, I already disabled the I2C mux. And in MP2 settings disabled all the sensors (Acceleration, Magnet, SRA, Light and Proximity), tried to enable Sensor Fusion User Mode Driver
Still no luck.
Phoenix mobile platforms don't support S3. It's just some crufty menu items. I wouldn't expect this to work.
Oh ok, the system had indeed some issues with S3 setting.
Edited by Marcus AI used this to access AMD PBS https://github.com/DavidS95/Smokeless_UMAF.
Got it.
Here are the configuration options, I already disabled the I2C mux. And in MP2 settings disabled all the sensors (Acceleration, Magnet, SRA, Light and Proximity), tried to enable Sensor Fusion User Mode Driver
You don't want to be touching any of those. Make sure you return anything you changed back to defaults so you don't cause futher problems. What you're looking for is this sub menu.
AMD CBS -> FCH Common Options -> I3C/I2C Configuration Options -> I3C/I2C 3 EnableCheck, reverted to defaults. It wasn't the I2C 3 controller, I disabled the I2C 2 controller and the ITE8530 device is now gone. But still no luck
Here is the s2idle report without that device. At least no GPIO active messages s2idle_report-2023-08-30.txt
Don't know if it may be interesting, I do have some ACPI errors in the kernel log. Here is my dmesg grepped on ACPI. acpi-boot-dmesg
Error (bug) like
[ 0.240285] ACPI BIOS Error (bug): Failure creating named object [\_SB.MHSP], AE_ALREADY_EXISTS (20230331/dswload2-326)Here is the s2idle report without that device. At least no GPIO active messages s2idle_report-2023-08-30.txt
2023-08-30 22:26:42,587 DEBUG: #8 🔥 😷| ↓| level| | | | | | |input ↓| |0x10040b00Yeah; but you can see in the logs that GPIO8 is now an unserviced interrupt (
🔥)
😷). I think that means with it physically there we do need the driver to be using it.So unfortunately this isn't going to work to disable it in CBS :/
Error (bug) like
[ 0.240285] ACPI BIOS Error (bug): Failure creating named object [\_SB.MHSP], AE_ALREADY_EXISTS (20230331/dswload2-326)This one I'm not worried about.
[ 5.940489] ACPI Error: No handler for Region [ECSI] (000000005108f85d) [EmbeddedControl] (20230331/evregion-130) [ 5.942195] ACPI Error: Region EmbeddedControl (ID=3) has no handler (20230331/exfldio-261) [ 5.943134] ACPI Error: Aborting method \_SB.UBTC.ECRD due to previous error (AE_NOT_EXIST) (20230331/psparse-529) [ 5.944389] ACPI Error: Aborting method \_SB.UBTC._DSM due to previous error (AE_NOT_EXIST) (20230331/psparse-529) [ 5.945267] ACPI: \_SB_.UBTC: failed to evaluate _DSM c298836f-a47c-e411-ad36-631042b5008f (0x6)These however are concerning. That may mean that the PD controller notifications aren't working and maybe the EC is what is triggering this issue. Have you already tried
acpi.ec_no_wakeup=1?Yeah; but you can see in the logs that GPIO8 is now an unserviced interrupt (
🔥)😷). I think that means with it physically there we do need the driver to be using it. So unfortunately this isn't going to work to disable it in CBS :/Bummer, best option is to wait for I2C HID developers (Benjamin?) to get this sorted I guess? As I understand correctly, this device is connected to the I2C bus and GPIO of the APU? And the GPIO pin is connected/configured as interrupt?
These however are concerning. That may mean that the PD controller notifications aren't working and maybe the EC is what is triggering this issue. Have you already tried
acpi.ec_no_wakeup=1?I was running with kernel parameter
acpi.ec_no_wakeup=1before I opened this issue. Still running with this parameter.Edited by Marcus ABummer, best option is to wait for I2C HID developers (Benjamin?) to get this sorted I guess? As I understand correctly, this device is connected to the I2C bus and GPIO of the APU? And the GPIO pin is connected/configured as interrupt?
It's connected to the I2C bus, but inherently I2C doesn't have a way to trigger an interrupt "in-band". So the way interrupts are triggered is through a GPIO (Sometimes called the "attention pin").
Unfortunately right now I don't really understand what is wrong with the i2c-hid kernel driver and your device. That's why I'm hoping @bentiss has more ideas. It shouldn't be triggering the GPIO; especially when it's supposed to be asleep. The only other hack I can think is to skip the power off step with a quirk. Not sure how safe that is though.
I was running with kernel parameter
acpi.ec_no_wakeup=1before I opened this issue. Still running with this parameter.Oh you've been using that already? What exactly happens without it? Everything look very similar?
It's connected to the I2C bus, but inherently I2C doesn't have a way to trigger an interrupt "in-band". So the way interrupts are triggered is through a GPIO (Sometimes called the "attention pin").
Check, I now understand better what happens.
Unfortunately right now I don't really understand what is wrong with the i2c-hid kernel driver and your device. That's why I'm hoping @bentiss has more ideas. It shouldn't be triggering the GPIO; especially when it's supposed to be asleep. The only other hack I can think is to skip the power off step with a quirk. Not sure how safe that is though.
As long it doesn't break things physically I don't mind to experiment.
Oh you've been using that already? What exactly happens without it? Everything look very similar?
Most of the time I try with and without. No difference on behavior. Now booted without the parameter (and disabled I2C 2 controller). GPIO 8 is still masked and unserviced interrupts
2023-08-30 23:19:13,859 DEBUG: #8 🔥 😷| ↓| level| | | | | | |input ↓| |0x10040b00Edited by Marcus AAbout the GPIO pins and the ITE8530 Sensor Hub. I booted to Windows with the disabled I2C controller. The Sensor Hub was not listed in device manager. But the laptop does suspend. I guess that this Sensor Hub is not the cause, but I might be wrong.
Sleep study after very short suspend session sleepstudy-report-no-ite.html
And I do have some gpio initialization errors on Linux, it might be interesting.
[ 0.816143] amd_gpio AMDI0030:00: Invalid config param 0014 [ 0.816177] amd_gpio AMDI0030:00: Invalid config param 0014 [ 0.816197] amd_gpio AMDI0030:00: Invalid config param 0014 [ 0.816220] amd_gpio AMDI0030:00: Invalid config param 0014 [ 0.816240] amd_gpio AMDI0030:00: Invalid config param 0014 [ 0.816260] amd_gpio AMDI0030:00: Invalid config param 0014 [ 6.318855] amd_gpio AMDI0030:00: Invalid config param 0014 [ 6.320966] amd_gpio AMDI0030:00: Invalid config param 0014 [ 6.322379] amd_gpio AMDI0030:00: Invalid config param 0014 [ 6.324086] amd_gpio AMDI0030:00: Invalid config param 0001Edited by Marcus ASleep study after very short suspend session sleepstudy-report-no-ite.html
Ah, but notice; Windows fails to get to HW sleep now too. This strengthens the resolve of my statement that this is something wrong with the handling for this I2C device that is causing it to trigger the GPIO.
And I do have some gpio initialization errors on Linux, it might be interesting.
Those are red herrings and just loud, the fix for them is coming in 6.6-rc1 to make them quiet. It's CC to stable, so future stable kernels will quiet down too.
Unfortunately right now I don't really understand what is wrong with the i2c-hid kernel driver and your device. That's why I'm hoping @bentiss has more ideas. It shouldn't be triggering the GPIO; especially when it's supposed to be asleep. The only other hack I can think is to skip the power off step with a quirk. Not sure how safe that is though.
FWIW I really don't have the time to work on that right now. And IIRC, now, i2c-hid delegates all of the handling of ACPI/GPIO and IRQs to I2C and ACPI, which means I don't have the slightest idea of what is going on.
Maybe @jwrdegoede will know a little bit more why that GPIO is not served as an IRQ?
FWIW I really don't have the time to work on that right now. And IIRC, now, i2c-hid delegates all of the handling of ACPI/GPIO and IRQs to I2C and ACPI, which means I don't have the slightest idea of what is going on. Maybe @jwrdegoede will know a little bit more why that GPIO is not served as an IRQ?
To me it doesn't seem to be an IRQ handling problem; the kernel is doing exactly what it should when the GPIO is triggered. It wakes up the system immediately. If we try to ignore that wakeup in the variety of ways tried (disabling in BIOS, ignoring in kernel, etc) then the GPIO is unserviced and you can't get to the deepest state.
I think the problem is the I2C device misbehaving (or depending on your perspective behaving exactly as it is intended for the sequence of commands sent).
What if the fact that it's not usable as a wakeup source means that turning it off causes a problem? If that theory is right, then this patch might help.
diff --git a/drivers/hid/i2c-hid/i2c-hid-core.c b/drivers/hid/i2c-hid/i2c-hid-core.c index efbba0465eef..438aa3af7a50 100644 --- a/drivers/hid/i2c-hid/i2c-hid-core.c +++ b/drivers/hid/i2c-hid/i2c-hid-core.c @@ -1102,7 +1102,7 @@ static int i2c_hid_core_suspend(struct device *dev) disable_irq(client->irq); - if (!device_may_wakeup(&client->dev)) + if (dev->power.can_wakeup && !device_may_wakeup(&client->dev)) i2c_hid_core_power_down(ihid); return 0;
Still no luck with the patch. I really hoped that it will do something, bummer.
Here are some s2idle reports. Just starting with 6.5.0 with above patch: s2idle_report-2023-08-31.txt
Same as above but with unbinded device: s2idle_report-2023-08-31-unbind.txt
And with acpi.ec_no_wakeup=1 and binded device: s2idle_report-2023-08-31-ec-nowakeup.txt
Still no luck with the patch. I really hoped that it will do something, bummer.
That's too bad.
Here are some s2idle reports
Nothing new stands out in these
I don't really know how to go any further with this issue. In Windows given it's using the "generic" driver, I am wondering if maybe there is a service or another "filter driver" that is communicating with this device and sending a device specific command to tell it to stop reporting data or something.
I found that Windows does have a built-in trace report that it can create for HID I2C transactions. I have ZERO experience with this, but maybe you can experiment with it running across a suspend cycle and see if you can identify the traffic with the Windows Performance Analyzer.
I don't really know how to go any further with this issue. In Windows given it's using the "generic" driver, I am wondering if maybe there is a service or another "filter driver" that is communicating with this device and sending a device specific command to tell it to stop reporting data or something.
I found that Windows does have a built-in trace report that it can create for HID I2C transactions. I have ZERO experience with this, but maybe you can experiment with it running across a suspend cycle and see if you can identify the traffic with the Windows Performance Analyzer.
I also don't have any experience with it, my Windows knowledge is very basic. But it's worth the try. I'll read the docs and try to get a trace.
I saw a few Yoga quirks in the
i2c-hid-core.cfile, also with I2C HID device quirks on ITE devices, may that be worth experimenting?I saw a few Yoga quirks in the
i2c-hid-core.cfile, also with I2C HID device quirks on ITE devices, may that be worth experimenting?More likely this is something special for
drivers/hid/hid-ite.c. But right now we don't know what about it is special. That's what a logic analyzer or software trace will hopefully pull out.I got a trace (i think), but still looking how to read them. Installed Windows Driver Kit (WDK) that contains traceview, but I think I'm missing some definition files (like a PDB file??) to match the events.
Maybe someone knows how to read the events. I'll continue to get something usefull out of this.
Edited by Marcus AYeah I think you need PDB symbols from the Microsoft symbol server
This seems like it might be the best way to do it: https://reverseengineering.stackexchange.com/questions/26599/where-can-i-get-pdb-files-for-windows-os-components
@oxar any luck with interpreting the ETL trace?
I went on the DSDT patching trying to get GPIO 8 silenced. I think I succeeded. I changed the Pull direction of the pin so it won't work if the devices is unbind. But I might be wrong.
Suspend behavior is still the same, fans do spin down (that happened all the other times too) but wakes immediately.
Here is a s2idle report s2idle_report-2023-09-01.txt
Did some more testing with another laptop mentioned before. Yoga Slim 6 with 7840U (also Phoenix). Here is the s2idle report from that laptop (10 min run), we see GPIO pin 84 active, that GPIO is connected to the ITE8353 controller. What I also found out is that the device ID's are the same for the ITE controller/sensor hub for the both laptops. Only different name in DSDT. But this laptop reaches hardware sleep with an active GPIO.
Is it possible it could be something else what is blocking the sleep on the Yoga Slim 7.
s2idle report Slim 6: s2idle_report-2023-09-02.txt DSDT Slim 6: dsdt.dsl
@superm1 Is the above information something interesting for you or am I on a path with dead end?
@superm1 Is the above information something interesting for you or am I on a path with dead end?
I think it's quite an interesting result. The GPIO may be a red herring then.
Something I'll point out to you is that the slim 6 has a newer SMC firmware. I don't have insight into what is changed between those firmware versions, I can just point out the difference.
Slim 6:
SMC feature version: 0, program: 4, firmware version: 0x044c0fcd (76.15.205)Slim 7:
SMC feature version: 0, program: 4, firmware version: 0x044c0b9f (76.11.159)This result tells me that this is very likely a platform firmware bug, but without some specialized equipment unfortunately I don't think I'll be able to debug any further. I'd suggest keeping up with the F/W upgrades that Lenovo posts until you have something that works.
Something I'll point out to you is that the slim 6 has a newer SMC firmware. I don't have insight into what is changed between those firmware versions, I can just point out the difference.
Ah check, I also saw that difference. For now still no BIOS update on the support site. I will try contact Lenovo again and hope that an update will be released soon. If it fixes the issue I will report it back here.
Thank you very much for all your efforts. Very pleased (and somewhat surprised
Small update, Lenovo did release a new firmware update, unfortunately without SMC firmware update. As expected the issue is still there.
Edited by Marcus AHi there,
I've been seeing a very similar issue on a Lenovo Ideapad 5 14ALC05 Ryzen 5 5500U running Void Linux.
This issue did not occur at the start of August but began happening at the start of September and has been happening since. I do roughly weekly updates and am currently on Linux 6.5.5_1 (this is the mainline kernel)
The weird quirk that the first sleep always works without fail, then every subsequent sleep wakes immediately.
I've taken similar troubleshooting steps to you with no avail. I am however looking to achieve s3 rather than s2idle.
Booting into my LTS (6.3.13_1) kernel that I keep around for these special occasions restores sleep functionality as expected.
If it's useful I can collect some logs although I'll need some instructions to gather useful data.
Thanks!
Edited by Caleb AllenHave opened #2978, thanks!
mentioned in issue #2883 (closed)
marked #2883 (closed) as a duplicate of this issue
