[Intel-gfx] [PATCH] Fix system lockup when a client tries to allocate a huge BO
Eric Anholt
eric at anholt.net
Tue Jul 7 20:01:59 CEST 2009
On Mon, 2009-07-06 at 10:55 +0100, Simon Farnsworth wrote:
> Chris Wilson wrote:
> > On Mon, 2009-07-06 at 10:10 +0100, Simon Farnsworth wrote:
> >> Eric Anholt wrote:
> >>> Anyway, we could just cap allocations at aperture size and avoid any
> >>> trickiness. There's no reason to allow a BO to be allocated that won't
> >>> fit in the GPU, right?
> >>>
> >> Sounds very reasonable; how do I code that?
> >
> > I think adding a defensive guard to bo_alloc of
> > if(size > bufmgr->gtt_size) return NULL;-
> > would be the first step -- which for now also ensures that size will be
> > less than ULONG_MAX/2.
>
> Something like:
> >From f379163937f0f27a155a5f238ae41e37f9d110e3 Mon Sep 17 00:00:00 2001
> From: Simon Farnsworth <simon.farnsworth at onelan.co.uk>
> Date: Mon, 6 Jul 2009 10:53:09 +0100
> Subject: [PATCH] Limit BO allocations to fit within the GTT
>
> There's no point allowing you to allocate BOs that won't fit inside
> the GTT - the GPU will be unable to operate on them.
Sorry for not noticing this yesterday -- I was operating without email
due to network troubles at home.
I chatted with keithp about it, and since we need to implement using 2GB
of address space on the GPU soon anyway, we needed to fix the issues
you'd noted before. So, hopefully the pair of patches I pushed work
out.
--
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/20090707/a5955265/attachment.sig>
More information about the Intel-gfx
mailing list