You are not logged in.
Pages: 1
Apparently, there is an issue with nvidia: https://www.archlinux.org/news/nvidia-4 … -linux-59/
And sometimes, when I don't use the computer it seems, the main screen starts to have huge delays.
The second screen is always fine until now, despite the fact both are connected to the same graphic card splitter.
After a while, the main screen refreshes normally.
Also, htop doesn't show any abnormal behavior: the cpu and ram are stable, and there is no excessive swapping if at all.
Could it be related to the nvidia issue?
Last edited by thomasbb (2020-10-26 17:13:47)
Offline
No. The issue mentioned there has a quite defined usecase that shouldn't be related to what you are doing in a normal desktop scenario. But if you want to test that you could change to the LTS kernel but there are many other changes between the two kernels that might have an effect.
Do you see anything in xorg/journal logs when the delay happens? How is the multi screen set up? Which window manager?
Offline
connected to the same graphic card splitter
Please elaborate on the setup.
Offline
Do you see anything in xorg/journal logs when the delay happens? How is the multi screen set up? Which window manager?
The journal says in red:
17:01:12 LN-TW-01 kernel: nouveau 0000:01:00.0: DRM: base-0: timeout
and then in yellow, several
17:02:30 LN-TW-01 kernel: ------------[ cut here ]------------
17:02:30 LN-TW-01 kernel: WARNING: CPU: 2 PID: 328079 at drivers/gpu/drm/nouveau/dispnv50/disp.c:211 nv50_dmac_wait+0x22f/0x280 [nouveau]
17:02:30 LN-TW-01 kernel: Modules linked in: rndis_host cdc_ether usbnet mii fuse uvcvideo videobuf2_vmalloc videobuf2_memops snd_usb_audio videobuf2_v4l2 videobuf2_common videodev snd_usbmidi_lib snd_rawmidi snd_seq_device mc input_leds snd_hda_codec_analog snd_hda_codec_generic cfg80211 ledtrig_audio rfkill 8021q garp mrp stp llc nouveau mousedev hid_generic usbhid coretemp mxm_wmi i2c_algo_bit kvm_intel hid ttm drm_kms_helper at24 kvm iTCO_wdt mei_wdt snd_hda_intel gpio_ich intel_pmc_bxt cec iTCO_vendor_support snd_intel_dspcfg wmi_bmof snd_hda_codec rc_core syscopyarea irqbypass snd_hda_core sysfillrect i2c_i801 snd_hwdep tpm_tis sysimgblt pcspkr tpm_tis_core snd_pcm i2c_smbus fb_sys_fops lpc_ich snd_timer tpm mei_me snd rng_core e1000e mei intel_agp soundcore evdev intel_gtt mac_hid wmi acpi_cpufreq vboxnetflt(OE) vboxnetadp(OE) vboxdrv(OE) drm sg crypto_user agpgart ip_tables x_tables ext4 crc32c_generic crc16 mbcache jbd2 uhci_hcd sr_mod cdrom ehci_pci ehci_hcd ata_generic pata_acpi floppy
17:02:30 LN-TW-01 kernel: CPU: 2 PID: 328079 Comm: kworker/u8:2 Tainted: G W OE 5.9.1-arch1-1 #1
17:02:30 LN-TW-01 kernel: Hardware name: LENOVO 6258W98/LENOVO, BIOS 5CKT61AUS 02/01/2010
17:02:30 LN-TW-01 kernel: Workqueue: events_unbound nv50_disp_atomic_commit_work [nouveau]
17:02:30 LN-TW-01 kernel: RIP: 0010:nv50_dmac_wait+0x22f/0x280 [nouveau]
17:02:30 LN-TW-01 kernel: Code: 8d 48 04 48 89 4a 68 c7 00 00 00 00 20 49 8b 45 38 41 c7 85 20 01 00 00 00 00 00 00 49 89 45 68 e8 66 fc ff ff e9 4f fe ff ff <0f> 0b b8 92 ff ff ff e9 c4 fe ff ff 49 8b bd 80 00 00 00 e8 49 fc
17:02:30 LN-TW-01 kernel: RSP: 0018:ffffb4df84be7d48 EFLAGS: 00010282
17:02:30 LN-TW-01 kernel: RAX: ffffffffffffff92 RBX: 0000000000000002 RCX: 0000000000000000
17:02:30 LN-TW-01 kernel: RDX: ffffffffffffff92 RSI: ffffb4df84be7c88 RDI: ffffb4df84be7d28
17:02:30 LN-TW-01 kernel: RBP: 00000000fffffffb R08: 0000000000000000 R09: ffffb4df84be7c58
17:02:30 LN-TW-01 kernel: R10: 0000000000000030 R11: ffffb4df804697f8 R12: ffff92c851466b68
17:02:30 LN-TW-01 kernel: R13: ffff92c851466ba8 R14: ffff92c7dc8d6200 R15: ffff92c84a903800
17:02:30 LN-TW-01 kernel: FS: 0000000000000000(0000) GS:ffff92c855f00000(0000) knlGS:0000000000000000
17:02:30 LN-TW-01 kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
17:02:30 LN-TW-01 kernel: CR2: 00005558c6789758 CR3: 000000005960e000 CR4: 00000000000406e0
17:02:30 LN-TW-01 kernel: Call Trace:
17:02:30 LN-TW-01 kernel: ? _raw_spin_lock+0x13/0x30
17:02:30 LN-TW-01 kernel: ? _raw_spin_unlock+0x16/0x30
17:02:30 LN-TW-01 kernel: base507c_update+0x30/0x70 [nouveau]
17:02:30 LN-TW-01 kernel: nv50_disp_atomic_commit_wndw+0x5a/0x70 [nouveau]
17:02:30 LN-TW-01 kernel: nv50_disp_atomic_commit_tail+0x4df/0x7a0 [nouveau]
17:02:30 LN-TW-01 kernel: process_one_work+0x1da/0x3d0
17:02:30 LN-TW-01 kernel: worker_thread+0x4d/0x3d0
17:02:30 LN-TW-01 kernel: ? rescuer_thread+0x410/0x410
17:02:30 LN-TW-01 kernel: kthread+0x142/0x160
17:02:30 LN-TW-01 kernel: ? __kthread_bind_mask+0x60/0x60
17:02:30 LN-TW-01 kernel: ret_from_fork+0x22/0x30
17:02:30 LN-TW-01 kernel: ---[ end trace a8ef476c7b7d9728 ]---
Regarding the setup:
the graphic card is an Nvidia Quadro Fx 370 and the Hdmi output goes to two vga screens
the window manager is Swaywm
Also, the secondary screen is 1440x990 but the display is half an inch shorter in width. This screen doesn't seem to have a lag issue.
Offline
You mean you're using one HDMI output on the card, then some sort of Y-cable or external hub/adapter box that splits the signal to two VGA jacks and one of them works as expected and the other doesn't?
Offline
You mean you're using one HDMI output on the card, then some sort of Y-cable or external hub/adapter box that splits the signal to two VGA jacks and one of them works as expected and the other doesn't?
Exactly: the Y-cable has two numbers, 1 and 2, and the screen connected to plug #1 sometimes freezes whereas the other one seems fine
Having executed journalctl -f in a terminal, when the screen freezes it show several red lines of
nouveau 0000:01:00.0: DRM: base-0: timeout
and then yellow "---[cut here]--- (...) ---[end trace a8xxx3c]---" blocks
Last edited by thomasbb (2020-10-25 17:23:04)
Offline
#1 reason: It's the cable. :-(
The generated output signal is fine (proof: working output) but the split fails - "somehow".
Are both outputs 1440x990 (that's a rather odd resolution) and at the same refresh rate?
Offline
It has been working for several months though, it's really recently it started to freeze. Maybe this week only, actually
The resolutions are 1440x900 and 1280x1024, but until these days it used to work.
Has the nouveau driver been updated a few days ago?
Offline
Well there was a new major kernel release so you could try to go down to 5.8.x
Offline
If there has been a major upgrade of the kernel, there's nothing worrying. Let me try the Lts kernel, if something goes wrong I'll reopen the post
Offline
Pages: 1