Re: [Dri-devel] Re: PPC Lockup (ati-pcigart-branch)

Dan Malek wrote:

Michel Dänzer wrote:

quoted

[CC'ing linuxppc-dev, hopefully someone there knows what might be up...]

This is where it dies:

        /* FIXME: We should really have a kernel call for this...
         */
        entry->virtual = __vmalloc( (pages << PAGE_SHIFT),
                                    GFP_KERNEL,
                                    PAGE_KERNEL);

This isn't very much information, but only one thing can really
be wrong........

What is the value of 'pages'?  I suspect it is huge (and perhaps
wrong).  The GFP_KERNEL flag will cause vmalloc() to wait for pages
to become available (i.e. it will swap other things out).  If this
value in incorrect, this call will wait forever for pages that are
never going to arrive.  Worse, it is going to keep sucking up pages
and holding them, so nothing else is going to run either.  Is "pages"
really the number of pages, or a size that was never converted to pages?

Pages is definitely the number of pages (at least when I wrote the
code...).

...and for the 'FIXME' comment, you want a function that does
what? vmalloc?  Why don't you just call it (or one of the more
appropriate variants if necessary)?

This was originally when I was passing a flag to make the memory
uncached.  This wasn't needed, and we really should be using
vmalloc_32(...) instead (which will result in exactly the same code, but
it is cleaner).

-- Gareth

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/