Hi, I came across this thread and want to let you know that I also have problems with the cx23885 driver on a Ryzen system. The only solution I found on the 'net that could make it work was to add a line options cx23885 debug=7 to the file /etc/modprobe.d/cx23885.conf However, this causes a *huge* number of debug messages, so I also run the command rm -f /var/log/kern.log* in a daily cronjob. This works stable here for some months now. With lower debug levels the problem occurred less often, but it still occurred. Only with debug level 7 (at least) the driver runs stable over time here. In case somebody is interested in details of the systemI'm running here: https://burnicki.net/public_html/martin/tmp/system-etails.txt The commit messages mentioned earlier in this thread are already pretty old (from ~2018 or so), and I'm running kernel 5.3 on my Ubuntu system, so I guess those commits are already in there, but the problem still occurs. I'm not familiar with the video stuff, with the cx23885 driver, etc., but I'm maintaining another kernel driver for different PCI cards and encountered similar problems as the cx23885 driver. The symptoms were that the driver worked stable for many years on all systems, but suddenly failed to work properly on systems with very new chips sets and/or CPUs (not only AMD Ryzen). It turned out that the problem was due to missing barriers when accessing memory mapped registers. In my original driver code (written many years ago) the driver accessed the memory mapped registers directly val = *mem_addr *mem_addr = val which worked without problems for a long time, so it looks like older CPUs/chipsets didn't do reordering which would have been inhibited by barriers. As said above, with recent versions of CPUs/chipsets this seems indeed to happen, but since I changed the driver code so that all access to memory mapped registers uses the specific kernel inline functions (which use barriers, AFAIK), all problems have vanished and my driver works fine with the latest CPUs and chipsets. So maybe somewhere in the cx23885 driver code a memory barrier may be missing, and depending on whether debugging is enabled, or not, accesses to the device are re-ordered, or not. This is just an idea, and maybe this is not the case here, but by chance someone who is familiar with the cx23885 code may have a look. Martin
