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?
@junaruga I think you meant to report that USB audio issue to the fedora bug titled “Thinkpad …”? That’s the one about USB audio. The one about framework is not related to USB audio.
I ran a Fedora system update the other day that installed kernel 5.16.9-200.fc35.x86_64, and my wifi doesn’t work at all. KDE doesn’t even list any wifi adapters. It was working fine with my original kernel, 5.14.10.
Here’s a dmesg dump from where it tries to load the wifi driver:
@n1kt0 I didn’t have any issues like this with 5.16.9/10/11. I do sometimes see similar-looking errors on resume from sleep (both S3 and s2idle), opened a fedora bug to track that. But after that wifi still works post-resume.
I saw a message here (can’t find it atm) that pointed to recent kernels disabling the wifi6 bands based on responses obtained by iwlwifi from the BIOS, but that shouldn’t be disappearing the wireless adapter completely.
I see fedora 35 is by now at 5.16.13 . Does anyone have data on whether all 5.16 regressions that framework’s hardware suffers from have been resolved? I’, still on 5.15.18 because of these regressions.
Just upgraded to Fedora 36 (with 5.17.6-300.fc36.x86_64) and so far so good, the kernel dmesg is much quieter (over the last 3-4 hours) and wifi looks to be much more stable. Crossed fingers.
Wifi might be fixed but the standby issue which started after 5.15.18 is still present with 15.17.13…
Thanks for the fix and reporting dimitris.
Edit:
I have noticed this fix is not always working, there are times when the laptop is not sleeping properly when pressing the power button, laptop is hot and battery drained a lot. I think I will remove this from grub and maybe simulate closing the lid with a magnet until the issue is fixed, if it is fixed.