… but even if they are unrelated, I think all the amdgpu and drm related fixes just in that one 15.3-rc list sort of proves that the body of kernel work is always in motion, things are always getting better.
Now I would love to make sure my (and @Zesko 's) issue is known and is being worked on… but I’m a little green, and don’t fully understand everything I read in the kernel notes (or here sometimes) and how it might relate to my issues. For example, is it really a problem when some “depends” are absent from one kernel version to another? Or was it planned?
If I can take the information I posted here and repost it upstream… where would I do that? I figure in the worst case scenario, someone might close it as a duplicate, and I’m okay with that. Or maybe the worst case scenario would be them telling me to redirect the issue to VLC?
But there is also a part of me that thinks that with the new Test build released that stable may be seeing an update soon… and a 5.15.5+ kernel will land to retest the script and VLC with hardware acceleration.
In fact, what I might do in preparation for that is to try duplicate the problem first. Twice I have been able to play my 91 minute video playlist without issue using VLC with hardware acceleration disabled. So, I think I’ll reverse that setting back to auto and see if I can trigger the corruption and errors at least one more time.
If I can’t duplicate the issue… I’m not sure what the next steps are. But if I can duplicate it, then I have a definite test case for all future kernels past 5.15.2… and I think upstream will take anything I post more seriously if I can provide repeatable steps.
EDIT: And I guess I need to remember it was mentioned the “fix” was in kernel 5.16… so I might be waiting a while to run the final test case
I also do not know. If need certain answer an investigation needed. I just suggest to compare.
Need to know what is the bug related to. If to load 5.15 kernel gen and do not use VLC but to use other player (Manjaro - Branch Compare or another), than do you see the bug?
Before to bug report much much better to have the latest possible versions within you kernel gen if 5.15 then currently (https://www.kernel.org/) (5.15.6) which is currently in unstable and testing branches only (Manjaro - Branch Compare)
If VLC related, than you will be asked to test on nightly build first (git version) or even 4th version of VLC which was not released at least a few days ago and to reset settings (Report bugs - VideoLAN Wiki):
Bug reports on older versions of VLC are likely to be ignored, because changes in newer versions of VLC may have already fixed the issue.
Before you file a new bug, please try a preview development build of our next version on our nightly build website. The bug may already be fixed in those builds.
Old preferences and/or incorrect settings are common causes of problems.
And the trick I think I learned was how to find other installed module dependencies/differences without having to boot the other kernels…
so taking the find command above, I thought I’d try remove the loaded kernel uname part of the path and instead grep for one of “missing” modules… drm.ko (ko = kernel object)… which basically confirmed it was absent (even on the drive) for the 5.15 kernel.
While thinking about how I would get the entire amdgpu depends list for the other kernels, and feeling a bit more comfortable with the paths and extensions/file-types, I recalled the “ugly” $ cat /lib/modules/$(uname -r)/modules.dep | grep amdgpu command I’d found earlier, and built a command to find all the module.dep files…
Now that I had all the paths, I could check for the amdgpu module dependencies for … say kernel 5.14 (which happened to pull the same list as the 5.13 file)…
But the results from this file (5.13 and 5.14) introduces another head scratcher, as it lists a few more depends than the script found… I’ll apply tr to the command to make it easier to read…
That’s 13 depends, not 8 like the script found. Maybe the .dep file just lists the dependencies… but whether or not they are used may be another matter? If that’s the case, my trick may be a red herrring and I really do have to boot the kernel to really know what was actually loaded
Daniel, perhaps by that publication of research pages you cut almost all auditory from reading the thread: it is hard to read and understand that all. May be now we are alone here who read fresh posts and I do not know how can I be useful in your case.
Imagine any people reaction who will find this thread by key excerpts from logs. It is already like about a 10% of book size Now the only cure for further readers, who will search solution also - is your mark that some post was the solution for you. But I guess it is some further post, not nearest one.
About to manually load kernel module from 5.13 kernel by modprobe to 5.15: 5.15’s platform should accept the module as actual. may be 5.15 mutate and modules from 5.13 could be loaded by there no triggers to switch to graphics processing to them or it is not easy to do. So it is possible idea to try, but not so highly promising.
you may be right… but I will never be accused of (1) not providing enough information or (2) having no desire to learn
I decided to look past the kernel module learning session, and decided to focus on the first 4 lines of the original error message I posted… and I just now noticed the reference to “process: vlc” (line 4), and decided to focus on DDG searches for…
Maybe I’m wrong, but I somewhat expect a fix like this (committed only 3 days ago) to find it’s way back into 5.15 as well (the latest LTS )… and if not, I know where the fix is and will wait for it unless I find disabling hardware acceleration is no longer a workaround.
But … also … like I have mentioned before …
What about, assuming you have HWAccel properly implemented in your system, setting VLC to use it, instead of relying on ‘automatic’ (which indicates a bug in vlc instead).
You have an amdgpu like me, so it can do VAAPI or VDPAU … though I consider vdpau more ‘native’.
(again this is hardware/configuration dependent … many users, especially without acceleration for example, may get best results from OpenGL or X11 output)
I was aware the Input/Codecs option defaulted to automatic, but I was unaware there was another automatic default under Video as well… seems I hadn’t followed the link yet you’d shared. Doh!
This information is perfect… I was thinking to try duplicate the issue again, and these VDPAU settings will be what I’ll try use first.
PS … you know what. Your logs include DRM messages right?
I realized VLC has HWAccel option “VAAPI via DRM” … maybe thats what automatic was trying to do…
Well I had successfully played a 5 minute video using the VDPAU (x2) settings, so that was a good initial run… and I just confirmed in the pamac GUI that I had all the core packages you listed installed:
Without delving into it I am tempted to pick this one, as I havent really run into the issue of something being unplayable.
Granted, I do use a superior player (smplayer) , but still, I cant remember a video file that wouldnt work.
EDIT:
OK … one quick ffmpeg -i file.mp4 file.mpeg later and … yeah it plays.
Looks terrible of course. But it definitely plays.
Hmm, maybe it’s time to try something new. So it looks like smplayer defaults to loading mpv, but also includes mplayer as an alternate mutimedia engine… did you stick with mpv?
I’ve used both.
I was about to respond ‘mplayer’ … but in fact its actually set to ‘other’ with path /bin/mpv for some reason. Ha.
Go ahead and configure it. But one of the nice things is its automatics ‘just work’ … or at least well enough to not crash in funkadelic style.
Also make sure to get the skins/themes … makes it a lot nicer.
I use interface : GUI=Basic Icon=PapirusDark Style=Breeze
(packages smplayer-themes, smplayer-skins)
Ok, I “spoiled” my initial plan a little bit by installing a BIOS update related to another issue… I thought I already had AGESA 1.2.0.2, but found I was a version back @ AGESA 1.2.0.0.
So after my RAID scrubbing and updating my BIOS, I decided to run VLC (VDPAU/VDPAU) and SMPlayer (VDPAU/GPU) in parallel (one muted) to save time and try force the issue by throwing more at the hardware accelerators… and had zero issues. No monitor sleeping, no corruption, and no errors… on kernel 15.5.2-2 with acceleration properly configured for AMD.
I’m going to select “setting Hardware Acceleration up properly for the hardware” as the solution… but also noting the importance of BIOS/AGESA updates.
aha!
Dumb VLC.
Not to beat it to death … but yeah … this ‘automatic’ thing on VLC has been an issue that bites people for years. Its actually what made me switch oh so many moons ago.
In any case I am glad everything is OK and you dont need to do a kernel bisect
Now the only cure for further readers, who will search solution also - is your mark that some post was the solution for you. But I guess it is some further post, not nearest one.
, but still, I cant remember a video file that wouldnt work.
