LE13-nightly / x86-Generic : Attempting resume from S3 sleep locks up system

    On an Odroid H4 (Intel N97 Alder Lake x86 SBC) attempting resume from S3 sleep now results in a locked up state where system powers on but does not progress to restoration of OS & Kodi state.

    It's a hard lock-up - doesn't respond to the reset button and requires a 4-second press on PWR to force hard power off. System does a normal cold boot at next power-on.

    Has something fundamental changed in LE13 with the resume/sleep management ? (Maybe kernel version or something in the Linux scaffolding of LE's x86 build ?)


    For further information, state & meaning of the 5 onboard diagnostic LEDs:

    Code
    - Red (PWR) – Solid light when DC power is supplied
– Blue (left, SLEEP) – turns off only when the system enters into suspend mode
– Blue (right, PMIC) – turns on only when the major power rails are working
– Amber (SATA) – Flashes when SATA data transfers
– Green (NVMe) – Flashes when NVMe data transfers

    In normal powered-down state with PSU still connected:

    \ Red \ - - - - \ - - - - \ - - - - \ - - - - \

    In regular powered on running state (Amber & Green flash as disk I/O happens) :

    \ Red \ Blue-L \ Blue-R \ - - - - \ - - - - \

    After a failed resume the system LEDs show:

    \ Red \ Blue-L \ - - - - \ Amber \ - - - - \


    The presence of the solid Amber LED (SATA) seems slightly anomalous - there are no SATA devices present, the only disk in the system is an M.2 NVME

    In normal operation and with prior LE12 builds the Green NVME was the only I/O LED that flashes at any point.

    Grasping at straws ... Perhaps something is making a faulty assumption that a SATA device should be present, and is hanging the resume process as it waits for a response that will never come ?


    I am somewhat stuck at this point as I don't have a further way to diagnose the resume process - logging stops in what looks like a normal manner after S3 sleep is triggered and proceeds to shutdown state. Given that I have to hard power-off and cold boot after this point there isn't any logging available for the S3 resume sequence, just the kodi.old.log to the point of sleep shutdown.

    Any pointers would be appreciated.

    log-2025-11-04-19.28.03.zip

    Edited once, last by kurai (November 5, 2025 at 4:19 AM).

    TL;DR

    Weirdness with random USB <-> SATA adapter. Booting once with disk attached somehow reset/cleared the issue and it now sleeps/resumes as expected.

    Not worth anyone elses brainpower to dig deeper into root issue, so marked as solved.


    Finally got around to poking at this in a more organized way.

    The hardware that triggers the bug turns out to be a USB SATA adapter (JMicron JMS578 based).

    No onboard SATA sockets on this SBC, just NVME, so I use this to plug in an ancient spare SATA SSD to do occasional full disk image block-based backup snapshots with Clonezilla - more frequent when I'm futzing around with LE nightlies. I usually leave the adapter plugged in and only stick the SSD on the end when I want to trigger a backup.

    (Script detects SSD volume being mounted, runs efibootmgr --bootnext 3; to select the SSD at next boot instead of the default NVME device with LE on it, reboots, runs an automated Clonezilla session from the SSD, saves the backup locally to a dedicated partition on the SSD, then reboots again, once done, from the default NVME boot device, back into LE.)


    Aaaaaanyway - systematically going through the various bits of installed hardware, the hang on resume-after-sleep went away after unplugging/boot/replugging/boot of the JMicron SATA adapter (without and disk attached).

    Puzzling - I saw that lsusb / dmsg only listed the JMicron device when it had a disk attached. I unmounted the disk and unplugged, leaving USB adapter in place and rebooted ... and now the sleep resume test worked just fine, as it did with LE12.x stable.

    Huh.

    Now I can't recreate the hang condition.

    Maaaaybe there's only power running through the adapter's chipset when there's a SATA device attached, completing a circuit?

    Maaaaybe booting with a SATA disk attached reset/cleared some non-volatile state register in UEFI ?

    Maaaaybe some change to S3 sleep parameters/implementation was buried in the depths of one of the kernel releases ?

    Maaaaybe it's just ghosts ?

    /shrug


    This seems like a bizarre edge case of circumstances and hardware unlikely to ever affect anyone else, and ultimately not worth wasting any of the LibreELEC team's time on, so I'll close this and we can all move on with our lives :*