[Intel-gfx] [PATCH] crash and mem leak fixes

[Eric Anholt]

On Fri, 2009-04-10 at 17:10 +0200, Zdenek Kabelac wrote:
> Hi
> 
> This is list of small patches to fixes various leak and crashes I've
> noticed on my system:

For the future, please use git send-email to send out patches.  It lets
people review them inline, breaks them into separate messages for
separate topics, and makes it so that we can easily apply them while
making sure you get attribution.  There's some good stuff in here,
though.

01: We probably shouldn't even be doing this at VT switch time.  BOs
stay around across VT switch.  Still, applied with minor tweak.
02: Applied.
03: Applied.
04: Made xv_offscreen be offscreenImages to be consistent with the
variable name.  Applied.
05: NAK. Note the "start/end markers" comment.  This function is for
freeing the AGP memory that has been allocated, not the allocator
structure.  i830_allocator_fini covers that.
06: We need to figure out why this path is failing rather than papering
over it with an abort.  I guess we successfully open the dri device
because the first server's the master, but we don't check that we're
master, and then we don't get to set up GEM?  But then why only on the
second start?
07: Not sure about this one.  If this is the way we should go (FreeRec
as cleanup for things allocated in preinit that need freeing at preinit
fail or FreeScreen), it seems like there should be a lot more in it.
But that brings me to lifetime concerns in the next patch:
08: The DRI CloseScreens have closed the drm fd, right?  So now the
bufmgr destroy is going to do a bunch of bogus stuff.  Do we need to
hook ourselves in lower in the call chain so that we can have the
DRICloseScreen be the last thing we do pretty much?

We really want to have our DRM fd and bufmgr over the lifetime of the
server, but server regenerations make that hard, particularly vs DRI1.
Maybe we can have the driver be in control of the drm fd when we're
DRI2-only?  Server regenerations are a source of uncountable bugs for
us, and I'm trying to get a straight answer on "can we just stop
supporting server regenerations?"  If so, it seems like we could get
closer to a sane init/destroy cycle.


-- 
Eric Anholt
eric at anholt.net                         eric.anholt at intel.com


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://lists.freedesktop.org/archives/intel-gfx/attachments/20090421/b3772541/attachment.sig>