[arch-general] More Nouveau woes

Alexander Kapshuk alexander.kapshuk at gmail.com
Sat Oct 12 14:36:13 UTC 2019


On Sat, Oct 12, 2019 at 4:31 PM pete via arch-general
<arch-general at archlinux.org> wrote:
>
>  Since it seems the  messing around  with the base package i ma now getting
>  this
> [  245.303334] WARNING: CPU: 0 PID: 209 at
>  drivers/gpu/drm/nouveau/nvif/vmm.c:68 nvif_vmm_put.cold+0xc/0x13 [nouveau] [
>  245.303336] Modules linked in: fuse cfg80211 rfkill 8021q garp mrp stp llc
>  ext4 crc16 mbcache jbd2 dvb_pll cx22702 cx88_dvb cx88_vp3054_i2c videobuf2_dvb
>  dvb_core videobuf2_vmalloc ir_rc5_decoder rc_hauppauge nouveau
>  snd_hda_codec_hdmi mxm_wmi cx8800 cx8802 cx88xx wmi ttm tveeprom
>  videobuf2_dma_sg videobuf2_memops edac_mce_amd videobuf2_v4l2 v4l2_common
>  videobuf2_common kvm_amd ccp videodev snd_hda_codec_realtek drm_kms_helper
>  snd_hda_codec_generic rng_core ledtrig_audio drm agpgart i2c_algo_bit kvm
>  snd_hda_intel snd_usb_audio syscopyarea sysfillrect rc_core sysimgblt
>  snd_hda_codec mousedev fb_sys_fops r8169 snd_usbmidi_lib pl2303 snd_rawmidi
>  snd_seq_device mc snd_hda_core joydev input_leds snd_hwdep snd_pcm irqbypass
>  realtek snd_timer libphy snd sp5100_tco soundcore evdev i2c_piix4 mac_hid
>  k10temp pcspkr acpi_cpufreq sg crypto_user ip_tables x_tables xfs libcrc32c
>  crc32c_generic hid_generic usbhid hid sr_mod cdrom sd_mod ohci_pci ata_generic
>  pata_acpi ahci libahci pata_atiixp libata [  245.303401]  ehci_pci ehci_hcd
>  scsi_mod ohci_hcd [  245.303410] CPU: 0 PID: 209 Comm: kworker/0:2 Not tainted
>  5.3.5-arch1-1-ARCH #1 [  245.303411] Hardware name: To Be Filled By O.E.M. To
>  Be Filled By O.E.M./A74ML-K, BIOS 080014  04/14/2011 [  245.303472] Workqueue:
>  events nouveau_cli_work [nouveau] [  245.303528] RIP:
>  0010:nvif_vmm_put.cold+0xc/0x13 [nouveau] [  245.303531] Code: 45 31 e4 e9 a5
>  1a f1 ff 48 c7 c7 70 cd af c0 e8 73 9a 6c d6 0f 0b 45 31 e4 e9 8f 1a f1 ff 48
>  c7 c7 c0 cd af c0 e8 5d 9a 6c d6 <0f> 0b e9 1c 1f f1 ff 48 c7 c7 c0 cd af c0
>  e8 4a 9a 6c d6 0f 0b b8 [  245.303532] RSP: 0018:ffffb2af40327dc8 EFLAGS:
>  00010246 [  245.303534] RAX: 0000000000000024 RBX: ffffb2af40327df0 RCX:
>  0000000000000000 [  245.303535] RDX: 0000000000000000 RSI: ffff8d95f3a17708
>  RDI: 00000000ffffffff [  245.303536] RBP: ffffb2af40327e20 R08:
>  0000000000000366 R09: 0000000000000004 [  245.303536] R10: 0000000000000000
>  R11: 0000000000000001 R12: ffff8d9555d6be00 [  245.303537] R13:
>  dead000000000122 R14: dead000000000100 R15: ffff8d9555ec66c0 [  245.303539]
>  FS:  0000000000000000(0000) GS:ffff8d95f3a00000(0000) knlGS:0000000000000000 [
>   245.303540] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [  245.303541]
>  CR2: 00005583b3d2b830 CR3: 000000009a2a8000 CR4: 00000000000006f0 [
>  245.303542] Call Trace: [  245.303603]  nouveau_vma_del+0x81/0xc0 [nouveau] [
>  245.303657]  nouveau_gem_object_delete_work+0x36/0x60 [nouveau] [  245.303711]
>   nouveau_cli_work+0xbd/0x100 [nouveau] [  245.303720]
>  process_one_work+0x1d1/0x3a0 [  245.303723]  worker_thread+0x4a/0x3d0 [
>  245.303725]  kthread+0xfb/0x130 [  245.303728]  ? process_one_work+0x3a0/0x3a0
>  [  245.303729]  ? kthread_park+0x80/0x80 [  245.303734]
>  ret_from_fork+0x22/0x40 [  245.303738] ---[ end trace f9440c5b9c6a6d44 ]---
>
> on EVERY boot now a good 70 to 75% of software i use just causes the machine to
> lock solid instantly no logs nothing only full power off gets it going again  .
>
> What is going on
>
>
> Pete .

Here's a similar bug report by a fellow arch user:
https://bugs.freedesktop.org/attachment.cgi?id=144895

The error log is for libvdpau_nouveau.so used by chromium.
The call stack and the Code line seem identical to yours.

That particular problem has a patch proposed for it:
https://bugs.freedesktop.org/attachment.cgi?id=144875&action=edit

Not sure though if this would be at all applicable to your situation,
as you mention that there is a number of apps causing this on your
system.
Recent upstream kernels have seen a number of changes that introduced
the use of gem reservation objects instead of buffer objects used by
individual video drivers, amd, nouveau, etc.
Perhaps the apps that cause these lockups for you rely on the old
buffer objects that are no longer there.


More information about the arch-general mailing list