On Tue, Jan 8, 2013 at 12:09 AM, Ilija Hadzic <ihadzic@xxxxxxxxxxxxxxxxxxxxxx> wrote: > > > On Fri, 4 Jan 2013, Alex Deucher wrote: > >> R6xx and r7xx are really all you need to worry about in this case. >> R1xx-r5xx UMS uses a different kernel interface for command submission >> and evergreen and later don't have UMS drm support. UMS r6xx/r7xx >> support used the same kernel interface for command submission but the >> kernel side was much simpler. > > > OK, I have found an old machine with RV730 GPU and a known-working UMS: > 2.6.35 kernel, 6.13.2 DDX, 7.8.2 mesa (classic), 1.9 Xorg). I changed the > kernel to the latest drm-next and ran tests with and without my > CS-refactoring patches. Here are the results: > > * It appears that drm-next in its current state is broken with regard > to UMS (nothing to do with my patches, it was pre-broken to begin with). > UMS provokes the kernel into a NULL-pointer dereference oops. Good news > is that I have tracked down the crash and I will be sending the patches > with the fix shortly. > > * There are multiple patches that contributed to the breakage of UMS. > I didn't bother pin-pointing them all, but one that I looked > (6a7068b4) dates back to April 2012 so there are kernels out in > distros that crash on UMS. That probably tells us how many UMS > users are left out there :-). BTW, the reason UMS crashes is > because parser->rdev is NULL in UMS mode so every patch that tries > to dereference it (and shares the code path with UMS) will cause an > oops (it will become clear when you see the patches). > > * So, having fixed the above incidental finding, I got my machine > with ancient UMS-userspace and a shiny latest drm-next kernel (plus > my CS-refactoring patches plus my yet-to-be-sent UMS fixes) to > work. My test consists of bringing up Gnome (it's Gnome 2 on that > machine), running glxgears, sphereworld (an example code from > OpenGL Superbible book), and OpenArena. Everything seems to work. > > * Going back to KMS and retesting there, things still look good. > > So this (with tests I did on Friday) should cover all the cases. > > >> Additionally, UMS requires the old >> non-gallium 3D drivers. It sounds like some other change in the ddx >> broke UMS support for r6xx/r7xx. > > > The DDX segfault I reported on Friday was provoked by trying to run Gallium > 3D driver on the top of UMS. Once I switched back to classic, the crash went > away. So I guess the userspace crash was provoked by some obscure path that > was never intended to be exercised. I don't think > it's worth investigating further. IIRC, the radeon gallium drivers call abort() if they encounter an unsupported DRM version (that is UMS). Marek _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
