It looks like there is different behavior if you are using builtin radeon (and agpgart) instead of using modules radeon.o and agpgart.o: If I start X from command-line, exit session, startx again, X and DRI seems to work fine, at least there is no lockup. (radeon and agpgart as modul)
As I understand Linus, he has a problem even in this case. I grepped /var/log/messages for mtrr, but found nothing (kernel 2.4.20 with v4l2)
MY box only locks up when exiting a session if I am using a graphical login.
(maybe it would be interesting to see what happens when using radeon.o modul and builtin agpgart, or radeon.o modul _without_ agpgart, or radeon compiled-in without agpgart)
to the History of the "bug": I remember that I had to use gdm, because kdm "didnt work". That was about a year ago when I bought this box with the radeon7500. gdm just startet the Xserver again if it exited with an error. So "something" seems to be there for over a year (maybe since xfree 4.2.0 or even before?) but it "only" crashed the Xserver, not the whole box. And since that wasnt really hurting someone, nobody cared about it...
best regards, Andreas
Am 2003.03.08 13:31:15 +0100 schrieb(en) Keith Whitwell:
Linus Torvalds wrote: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.
Yes it looks suspicious, but I don't think it's the cause of the lockups on X recycle.
Evidence for this:
- The lockup is new, while the code has been suspicious forever...
- I can exit and restart X just fine, it's only recycle that locks. From the kernel point of view, these should be the same.
- In the Mesa embedded branch, I have a demo that closes & reopens its connections to the kernel without exiting. Again this works fine.
I've also verified that this lockup wasn't introduced in the filp work, ie. it had already sneaked into the trunk somehow. More & more I want to clean up the drm_*.h files. Starting by removing code that isn't widely used... At this time my eyes turn towards the gamma driver, which is the hook a lot of the bogus code in those files hangs on -- does *anyone* use this in the current tree?
Keith
------------------------------------------------------- This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger for complex code. Debugging C/C++ programs can leave you feeling lost and disoriented. TotalView can help you find your way. Available on major UNIX and Linux platforms. Try it free. www.etnus.com _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
