Shutdown/sleep and Restart not working due "Storage device maintenance tasks"

[MLuna]

I was having issues shutting down, suspending and restarting my Steam Deck.

A little bit of research led me to this forum https://www.gamingonlinux.com/forum/topic/5644/ where they explain that if you try to shut it down, suspend or restart the Steam Deck while is running storage device maintenance tasks it will freeze.

Indeed that was the problem. As soon as it was done everything went back to normal.

You guys have been doing great work with the Steam Deck. We appreciate it if you can fix this.

Thank you.

[Kewne]

I was having the same issue & I was wondering wtf was up with my Deck, was worried I'd have to RMA it - but yeah. whenever this is running, it does it.

What's really annoying is that whenever it's running, there's no way to STOP it.
Like right now, my Deck started running it out of nowhere &when I went to sleep it to store it, the glitch happened & came back up. Now I have to leave my Deck on, when I wanted to put it away.

Valve: Please add a 'STOP TASKS' feature for the storage device maintenance tasks, or automatically stop the tasks if the Deck is put in sleep mode.
Imagine a situation where you need to sleep the Deck & put it away immediately (such as traveling) - this is really frustrating.

[ToothPaste]

I can help you with this one. This is probably an SDCard problem because the trimming process can take a lot of time. This depends on how manifacturer, quality, ecc
(Test it removing the SDCard and check how much time trimming takes. It shouldn't last more than 3 minutes at worst).

Devs at Valve do certain checks on the SDCard to see if it's a faulty one or not and if it can run the "trim" command without any risk of using data.

The problem is that SDCards, even if they report correct values to the kernel, don't guarantee any trimming time estimation. This can take a very long time, especially if you have a 1TB SDCard with a microcontroller that doesn't do a good job.
There is asyncronous trimming mode in Linux and in some microcontrollers is supported, but that can lead to problems too, since manifacturers don't implement the features properly and can lead to loss of data (The Linux kernel has a huge blacklist to certain device model, NT probably does have it too, but who knows).

My A2 SDCard 1TB has nice RW performance, but when it comes to trimming the performance is awfully bad. It can take 20 minutes. The more space, the worse it is. It's an Amazon Basic one. Technically it's withing A2 specs but there's nothing that guarantee trimming speed on SDCard.

The code that does this check is under this file:

/usr/lib/hwsupport/trim-devices.sh

There are comments from the developer at Valve that explain each steps they're taking to verify the SDCard. Sadly they are not enough in this case.

#!/bin/bash

set -e

function is_known_bad_device()
{
    local sdcard_dir=$(find /sys/class/mmc_host/mmc0/mmc0\:* -maxdepth 0)
    if [[ ! -d "$sdcard_dir" ]]; then
        echo "No sdcard present"
        false
        return;
    fi

    local sdcard_manfid=$(cat "$sdcard_dir"/manfid)
    local sdcard_oemid=$(cat "$sdcard_dir"/oemid)
    local sdcard_safe_trim_quirk_version=$(cat "$sdcard_dir"/safe_trim_quirk)

    if [ -z "$sdcard_safe_trim_quirk_version" ]; then
        echo "Warning: kernel does not advertise safe_trim_quirk version, assuming 0"
        sdcard_safe_trim_quirk_version=0
    fi

    echo "Found sdcard: manfid=$sdcard_manfid oemid=$sdcard_oemid safe_trim_quirk_version=$sdcard_safe_trim_quirk_version"

    # Check for problematic cards

    # These cards are not safe to trim unless we have a discard->erase quirk
    # present in the kernel
    if (( "$sdcard_manfid" == 0x3 || "$sdcard_oemid" == 0x5344 )); then
        # Only allow trim on these cards if the kernel has the necessary quirk
        # to convert discard commands to erase commands
        if [[ "$sdcard_safe_trim_quirk_version" -lt "1" ]]; then
            echo "Warning: sdcard is not safe to trim"
            true
            return
        fi

        echo "Warning: possible problematic card, but kernel advertises workaround support. Proceeding."
        false
        return;
    fi

    echo "sdcard is safe to trim"
    false
    return;
}

# In some cases it is unsafe to trim an sdcard. When we detect this case
# lets just trim the partitions on the internal drive which we know are
# safe to trim/discard
if is_known_bad_device; then
    fstrim -v /var
    fstrim -v /home
    exit
fi

fstrim -av

The function is_known_bad_device is the culprit. Sadly that one cannot infer the ETA of the SDCard trimming function and it just say "Ok, the device supports everything and it's good".

My 2 cents is that my SDcard supports Trim, but is one of those at risk of losing data. That converts the discard (which is trim basically) operation to "erase", which takes a hell lot of time if your SDCard has 1TB of space (And it's mostly empty).

To bypass this problem, you have to add these 2 lines inside the function is_known_bad_device

    
    true
    return;

Doing this, SteamOS will flag the SDCard as one that doesn't support trim and that will disable the trim operaton just for the SDCard. This means that, sometimes, you'll have to manually do it via terminal (Altho Games don't usually do too much R/W after the installation, so it shouldn't be required).
if you don't know what I'm talking about and you're not confident about editing system files, please avoid doing these changes.

[scooter800m]

Originally posted by ToothPaste:

I can help you with this one. This is probably an SDCard problem because the trimming process can take a lot of time. This depends on how manifacturer, quality, ecc
(Test it removing the SDCard and check how much time trimming takes. It shouldn't last more than 3 minutes at worst).

Devs at Valve do certain checks on the SDCard to see if it's a faulty one or not and if it can run the "trim" command without any risk of using data.

The problem is that SDCards, even if they report correct values to the kernel, don't guarantee any trimming time estimation. This can take a very long time, especially if you have a 1TB SDCard with a microcontroller that doesn't do a good job.
There is asyncronous trimming mode in Linux and in some microcontrollers is supported, but that can lead to problems too, since manifacturers don't implement the features properly and can lead to loss of data (The Linux kernel has a huge blacklist to certain device model, NT probably does have it too, but who knows).

My A2 SDCard 1TB has nice RW performance, but when it comes to trimming the performance is awfully bad. It can take 20 minutes. The more space, the worse it is. It's an Amazon Basic one. Technically it's withing A2 specs but there's nothing that guarantee trimming speed on SDCard.

The code that does this check is under this file:

/usr/lib/hwsupport/trim-devices.sh

There are comments from the developer at Valve that explain each steps they're taking to verify the SDCard. Sadly they are not enough in this case.

#!/bin/bash

set -e

function is_known_bad_device()
{
    local sdcard_dir=$(find /sys/class/mmc_host/mmc0/mmc0\:* -maxdepth 0)
    if [[ ! -d "$sdcard_dir" ]]; then
        echo "No sdcard present"
        false
        return;
    fi

    local sdcard_manfid=$(cat "$sdcard_dir"/manfid)
    local sdcard_oemid=$(cat "$sdcard_dir"/oemid)
    local sdcard_safe_trim_quirk_version=$(cat "$sdcard_dir"/safe_trim_quirk)

    if [ -z "$sdcard_safe_trim_quirk_version" ]; then
        echo "Warning: kernel does not advertise safe_trim_quirk version, assuming 0"
        sdcard_safe_trim_quirk_version=0
    fi

    echo "Found sdcard: manfid=$sdcard_manfid oemid=$sdcard_oemid safe_trim_quirk_version=$sdcard_safe_trim_quirk_version"

    # Check for problematic cards

    # These cards are not safe to trim unless we have a discard->erase quirk
    # present in the kernel
    if (( "$sdcard_manfid" == 0x3 || "$sdcard_oemid" == 0x5344 )); then
        # Only allow trim on these cards if the kernel has the necessary quirk
        # to convert discard commands to erase commands
        if [[ "$sdcard_safe_trim_quirk_version" -lt "1" ]]; then
            echo "Warning: sdcard is not safe to trim"
            true
            return
        fi

        echo "Warning: possible problematic card, but kernel advertises workaround support. Proceeding."
        false
        return;
    fi

    echo "sdcard is safe to trim"
    false
    return;
}

# In some cases it is unsafe to trim an sdcard. When we detect this case
# lets just trim the partitions on the internal drive which we know are
# safe to trim/discard
if is_known_bad_device; then
    fstrim -v /var
    fstrim -v /home
    exit
fi

fstrim -av

The function is_known_bad_device is the culprit. Sadly that one cannot infer the ETA of the SDCard trimming function and it just say "Ok, the device supports everything and it's good".

My 2 cents is that my SDcard supports Trim, but is one of those at risk of losing data. That converts the discard (which is trim basically) operation to "erase", which takes a hell lot of time if your SDCard has 1TB of space (And it's mostly empty).

To bypass this problem, you have to add these 2 lines inside the function is_known_bad_device

    
    true
    return;

Doing this, SteamOS will flag the SDCard as one that doesn't support trim and that will disable the trim operaton just for the SDCard. This means that, sometimes, you'll have to manually do it via terminal (Altho Games don't usually do too much R/W after the installation, so it shouldn't be required).
if you don't know what I'm talking about and you're not confident about editing system files, please avoid doing these changes.

unfortunately for me, i am unable to write to that file period. file system is read only and no matter what i do even all the way up the path i can't make it writeable. honestly i'd rather a way to disable the autorunning of the script and i'll just run it before going to work and stuff like that as it always picks the worst time to run. even if the sdcard is not present it takes a minimum of an hour and at that point the little bit of time that i do have for games just got thrown out the window.