Input freezes, screen freezes, everything else is fine, fans go wild

elaiolado · 2023-07-14 10:28:45

I've a recent Arch installation with an encrypted file system. It's my first time installing and using an encrypted file system. The entire `/` is encrypted except for `/boot`. It's been randomly crashing since the installation, sometimes once every two or three days; sometimes twice in a single day. I will describe the crash:

1) keyboard and mouse (actually a trackball) stop working;
2) image freezes;
3) if audio is playing, it keeps playing; I've been able to continue a call on Google Meet while input and image were frozen;
4) I have an ssh server running and it keeps running after the crash; I was able to ssh into a frozen system (from another laptop) and check cpu and memory - everything is fine;
5) after a few minutes of input and image frozen, laptop fans go wild (really really loud) (cpu usage is fine, unrelated to the fans' activity) and then everything stops working for real (sound, ssh etc.);
6) at this point, rebooting is the only option;

Note: I mostly use the laptop at home for work, however recently I had a 2 weeks travel and brought my laptop with me for remote work. Unusually it didn't crash even once during those 2 weeks. After coming back home, it crashed right away. The only difference I can think of between working at home and working while travelling is the presence of an external monitor when at home. I'm thinking about working without an external monitor again for a while just to see what happens.

## Technical aspects

Laptop: Dell Precision 3571
CPU: 12th Gen Intel(R) Core(TM) i7-12800H
GPU: Nvidia RTX A1000
Driver: nvidia
External Monitor: Dell P2422H
WM: i3

## Files

Output of "journalctl -b -1" after a crash: https://pastebin.com/N9Zwf6cy
(note: I think 03:48 is the time when it crashed, there's an error there, but I'm pretty sure that that error wasn't there other times when I saw it, it's the first time I see this! I'll keep an eye open for it next time)

This is the Xorg.0.log downloaded from a frozen system when sshing into it from outside: https://pastebin.com/4xakHZfu

Note: journalctl -b -1 and Xorg.0.log are not from the same day.

## Questions

1) What other information should I look for that could give me a clue on what's happening?
2) Can I configure xorg to log a more readable timestamp instead of logging that fancy number?

Thanks!

Last edited by elaiolado (2023-07-14 15:57:02)

elaiolado · 2023-07-16 08:47:59

Another freeze. The same error in journalctl, apparently related.

Jul 16 05:25:07 rstation kernel: ------------[ cut here ]------------
Jul 16 05:25:07 rstation kernel: WARNING: CPU: 4 PID: 1082 at mm/gup.c:1101 __get_user_pages+0x57f/0x680
Jul 16 05:25:07 rstation kernel: Modules linked in: tun snd_hda_codec_hdmi snd_ctl_led snd_hda_codec_realtek snd_hda_codec_generic hid_sensor_custom_intel_hinge hid_sensor_gyro_3d hid_sensor_rotation hid_sensor_als hid_sensor_accel_3d hid_sensor_trigger industrialio_triggered_buffer kfifo_buf hid_sensor_iio_common industrialio hid_sensor_custom hid_sensor_hub nvidia_drm(POE) ccm nvidia_modeset(POE) algif_aead des_generic libdes ecb algif_skcipher cmac md4 algif_hash af_alg intel_ishtp_hid snd_sof_pci_intel_tgl snd_sof_intel_hda_common soundwire_intel soundwire_cadence snd_sof_intel_hda_mlink snd_sof_intel_hda snd_sof_pci snd_sof_xtensa_dsp snd_sof snd_sof_utils snd_soc_hdac_hda snd_hda_ext_core snd_soc_acpi_intel_match pkcs8_key_parser joydev snd_soc_acpi soundwire_generic_allocation nvidia_uvm(POE) soundwire_bus snd_soc_core i915 snd_compress ac97_bus intel_uncore_frequency intel_uncore_frequency_common snd_pcm_dmaengine iwlmvm hid_multitouch x86_pkg_temp_thermal intel_powerclamp dell_rbtn nvidia(POE) drm_buddy i2c_algo_bit snd_hda_intel
Jul 16 05:25:07 rstation kernel:  coretemp mac80211 btusb ttm snd_intel_dspcfg snd_usb_audio kvm_intel snd_intel_sdw_acpi iTCO_wdt btrtl dell_laptop libarc4 uvcvideo kvm videobuf2_vmalloc dell_wmi snd_hda_codec drm_display_helper intel_pmc_bxt snd_usbmidi_lib uvc btbcm processor_thermal_device_pci irqbypass dell_smbios btintel iwlwifi mei_hdcp mei_pxp dell_wmi_sysman iTCO_vendor_support dell_wmi_ddv videobuf2_memops snd_hda_core rapl processor_thermal_device dcdbas snd_rawmidi btmtk snd_hwdep cec snd_seq_device processor_thermal_rfim vfat firmware_attributes_class videobuf2_v4l2 intel_cstate intel_rapl_msr ledtrig_audio dell_wmi_descriptor wmi_bmof bluetooth spi_nor videodev snd_pcm ucsi_acpi fat intel_uncore intel_gtt intel_lpss_pci psmouse snd_timer pcspkr cfg80211 typec_ucsi intel_lpss video videobuf2_common i2c_i801 ecdh_generic mei_me processor_thermal_mbox mtd e1000e snd mei i2c_smbus mc typec rfkill idma64 intel_ish_ipc processor_thermal_rapl thunderbolt soundcore intel_ishtp roles intel_rapl_common igen6_edac i2c_hid_acpi
Jul 16 05:25:07 rstation kernel:  int3403_thermal i2c_hid int340x_thermal_zone intel_hid int3400_thermal wmi dell_smo8800 sparse_keymap acpi_tad mousedev acpi_thermal_rel acpi_pad mac_hid fuse loop bpf_preload ip_tables x_tables ext4 crc32c_generic crc16 mbcache jbd2 usbhid dm_crypt cbc encrypted_keys trusted asn1_encoder tee dm_mod nvme nvme_core nvme_common crct10dif_pclmul serio_raw crc32_pclmul crc32c_intel atkbd rtsx_pci_sdmmc polyval_clmulni libps2 polyval_generic mmc_core vivaldi_fmap gf128mul ghash_clmulni_intel sha512_ssse3 aesni_intel crypto_simd spi_intel_pci cryptd rtsx_pci xhci_pci spi_intel vmd xhci_pci_renesas i8042 serio
Jul 16 05:25:07 rstation kernel: CPU: 4 PID: 1082 Comm: chrome_crashpad Tainted: P           OE      6.4.2-arch1-1 #1 9be134a67309bc8a94131d6d8445f4f91f7fe038
Jul 16 05:25:07 rstation kernel: Hardware name: Dell Inc. Precision 3571/0YRYMK, BIOS 1.9.0 10/07/2022
Jul 16 05:25:07 rstation kernel: RIP: 0010:__get_user_pages+0x57f/0x680
Jul 16 05:25:07 rstation kernel: Code: d0 0f 1f 00 e9 cb fd ff ff 48 03 7d 48 e9 ca fb ff ff 48 81 e1 00 f0 ff ff e9 4e fc ff ff 48 81 e2 00 f0 ff ff e9 b8 fc ff ff <0f> 0b e9 24 fb ff ff f6 c3 04 0f 85 50 ff ff ff 49 8b 3f 48 89 f8
Jul 16 05:25:07 rstation kernel: RSP: 0018:ffffb52fc39b3bb8 EFLAGS: 00010202
Jul 16 05:25:07 rstation kernel: RAX: ffff9c49dc742e70 RBX: 000000000005000a RCX: 00007ffc28feafff
Jul 16 05:25:07 rstation kernel: RDX: 0000000000000000 RSI: 00007f1e4f1d9000 RDI: ffff9c49d6baa0c0
Jul 16 05:25:07 rstation kernel: RBP: ffff9c49c006af40 R08: ffff9c49cb53a408 R09: 0000000000000001
Jul 16 05:25:07 rstation kernel: R10: ffff9c49cb53a480 R11: ffff9c49cb53a40c R12: 0000000000000000
Jul 16 05:25:07 rstation kernel: R13: ffff9c49dc742e70 R14: ffffb52fc39b3c7c R15: ffffb52fc39b3c7c
Jul 16 05:25:07 rstation kernel: FS:  00007f3063930800(0000) GS:ffff9c513f300000(0000) knlGS:0000000000000000
Jul 16 05:25:07 rstation kernel: CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
Jul 16 05:25:07 rstation kernel: CR2: 000038e00048c300 CR3: 000000013153c000 CR4: 0000000000f50ee0
Jul 16 05:25:07 rstation kernel: PKRU: 55555554
Jul 16 05:25:07 rstation kernel: Call Trace:
Jul 16 05:25:07 rstation kernel:  <TASK>
Jul 16 05:25:07 rstation kernel:  ? __get_user_pages+0x57f/0x680
Jul 16 05:25:07 rstation kernel:  ? __warn+0x81/0x130
Jul 16 05:25:07 rstation kernel:  ? __get_user_pages+0x57f/0x680
Jul 16 05:25:07 rstation kernel:  ? report_bug+0x171/0x1a0
Jul 16 05:25:07 rstation kernel:  ? handle_bug+0x3c/0x80
Jul 16 05:25:07 rstation kernel:  ? exc_invalid_op+0x17/0x70
Jul 16 05:25:07 rstation kernel:  ? asm_exc_invalid_op+0x1a/0x20
Jul 16 05:25:07 rstation kernel:  ? __get_user_pages+0x57f/0x680
Jul 16 05:25:07 rstation kernel:  ? __get_user_pages+0x8a/0x680
Jul 16 05:25:07 rstation kernel:  get_user_pages_remote+0x14a/0x400
Jul 16 05:25:07 rstation kernel:  __access_remote_vm+0x1b0/0x400
Jul 16 05:25:07 rstation kernel:  mem_rw.isra.0+0x10b/0x1c0
Jul 16 05:25:07 rstation kernel:  vfs_read+0xa9/0x320
Jul 16 05:25:07 rstation kernel:  ? vfs_read+0xa9/0x320
Jul 16 05:25:07 rstation kernel:  __x64_sys_pread64+0x98/0xd0
Jul 16 05:25:07 rstation kernel:  do_syscall_64+0x5d/0x90
Jul 16 05:25:07 rstation kernel:  ? syscall_exit_to_user_mode+0x1b/0x40
Jul 16 05:25:07 rstation kernel:  ? do_syscall_64+0x6c/0x90
Jul 16 05:25:07 rstation kernel:  ? __x64_sys_pread64+0xa8/0xd0
Jul 16 05:25:07 rstation kernel:  ? syscall_exit_to_user_mode+0x1b/0x40
Jul 16 05:25:07 rstation kernel:  ? do_syscall_64+0x6c/0x90
Jul 16 05:25:07 rstation kernel:  ? do_syscall_64+0x6c/0x90
Jul 16 05:25:07 rstation kernel:  ? do_syscall_64+0x6c/0x90
Jul 16 05:25:07 rstation kernel:  ? do_syscall_64+0x6c/0x90
Jul 16 05:25:07 rstation kernel:  ? do_syscall_64+0x6c/0x90
Jul 16 05:25:07 rstation kernel:  entry_SYSCALL_64_after_hwframe+0x72/0xdc
Jul 16 05:25:07 rstation kernel: RIP: 0033:0x7f306350db67
Jul 16 05:25:07 rstation kernel: Code: 08 89 3c 24 48 89 4c 24 18 e8 85 bc f8 ff 4c 8b 54 24 18 48 8b 54 24 10 41 89 c0 48 8b 74 24 08 8b 3c 24 b8 11 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 31 44 89 c7 48 89 04 24 e8 d5 bc f8 ff 48 8b
Jul 16 05:25:07 rstation kernel: RSP: 002b:00007fff88973190 EFLAGS: 00000293 ORIG_RAX: 0000000000000011
Jul 16 05:25:07 rstation kernel: RAX: ffffffffffffffda RBX: 00005577c99be710 RCX: 00007f306350db67
Jul 16 05:25:07 rstation kernel: RDX: 0000000000001000 RSI: 00007fff889735b0 RDI: 0000000000000007
Jul 16 05:25:07 rstation kernel: RBP: 00007fff889733a0 R08: 0000000000000000 R09: 000038e000226040
Jul 16 05:25:07 rstation kernel: R10: 00007f1e4f1d8880 R11: 0000000000000293 R12: 00007fff889735b0
Jul 16 05:25:07 rstation kernel: R13: 000038e00023e640 R14: 00007f1e4f1d8880 R15: 0000000000001000
Jul 16 05:25:07 rstation kernel:  </TASK>
Jul 16 05:25:07 rstation kernel: ---[ end trace 0000000000000000 ]---

Note that this error message could be a consequence of the issue and not the cause of the issue.

And I thought about another thing that changed while I was travelling: the network I was connected to. Will investigate more.

Last edited by elaiolado (2023-07-16 12:10:34)

elaiolado · 2023-07-24 08:45:17

I spent another week without an external monitor and had no freezes. The evidence of a relation is becoming stronger.

seth · 2023-07-24 13:29:41

Please post the complete system journal and results or restarting the graphical.target here, thanks.

elaiolado · 2023-07-30 04:39:42

seth wrote:

Please post the complete system journal and results or restarting the graphical.target here, thanks.

It took me a few days to experience another freeze. I ssh'd into the frozen system and did it.

Journal: http://ix.io/4BPb
Restarting `graphical.target` didn't do anything.

Thanks!

seth · 2023-07-30 08:11:52

There isn't that much new

Jul 30 01:28:07 rstation kernel: CPU: 0 PID: 92868 Comm: chrome_crashpad Tainted: P           OE      6.4.4-arch1-1 #1 655744e6f70dbd2f57b072f7158d7c5b4468b4ff

happens out of the blue, then you ssh in that's it.
There's

Jul 29 22:17:15 rstation kernel: i915 0000:00:02.0: [drm] *ERROR* The master control interrupt lied (DE MISC)!
Jul 29 22:17:15 rstation kernel: i915 0000:00:02.0: [drm] *ERROR* The master control interrupt lied (DE PIPE)!

but that's hours ahead.

Since this is a hybrid graphics system, but your nvidia chip doesn't seem to be a VGA device (mere 3D accelerator) and from the othre thread

I spent the entire week working without an external monitor again, and had no freeze.

What exactly is the graphical session and how're the hybrid GPUs configured?
In doubt please post your Xorg log, https://wiki.archlinux.org/title/Xorg#General

elaiolado · 2023-07-30 17:35:25

seth wrote:

There isn't that much new
Jul 30 01:28:07 rstation kernel: CPU: 0 PID: 92868 Comm: chrome_crashpad Tainted: P           OE      6.4.4-arch1-1 #1 655744e6f70dbd2f57b072f7158d7c5b4468b4ff
happens out of the blue, then you ssh in that's it.
There's
Jul 29 22:17:15 rstation kernel: i915 0000:00:02.0: [drm] *ERROR* The master control interrupt lied (DE MISC)!
Jul 29 22:17:15 rstation kernel: i915 0000:00:02.0: [drm] *ERROR* The master control interrupt lied (DE PIPE)!
but that's hours ahead.
Since this is a hybrid graphics system, but your nvidia chip doesn't seem to be a VGA device (mere 3D accelerator) and from the othre thread
I spent the entire week working without an external monitor again, and had no freeze.
What exactly is the graphical session and how're the hybrid GPUs configured?
In doubt please post your Xorg log, https://wiki.archlinux.org/title/Xorg#General

Unfortunately I forgot to download xorg's log file while sshd into the frozen machine, but I can give you the `/var/log/Xorg.0.log` from my currently running session: https://pastebin.com/sqZg1hHR

I don't really understand how to answer "what exactly is the graphical session?", do you mean the window manager/desktop environment I'm using? if that's the case, it's i3wm. I start X manually using startx. I have `exec i3` in my `~/.xinitrc`. I run xrandr from my i3 config file automatically at startup. If I can provide more useful information, please tell me and I'll look for it.

Regarding the hardware, the laptop's CPU has integrated graphics (Intel Iris Xe Graphics), but the laptop also has a dedicated GPU (Nvidia RTX A1000). After installing Arch, it was working out of the box, but it was loading the "nouveau" driver (assessed by running lspci -v). I followed the instructions from Arch's wiki on installing the proper nvidia driver (install the nvidia package, edit `mkinitcpio.conf`, regenerate initramfs) and it worked (now, the loaded driver is "nvidia").

I'm considering undoing those changes, running the nouveau driver for a while and see what happens. What do you think?

Thanks!

Last edited by elaiolado (2023-07-30 17:42:14)

seth · 2023-07-30 19:26:36

do you mean the window manager/desktop environment I'm using? if that's the case, it's i3wm. I start X manually using startx

Yes. I don't see how any mistake there could relate to the second monitor, but jsut to be sure, please post your entire xinitrc.

I'm considering undoing those changes, running the nouveau driver for a while and see what happens. What do you think?

All outputs are wired to the intel chip, so unless you're prime-running chromium on the nvidia chip, I don't think this would have any impact (and if the nvidid drivers would mess up the kernel or xorg stack you'd expect more wild and random issues)

There's also nothing fancy about the two outputs and you're not using xf86-video-intel, so no obvious problems there.
…

So one theory would be that the 2nd screen somehow crashes chromium, that triggers the crashpad handler, that crashes the system (perhaps through the GUP bug):
- Does "chromium --crash" crash the system right away, even w/ only one monitor?
- Does "chromium --crash --disable-breakpad --disable-crash-reporter"?

elaiolado · 2023-07-30 22:03:30

seth wrote:

do you mean the window manager/desktop environment I'm using? if that's the case, it's i3wm. I start X manually using startx
Yes. I don't see how any mistake there could relate to the second monitor, but jsut to be sure, please post your entire xinitrc.
I'm considering undoing those changes, running the nouveau driver for a while and see what happens. What do you think?
All outputs are wired to the intel chip, so unless you're prime-running chromium on the nvidia chip, I don't think this would have any impact (and if the nvidid drivers would mess up the kernel or xorg stack you'd expect more wild and random issues)
There's also nothing fancy about the two outputs and you're not using xf86-video-intel, so no obvious problems there.
…
So one theory would be that the 2nd screen somehow crashes chromium, that triggers the crashpad handler, that crashes the system (perhaps through the GUP bug):
- Does "chromium --crash" crash the system right away, even w/ only one monitor?
- Does "chromium --crash --disable-breakpad --disable-crash-reporter"?

My .xinitrc has one line: `exec i3`
My i3 config has this line: `exec_always --no-startup-id xrandr --output HDMI-1 --mode 1920x1080 --rate 60 --left-of eDP-1`

I'm thinking... should I even have --rate 60 set? I might remove that flag.

Regarding the chromium commands, running both just opens chromium with no effect at all (and it doesn't crash, which apparently it should?).

seth · 2023-07-31 06:42:14

Ok, your xinitrc is broken - not sure whether that's the cause for the chromium crash, but could be.
See the last link below and esp. the note what to include at least.

chromium --crash should have crashed chromium right away (what wuold have allowed deterministic tests), according to https://peter.sh/experiments/chromium-c … -switches/
But I tried and it indeed doesn't

WIth a little luck the other two switches work and you'll get a chromium crash w/o crashpad invocation from this.

elaiolado · 2023-08-01 00:31:10

seth wrote:

Ok, your xinitrc is broken - not sure whether that's the cause for the chromium crash, but could be.
See the last link below and esp. the note what to include at least.
chromium --crash should have crashed chromium right away (what wuold have allowed deterministic tests), according to https://peter.sh/experiments/chromium-c … -switches/
But I tried and it indeed doesn't
WIth a little luck the other two switches work and you'll get a chromium crash w/o crashpad invocation from this.

I'll add this "Note: At the very least, ensure that the last if block in /etc/X11/xinit/xinitrc is present in your ~/.xinitrc file to ensure that the scripts in /etc/X11/xinit/xinitrc.d are sourced." to my ~/.xinitrc. Would there be anything else?

And I'll use chromium with those flags and wait for the freeze.

Thanks.

seth · 2023-08-01 06:48:42

Would there be anything else?

Nope, the relevant part is to import the session environment w/ /etc/X11/xinit/xinitrc.d/50-systemd-user.sh

Edit: but, for clarification, just make sure that your xinitrc runs (ie. before the first line that "exec"'s anything) the entire block that includes all files in that path.

Last edited by seth (2023-08-01 06:50:11)

elaiolado · 2023-08-05 21:51:56

seth wrote:

Would there be anything else?
Nope, the relevant part is to import the session environment w/ /etc/X11/xinit/xinitrc.d/50-systemd-user.sh
Edit: but, for clarification, just make sure that your xinitrc runs (ie. before the first line that "exec"'s anything) the entire block that includes all files in that path.

Added the missing part to my `~/.xinitrc`. Freeze happened again.
Used chromium with `--disable-breakpad --disable-crash-reporter`. Freeze happened again (with the same warning showing up on journal).

elaiolado · 2023-08-05 22:13:25

I can reproduce this warning by accessing `chrome://crash`, however only the first time! When I access `chrome://crash` the second time, I don't see the warning anymore.

seth · 2023-08-06 07:09:21

"warning" or "freeze" as well?
If you make sure to kill every single chromium process, start w/ "--disable-breakpad --disable-crash-reporter" (you can btw. also add that to ~/.config/chromium-flags.conf )and open "chrome://crash", do you still get he crashpad / GUP warning and or the original freeze problem at all?

elaiolado · 2023-08-06 14:39:50

seth wrote:

"warning" or "freeze" as well?
If you make sure to kill every single chromium process, start w/ "--disable-breakpad --disable-crash-reporter" (you can btw. also add that to ~/.config/chromium-flags.conf )and open "chrome://crash", do you still get he crashpad / GUP warning and or the original freeze problem at all?

I can reproduce the warning, but not the freeze. And yes, I am using flags --disable-breakpad and --disable-crash-reporter.

Regarding how to set the flags, what I ended up doing was to add two aliases for the two chromium browsers I use:

alias chromium='chromium --disable-breakpad --disable-crash-reporter'
alias brave='brave --disable-breakpad --disable-crash-reporter'

elaiolado · 2023-08-06 15:11:28

elaiolado wrote:

seth wrote:
"warning" or "freeze" as well?
If you make sure to kill every single chromium process, start w/ "--disable-breakpad --disable-crash-reporter" (you can btw. also add that to ~/.config/chromium-flags.conf )and open "chrome://crash", do you still get he crashpad / GUP warning and or the original freeze problem at all?
I can reproduce the warning, but not the freeze. And yes, I am using flags --disable-breakpad and --disable-crash-reporter.
Regarding how to set the flags, what I ended up doing was to add two aliases for the two chromium browsers I use:
alias chromium='chromium --disable-breakpad --disable-crash-reporter'
alias brave='brave --disable-breakpad --disable-crash-reporter'

One more thing: I'm mentioning brave but actually this warning comes from chromium. Accessing chrome://crash in brave doesn't throw that warning.

seth · 2023-08-06 15:15:27

If there's still crashpad and the GUP warning, "--disable-breakpad --disable-crash-reporter" is likely ignored - and the freeze unrelated to any of that…

elaiolado · 2023-08-08 21:06:41

Update: I forced the error message by accessing chrome://crash and used the system as I do everyday until the freeze happened.

After some hours of normal usage, the freeze happened. And there was no chrome error in journal.

Conclusion: the error message seems to be an inocuous warning thrown specifically the first time chrome crashes. From the second crash onwards, chrome doesn't throw that warning anymore. And it doesn't affect the issue with the system getting frozen.

seth · 2023-08-09 07:18:21

https://wiki.archlinux.org/title/Kdump

elaiolado · 2023-10-24 06:14:54

Update:

1. I used the laptop without an external monitor for one month. Has no freezes.

2. I plugged in the external monitor. Froze right away and continued freezing for the next days.

3. I disabled the laptop's screen, leaving only the external monitor enabled. Been using like that for a few weeks and no freezes.

Conclusion: the issue seems to be related to having both screens enabled at the same time. If only one screen is enabled, it's fine.

seth · 2023-10-24 07:09:11

From teh xorg log in #7

[    76.361] (II) modeset(0): Output eDP-1 using initial mode 1920x1080 +0+0
[    76.361] (II) modeset(0): Output HDMI-1 using initial mode 1920x1080 +1920+0

The nvidia GPU doesn't looks like it has outputs at all (so not a reverse prime issue) and no output looks VRR capable.
Does the system freeze if you're running the output in clone-mode (ie. both display exactly the same thing)?

elaiolado · 2023-10-24 09:43:28

seth wrote:

From teh xorg log in #7
[    76.361] (II) modeset(0): Output eDP-1 using initial mode 1920x1080 +0+0
[    76.361] (II) modeset(0): Output HDMI-1 using initial mode 1920x1080 +1920+0
The nvidia GPU doesn't looks like it has outputs at all (so not a reverse prime issue) and no output looks VRR capable.
Does the system freeze if you're running the output in clone-mode (ie. both display exactly the same thing)?

Will see if I take some time to try the clone mode thing.

There's one detail I forgot to mention in my previous reply. Even if the system isn't freezing (when only one screen enabled), it still occasionally overheats - fans go wild for a few minutes (no freeze, no slowness) and then everything goes back to normal - out of nowhere.

seth · 2023-10-24 13:03:42

Does that correlate w/ increased CPU load? In what process?
Maybe https://bbs.archlinux.org/viewtopic.php?id=288723 ?

Arch Linux

#1 2023-07-14 10:28:45

Input freezes, screen freezes, everything else is fine, fans go wild

#2 2023-07-16 08:47:59

Re: Input freezes, screen freezes, everything else is fine, fans go wild

#3 2023-07-24 08:45:17

Re: Input freezes, screen freezes, everything else is fine, fans go wild

#4 2023-07-24 13:29:41

Re: Input freezes, screen freezes, everything else is fine, fans go wild

#5 2023-07-30 04:39:42

Re: Input freezes, screen freezes, everything else is fine, fans go wild

#6 2023-07-30 08:11:52

Re: Input freezes, screen freezes, everything else is fine, fans go wild

#7 2023-07-30 17:35:25

Re: Input freezes, screen freezes, everything else is fine, fans go wild

#8 2023-07-30 19:26:36

Re: Input freezes, screen freezes, everything else is fine, fans go wild

#9 2023-07-30 22:03:30

Re: Input freezes, screen freezes, everything else is fine, fans go wild

#10 2023-07-31 06:42:14

Re: Input freezes, screen freezes, everything else is fine, fans go wild

#11 2023-08-01 00:31:10

Re: Input freezes, screen freezes, everything else is fine, fans go wild

#12 2023-08-01 06:48:42

Re: Input freezes, screen freezes, everything else is fine, fans go wild

#13 2023-08-05 21:51:56

Re: Input freezes, screen freezes, everything else is fine, fans go wild

#14 2023-08-05 22:13:25

Re: Input freezes, screen freezes, everything else is fine, fans go wild

#15 2023-08-06 07:09:21

Re: Input freezes, screen freezes, everything else is fine, fans go wild

#16 2023-08-06 14:39:50

Re: Input freezes, screen freezes, everything else is fine, fans go wild

#17 2023-08-06 15:11:28

Re: Input freezes, screen freezes, everything else is fine, fans go wild

#18 2023-08-06 15:15:27

Re: Input freezes, screen freezes, everything else is fine, fans go wild

#19 2023-08-08 21:06:41

Re: Input freezes, screen freezes, everything else is fine, fans go wild

#20 2023-08-09 07:18:21

Re: Input freezes, screen freezes, everything else is fine, fans go wild

#21 2023-10-24 06:14:54

Re: Input freezes, screen freezes, everything else is fine, fans go wild

#22 2023-10-24 07:09:11

Re: Input freezes, screen freezes, everything else is fine, fans go wild

#23 2023-10-24 09:43:28

Re: Input freezes, screen freezes, everything else is fine, fans go wild

#24 2023-10-24 13:03:42

Re: Input freezes, screen freezes, everything else is fine, fans go wild

Board footer