Changing cstate is a good idea, but based on what I am told from a representative of the Fedora project, it has affected other distros and has been difficult to replicate. I’m on a 12th Gen Framework, on Fedora 37, latest kernel - zero freezing. But I also have nothing attached.
Fedora dumped a bunch of f37 updates in last 12-24 hours. I got about 34 updates – lots of firmware packages. Noteworthy: kernel-6.0.14-300.fc37 and intel-gpu-firmware-20221214-145.fc37 and intel-gpu-firmware-20221109-144.fc37.
Made no real changes for me. After a fresh boot, no switches, usually with 5 min after gdm login hang, with lots of trash on my screen. This happened after these updates, too.
Rebooting with max_cstate=1 and max_cstate=2, AFAIK, is stable. max_cstate=3, had a lock up (but not graphics artifacts on screen) after about an hour or so. This is primarily browsing with chrome (google variant); some www/youtube videos, really not much else – machine too unreliable to work on at this point.
I did, for a work day, have this rig using HDMI monitor and then a thunderbolt hub with a 2nd HDMI driving another monitor, as well as ethernet rolling. This surprisingly worked out really well, for like 8 hours – primarily local browsing and then a VPN to my corporate with an RDC session.
I don’t know if some poison came in some dnf update – but hasn’t been stable since 12/19 and was only moderately stable since inception of this laptop on 12/15.
(will review thread to see how you/others got to some stability – maybe I missed something; the cstate thing was picked up from some other thread out on the WWW )
HTH someone
If it’s freezing while attached to something (hub, monitor, etc), I’d start by testing stability without those things. Then if it’s stable, we know that updates may have hosed something in terms of the extras attached.
Checking dmesg when possible or even better if it’s completely freezes, checking the journalctl.
But if a distro is unstable, begin stripping things away as to identify the trigger point (even if caused by an update). It’s a good starting point in conjunction to checking the journalctl after freezing.
As it sits now, there should be no reason to add cstate parameters for stability. When a specific kernel breaks something, sure, but otherwise if it’s needed, it’s time to revisit a previously working kernel.
I will run updates tonight to catch my Framework up to the latest. See if I can replicate it. I will not be connecting to a dock or display because I want to emulate Framework issues first, vs attached device compatibility issues. That’s after I establish the laptop is golden, first.
1 Like
Agreed, actually except for the 1 day of ‘success’, with hub, monitors, etc, I usually run the laptop with nothing plugged in. Sigh, almost seemed more stable with the hub and stuff – but not enough for a daily driver.
FWIW: last dnf update (230 PM est 12/23/2022) contained, among other things:
Upgrade xorg-x11-drv-intel-2.99.917-54.20210115.fc37.x86_64 @updates
Upgraded xorg-x11-drv-intel-2.99.917-53.20200205.fc37.x86_64 @@System
I applied that and after a naked boot (just laptop, no peripherals), almost immediate hang/crudded-up screen. I added back in intel_idle.max_cstate=2; still seems to ok for me at the moment, no enable_psr=0, no Huc/Guc tuning.
HTH
I don’t know if this will add something useful to the discussion here but hopefully all small details count.
I just experienced another freeze in the gnome settings in debian sid with a 12th gen frame.work laptop.
keyboard and mouse seemed to be non-responsive, the sound (music) was still going and I could hear my fan running at maximum.
I was able to ssh into the laptop from another computer. from there I could see in dmesg a line mentioning “GPU HANG” like mentioned in #24. the process gnome-shell was running at 100% cpu and when I straced it I could see the following line coming out repeatedly very fast:
ioctl(12, DRM_IOCTL_SYNCOBJ_WAIT, 0x7fff22383b40) = 0
Then I used kill -9 on the gnome-shell process and got brought back to gdm on the laptop so I could start using it again.
@Fred_Welland Hmm, I’ve been on my 12th gen all day, and here is what I have. Flawless performance.
- Fedora 37, 6.0.14-300.fc37.x86_64
- Used heavily on Battery and AC
- Firefox and Brave open, multiple tabs both browsers
- Using Wayland
- See attached images
1 Like
Finally had some sort of error, but unless this repeats itself, I don’t think it’s worth noting. Connected to AC power, wifi showed connected and then fell down.
If this error repeats, I’ll note it to the Fedora devs.
iwlwifi 0000:00:14.3: Microcode SW error detected. Restarting 0x0.
iwlwifi 0000:00:14.3: Start IWL Error Log Dump:
iwlwifi 0000:00:14.3: Transport status: 0x0000004A, valid: 6
iwlwifi 0000:00:14.3: Loaded firmware version: 72.daa05125.0 so-a0-hr-b0-72.ucode
iwlwifi 0000:00:14.3: 0x00000071 | NMI_INTERRUPT_UMAC_FATAL
iwlwifi 0000:00:14.3: 0x00808210 | trm_hw_status0
iwlwifi 0000:00:14.3: 0x00000000 | trm_hw_status1
iwlwifi 0000:00:14.3: 0x004D8C8A | branchlink2
iwlwifi 0000:00:14.3: 0x004D769A | interruptlink1
iwlwifi 0000:00:14.3: 0x004D769A | interruptlink2
iwlwifi 0000:00:14.3: 0x00015114 | data1
iwlwifi 0000:00:14.3: 0x00000010 | data2
iwlwifi 0000:00:14.3: 0x00000000 | data3
iwlwifi 0000:00:14.3: 0x8AC18C68 | beacon time
iwlwifi 0000:00:14.3: 0x5801462D | tsf low
iwlwifi 0000:00:14.3: 0x000000E8 | tsf hi
iwlwifi 0000:00:14.3: 0x00000000 | time gp1
iwlwifi 0000:00:14.3: 0xA61A69AA | time gp2
iwlwifi 0000:00:14.3: 0x00000001 | uCode revision type
iwlwifi 0000:00:14.3: 0x00000048 | uCode version major
iwlwifi 0000:00:14.3: 0xDAA05125 | uCode version minor
iwlwifi 0000:00:14.3: 0x00000370 | hw version
iwlwifi 0000:00:14.3: 0x00489002 | board version
iwlwifi 0000:00:14.3: 0x802AFC03 | hcmd
iwlwifi 0000:00:14.3: 0x24020000 | isr0
iwlwifi 0000:00:14.3: 0x01000000 | isr1
iwlwifi 0000:00:14.3: 0x48F00002 | isr2
iwlwifi 0000:00:14.3: 0x00C3080C | isr3
iwlwifi 0000:00:14.3: 0x00000000 | isr4
iwlwifi 0000:00:14.3: 0x058F001C | last cmd Id
iwlwifi 0000:00:14.3: 0x00015114 | wait_event
iwlwifi 0000:00:14.3: 0x00000080 | l2p_control
iwlwifi 0000:00:14.3: 0x00010034 | l2p_duration
iwlwifi 0000:00:14.3: 0x0000003F | l2p_mhvalid
iwlwifi 0000:00:14.3: 0x00CE18B8 | l2p_addr_match
iwlwifi 0000:00:14.3: 0x00000009 | lmpm_pmg_sel
iwlwifi 0000:00:14.3: 0x00000000 | timestamp
iwlwifi 0000:00:14.3: 0x0000284C | flow_handler
iwlwifi 0000:00:14.3: Start IWL Error Log Dump:
iwlwifi 0000:00:14.3: Transport status: 0x0000004A, valid: 7
iwlwifi 0000:00:14.3: 0x20003463 | ADVANCED_SYSASSERT
iwlwifi 0000:00:14.3: 0x00000000 | umac branchlink1
iwlwifi 0000:00:14.3: 0x8045E934 | umac branchlink2
iwlwifi 0000:00:14.3: 0x804694E2 | umac interruptlink1
iwlwifi 0000:00:14.3: 0x00000000 | umac interruptlink2
iwlwifi 0000:00:14.3: 0x5801461F | umac data1
iwlwifi 0000:00:14.3: 0xA61A699B | umac data2
iwlwifi 0000:00:14.3: 0xB2BF92AD | umac data3
iwlwifi 0000:00:14.3: 0x00000048 | umac major
iwlwifi 0000:00:14.3: 0xDAA05125 | umac minor
iwlwifi 0000:00:14.3: 0xA61A69A4 | frame pointer
iwlwifi 0000:00:14.3: 0xC0885DA8 | stack pointer
iwlwifi 0000:00:14.3: 0x008C010D | last host cmd
iwlwifi 0000:00:14.3: 0x00000000 | isr status reg
iwlwifi 0000:00:14.3: IML/ROM dump:
iwlwifi 0000:00:14.3: 0x00000B03 | IML/ROM error/state
iwlwifi 0000:00:14.3: 0x00004FE3 | IML/ROM data1
iwlwifi 0000:00:14.3: 0x00000080 | IML/ROM WFPM_AUTH_KEY_0
iwlwifi 0000:00:14.3: Fseq Registers:
iwlwifi 0000:00:14.3: 0x60000000 | FSEQ_ERROR_CODE
iwlwifi 0000:00:14.3: 0x80350002 | FSEQ_TOP_INIT_VERSION
iwlwifi 0000:00:14.3: 0x00150000 | FSEQ_CNVIO_INIT_VERSION
iwlwifi 0000:00:14.3: 0x0000A482 | FSEQ_OTP_VERSION
iwlwifi 0000:00:14.3: 0x00000003 | FSEQ_TOP_CONTENT_VERSION
iwlwifi 0000:00:14.3: 0x4552414E | FSEQ_ALIVE_TOKEN
iwlwifi 0000:00:14.3: 0x00080400 | FSEQ_CNVI_ID
iwlwifi 0000:00:14.3: 0x01300504 | FSEQ_CNVR_ID
iwlwifi 0000:00:14.3: 0x00080400 | CNVI_AUX_MISC_CHIP
iwlwifi 0000:00:14.3: 0x01300504 | CNVR_AUX_MISC_CHIP
iwlwifi 0000:00:14.3: 0x05B0905B | CNVR_SCU_SD_REGS_SD_REG_DIG_DCDC_VTRIM
iwlwifi 0000:00:14.3: 0x0000025B | CNVR_SCU_SD_REGS_SD_REG_ACTIVE_VDIG_MIRROR
Thanks @Gabriel_Filion, different distro and likely different with a number of libraries as well since it’s Debian (not sure which version). But I would agree that GNOME has seen some issues that will likely see solutions in the updates.
Also worth noting and likely why I’ve had a great experience - Fedora Freezes and Flickering on newer Kernels - #40 by nadb
This is Fedora 37 and matches my config.
Another item to look at when testing is extensions. Turn them all off first and then slowly add. A lot of these troubles are just reminiscent of other issues I have seen elsewhere and quite often they are tied to dash-to-panel, desktop icon related extension, system tray type extensions, anything moving the dash elsewhere or adding old functionality is more likely to create, contirbute, or enhance graphics related issues.
2 Likes
Completely agree, it’s been on my growing list as well. Because as you point out, create, contribute to, or enhance graphics related issues.
100% agree.
1 Like
@Matt_Hartley you should try using chrome or something chromium based on your framework laptop.
I don’t think I’ve had a hard freeze while using only firefox. But switching to chrome will trigger one. I also noticed some weird things related to plugging in power.
Hi @Kelby_Faessler, no freezing on mine. Other users. 
Thanks for the insights you’ve noted, appreciated!
No such issues with Chromium or Vivaldi, with Firefox running with Discord Video going.
Additional Info: I am using a dock with two external hdmi monitors at 1920x1080. Intel i7-1260p, 64GB RAM, P41 SK Hynix NVME. Experiencing no issues at this time on battery or on AC. Fedora 37 (updated daily for now), Wayland, Gnome. Have not had a hard freeze in two weeks now.
This looks like Screen freeze because gnome-shell waits DRM_IOCTL_SYNCOBJ_WAIT forever in Wayland mode when resource is tight (#6851) · Issues · drm / intel · GitLab , which seems to be one possible cause of the freezes, but there are freezes unrelated to this.
Currently trying to run with minimal extensions and without the i915 kernel option. So far ran for a good couple hours with Chrome, Discord w/ video and screen share, and more without any issue. Perhaps my two graphical extensions have some connection to the freezes I’ve been experiencing. 
1 Like
Out of curiosity which extensions did you turn off?
I don’t use any extensions and I still get freezes
Initially all but eventually turned all back on except “Gnome 4x UI Improvements” and “Blur my Shell”. My finding are unfortunately inconclusive and out of convenience I re-enabled the i915 fix.
1 Like