Bug 75569

Hi Ronald,

Apart from using the latest version of libdrm, mesa and xf86-video-nouveau (which you probably are) I can think of one more thing. Some old chipsets are having problems with running the agp at 8x mode including yours (according to the radeon agp quirk table)

Experiment with the agp mode by appending "nouveau.agpmode=N" where N is the number 0, 1, 2 or 4. This will be reflected in your log if done correctly

"putting AGP V3 device into Nx mode"

I added the config and now it's running in 4x mode.

I will report back if there are no more issue's. But this might take a week or two to confirm.

Thank you.

It hanged again albeit maybe less I don't know. I think it's better to close this post. I think this might be the age of the card (10 years of service).

[root@delta gebruiker]# dmesg | grep -i agp
[    0.000000] Kernel command line: BOOT_IMAGE=/bzImage quiet xt_recent.ip_list_tot=6400 xt_recent.ip_pkt_list_tot=1 zswap.enabled=1 nouveau.agpmode=2
[    1.889562] Linux agpgart interface v0.103
[    1.889590] agpgart: Detected VIA KT400/KT400A/KT600 chipset
[    1.910421] agpgart-via 0000:00:00.0: AGP aperture is 256M @ 0xe0000000
[    1.958357] agpgart-via 0000:00:00.0: AGP 3.5 bridge
[    1.958370] agpgart: swapper tried to set rate=x0. Setting to AGP3 x4 mode.
[    1.958380] agpgart-via 0000:00:00.0: putting AGP V3 device into 4x mode
[    1.958430] nouveau 0000:01:00.0: putting AGP V3 device into 4x mode

It seems that I cannot set it lower than 4x mode -> nouveau.agpmode=2

You can do nouveau.agpmode=0 to disable agp entirely. An intermediate option if you're not seeing any real corruption, but the pushbuf is getting occasionally corrupted, you can do nouveau.vram_pushbuf=1 which will make sure that the pushbuf is in vram as opposed to the (AGP) GART memory.

Good morning!

I don't see any corruption so I'll try nouveau.vram_pushbuf=1. Thank you.

It seemed to hang and then recover.

Trying with nouveau.agpmode=4 + nouveau.vram_pushbuf=1

I plugged in new RAM at an higher rate, I guess that might be related? I'm sorry for not mentioning this before. But hardware is a new ballpark for me.

With nouveau.vram_pushbuf it seems to hang but also to recover. It did this twice in a row:

[  989.334399] nouveau E[   PFIFO][0000:01:00.0] DMA_PUSHER - ch 1 [X[730]] get 0x00519000 put 0x00519090 state 0x80000054 (err: INVALID_CMD) push 0x00000000
[ 1017.880696] nouveau E[   PFIFO][0000:01:00.0] DMA_PUSHER - ch 1 [X[730]] get 0x00519000 put 0x00519088 state 0x80000000 (err: INVALID_CMD) push 0x00000000
[ 1080.599917] nouveau E[   PFIFO][0000:01:00.0] DMA_PUSHER - ch 1 [X[730]] get 0x00519000 put 0x00519080 state 0x80000054 (err: INVALID_CMD) push 0x00000000
[ 1182.233193] nouveau E[   PFIFO][0000:01:00.0] DMA_PUSHER - ch 1 [X[730]] get 0x00519000 put 0x00519088 state 0x80000000 (err: INVALID_CMD) push 0x00000000
[ 1210.013989] bpkt raw broadcast: IN=enp0s18 OUT= MAC=ff:ff:ff:ff:ff:ff:b4:b6:76:5d:7c:b2:08:00 SRC=0.0.0.0 DST=255.255.255.255 LEN=328 TOS=0x00 PREC=0x00 TTL=128 ID=27791 PROTO=UDP SPT=68 DPT=67 LEN=308 
[ 1227.086996] BTRFS: device fsid 6cc7990a-8185-441a-b90d-c73a25f7d4cc devid 1 transid 271 /dev/mapper/main-boot
[ 1227.088925] BTRFS info (device dm-6): disk space caching is enabled
[ 1234.066610] nouveau E[   PFIFO][0000:01:00.0] DMA_PUSHER - ch 1 [X[730]] get 0x00519000 put 0x00519090 state 0x80000054 (err: INVALID_CMD) push 0x00000000


... continues here

-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/xorg/driver/xf86-video-nouveau/issues/95.