A patched kernel is not really an option here, since users need to be able to install security updates and we don't want to have to rebuild such a patched kernel on every kernel update just for the framework laptop.

But there is another option, you can add "mem_sleep_default=deep" to the kernel commandline to get the same result as the echo; and if we are going to spin a special image, then we might be able to insert that into the image, after which it should stick around since the previous kernel-commandline is re-used when installing newer kernel packages.

Thanks Hans for the answer. I was afraid of that, but no worries. I think we will list this as a commonbugs type of thing and have the user run the command themselves after the fact. Closing the bug...

So thinking more about this and looking at what was done the previous time we respun an image with included updates for vendor-preload purposes, I'm not entirely sure if the kernel cmdline idea is the best option. Give how the previous image was published it really boils down to a mostly offical F33 respin with latest updates included, which means others might use it for other purposes too.

As such I think it might be better to just add a downstream patch to the regular Fedora kernels which enables mem_sleep_default=deep on the Framework laptop based on identifying it by its DMI strings.

The kernel is full of DMI quirks for various hw, but I don't think there is a pre-existing quirk mechanism we can use here in this case. Still adding one should not be hard. Ideally we would get the patch for this upstream, but otherwise it might be acceptable as a downstream (Fedora specific) kernel patch too; and that way the respun image would be as standard as possible, rather then it having Framework specific mods.

(In reply to Hans de Goede from comment #3)
> The kernel is full of DMI quirks for various hw, but I don't think there is
> a pre-existing quirk mechanism we can use here in this case. Still adding
> one should not be hard. Ideally we would get the patch for this upstream,
> but otherwise it might be acceptable as a downstream (Fedora specific)
> kernel patch too; and that way the respun image would be as standard as
> possible, rather then it having Framework specific mods.

I do not have a problem with this approach, but would really like to see it upstream. I am not going to say that I absolutely won't take it as a downstream patch if it is rejected upstream, but I would have to think pretty hard on it, particularly as kernel command line options do exist to work around the issue.  As things go, I expect that next week will be the last of the 5.12 kernels and we will move to 5.13 unless things come up during test week.

(In reply to Justin M. Forbes from comment #4)
> (In reply to Hans de Goede from comment #3)
> > The kernel is full of DMI quirks for various hw, but I don't think there is
> > a pre-existing quirk mechanism we can use here in this case. Still adding
> > one should not be hard. Ideally we would get the patch for this upstream,
> > but otherwise it might be acceptable as a downstream (Fedora specific)
> > kernel patch too; and that way the respun image would be as standard as
> > possible, rather then it having Framework specific mods.
> 
> I do not have a problem with this approach, but would really like to see it
> upstream. I am not going to say that I absolutely won't take it as a
> downstream patch if it is rejected upstream, but I would have to think
> pretty hard on it, particularly as kernel command line options do exist to
> work around the issue.

So first of all some good news, I did some further digging and there already is an existing mechanism to do this based on DMI strings, so it is just a matter of adding an extra entry to the existing acpisleep_dmi_table[] in drivers/acpi/sleep.c .

Geoffrey, can you provide the output of:

grep . /sys/class/dmi/id/* 2> /dev/null

Run on the Framework laptop, then I can prepare a patch to add a DMI quirk for this for now. Also is there a bug or discussion somewhere about this issue, so that I can reference it in the commit-msg ?

Justin, once tested I'll also try to submit the patch upstream, but I expect Rafael to nack it, since he probably will want to fix the root-cause of this rather then doing the quirk (the existing DMI table entry for this is special / broken beyond repair). The patch will be very small and KISS though, so I hope you will be ok with carrying it downstream until a proper fix is found.

> As things go, I expect that next week will be the
> last of the 5.12 kernels and we will move to 5.13 unless things come up
> during test week.

I'm not sure why this is relevant, is 5.13 known to fix the s2idle issues seen on the Framework laptop? If yes then waiting for that indeed seems better.

Regardless, it is probably a good idea to test things with 5.13. Geoffrey, can you give this kernel a try on the Framework laptop: https://koji.fedoraproject.org/koji/buildinfo?buildID=1779220

See here for instructions for installing a kernel directly from koji: https://fedorapeople.org/~jwrdegoede/kernel-test-instructions.txt . Note since this is an official build it is not necessary to disable secureboot.

(In reply to Hans de Goede from comment #5)
> (In reply to Justin M. Forbes from comment #4)
> > (In reply to Hans de Goede from comment #3)
> Justin, once tested I'll also try to submit the patch upstream, but I expect
> Rafael to nack it, since he probably will want to fix the root-cause of this
> rather then doing the quirk (the existing DMI table entry for this is
> special / broken beyond repair). The patch will be very small and KISS
> though, so I hope you will be ok with carrying it downstream until a proper
> fix is found.

As long as there are plans for a proper fix, and this is not a patch we will be carrying around forever, that shouldn't be a problem. And a proper upstream root-cause fix would certainly benefit more users.

> > As things go, I expect that next week will be the
> > last of the 5.12 kernels and we will move to 5.13 unless things come up
> > during test week.
> 
> I'm not sure why this is relevant, is 5.13 known to fix the s2idle issues
> seen on the Framework laptop? If yes then waiting for that indeed seems
> better.
> 

I am not aware that it does, just pointing out the timing because it seems like this is something that should ship with 5.13, so testing should be done on 5.13.

So as dicussed I can write a patch to make this just work with regular Fedora kernel builds, but I'm going to need the DMI strings of the framework laptop to do this.

Geoffrey, can you please provide the output of:

grep . /sys/class/dmi/id/* 2> /dev/null

run on the Framework laptop.

This message is a reminder that Fedora Linux 34 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora Linux 34 on 2022-06-07.
It is Fedora's policy to close all bug reports from releases that are no longer
maintained. At that time this bug will be closed as EOL if it remains open with a
'version' of '34'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, change the 'version' 
to a later Fedora Linux version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora Linux 34 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora Linux, you are encouraged to change the 'version' to a later version
prior to this bug being closed.

Fedora Linux 34 entered end-of-life (EOL) status on 2022-06-07.

Fedora Linux 34 is no longer maintained, which means that it
will not receive any further security or bug fix updates. As a result we
are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release.

Thank you for reporting this bug and we are sorry it could not be fixed.

The needinfo request[s] on this closed bug have been removed as they have been unresolved for 365 days