Flaky Suspend on LGO + latest bazzite updates
flaky on latest bazzite image. currently being investigated, suspend works flawlessly on image
39-20240205Solution:Jump to solution
looks like this might be resolved with 6.7.5, see #Legion Go Suspend issue for updates
138 Replies
@antheas logs from
sudo hhd.contribSo
You press one you get multiple presses
A press has a value of 1
hrm, i wonder if it'll be different if i use hhd 1.3.3
this was with the built in hhd on bazzite
In this
It's ok it's the same script
Is that right?
You press once
You get multiple presses
this was with me pressing the button multiple time
you had said to capture it and go ham 😅
You get what I'm saying those
Though
You press it once
Do you get a clean 1 and 0?
With code 116
single tap of power button:
Is that always what happens?
Does every press look like this?
Because that's how it should look like
3 power button taps
looks like the same pattern every time
event at 1707837342.061445, code 116, type 01, val 01
event at 1707837342.061445, code 00, type 00, val 00
event at 1707837342.061456, code 116, type 01, val 00
event at 1707837342.061456, code 00, type 00, val 00
Always?
Hmm
You get 4 lines every time
Not sometimes 8 right?
looks like it, but let me try doing a lot of presses
gimme one min
Also there is no other power button right?
The lnx one
don't think so, but i can try it real quick
I will also check it out when I get home
But maybe the double presses are a kernel issue
Maybe there's a broken loop or sth
lnx didn't capture anything when i tapped the power button
If there are double press issues I can debounce
There's lnx though?
Maybe that's it
but i do think hhd 1.3.3 seems much more stable for suspend
I think I capture lnx by default now
Maybe lnx goes wonky
i'll try different hhd versions and see if the problem becomes more noticable
No that's it maybe
I capture lnx now not pnp whatever
Open 2 terminals and capture both buttons
See what happens
nothing on the lnx on button press
Lmao not that one
I don't remember the name I'm on the bus
I recall the go not having it though
lol no rush, for now i can continue investigating. think maybe it's due to the new beta bios then?
though i get better suspend on hhd 1.3.3 even on the new beta bios
If it's not hhd
It's the button giving multiple presses
If you say it doesn't it doesn't and it's hhd
And I will look into it
It works with the previous version of Bazzite
I'm trying to see if there are double presses in the button
If not then it's hhd and I will hotfix today
if it's the command I gave you, that was an older bazzite image, not necessarily the previous version
On the bazzite that doesn't work
Run the xontrib command
See if that breaks anything
I’m still on bios v39 I haven’t flashed the beta version so I think we can rule that out
Find broken bazzite version
Run contrib command
Validate there are no double presses
And in 2 hours I will test if hhd is broken after 3.3
no rush, i'm going to test bazzite latest and incrementally bump up hhd versions
and see if the problem starts happening more frequently at some point
I just need the contrib command
To see if there are double presses
Everything else I can take care off
hrm, does local hhd install have it's own contrib script somewhere?
If you want to spend time on hhd work on hhd ui
It does
hhd.contrib is an executable too in the venv
maybe unsurprisingly, still the same for every version of hhd after 1.3.3
and in hhd logs, whenever there's only one
short press, suspend works no problem
it fails whenever there's 2 or more short press right after each other
not sure what's trigger the multiple short presses
for now, time to dust off the old powerbuttond service as a temp workaround for myselfwhen does that happen
ill fix it now
i did over 50 button presses
it always says executing short press once
i literally keep doing it
latest version on git
i commented out the sleep command
its always a single press
yeah, i'm not sure what trigger the 2x short press in hhd
can u make it happen with this?
i'm just tapping the power button as usual, and sometimes it's logging 2x short press
i can't reliably reproduce it
it could very well be kernel related
i can work around it either way
but you have to reproduce
if you get a double press here its kernel related
otherwise its hhd related
i have not been able to get it to double press via the contrib script
so
but let me try like 100x times lol
hhd does executing sleep 2x
just to make sure
but contrib does not
i cant i keep pressing it its always one shortpress
maybe
its beta bios
lmao
tecnor mentioned he's seeing the problem on v29 bios
so it's not beta bios
it really could only be kernel related then
since you're on 6.6, vs 6.7 on bazzite
but if it is kernel related
you will see it on contrib
ok, let me try contrib 100x times. gimme 5 min
comment out and go ham on the buttons
so it doesnt sleep every time
let me uncomment and actually sleep i guess
works perfect on steam too
tapped 50x times so far, every time it's been:
so most likely not kernel then
100x times, every time the same
no double presses, always logged those 4 lines on every button press
ok, so comment out those lines in hhd and reproduce
also get me a log of hhd
i also have another suspicion
ok, so if i comment out the lines and tap power button, it also shows up once on every tap
so what triggers the 2x or 3x short presses in the hhd log? 🤔 https://discord.com/channels/1072614816579063828/1087140957096517672/1206661206820003931
oh i see
let me double check something
it could be that something is waking the device right after suspend
which would make sense
Those presses are too far apart
Like 10s
ok yep, you're right
Almost like you press the button twice
so hhd is properly only executing short press once
So kernel problem
Look at journalctl
yeah, so every time you see the 2x or 3x short presses, that's when the suspend fails
so i retry
for some reason i thought there'd be additional logs between the short presses, my bad 😦
but yeah, each of those are a suspend fail
🙂
Aru can you verify my observation that it seems to be worse under heavy load vs when nothing is running?
this makes more sense, so it's kernel related somehow
🙃
Journalctl
i mean, i'm seeing the issue at 13w tdp, doubt it's due to heavy load
journalctl output
11 mb txt
I only see it when running a game, otherwise it functions fine
i also see it when running a game
Feb 13 11:52:14 fedora systemd-sleep[6724]: Failed to put system to sleep. System resumed again: Cannot allocate memoryThat looks like a smoking gun to me
I see that in journalctl too
🤔 so kernel 6.6. is the golden kernel for LGO
shame that gamescope patches aren't on the 6.6 image
@Kyle Gospo as a heads up, seems like kernel 6.7 might have flaky suspend on the LGO.
rip
time to roll back to 6.6 for now
imo get back to 6.6
only bad things from here
literally 0 benefit to 6.7, leave it to testing for 3 weeks
i mean, downside is that you can't update bazzite
guess this is the downside of immutable
can't easily selectively pick and choose the parts you need
anyways, sorry for the false alarm on hhd @antheas
guess so
oh i thought this was fixed
rip
maybe it was 6.8 have no clue
¯\_(ツ)_/¯
i guess i could try to use rpm-ostree to layer on the latest patched gamescope on top of 6.6
not a bad idea
still not a viable long term solution though, for most users
since eventually the 2024-02-05 image will be deleted
there a known patch for this? Can always look into adding it
is there a patch for this? no idea
yeah using 6.6 and not worrying about this
letting someone else figure it out
but i guess we dont know who would that be
i wonder if increasing zram would help
is your kernel tainted
secure boot enabled right now
I had a swapfile and it didn’t seem to help. I just deleted it in case that was the cause, but I’d be curious about the zram.
but doubt that's related
bazzite no longer users swapfiles, i think
is your kernel tainted?
I created it and mounted it myself
if it is ur fucked
that crash was big
yeah, no swapfile on bazzite
zram only
how does that magic work
Upstream fedora is the same
I created it and added it to fstab
I had both
hwo do you hibernate then
cat /proc/sys/kernel/tainted
4097
I needed it for testing one game.
fedora doesn't hibernate
turns out mine is too?
yeah my kernel got tainted bc I loaded acpi_call
dkms variant
lol
and i didnt sign it
I wiped out my swapfile though and it didn’t make a difference fwiw
yeah, i think zram is used for swap on bazzite,
important for handheld devices imo
I had both. I manually created the swapfile and added it to fstab.
I had the priority lower than zram so that it only was used in emergencies
I was testing Star Citizen and it wouldn’t work without it
I needed the extra. Even increasing ZRAM size didn’t helps
Besides the point here, it’s not the issue
yeah, i'm assuming it's not related to the suspend issue
steam deck doesn't hibernate, just sleep
beyond that, silverblue in general doesn't hibernate even on desktop
so the chance we support it is basically zero
you need to give a couple of thunks to it
bc a lot of the devices you claim to support dont sleep properly
and they will start asking
hmmm
so i did 3x zram
and suspend seems better?
I’ll give it a go
oh derp nevermind
A workaround but not really a solution
forgot to reboot
i was on the old image
let me reboot real quick
nope nevermind, false alarm
time to revert to 6.6 kernel
i need to figure out how to install patched gamescope on 6.6, then the LGO will fully setup
So with 6.6, no unified frame fix?
yep, pretty much
the only missing piece from 6.6 is the gamescope fix
thought this would work, but apparently not
iirc it's just gamescope-session
try that
but also, patch is in gamescope
so you want kylegospo:bazzite-multilib gamescope
make sure the repo is enabled in /etc/yum.repos.d
Once you figure out the final command let me know so I can rollback and use it too
so to enable the repo, do I basically just need to remove the
_ from the _copr_kylegospo-bazzite-multilib.repo file in /etc/yum.repos.d?inside of it there's just gonna be an enabled=0
set it to 1
ah ok, that makes more sense
we do that because checking the repos is meaningless on an OCI
so it's wasted time during update if they're enabled
but I wanted them present for use cases such as yours right now
I'll just catch the explainer video on YouTube 😂
🤔
everything I did so far:
sudoedit /etc/yum.repos.d/_copr_kylegospo-bazzite-multilib.repo
change enabled=0 to enabled=1
rebooted
I must be overlooking somethingsec
rpm-ostree override replace https://download.copr.fedorainfracloud.org/results/kylegospo/bazzite-multilib/fedora-39-x86_64/07007152-gamescope/gamescope-3.13.19-1.fc39.bazzite.0.0.git.2716.354b9dd4.x86_64.rpm
Try thathrm, well i'll keep trying to figure out. but so far, looks like this might be trickier than expected.
i'll try manually downloadign the rpm
ok, did a
sudo rpm-ostree reset, seemed to successfully run afterwards. rebooting now
nope, let me try again with gamescope and gamescope-libs
nope, no go
eh, i'll give up for now. i was able to get by fine without the unified slider before
i'll just revert to using the old sliderIs 20240205 the last image before the kernel update?
yep, pretty much
you can also check specific kernel versions for images, i documented it here: https://github.com/aarron-lee/legion-go-tricks?tab=readme-ov-file#roll-back-to-bazzite-image-with-specific-linux-kernel
6.7 is messing with suspend on my alienware laptop, also
In my case, I believe it's this issue, might be the same for you: https://bugzilla.redhat.com/show_bug.cgi?id=2262577
They say a fix is coming in 6.7.5
Looking at that bug report, it seems different from what I'm seeing on the LGO. Might be unrelated, but we'll have to see with 6.7.5
hrm, now that i know that steam temporarily caches old refresh rates, etc, i wonder if this had actually worked but steam was still showing stale data
guess i'll try again and find out
one more followup to note about kernel 6.7. I've noticed that sometimes, while suspending, the device will hang and freeze up. i'll need to force a reboot via holding the power button
still haven't seen the issue yet on kernel 6.6, so i've been sticking with the 02-05 image
Can replicate on 6.6 after 7 sleep attempts back to back
Or 10
A lot of the time steam gets confused and gets a black screen
But if I press the power button again it winks after a few sec
I was testing the flashing issue
hrm, actually that'd make sense for why i see the issue on 6.7 but not 6.6
because on 6.7, i often need to press the power button multiple times
for it to actually suspend
But they have to be back to back
Probably
whereas on 6.6 it suspends first tap every time
If you could get some journalctl -n 0 logs that would be great
When that happens
It usually says why it failed
Not my first rodeo
hrm, guess i'll have to run the latest bazzite image and replicate then.
since i've just been cruising on 6.6
Solution
looks like this might be resolved with 6.7.5, see #Legion Go Suspend issue for updates