linux-kernel - Re: Suspend/resume failing due to SPD5118

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <4e0827d4-137f-465c-8af6-41cc68ddaa8b@roeck-us.net>
Date: Fri, 2 May 2025 17:14:51 -0700
From: Guenter Roeck <linux@...ck-us.net>
To: carlon.luca@...il.com
Cc: jdelvare@...e.com, linux-hwmon@...r.kernel.org,
 linux-kernel@...r.kernel.org, lucas.demarchi@...el.com
Subject: Re: Suspend/resume failing due to SPD5118

On 5/2/25 16:07, carlon.luca@...il.com wrote:
>> The timeout is observed when the resume code tries to write data back to the
>> spd5118 chip. It originates from the i2c controller driver, not from the spd5118
>> driver. I have no idea why the i2c controller would time out in this situation.
>> Presumably it should have been brought out of suspend by the time devices connected
>> to it are re-enabled, but I don't see any associated message in the log.
>>
>> I know that others have tested suspend/resume support with the driver and confirmed
>> that it works. It might help to enable debugging of the i2c controller driver if that
>> is possible. Other than that I have no idea what might cause this problem or how to
>> track it down.
> 
> Hi,
> 
> I recently bought a new machine, and trying to hibernate results in these messages
> from the kernel:
> 
> [  195.176483] PM: hibernation: hibernation entry
> [  195.200054] Filesystems sync: 0.005 seconds
> [  195.200760] Freezing user space processes
> [  195.203723] Freezing user space processes completed (elapsed 0.002 seconds)
> [  195.203732] OOM killer disabled.
> [  195.204506] PM: hibernation: Marking nosave pages: [mem 0x00000000-0x00000fff]
> [  195.204512] PM: hibernation: Marking nosave pages: [mem 0x0009f000-0x000fffff]
> [  195.204517] PM: hibernation: Marking nosave pages: [mem 0x4ee2f000-0x524fefff]
> [  195.204924] PM: hibernation: Marking nosave pages: [mem 0x8b93b000-0x8bb7bfff]
> [  195.204941] PM: hibernation: Marking nosave pages: [mem 0x8eedd000-0x8eeddfff]
> [  195.204943] PM: hibernation: Marking nosave pages: [mem 0x92fe3000-0x92fe3fff]
> [  195.204945] PM: hibernation: Marking nosave pages: [mem 0x944ff000-0x97ffefff]
> [  195.205340] PM: hibernation: Marking nosave pages: [mem 0x98000000-0xffffffff]
> [  195.210276] PM: hibernation: Basic memory bitmaps created
> [  195.212709] PM: hibernation: Preallocating image memory
> [  196.875538] PM: hibernation: Allocated 1013859 pages for snapshot
> [  196.875544] PM: hibernation: Allocated 4055436 kbytes in 1.66 seconds (2443.03 MB/s)
> [  196.875547] Freezing remaining freezable tasks
> [  196.876843] Freezing remaining freezable tasks completed (elapsed 0.001 seconds)
> [  197.559071] printk: Suspending console(s) (use no_console_suspend to debug)
> [  197.771716] spd5118 1-0051: PM: dpm_run_callback(): spd5118_suspend [spd5118] returns -110
> [  197.771734] spd5118 1-0051: PM: failed to freeze async: error -110
> [  197.979717] spd5118 1-0050: PM: dpm_run_callback(): spd5118_suspend [spd5118] returns -110
> [  197.979739] spd5118 1-0050: PM: failed to freeze async: error -110
> [  199.028103] PM: hibernation: Basic memory bitmaps freed
> [  199.028080] mei_pxp i915.mei-gsc.768-fbf6fcf1-96cf-4e2e-a6a6-1bab8cbe36b1: bound 0000:03:00.0 (ops i915_pxp_tee_component_ops [i915])
> [  199.029101] OOM killer enabled.
> [  199.029104] Restarting tasks ... done.
> [  199.088935] efivarfs: resyncing variable state
> [  199.326219] PM: hibernation: hibernation exit
> 
> the operation aborts and I cannot hibernate the machine. I fixed the problem by
> blacklisting the driver spd5118.
> 
> I see that the reported problem was in the resume operation, mine is in the suspend
> operation, so I'm not sure if this is related and if the logs can help.
> 

That must be something different. If normal operation works (the sensors command
shows correct temperatures if the driver is loaded, and it is possible to read the
SPD eeprom), maybe the I2C controller is already suspended when the spd5118 driver's
suspend function is called. I don't know how that can happen, though. I would expect
that I2C controllers are only suspended after all its connected devices are suspended.

 From the context it looks like the "sensors" command was never executed. To get
another data point, it would help if you could load the driver, run the "sensors"
command, and then try to hibernate.

Thanks,
Guenter