Alright so I did not have the hantro info in the suspend script, so I was able to add that in but waking from sleep does not work. On closer examination, I seem to have the same issue as @vkoskiv, where the OLED reports 0%, briefly flashes “no response”, then blanks out.
@bnys did you make sure to also include the relevant lines in:
if [[ $1 = "suspend" ]]; then
setup_wake
wifi_off
hantro_off
kbd_backlight_off
hid_unbind
fi
if [[ $1 = "resume" ]]; then
kbd_backlight_on
wifi_on
hantro_on
hid_bind
fi
1 Like
Boom! I think that did the trick. Thanks, I didn’t know hantro needed to be added a few other spots too. Will test it out!
This seems resolved for me now. Perhaps thanks to the hantro fixes from earlier.
The irony is that my script doesn’t disable and re-enable hantro and yet my standby performance has been nearly 95% in terms of success.
I am curious if disabling it is recommended or required?
This worked for the longest time, but just this past week all of my attempts to wake from suspend have failed 
Not sure if this is related, but for some time I also have troubles with suspend.
On 2022-10-24 I upgraded LPC (using latest git commit from that date), and OLED shows now MREF2LPCR320220621fuLL chorse,500,430,1800.
Since then after resuming from suspend screen does not show anything. Backlight is working, and it reacts to all of below commands
echo 0 > /sys/class/backlight/backlight/brightness
echo 3 > /sys/class/backlight/backlight/brightness
echo 4 > /sys/class/backlight/backlight/bl_power
echo 0 > /sys/class/backlight/backlight/bl_power
but while they change brightness, nothing gets displayed.
System is working, I can ssh to it. I could not see anything pointing to source of problems in dmesg.
Another problem is inability to bring up NVMe disk from suspend. After waking up I can see following messages in dmesg (filtered to keep only relevant ones):
[ 291.023290] nvme 0001:01:00.0: Unable to change power state from D3hot to D0, device inaccessible
[ 353.248565] nvme nvme0: I/O 18 QID 0 timeout, disable controller
[ 353.288620] nvme nvme0: Identify Controller failed (-4)
[ 353.296366] nvme nvme0: Removing after probe failure status: -5
[ 353.320512] nvme0n1: detected capacity change from 3907029168 to 0
How can we fix both problems? They are keeping me from using MNT Reform as daily driver. I am ready to experiment (i.e. flashing different versions of firmware, providing more details) as long as someone shows what to test.
1 Like
My hunch is that both problems are related to kernel regressions that we didn’t have a chance to analyze yet. It needs to go on my TODO list, but if other people have time/resources to take a look (@nanocodebug perhaps?) this would be extremely helpful/appreciated.
2 Likes
I have looked into suspend/wake problems today and found that probably since 6.0 (also tested after upgrading to 6.1.7 today) there’s a regression in which the system works after wake, but the display doesn’t show anything. It doesn’t matter whether lcdif or dcss is used as the display engine for internal display.
Curiously, I found that I could still launch a terminal and type commands, and pkill sway brought the display back to life. I then found out that the following commands also bring back the display (including the sway session: swaymsg output eDP-1 disable; swaymsg output eDP-1 enable.
I bound this to a keybinding in sway config: bindsym $mod+x exec 'swaymsg output eDP-1 disable; swaymsg output eDP-1 enable'. Pressing super+x after waking brought the display and session back.
It looks like something is not reinitialized correctly in the display stack, perhaps in the nwl-dsi driver.
I also automated the workaround using this extremely ugly hack (modifying /usr/sbin/reform-standby):
sway_display_restart() {
export SWAYSOCK=$(echo /run/user/1000/sway-ipc*.sock)
swaymsg output eDP-1 disable
swaymsg output eDP-1 enable
}
And inserted a call to this function at this spot:
resume)
kbd_backlight_on
sway_display_restart
This is far from elegant, especially with the hardcoded user id 1000. But maybe this helps you with productively using suspend/resume until a real fix is found.
Edit: a cleaner option—if you have a bindsym to trigger suspend in sway—could be to just add the output disable and enable commands directly after the suspend command in the same line. Haven’t tested this.
3 Likes
@serpent what is your NVMe model? I don’t have this problem with the Transcend MTE220S. (0001:01:00.0 Non-Volatile memory controller: Silicon Motion, Inc. SM2262/SM2262EN SSD Controller (rev 03))
I wonder if doing this everytime whether necessary or not is a good idea? I mean in theory I suppose it should be fine, but I am curious if this might have some side effects.
Did not have side effects for me so far.
1 Like
I’d consider chipping in for a bug bounty if someone can fix and maintain suspend for 12 months at least. This is a big deal to get right and worth it for the platform, especially with Pocket Reform also coming with iMX8 by default.
3 Likes
@minute The NVMe model of @serpent might not be the issue. I saw the exact same error messages in dmesg as @serpent did with three different NVMe drives after resuming from suspend with a vanilla rescue system booted from SD-Card and the NVMe drive just mounted somewhere before suspending:
- Western Digital WDC WDS100T2B0C-00PXH0
- Transcend 220S M.2 2280 (TS1TMTE220S)
- Kingston NV2 NVMe SSD
[ 807.925640] nvme nvme0: I/O 20 QID 0 timeout, disable controller
[ 808.069698] nvme nvme0: Identify Controller failed (-4)
[ 808.074998] nvme nvme0: Removing after probe failure status: -5
[ 808.101611] nvme0n1: detected capacity change from 1953525168 to 0
See Confirmed Working NVME Drives - #33 by josch and the post after it.
In my tests, appending to the suspend command like you suggested did not wake up the display. However, using a separate keybinding worked.
Appending to the suspend command doesn’t work for me, too.
One more observation: I have a bunch of bad pixels on my LCD. They are shining white when the LCD is on. And they are shinning also after the suspend when the screen is black (in that moment when the eDP-1 command are needed). So think is that it is rather a sway(swaylock?) problem than anything else.
Decided to finally test this out today, I’m using the (currently) latest bundled kernel from the apt repository 6.1.0-reform2-arm64. For me currently neither of these those methods, the editing of the reform-standby script, nor the bindsym keybinding are solving the issue for me in sway.
After suspending, then waking up with circle-space, I’m greeted with the keyboard backlight turning back on and the screen backlight turning on but showing a black screen only. Pressing the bindsym at this point does nothing (it does disable/enable the screen before doing the suspend but not after). I also cannot seem to enter commands to sway at this point as typing commands like poweroff or opening a new terminal and trying the same do not work. However at the bare virtual terminal, while I’m also stuck at a blank display, I find I can enter a poweroff command just fine typing blindly.
I’m not sure if there’s another regression that’s possibly causing the keyboard not to come back up when in sway that’s preventing the keybind method from working or not. As a test I’m going to create a cronjob to run the swaymsg commands after a minute or two, so I can suspend the system, resume it, and see if it can reinit the screen without keyboard input.
Any advice would be appreciated if someone else has run into this variant of the issue, it’s 100% consistent at the moment.
1 Like
Interesting. I run the latest kernel (and the latest keyboard firmware, too), too. The symptoms are the same - the keyboard backllight is turning on, the screes is active but blank (I have a bunch of bad pixels in rith top edge - they are always white if the screen is active…).
Interestingly, I have hat just one case when the keyboard didn’t worked - in that case the keyboard backlight wasn’t active. My personal thought is that it happened while I suspend machine with keyboard oled screen active but I can be mistaken in this point.
I have been using my machine daily with about one suspend per day.
There is what appears to be a regression between the 5.12 and 6.1 kernel that the v3 image is using. Because of this it doesn’t seem to be possible to resume from suspend.
Thanks to the amazing efforts of @josch I was able to get a reproduction of the 5.12 kernel used in the v2 image. Under this kernel suspend works and you can happily still enjoy all the benefits of v3 with some caveats. As of right now it is known that hardware video decoding is not enabled in the 5.12 kernel.
Suspend is important to me, and I can live with that. This serves as a heads up for those looking for functional suspend.
I uploaded the kernel I built for @2disbetter here: Directory Tree
You will have to install linux-image-5.12.0-trunk-arm64_5.12-1~exp1.1_arm64.deb as well as linux-image-arm64_5.12-1~exp1.1_arm64.deb. As a result the linux-image-arm64 you have installed will be downgraded. Your existing kernels will still remain on the system. Since flash-kernel automatically starts the latest kernel you have installed, a reboot will still leave you with a newer kernel (6.x, assuming you have latest sysimage-v3). You have two options to fix this:
- Either make sure you have the latest uboot (the screen should turn on very early during boot and you should see the uboot output) and then install the
u-boot-menupackage. That package will auto-generate the file/boot/extlinux/extlinux.conffor you which your uboot will prefer over/boot/boot.scrand will present you a menu during each boot that you can use to choose from all your installed kernels. - Or just remove any newer kernel package – this is potentially dangerous as it could leave you with an unbootable system if 5.12 doesn’t work for you for some reason. Personally, I’m using the
u-boot-menuoption.
To make sure that the kernel packages you download are really by me and not by somebody trying to root your system, you can verify my GPG signature of linux_5.12-1~exp1.1_arm64.changes which references the packages. You can run dscverify linux_5.12-1~exp1.1_arm64.changes to perform this verification as my GPG key is part of /usr/share/keyrings/debian-keyring.gpg.
1 Like