On Sun, 2 Mar 2003, Linus Torvalds wrote:
>
> The _second_ DRI-enabled X startup caused problems, even if I had done
> multiple non-DRI X sessions in between. This is what makes me think that
> the DRI kernel modules keep some history around that they shouldn't. And
> maybe the problem is hidden if you actually unload and re-load the
> modules (is that what most people do?)
Ok, I went in and looked for suspicious behaviour, and I found some.
Look at AGP and MTRR behaviour: both of them are initialized by drm_init()
at module load time.
Both of them are _de-initialized_ by the "DRM(takedown)()" code, and never
re-initialized by the "DRM(setup)()" code.
So an example of badness would be:
- load DRM modules (in my case as part of kernel bootup, since they are
compiled in):
- initialize MTRR and AGP mappings
- run X with DRI.
- Everything is happy.
- exit DRI X
- we are the "last close" case for DRI, so DRM(release)() calls
DRM(takedown)(), which frees AGP and MTRR
- restart non-DRI X
- nothing happens
- kill non-DRI X
- nothing happens
- run X with DRI again
- oops. We now have neither AGP nor MTRR's set up, even though
the code looks like it is assuming it.
Yeah, maybe I'm missing where somebody else re-initializes AGP and MTRR,
but my point is that these things do not seem to nest correctly. That
mtrr_del() in particular seems to be wrong, and I do indeed get a
mtrr: MTRR 2 not used
when shutting down X normally.
Comments? I haven't really gone through the whole path of what happens at
open()/release() time, and these are really nothing more than "that looks
suspicious", maybe somebody who knows the code better than I can take a
better look at it.
Linus
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
