Date: Thu, 7 Nov 2019 16:00:50 -0600 From: "Matthew D. Fuller" <fullermd@over-yonder.net> To: Niclas Zeising <zeising@freebsd.org> Cc: freebsd-x11@freebsd.org Subject: Re: drm-fbsd11.2-kmod on 12 Message-ID: <20191107220050.GA3169@over-yonder.net> In-Reply-To: <77bac16b-0438-b7ed-0c44-fadc230e55f8@freebsd.org> References: <20191103231435.GH86455@over-yonder.net> <3231b40d-1041-10d2-f062-eda237e07a02@freebsd.org> <20191106230916.GI86455@over-yonder.net> <77bac16b-0438-b7ed-0c44-fadc230e55f8@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Nov 07, 2019 at 09:41:20AM +0100 I heard the voice of Niclas Zeising, and lo! it spake thus: > > What issues are you seeing with the 4.16 branch? Have you reported > this? On one machine with radeonkms and a Radeon 6450, it will eventually crash when using vdpau output for videos (I believe even with formats that don't get hardware accelerated). It doesn't happen deterministically, but on a frequency of maybe a few percent of the time. 4.11 is perfectly fine with it, and 4.16 hasn't shown any surprises without vdpau, so that's reasonably easily workaroundable in practice. On my main workstation, with amdgpu and a Radeon wx2100 (roughly 550-something-ish), it will crash out without obvious trigger, on the order of maybe twice a week. Playing video, not playing video, scrolling in a browser, not scrolling in a browser, xlock'd and DPMS'd off, everything on, etc. As I recall, backtraces wound up pointing at not much after ioctl handlers, bearing some resemblance to the stuff in GH issue #149 (though I'm on the different driver), and I believe once that looked more like #130 with the ttm funcs (with similar to both showing up in the BZ bug linked from there). I don't have any of the cores still around though; I switched back to 4.11 last year, and it's been solid since. Part of the difficulty with this being so much upstream-y code that we're a ways behind on, is that I know it can be really hard to separate "we cause this problem by a mistake in porting" vs "this is a bug in the pure code" (especially of the "... and is fixed in later upstream versions already" variant). So I figure the best way to get it fixed is to desperately strive to not distract the people trying to catch up to upstream, and more up-to-date-ish upstream code will either have fixed their bug, or make it more certain that it's something on our side causing it. Either way, there's more to work with than "it crashes every couple days"... > Getting 4.11 running on FreeBSD 12.1 would require some effort, and > I believe that effort is much better spent elsewhere. I figured it would actually be relatively simple; it works fine with a mid-July stable/12, and there's only a half dozen or so commits on the drm-v4.16-fbsd12.0 branch since then, so I expect I can probably get it working just by backporting a couple of them. (I _was_ asking "has anybody who knows this code already done this work?", more than "hey, can you guys do this for me?") -- Matthew Fuller (MF4839) | fullermd@over-yonder.net Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20191107220050.GA3169>