System returns to OEM boot logo, then hangs upon resume

[lool]

Hi!

NB: I'm just getting familiar with pm-graph tools, I might be using it wrong

I'm running pm-graph from a git checkout (I didn't make install) on a Dell XPS 13 7390 2-in-1 running Ubuntu Desktop 22.04 and connected to WiFi. This particular model is not optimized for Linux but works mostly fine nowadays. I'm running this command:
sudo ./sleepgraph.py -verbose -m mem -rtcwake 15

I see various debug messages prior to the system suspending, then the system remains suspended for 15s or so, but when it comes back on I get the OEM boot logo (Dell logo) which usually doesn't show up on suspend/resume. Briefly after that, the logo becomes garbled and the system seems hung (caps lock key doesn't work). It looks like whatever sleepgraph is doing, it's triggering some unhappy BIOS behavior. :-)

A classical suspend on the same system works relatively fine (just a brief extraneous screen off/on):
sudo sh -c 'rtcwake -s 15; systemctl suspend'

Is there a way to enable/disable various sleepgraph hooks to try to isolate the on causing this? What's the best course of action with this kind of bug, does it indicate some definitive BIOS or kernel issue?

Best,
- LM

[lool]

NB: I took videos of a normal/failing suspend; but that seems pretty heavy to put on the public record, let me know if that would be useful to provide

[tebrandt]

If you want to run sleepgraph over a more advanced command than just "echo mode > /sys/power/state" use "-cmd". For instance this will work the same as the default behavior: 'sudo sleepgraph -cmd "echo freeze > /sys/power/state" -rtcwake 15'. Or you could create a shell script with as much in it as you want 'sudo sleepgraph -cmd "suspend.sh" -rtcwake 15'. It issues the command then determines what mode was actually entered by looking at dmesg and ftrace.

[tebrandt]

Interesting, I just tried running "sudo sleepgraph -cmd "systemctl suspend" -rtcwake 15 -dev -proc" and didn't realize that systemctl suspend runs a background process, so sleepgraph basically finishes the instant after the call and the system is stuck in suspend. Try using "rtcwake -m mem" instead as it's synchronous and actually blocks until the suspend it done, like sleepgraph.

[tebrandt]

ok, I just tried this command: 'sudo sleepgraph -cmd "systemctl suspend && sleep 15" -rtcwake 15 -dev -proc' . And it works correctly, demonstrating that the sleepgraph timeline shows either a mem or freeze based on what's in /sys/power/mem_sleep