I am experiencing the same problem and same time I am a little bit concerned about Fedora releasing kernel where this kind of bugs is reported. It’s not just our laptop.
@Anil_Kulkarni Thanks for your time trying to bisect it!
Nice. So, could you create a small reproducing script to fail on the kernel 5.16.5, and pass the kernel 5.15? The test case is not included in the unit tests in kernel? I am curious to know which git repo in https://git.kernel.org/ is related to this issue.
And indeed, reverting this patch on-top of 5.16 fixes backlight at least. @ dimitris, if you wanted to try compiling a kernel with git revert 3bf70bd2538f0515ce17b1c067889ff0e4fec842 and see if it fixes your issues.
Since it’s the EOW, I’ll wait until Monday to create a bugzilla report over this
@Anil_Kulkarni nice work! I’ll try to build a Fedora kernel from source with that revert somehow included, but it’s something I’ve never done before so it may take me a while to get it done.
FWIW I tried to quickly play with the acpi_osi= kernel command line parameter (Linux, Windows, Windows 2019) but it didn’t make a difference.
I also reproduced the difference in behavior with lid vs power button: The lid does seem to put the laptop into s2idle sleep successfully. I still would prefer to use the power button primarily because there isn’t (yet) a way to visually confirm the laptop has in fact entered sleep. I believe this has been discussed in the EC thread(s) re: modifying LED behavior.
@Kieran_Levin this combination of “behavior deltas” (kernel adding a “reported capability” to ACPI and difference between power button vs lid sensor) point to some underlying EC/BIOS issue?
(edit: or sudo grubby --update-kernel=ALL --args='"acpi_osi=!Windows 2020"' to make it the default going forward)
and rebooting, I can now get into s2idle sleep with the power button. So it seems that telling the Insyde BIOS (3.07 anyway) that we “support/are” Windows 2020 makes it do Bad Things.
And one quick followup on the wifi issues: Those do persist, so they don’t seem to be a side effect of S3 sleep but rather an actual regression with the kernel/Intel wireless driver. I believe I’ve seen something in a thread here about that being worked on in 5.17 or 5.18, but I’m not sure… (edit: 5.17)
Anyway, the wireless network still does come back after a momentary/mildly annying freeze on resume.
Ah thanks for digging in - this makes more sense. Just from reading the patch I was very confused how Windows was affecting standby. But now it makes sense because it’s telling the bios “Yes, we’re windows 2020”
Here’s the key snippet:
Linux had no choice but to also return TRUE to _OSI(“Windows 2001”) and its successors. To do otherwise would virtually guarantee breaking a BIOS that has been tested only with that _OSI returning TRUE.
This strategy is problematic, as Linux is never completely compatible with the latest version of Windows, and sometimes it takes more than a year to iron out incompatibilities.
so I take it we’ll need yet-another-bios update to fix this eventually. In the mean time we probably should get those kernel args added to the linux guides on this site
I had a bunch of other things to focus on but I finally can devote a few minutes to helping troubleshoot this. In EndeavourOS (arch based), with 5.16.8:
Seeing the same keyboard backlight remaining on behavior for s2idle. It does take a power button push to wake it up, not a keyboard keypress, so I know it made it to some kind of “sleep”. I prefer deep by far though, so I’m going back to that.
No issues resuming wifi from s2idle or from deep
None of your iwlwifi errors show up in my dmesg.
Here’s dmesg at boot:
$ sudo dmesg | grep -i wifi
[ 3.469737] Intel(R) Wireless WiFi driver for Linux
[ 3.470023] iwlwifi 0000:aa:00.0: enabling device (0000 -> 0002)
[ 3.512379] iwlwifi 0000:aa:00.0: api flags index 2 larger than supported by driver
[ 3.512396] iwlwifi 0000:aa:00.0: TLV_FW_FSEQ_VERSION: FSEQ Version: 0.0.2.34
[ 3.512635] iwlwifi 0000:aa:00.0: loaded firmware version 67.8f59b80b.0 ty-a0-gf-a0-67.ucode op_mode iwlmvm
[ 3.654393] iwlwifi 0000:aa:00.0: Detected Intel(R) Wi-Fi 6 AX210 160MHz, REV=0x420
[ 3.660897] iwlwifi 0000:aa:00.0: WRT: Failed to set DRAM buffer for alloc id 1, ret=-1
[ 3.660900] iwlwifi 0000:aa:00.0: WRT: Failed to set DRAM buffer for alloc id 2, ret=-1
[ 3.660901] iwlwifi 0000:aa:00.0: WRT: Failed to set DRAM buffer for alloc id 3, ret=-1
[ 3.828038] iwlwifi 0000:aa:00.0: loaded PNVM version dda57f4f
[ 3.843264] iwlwifi 0000:aa:00.0: Detected RF GF, rfid=0x10d000
[ 3.912446] iwlwifi 0000:aa:00.0: base HW address: f4:46:37:ca:8b:bd
[ 4.004239] iwlwifi 0000:aa:00.0: WRT: Failed to set DRAM buffer for alloc id 1, ret=-1
[ 4.004242] iwlwifi 0000:aa:00.0: WRT: Failed to set DRAM buffer for alloc id 2, ret=-1
[ 4.004243] iwlwifi 0000:aa:00.0: WRT: Failed to set DRAM buffer for alloc id 3, ret=-1
[ 4.297471] iwlwifi 0000:aa:00.0: WRT: Failed to set DRAM buffer for alloc id 1, ret=-1
[ 4.297478] iwlwifi 0000:aa:00.0: WRT: Failed to set DRAM buffer for alloc id 2, ret=-1
[ 4.297480] iwlwifi 0000:aa:00.0: WRT: Failed to set DRAM buffer for alloc id 3, ret=-1
and I get this after every resume from either s2idle or from deep:
$ sudo dmesg | grep -i wifi
[ 3493.683355] iwlwifi 0000:aa:00.0: WRT: Failed to set DRAM buffer for alloc id 1, ret=-1
[ 3493.683362] iwlwifi 0000:aa:00.0: WRT: Failed to set DRAM buffer for alloc id 2, ret=-1
[ 3493.683364] iwlwifi 0000:aa:00.0: WRT: Failed to set DRAM buffer for alloc id 3, ret=-1
cannot reproduce your usb issues / messages. Is there a particular device that inserting/removing changes your behavior? Have you checked internall for EMI sticker issues, melted covers, etc?
@D.H I’ve checked inside the laptop, no melt/overhead issues, and the EMI stickers seem ok (it’s a batch 3 build, the KB article implies this was an issue only in batches 1 and 2).
About the iwlwifi stack traces: I’ve opened a fedora issue with pretty much the same issue, separate from the now worked-around s2idle one.
The Intel wireless firmware version in your dmesg is the same I have. This could be a difference in the patches that EndeavourOS carries in the kernel vs Fedora, or even the particular wireless network. Since it doesn’t reproduce 100% for me, it’s worth keeping an eye on it. In my case it’s roughly one in three attempts.
In an ideal world, it should be the company itself submitting patches/updates Upstream for its own hardware. I guess, but I may be wrong, that in this case the regression is due to Intel rather than to Framework, and that can be proved by replacing the wi-fi card with something else (not Intel, possibly) and see how it goes.
As per the USB error logs, it might as well be an hardware issue (possibly in the expansion card), but I hope I’m wrong.
The plot sickens. It seems plasma shell is unable to make the laptop sleep in s2idle nor in deep mode lately. Suspending via systemctl call works, but not clicking “sleep” in the GUI, closing the lid, etc.
Hibernate works from GUI and from command line as expected.
Suspend is working for me with the acpi_osi workaround but while I am cycling suspend/resume then sooner or later something happens to Pipewire or something underlying, all sound devices vanish from the system and sound related processes including pipewrite block shutting the machine down. I cannot even kill them with SIGKILL. It could be related to my USB-C dock.
@dimitris Thanks, I blacklisted the module and when I reboot I will test it with the latest Fedora kernel. It would be nice to stop drifting from the upstream.
Got my Framework Laptop last Thursday and installed Fedora 35 (5.16.9-200.fc35.x86_64 kernel). Everything is working well… except for the Wifi card (AX210) which is connecting to my home WiFi network (on the latest generation eero AP’s with WiFi6 support).
The main issues are:
It doesn’t reattach to the network after any sustained period (more than a hour) of suspend state (laptop closed)
Randomly craps out, sometimes in short succession, sometimes it then runs fine for 8+ hours.
Interesting. I don’t have these issues myself, openSUSE Tumbleweed.
I’ll post my logs in case if you find it useful.
[ 5.081334] iwlwifi 0000:aa:00.0: enabling device (0000 -> 0002)
[ 5.127504] iwlwifi 0000:aa:00.0: api flags index 2 larger than supported by driver
[ 5.127523] iwlwifi 0000:aa:00.0: TLV_FW_FSEQ_VERSION: FSEQ Version: 0.0.2.34
[ 5.127710] iwlwifi 0000:aa:00.0: loaded firmware version 67.8f59b80b.0 ty-a0-gf-a0-67.ucode op_mode iwlmvm
[ 5.281998] iwlwifi 0000:aa:00.0: Detected Intel(R) Wi-Fi 6 AX210 160MHz, REV=0x420
[ 5.297832] iwlwifi 0000:aa:00.0: WRT: Failed to set DRAM buffer for alloc id 1, ret=-1
[ 5.297836] iwlwifi 0000:aa:00.0: WRT: Failed to set DRAM buffer for alloc id 2, ret=-1
[ 5.297837] iwlwifi 0000:aa:00.0: WRT: Failed to set DRAM buffer for alloc id 3, ret=-1
[ 5.463635] iwlwifi 0000:aa:00.0: loaded PNVM version dda57f4f
[ 5.478965] iwlwifi 0000:aa:00.0: Detected RF GF, rfid=0x10d000
[ 5.548130] iwlwifi 0000:aa:00.0: base HW address: (OMITTED)
[ 5.885410] iwlwifi 0000:aa:00.0 wlp170s0: renamed from wlan0
[ 5.956659] iwlwifi 0000:aa:00.0: WRT: Failed to set DRAM buffer for alloc id 1, ret=-1
[ 5.956669] iwlwifi 0000:aa:00.0: WRT: Failed to set DRAM buffer for alloc id 2, ret=-1
[ 5.956671] iwlwifi 0000:aa:00.0: WRT: Failed to set DRAM buffer for alloc id 3, ret=-1
[ 6.244642] iwlwifi 0000:aa:00.0: WRT: Failed to set DRAM buffer for alloc id 1, ret=-1
[ 6.244647] iwlwifi 0000:aa:00.0: WRT: Failed to set DRAM buffer for alloc id 2, ret=-1
[ 6.244647] iwlwifi 0000:aa:00.0: WRT: Failed to set DRAM buffer for alloc id 3, ret=-1
Kernel is 5.16.8-1-default
Spotted something, our ucodes are different. Perhaps your ucode version is breaking things?