I am having problems with Fedora 36 KDE. After waking from hibernation I receive this message: Message from syslogd@Framework at Jul 12 20:21:40 …
kernel:Uhhuh. NMI received for unknown reason 30 on CPU 0.
Message from syslogd@Framework at Jul 12 20:21:40 …
kernel:Dazed and confused, but trying to continue
I just recently removed all kernel boot flags to see current state of issues w/ f36.
Keyboard backlight now of with sleep and only 10% battery discharge over night.
NVMe is WD Black with updated Firmware. I’m quite happy for now.
This does not help much, if you don’t use laptop for a day it will be dead. This is super annoying, especially if you used Mac for years before. The only solution is to keep it always plugged in when you at home and turn it off if you going to travel
The coming BIOS 3.10 might help you. You can watch the thread: 11th Gen BIOS 3.09 Beta release. We were testing the 3.09 that improves the battery life, but as the 3.09 has a bug, we are waiting for the 3.10.
When installing Fedora 36 on the new Framework laptop with 12th Gen i5, I was repeatedly hitting “dracut-initqueue timeout” issues because the live USB was not being detected despite the fact I just booted from it.
The fix for this in my case was to boot from the USB, then remove and re-insert the USB after the GRUB screen.
Note: I’d also disabled secure boot as part of my troubleshooting and that may or may not also be a requirement to get the boot to succeed.
After almost a year of using Manjaro Xfce on my Framework, I decided to distro hop to Fedora 36 this weekend (changed my avatar and everything) for a variety of reasons.
The installation was smooth. I ran into the problem with the fingerprint reader holding onto the print that I registered in Manjaro, but I found the answer here on the forum right away.
I think it will take a while to get used to GNOME, and there are a couple things I wish I could change, but I’ve always been impressed with how well put together it seems. It feels right to be on a distro and desktop environment that prioritizes and contributes to the development of the latest things like Wayland and PipeWire and Flatpak (although I’m not entirely sure what to make of that one yet). I’m happy that I can enable Secure Boot too.
I’m impressed with how up-to-date Fedora’s packages are, which I didn’t expect on a point release distro. Some might even be newer than on Manjaro since they hold them back from the stable branch for a couple weeks. I hit a bug when running any kernel beyond 5.15 with Manjaro, and now I’m happily running 5.18 on Fedora.
@tim300 curious, how was running Manjaro on the Framework? What are the reasons you decided to hop? Rolling pains?
For context, recently got my FW and running Fedora36 w/GNOME on it. Have been running Manjaro GNOME on a desktop for a few years and Manjaro Sway on a Thinkpad for a little less than a year… almost just went for it again on the FW but wanted to try something new. But, I am curious, were there particular things that felt not so great w/ Manjaro on the FW?
[ Hope this Q is not so off-topic - it feels related enough to Fedora in the sense of comparing it to other options people might be used to. But can move it elsewhere if this is a derailment ]
I’ll send you a private message with some of my other thoughts that are more about Manjaro than Fedora.
Been using Fedora 36 since its release in May, but have had ongoing issues with USB 3 storage devices (external HDD, SDD and flash drive) not being recognized when plugged into USB-A expansion cards. Has anyone else has had similar issues with USB 3 devices not being recognized in this way?
I’ve been in dialogue with the support team (thanks to them for helping to investigate), but after some research may have hit on what’s been causing this.
The Linux kernel has a USB autosuspend function, and I wonder if this function has got confused between the USB-A expansion card plugged into a USB-C bay in the Framework and the device plugged into the expansion card, so that when a device is removed, the autosuspend function “auto-suspends” the expansion card? It’s a thought.
I found that the USB autosuspend function can be turned off in the boot parameters by adding “usbcore.autosuspend=-1” to GRUB_CMDLINE_LINUX_DEFAULT in the etc/default/grub file.
Having done this and then updating grub (sudo grub2-mkconfig -o /boot/efi/EFI/fedora/grub.cfg) a few hours ago, all my devices are behaving so far.
Any further thoughts welcome.
@LDW Are you runing tlp setting to save the battery life? In my case, I see that my disk expansion card doesn’t recognize when starting the Fedora 36. It was recognized in a different port in the past. I suspect it is because of the tlp setting to auto-suspend the USB.
Fedora 36 is working reasonably ok on my Framework laptop (upgraded Intel 12th gen).
The only issues that I found were:
I am also getting this (on my 12th gen laptop) but I don’t really see any other issues and I guess Fedora 36 doesn’t officially support hibernation. I’m glad that it’s probably not a hardware fault given you see it as well.
I think this is fixed by adding module_blacklist=hid_sensor_hub to the kernel arguments as per the Fedora 36 setup guide. At least it works fine for me.
I am still having some pretty serious problems with my wifi card. Over the last 2 weeks I get from 0-15 minutes after a restart before the wifi driver crashes and I have to restart before wifi will work again.
The last handful of system logs I get before wifi fails are:
wlp170s0: disconnect from AP c8:9e:43:b5:70:4b for new auth to c8:9e:43:6d:76:ab
wlp170s0: authenticate with c8:9e:43:6d:76:ab
wlp170s0: send auth to c8:9e:43:6d:76:ab (try 1/3)
wlp170s0: authenticated
wlp170s0: associate with c8:9e:43:6d:76:ab (try 1/3)
wlp170s0: RX ReassocResp from c8:9e:43:6d:76:ab (capab=0x1511 status=0 aid=4)
iwlwifi 0000:aa:00.0: Got NSS = 4 - trimming to 2
wlp170s0: associated
wlp170s0: Limiting TX power to 27 (30 - 3) dBm as advertised by c8:9e:43:6d:76:ab
iwlwifi 0000:aa:00.0: Error sending STATISTICS_CMD: time out after 2000ms.
iwlwifi 0000:aa:00.0: Current CMD queue read_ptr 947 write_ptr 948
------------[ cut here ]------------
Timeout waiting for hardware access (CSR_GP_CNTRL 0xffffffff)
WARNING: CPU: 4 PID: 933 at drivers/net/wireless/intel/iwlwifi/pcie/trans.c:2118 __iwl_trans_pcie_grab_nic_access+0x1ef/0x220 [iwlwifi]
Modules linked in: binfmt_misc tls uinput rfcomm snd_seq_dummy snd_hrtimer xt_MASQUERADE xt_mark nft_compat ip6table_nat tun nft_objref nf_conntrack_netbios_ns nf_conntrack_broadcast nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_ct nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 ip_set nf_tables nfnetlink snd_hda_codec_hdmi qrtr bnep sunrpc snd_sof_pci_intel_tgl snd_sof_intel_hda_common soundwire_intel soundwire_generic_allocation soundwire_cadence snd_sof_intel_hda snd_sof_pci snd_sof_xtensa_dsp snd_sof iwlmvm snd_sof_utils snd_soc_hdac_hda snd_hda_ext_core snd_soc_acpi_intel_match snd_soc_acpi mac80211 soundwire_bus snd_soc_core snd_hda_codec_realtek snd_hda_codec_generic intel_tcc_cooling snd_compress x86_pkg_temp_thermal ac97_bus libarc4 ledtrig_audio intel_powerclamp snd_pcm_dmaengine iTCO_wdt intel_pmc_bxt coretemp iTCO_vendor_support mei_hdcp mei_pxp pmt_telemetry snd_hda_intel pmt_class
intel_rapl_msr kvm_intel snd_intel_dspcfg snd_intel_sdw_acpi snd_hda_codec iwlwifi kvm iwlmei snd_hda_core snd_hwdep snd_seq vfat irqbypass fat intel_cstate snd_seq_device intel_uncore cfg80211 snd_pcm uvcvideo btusb pcspkr wmi_bmof videobuf2_vmalloc snd_timer btrtl videobuf2_memops videobuf2_v4l2 i2c_i801 btbcm snd btintel videobuf2_common i2c_smbus mei_me btmtk soundcore mei videodev joydev bluetooth idma64 mc hid_sensor_als hid_sensor_trigger hid_sensor_iio_common industrialio_triggered_buffer kfifo_buf ecdh_generic processor_thermal_device_pci_legacy rfkill thunderbolt industrialio intel_vsec processor_thermal_device processor_thermal_rfim processor_thermal_mbox processor_thermal_rapl intel_rapl_common igen6_edac intel_soc_dts_iosf int3403_thermal int340x_thermal_zone int3400_thermal acpi_thermal_rel acpi_pad zram hid_sensor_hub intel_ishtp_hid i915 drm_buddy drm_dp_helper nvme intel_ish_ipc hid_multitouch ucsi_acpi crct10dif_pclmul crc32_pclmul crc32c_intel
ghash_clmulni_intel typec_ucsi serio_raw nvme_core intel_ishtp ttm typec wmi i2c_hid_acpi i2c_hid video pinctrl_tigerlake ip6_tables ip_tables fuse
CPU: 4 PID: 933 Comm: NetworkManager Not tainted 5.18.17-200.fc36.x86_64 #1
Hardware name: Framework Laptop/FRANBMCP06, BIOS 03.02 07/01/2021
RIP: 0010:__iwl_trans_pcie_grab_nic_access+0x1ef/0x220 [iwlwifi]
Code: 48 89 df e8 c3 b1 fe ff 4c 89 f7 e8 5b aa 78 d0 e9 e3 fe ff ff 89 c6 48 c7 c7 18 c1 61 c1 c6 05 21 fe 03 00 01 e8 d6 ab 70 d0 <0f> 0b e9 01 ff ff ff 48 8b 7b 40 48 c7 c2 80 c1 61 c1 31 f6 e8 08
RSP: 0018:ffffab22410c3578 EFLAGS: 00010296
RAX: 000000000000003d RBX: ffff8c3905040028 RCX: 0000000000000000
RDX: 0000000000000202 RSI: ffffffff9266f80c RDI: 00000000ffffffff
RBP: 00000000ffffffff R08: 0000000000000000 R09: ffffab22410c33b0
R10: 0000000000000003 R11: ffffffff92f453e8 R12: 0000000000000001
R13: 0000000000000000 R14: ffff8c3905042974 R15: 0000000000000011
FS: 00007fd0d3dd7500(0000) GS:ffff8c40af900000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 000000c000bc6000 CR3: 000000010bb50001 CR4: 0000000000770ee0
PKRU: 55555554
I am fully up to date via dnf upgrade my kernal version is 5.19.6-200.fc36.x86_64 wifi power management is disabled.
I have probably spent 3 hours searching this forum looking for a solution and nothing so far has worked. Any pointers would be helpful
Hey y’all! A few things on:
For those of you that haven’t seen it, there’s a great article on how to setup hibernation with btrfs/zram:
It started from this wonderful GitHub Gist:
I have hibernation/suspend-then-hibernate setup on my system where it will first S0ix sleep and then 2 hours later hibernate. Also hibernates at I believe 7% battery. It’s been working flawlessly since Fedora 35-36 until a few months ago, where sometimes on hibernation resumption, the system would freeze on a black screen. I troubleshooted today, and here’s my comment/solution:
If you have hibernation resumption issues, I recommend reading that, but to summarize so these words are populated in this forums search:
I added this to my kernel parameters to see debug logs upon system/kernel boot and hibernation resumption:
ignore_loglevel=1 initcall_debug=1
And saw that with resumption, my system froze here:
intel_ish_ipc 0000:00:12.0: [ishtp-ish]: Timed out waiting for FW-initiated reset
intel_ish_ipc 0000:00:12.0: ISH: hw start failed.
initcall ish_driver_init+0x0/0x1000 [intel_ish_ipc] returned 0 after 219091 usecs
To fix the issue, I simply blacklisted the intel_ish_ipc module by adding this to the kernel parameter:
modprobe.blacklist=intel_ish_ipc
Though it should also work by adding this to e.g. /etc/modprobe.d/blacklist.conf (or best-practice-naming as /etc/modprobe.d/intel_ish_ipc.conf) + rebooting:
blacklist intel_ish_ipc
After blacklisting, finally my system no longer freezes on that module and resumes normally!
Though it seems that the intel_ish_ipc module still loads afterwards since it’s a dependent module for intel_ishtp:
lsmod | grep ish
intel_ishtp 61440 2 intel_ishtp_hid,intel_ish_ipc
@ the Framework team
I’m still not sure if my issue was caused by a kernel regression, a Framework BIOS update, a Fedora update, or something else. These all kind of happened around the time this issue popped up. But I do remember this started happening right around upgrading to BIOS 3.09/3.10.
It could also be from a recent Linux kernel regression (a Kernel bug report I found), as I’ve seen reports on different systems (Ubuntu 22.04 Dell XPS 9500 and Arch Linux).
Is there any downside to blacklisting the intel_ish_ipc module? Though it seems to get loaded later as a dependent module for intel_ishtp anyways.
Everything still seems to work normally on my system + hibernation resumption works everytime again.
Just took a look at your post and saw that your BIOS version is quite old. I don’t think there were any BIOS fixes regarding wifi, but might want to update for other reasons.
I can confirm that I haven’t had any issues with the Intel AX210 on 5.19.6-200.fc36.x86_64.
Here are some troubleshooting questions:
I just quickly typed/threw out a bunch of steps I usually run through in my head, and it can get deeper than that, so if @Freemasen have any questions lmk since I might be missing something.
@Michael_Wu thanks for the reply!
I have never been able to get my laptop to have stable wifi (longest I’ve gone w/o losing the connection is 30 minutes). I tried updating the bios today and the problem persists. I also tried a fresh install of Ubuntu 22.04 and manually placing the intel driver into /lib/firmware, also no change.
I don’t have any problems with any of the other devices I have connected to my wifi.
Unfortunately I do not have another laptop or wifi card to test either option out (though I might buy a new wifi card this weekend since I don’t have a lot of use for a laptop w/o wifi).
Thanks again for the reply
@Freemasen sure thing!
Issue persists on a fresh install of Ubuntu as well as using another driver version? If the issue persists on a fresh install of Fedora and Ubuntu, I wouldn’t think it’s due to software unless you’re running into an issue that spans the two kernel/driver versions.
You can also try a Windows installation to rule out Linux as the cause.
If it also happens in Windows, then I’d think it’s likely a hardware issue (unless it’s just an incompatibility with your wireless router).
If you haven’t already, ensure the physical antennas are hooked up properly to the wifi chip.
But yeah testing with a new wifi card’s an easy way to shed some serious light into the issue.
Yup! A laptop without wifi? Ahhhhhh that’s scary, goodspeed!
Edit: quick searching around for the error message in your log
This person (different wifi card/laptop) removed the wifi card and reinserted which fixed the issue: 91171 – iwlwifi: Timeout waiting for hardware access (CSR_GP_CNTRL 0xffffffff) - MWG100226667
Thought I would share this for anyone interested: Decrypt LUKS volumes with a TPM on Fedora 35+ · GitHub
Got it working on my FW 12th gen in Fedora 36 without a hitch.
Note: you do give up the ability to hibernate with this from my understanding (or at least makes it much more difficult). Personally, I felt like this was something I wanted a little more (versus hibernation). I’m sure there are some security pros that would say this is a bad idea versus typing in a password at boot to decrypt in addition to your account. I wanted a linux experience that was closer to what I was coming from with Windows and macOS where you only do your login.
Anyways, hope some of you find it helpful 
It could probably work with this kernel patch and parameter: Enable hibernate during lockdown · GitHub (found via windows - Patching the kernel to allow hibernation with secure-boot enabled - Unix & Linux Stack Exchange)