Re: DRM memory manager on cards with hardware contexts
Benjamin Herrenschmidt wrote:
OK. It seems like mmap locks are needed even for
unmap_mapping_range().
Well, I came to the opposite conclusion :) unmap_mapping_range() uses
the truncate count mecanism to guard against a racing no_page().
The idea is that:
no_page() itself internally takes the per-obkect lock/mutex mostly as a
sycnhronisation point before looking for the struct page and releases it
before returning the struct page to do_no_page().
unmap_mapping_range() is called with that muetx/lock held (and the copy
is done with that held too).
That should work without taking the mmap_sem.
OK. i was reffering to another approach: Copying _to_ VRAM /AGP:
lock_mmap_sems()
unmap_mapping_range() (or similar)
copy() / flip()
foreach_affected_vma{
io_remap_pfn_range() /* Map vram / AGP space */
}
unlock_mmap_sem()
This works like a charm in the drm memory manager but it requires the
lock of the mmap sems from all affected processes, and the locking
order must be the same all the time otherwise deadlocks will occur.
Now, of course, the real problem is that we don't have struct page for
vram There are two ways out of this:
- Enforce use of sparsemem and create struct page for vram. That will
probably make a few people jump out of their seats in x86 land but
that's what we do for cell and SPUs for now.
- There's a prooposal that I'm pusing to add a way for no_page() to
return a NOPAGE_RETRY error, which essentially causes it to go all the
way back to userland and re-do the access. I want that to be able to
handle signals while blocked inside no_page() but that could -also- be
used to have no_page() setup the PTE mappings itself and return
NOPAGE_RETRY, thus avoiding the need for a struct page. Now I do not
-ever- want to see drivers mucking around with PTEs directly, however,
we can provide something in mm/memory.c that a driver can call from
within no_page() to perform the set_pte() along with all the necessary
locking, flushes, etc... The base code for NOPAGE_RETRY should get in
2.6.19 soon (one of these days).
do_no_page() is smart enough to recheck the pte when it retakes the
page table spinlock(), so if the pte has been populated by someone
while in the driver nopage(), the returned struct page will simply be
discarded.
io_remap_pfn_range() should do the job of setting up the new ptes, but
it needs the mmap_sem, so if that one is held while blocked in
nopage(), a deadlock will occur. Here, the NOPAGE_RETRY will obviously
do the job. When io_remap_pfn_range() has finished setting up the ptes,
one can simply return a bogus page to nopage() if it insists on
retrying. Until NOPAGE_RETRY is implemented, I'm afraid I'm stuck with
the approach outlined above.
/Thomas
Ben.
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRM memory manager on cards with hardware contexts
> OK. i was reffering to another approach: Copying _to_ VRAM /AGP:
>
> lock_mmap_sems()
> unmap_mapping_range() (or similar)
> copy() / flip()
> foreach_affected_vma{
>io_remap_pfn_range() /* Map vram / AGP space */
> }
> unlock_mmap_sem()
>
> This works like a charm in the drm memory manager but it requires the
> lock of the mmap sems from all affected processes, and the locking
> order must be the same all the time otherwise deadlocks will occur.
Yes, and that's what I think we can "fix" using do_no_page() and
unmap_mapping_ranges(). That is, we don't io_remap_pfn_range(), we just
"fault" in pages either from VRAM or from memory depending on where an
object sits at a given point in time. and we use
unmap_mappingng_ranges() to invalidate current mappings of an object
when we "move" it. That can be done with the minimal approach I
described with the only limitation (though a pretty big one today) that
you need struct page for VRAM for no_page() to be useable in those
conditions.
> do_no_page() is smart enough to recheck the pte when it retakes the
> page table spinlock(), so if the pte has been populated by someone
> while in the driver nopage(), the returned struct page will simply be
> discarded.
Yup, indeed. It has to to avoid races since no_page() has to be called
without the PTE lock. The NOPAGE_RETRY approach would still be slightly
more efficient though.
> io_remap_pfn_range() should do the job of setting up the new ptes, but
> it needs the mmap_sem, so if that one is held while blocked in
> nopage(), a deadlock will occur. Here, the NOPAGE_RETRY will obviously
> do the job. When io_remap_pfn_range() has finished setting up the
> ptes, one can simply return a bogus page to nopage() if it insists on
> retrying. Until NOPAGE_RETRY is implemented, I'm afraid I'm stuck with
> the approach outlined above.
It's not completely clear to me if we need the mmap_sem for writing to
call io_remap_pfn_range()... We can certainly populate PTEs with only
the read semaphore and we happen to have it in no_page so that would
just work being called just within no_page().
So this approach would work today imho:
* objects have rwsem to protect migration.
* no_page() does:
- takes that object read sem
- if object is in vram or other non-memory location then do
io_remap_pfn_range() and get a dummy page struct pointer
- else get the struct page of the object page in memory
- release the object read sem and return whatever struct page we got
* migration does:
- take that object write sem
- copy the data to the new location
- call unmap_mapping_ranges() for that object
- release the object write sem
With 2.6.19, hopefully, NOPAGE_RETRY will get in, which means that
no_page() can be optimized for the case where it calls
io_remap_pfn_range() to not return a bogus page and have a faster return
path to userland. It's also possible to provide a io_remap_one_page()
that would be faster than having to call the whole 4 level
io_remap_pfn_range() for every page faulted in (though we might just
remap the entire object on the first fault, might well work ...)
Or do you think I missed something ?
Cheers,
Ben
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRM memory manager on cards with hardware contexts
> * objects have rwsem to protect migration.
> * no_page() does:
>- takes that object read sem
>- if object is in vram or other non-memory location then do
> io_remap_pfn_range() and get a dummy page struct pointer
>- else get the struct page of the object page in memory
>- release the object read sem and return whatever struct page we got
> * migration does:
>- take that object write sem
>- copy the data to the new location
>- call unmap_mapping_ranges() for that object
>- release the object write sem
Ok, there is one fault in my reasoning: io_remap_pfn_range() isn't
designed to be used in that context (it's really made to be called with
the mmap_sem held for writing) and thus doesn't check if the PTE is
still empty after locking it which is necessary if you are only holding
the read semaphore.
That means that it's still all possible, but not using
io_remap_pfn_range(). Best is to provide a specific new function, called
something like map_one_io_page() or something like that, which does
something along the lines of
pgd = pgd_offset(mm, address);
pud = pud_alloc(mm, pgd, address);
if (!pud)
return VM_FAULT_OOM;
pmd = pmd_alloc(mm, pud, address);
if (!pmd)
return VM_FAULT_OOM;
pte = pte_alloc_map(mm, pmd, address);
if (!pte)
return VM_FAULT_OOM;
pte = pte_offset_map_lock(mm, pmd, address, &ptl);
if (pte_none(*page_table)) {
flush_icache_page(vma, new_page);
entry = mk_pte(new_page, vma->vm_page_prot);
if (write_access)
entry = maybe_mkwrite(pte_mkdirty(entry), vma);
set_pte_at(mm, address, page_table, entry);
} else {
page_cache_release(new_page);
goto unlock;
}
update_mmu_cache(vma, address, entry);
lazy_mmu_prot_update(entry);
unlock:
pte_unmap_unlock(pte, ptl);
Note that it's clear that this is to be used exclusively for mapping on
non real pages and it doesn't handle racing with truncate (concurrent
unmap_mapping_ranges(), which is fine in our case as we have the object
semaphore).
We're looking into doing something like that for Cell to not require
sparsemem anymore and thus not create struct page's for SPE local stores
and registers which is a real pain...
We should probably move that discussion to linux-mm and/or lkml tho :)
Cheers,
Ben.
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRM memory manager on cards with hardware contexts
Benjamin Herrenschmidt wrote:
>> * objects have rwsem to protect migration.
>> * no_page() does:
>>- takes that object read sem
>>- if object is in vram or other non-memory location then do
>> io_remap_pfn_range() and get a dummy page struct pointer
>>- else get the struct page of the object page in memory
>>- release the object read sem and return whatever struct page we got
>> * migration does:
>>- take that object write sem
>>- copy the data to the new location
>>- call unmap_mapping_ranges() for that object
>>- release the object write sem
>
> Ok, there is one fault in my reasoning: io_remap_pfn_range() isn't
> designed to be used in that context (it's really made to be called with
> the mmap_sem held for writing) and thus doesn't check if the PTE is
> still empty after locking it which is necessary if you are only holding
> the read semaphore.
>
> That means that it's still all possible, but not using
> io_remap_pfn_range(). Best is to provide a specific new function, called
> something like map_one_io_page() or something like that, which does
> something along the lines of
>
> pgd = pgd_offset(mm, address);
> pud = pud_alloc(mm, pgd, address);
> if (!pud)
> return VM_FAULT_OOM;
> pmd = pmd_alloc(mm, pud, address);
> if (!pmd)
> return VM_FAULT_OOM;
> pte = pte_alloc_map(mm, pmd, address);
> if (!pte)
> return VM_FAULT_OOM;
> pte = pte_offset_map_lock(mm, pmd, address, &ptl);
> if (pte_none(*page_table)) {
> flush_icache_page(vma, new_page);
> entry = mk_pte(new_page, vma->vm_page_prot);
> if (write_access)
> entry = maybe_mkwrite(pte_mkdirty(entry), vma);
> set_pte_at(mm, address, page_table, entry);
> } else {
> page_cache_release(new_page);
> goto unlock;
> }
> update_mmu_cache(vma, address, entry);
> lazy_mmu_prot_update(entry);
> unlock:
> pte_unmap_unlock(pte, ptl);
>
> Note that it's clear that this is to be used exclusively for mapping on
> non real pages and it doesn't handle racing with truncate (concurrent
> unmap_mapping_ranges(), which is fine in our case as we have the object
> semaphore).
>
> We're looking into doing something like that for Cell to not require
> sparsemem anymore and thus not create struct page's for SPE local stores
> and registers which is a real pain...
>
> We should probably move that discussion to linux-mm and/or lkml tho :)
>
I'm finding this an interesting discussion. If it shifts to lkml, for
instance, is there a way to follow *and post* on the thread without
either subscribing to lkml or requiring myself to be on the CC list?
Keith
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRM memory manager on cards with hardware contexts
Benjamin Herrenschmidt wrote:
>>OK. i was reffering to another approach: Copying _to_ VRAM /AGP:
>>
>>lock_mmap_sems()
>>unmap_mapping_range() (or similar)
>>copy() / flip()
>>foreach_affected_vma{
>> io_remap_pfn_range() /* Map vram / AGP space */
>>}
>>unlock_mmap_sem()
>>
>>This works like a charm in the drm memory manager but it requires the
>>lock of the mmap sems from all affected processes, and the locking
>>order must be the same all the time otherwise deadlocks will occur.
>>
>>
>
>Yes, and that's what I think we can "fix" using do_no_page() and
>unmap_mapping_ranges(). That is, we don't io_remap_pfn_range(), we just
>"fault" in pages either from VRAM or from memory depending on where an
>object sits at a given point in time. and we use
>unmap_mappingng_ranges() to invalidate current mappings of an object
>when we "move" it. That can be done with the minimal approach I
>described with the only limitation (though a pretty big one today) that
>you need struct page for VRAM for no_page() to be useable in those
>conditions.
>
>
>
>>do_no_page() is smart enough to recheck the pte when it retakes the
>>page table spinlock(), so if the pte has been populated by someone
>>while in the driver nopage(), the returned struct page will simply be
>>discarded.
>>
>>
>
>Yup, indeed. It has to to avoid races since no_page() has to be called
>without the PTE lock. The NOPAGE_RETRY approach would still be slightly
>more efficient though.
>
>
>
>>io_remap_pfn_range() should do the job of setting up the new ptes, but
>>it needs the mmap_sem, so if that one is held while blocked in
>>nopage(), a deadlock will occur. Here, the NOPAGE_RETRY will obviously
>>do the job. When io_remap_pfn_range() has finished setting up the
>>ptes, one can simply return a bogus page to nopage() if it insists on
>>retrying. Until NOPAGE_RETRY is implemented, I'm afraid I'm stuck with
>>the approach outlined above.
>>
>>
>
>It's not completely clear to me if we need the mmap_sem for writing to
>call io_remap_pfn_range()... We can certainly populate PTEs with only
>the read semaphore and we happen to have it in no_page so that would
>just work being called just within no_page().
>
>So this approach would work today imho:
>
>* objects have rwsem to protect migration.
>* no_page() does:
> - takes that object read sem
> - if object is in vram or other non-memory location then do
>io_remap_pfn_range() and get a dummy page struct pointer
> - else get the struct page of the object page in memory
> - release the object read sem and return whatever struct page we got
>* migration does:
> - take that object write sem
> - copy the data to the new location
> - call unmap_mapping_ranges() for that object
> - release the object write sem
>
>With 2.6.19, hopefully, NOPAGE_RETRY will get in, which means that
>no_page() can be optimized for the case where it calls
>io_remap_pfn_range() to not return a bogus page and have a faster return
>path to userland. It's also possible to provide a io_remap_one_page()
>that would be faster than having to call the whole 4 level
>io_remap_pfn_range() for every page faulted in (though we might just
>remap the entire object on the first fault, might well work ...)
>
>Or do you think I missed something ?
>
>
>
No, that's probably the safest approach we can use until NOPAGE_RETRY
arrives.
Only I was not sure it'd be safe to call io_remap_pfn_range() from
within nopage, in case it modifies some internal mm structs that the
kernel nopage() code
expects to be untouched.
Once NOPAGE_RETRY arrives, (hopefully with a schedule() call attached to
it),
it's possible, however, that repopulating the whole vma using
io_remap_pfn_range() outside nopage, just after doing the copying is
more efficient. Although this means keeping track of vmas, the mmap_sems
can be taken and released one at a time, without any locking problems.
I agree the single-page approach looks nicer, though. It's somewhat ugly
to force one's way into another process' memory space.
/Thomas
>Cheers,
>Ben
>
>
>
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRM memory manager on cards with hardware contexts
> I'm finding this an interesting discussion. If it shifts to lkml, for > instance, is there a way to follow *and post* on the thread without > either subscribing to lkml or requiring myself to be on the CC list? I don't know if lkml allows non-subscriber posted, I think it does tho. So you can follow from an archive, though that sucks. Or we can keep both lists CCed. Ben. - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRM memory manager on cards with hardware contexts
On Thu, Sep 21, 2006 at 07:18:07PM +1000, Benjamin Herrenschmidt wrote: > > > I'm finding this an interesting discussion. If it shifts to lkml, for > > instance, is there a way to follow *and post* on the thread without > > either subscribing to lkml or requiring myself to be on the CC list? > > I don't know if lkml allows non-subscriber posted, I think it does tho. It does. And you can post via Gmane too. > So you can follow from an archive, though that sucks. nntp://news.gmane.org is quite nice. -- Ville Syrjälä [EMAIL PROTECTED] http://www.sci.fi/~syrjala/ - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRM memory manager on cards with hardware contexts
> No, that's probably the safest approach we can use until NOPAGE_RETRY > arrives. > Only I was not sure it'd be safe to call io_remap_pfn_range() from > within nopage, in case it modifies some internal mm structs that the > kernel nopage() code > expects to be untouched. It does a couple of things that I don't like and lacks the re-test of the PTE as I explained in my other email. I really want to provide a function for doing that tho, one page at a time. > Once NOPAGE_RETRY arrives, (hopefully with a schedule() call attached to > it), What about schedule ? NOPAGE_RETRY returns all the way back to userland... So things like signals can be handled etc... and the faulting instruction is re-executed. If there is a need for rescheduling, that will be handled by the kernel on the return path to userland as with signals. I want that for other things on cell which might also be useful for you, for example, the no_page() handler for cell might wait a long time to be able to schedule in a free HW SPE to service the fault. With NOPAGE_RETRY, I can make that wait interruptible (test for signals) and return to userland _without_ filling the PTE if a signal is pending, thus causing signals to be serviced and the faulting instruction re-executed. > it's possible, however, that repopulating the whole vma using > io_remap_pfn_range() outside nopage, just after doing the copying is > more efficient. Might well be when switching to vram but that means knowing about all VMAs and thus all clients... possible but I was trying to avoid it. > Although this means keeping track of vmas, the mmap_sems > can be taken and released one at a time, without any locking problems. Yup. > I agree the single-page approach looks nicer, though. It's somewhat ugly > to force one's way into another process' memory space. It is but it works :) It's typically done by things like ptrace, or some drivers DMA'ing to user memory, that's for example what get_user_pages() allows you to do. So it should work as long as you are only faulting pages, or invalidating mappings. We (ab)use that on cell too as SPEs run in the host process address space. They have an MMU that we point to the page tables of the process owning the context running on them. That means we might have take interrupts on the host to service faults for an SPE which is running another mm :) It might be more efficient performance wise however to do the full remap of the entire vram on the first no_page() to it when the object is in vram. That can be done safely with a simple change to io_remap_pfn_range() to make it safe against racing with itself, basically by having remap_pte_range() return 0 instead of BUG()'ing if the PTE has been populated after the lock. Should be pretty trivial and we shouldn't break anything since that was a BUG() case. That would work around what I'm explaining in another email that it currently needs the write mmap_sem because it doesn't handle races with another faulting path (that is with itself basically). Ben. - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRM memory manager on cards with hardware contexts
Ville Syrjälä wrote: > On Thu, Sep 21, 2006 at 07:18:07PM +1000, Benjamin Herrenschmidt wrote: >>> I'm finding this an interesting discussion. If it shifts to lkml, for >>> instance, is there a way to follow *and post* on the thread without >>> either subscribing to lkml or requiring myself to be on the CC list? >> I don't know if lkml allows non-subscriber posted, I think it does tho. > > It does. And you can post via Gmane too. > >> So you can follow from an archive, though that sucks. > > nntp://news.gmane.org is quite nice. > Gmane is working nicely for me now - thanks. Keith - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRM memory manager on cards with hardware contexts
Benjamin Herrenschmidt wrote: >>No, that's probably the safest approach we can use until NOPAGE_RETRY >>arrives. >>Only I was not sure it'd be safe to call io_remap_pfn_range() from >>within nopage, in case it modifies some internal mm structs that the >>kernel nopage() code >>expects to be untouched. >> >> > >It does a couple of things that I don't like and lacks the re-test of >the PTE as I explained in my other email. I really want to provide a >function for doing that tho, one page at a time. > > > >>Once NOPAGE_RETRY arrives, (hopefully with a schedule() call attached to >>it), >> >> > >What about schedule ? NOPAGE_RETRY returns all the way back to >userland... So things like signals can be handled etc... and the >faulting instruction is re-executed. If there is a need for >rescheduling, that will be handled by the kernel on the return path to >userland as with signals. > >I want that for other things on cell which might also be useful for you, >for example, the no_page() handler for cell might wait a long time to be >able to schedule in a free HW SPE to service the fault. With >NOPAGE_RETRY, I can make that wait interruptible (test for signals) and >return to userland _without_ filling the PTE if a signal is pending, >thus causing signals to be serviced and the faulting instruction >re-executed. > > OK. I was thinking about the case where NOPAGE_RETRY was used to release the mmap semaphore for the process doing io_remap_pfn_range() Having the process yield CPU would make it more probable that it wasn't regrabbed by the process doing nopage. > > >>it's possible, however, that repopulating the whole vma using >>io_remap_pfn_range() outside nopage, just after doing the copying is >>more efficient. >> >> > >Might well be when switching to vram but that means knowing about all >VMAs and thus all clients... possible but I was trying to avoid it. > > Although this means keeping track of vmas, the mmap_sems >can be taken and released one at a time, without any locking problems. > > > >Yup. > > > >>I agree the single-page approach looks nicer, though. It's somewhat ugly >>to force one's way into another process' memory space. >> >> > >It is but it works :) It's typically done by things like ptrace, or some >drivers DMA'ing to user memory, that's for example what get_user_pages() >allows you to do. So it should work as long as you are only faulting >pages, or invalidating mappings. We (ab)use that on cell too as SPEs run >in the host process address space. They have an MMU that we point to the >page tables of the process owning the context running on them. That >means we might have take interrupts on the host to service faults for an >SPE which is running another mm :) > >It might be more efficient performance wise however to do the full remap >of the entire vram on the first no_page() to it when the object is in >vram. That can be done safely with a simple change to >io_remap_pfn_range() to make it safe against racing with itself, >basically by having remap_pte_range() return 0 instead of BUG()'ing if >the PTE has been populated after the lock. Should be pretty trivial and >we shouldn't break anything since that was a BUG() case. That would work >around what I'm explaining in another email that it currently needs the >write mmap_sem because it doesn't handle races with another faulting >path (that is with itself basically). > >Ben. > > > > Hmm, the comments to handle_pte_fault(), which is calling do_nopage gives some insight.. * Note the "page_table_lock". It is to protect against kswapd removing * pages from under us. Note that kswapd only ever _removes_ pages, never * adds them. As such, once we have noticed that the page is not present, * we can drop the lock early. * * The adding of pages is protected by the MM semaphore (which we hold), * so we don't need to worry about a page being suddenly been added into * our VM. * So basically when driver nopage is called we should _never_ have a valid PTE. This makes the extra check in do_nopage() after the call to driver nopage() somewhat mysterious, (but fortunate). Perhaps the intention is for driver nopage() to be able to temporarily release the MM semaphore. (Which would be even more fortunate). In any case, if the comments hold, we should never hit the BUG() statement in io_remap_pfn_range(), but it also seems clear that the code doesn't really expect ptes to be added. Taking this to the lkml for some clarification might be a good idea. On a totally different subject, the previous discussion we had about having pages outside of the kernel virtual map (highmem pages) for example, might be somewhat tricky with the current definition of alloc_gatt_pages and free_gatt_pages, which both returns kernel virtual addresses. Would be nice to have them return struct page* instead. /Thomas - Take Surveys. Earn Cash. Influence
Re: DRM memory manager on cards with hardware contexts
> Hmm, the comments to handle_pte_fault(), which is calling do_nopage > gives some insight.. > > * Note the "page_table_lock". It is to protect against kswapd removing > * pages from under us. Note that kswapd only ever _removes_ pages, never > * adds them. As such, once we have noticed that the page is not present, > * we can drop the lock early. > * > * The adding of pages is protected by the MM semaphore (which we hold), > * so we don't need to worry about a page being suddenly been added into > * our VM. > * This comment is a bit stale I think :) For example, the PTL is no longer used for faulting in PTEs, in favor of a more fine grained lock. Also, fauling only takes the mmap_sem for reading, which can be taken multiple times. It's only taken for writing (which excludes other writers and all readers) when modifying the VMA list itself. > So basically when driver nopage is called we should _never_ have a valid > PTE. No, we can have two no_page racing. > This makes the extra check in do_nopage() after the call to driver > nopage() somewhat mysterious, (but fortunate). Perhaps the intention is > for driver nopage() to be able to temporarily release the MM semaphore. > (Which would be even more fortunate). It's a rwsem, it can be taken multiple times for reading. Only once the PTE lock has been taken (ex page table lock, now a "PTE lock" whose actual granularity is arch dependent) then you know for sure that nobody else will be mucking around with -this- specific PTE. Which is why you need to re-check after taking the lock. The mmap_sem only protects against the whole VMA being teared down or modified (though truncate doesn't take it neither, thus the truncate count trick which ends up in a retry if we raced with it). > In any case, if the comments hold, we should never hit the BUG() > statement in io_remap_pfn_range(), but it also seems clear that the code > doesn't really expect ptes to be added. Unfortunately, the comment is misleading. I suppose I should submit a patch changing or removing it one of these days... > Taking this to the lkml for some clarification might be a good idea. > > On a totally different subject, the previous discussion we had about > having pages outside of the kernel virtual map (highmem pages) for > example, might be somewhat tricky with the current definition of > alloc_gatt_pages and free_gatt_pages, which both returns kernel virtual > addresses. Would be nice to have them return struct page* instead. Yes. Currently, we can get to struct page with virt_to_page, which is what we do in drm_vm.h for platforms where the AGP aperture cannot be accessed as MMIO and thus requires a no_page() for faulting the individual pages in (which is what we do on ppc btw). But that will not work with pages that aren't coming from the virtual mapping. Thus it might indeed be a good idea to change the AGP allocation to return struct page. Ben. - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRM memory manager on cards with hardware contexts
Thomas Hellström wrote: >Benjamin Herrenschmidt wrote: > > > > >Hmm, the comments to handle_pte_fault(), which is calling do_nopage >gives some insight.. > > * Note the "page_table_lock". It is to protect against kswapd removing > * pages from under us. Note that kswapd only ever _removes_ pages, never > * adds them. As such, once we have noticed that the page is not present, > * we can drop the lock early. > * > * The adding of pages is protected by the MM semaphore (which we hold), > * so we don't need to worry about a page being suddenly been added into > * our VM. > * > >So basically when driver nopage is called we should _never_ have a valid >PTE. > > ...Or perhaps that comment is a remnant from the time when the mm semaphore wasn't a rw semaphore. /Thomas >This makes the extra check in do_nopage() after the call to driver >nopage() somewhat mysterious, (but fortunate). Perhaps the intention is >for driver nopage() to be able to temporarily release the MM semaphore. >(Which would be even more fortunate). > >In any case, if the comments hold, we should never hit the BUG() >statement in io_remap_pfn_range(), but it also seems clear that the code >doesn't really expect ptes to be added. > >Taking this to the lkml for some clarification might be a good idea. > >On a totally different subject, the previous discussion we had about >having pages outside of the kernel virtual map (highmem pages) for >example, might be somewhat tricky with the current definition of >alloc_gatt_pages and free_gatt_pages, which both returns kernel virtual >addresses. Would be nice to have them return struct page* instead. > > >/Thomas > > > > > > >- >Take Surveys. Earn Cash. Influence the Future of IT >Join SourceForge.net's Techsay panel and you'll get the chance to share your >opinions on IT & business topics through brief surveys -- and earn cash >http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV >-- >___ >Dri-devel mailing list >Dri-devel@lists.sourceforge.net >https://lists.sourceforge.net/lists/listinfo/dri-devel > > - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 6624] AIGLX reports not supported visuals
Please do not reply to this email: if you want to comment on the bug, go to the URL shown below and enter yourcomments there. https://bugs.freedesktop.org/show_bug.cgi?id=6624 --- Additional Comments From [EMAIL PROTECTED] 2006-09-21 18:16 --- (In reply to comment #19) > Actually, I'm still seeing this with the radeon/r200 drivers and more or less > current development snapshots. Needs investigation. > > That said, it seems mostly if not completely cosmetic. The `visual 0x4b' warnings disappear when disabling the composite extension (radeon) in xorg.conf. Or the other way round: They only appear when enabling the composite extension ;-) -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 7092] Add Dell Poweredge ATI Rage ID
Please do not reply to this email: if you want to comment on the bug, go to the URL shown below and enter yourcomments there. https://bugs.freedesktop.org/show_bug.cgi?id=7092 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2006-09-21 20:44 --- fixed in drm -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 4946] [mga] PCI DMA is broken
Please do not reply to this email: if you want to comment on the bug, go to the URL shown below and enter yourcomments there. https://bugs.freedesktop.org/show_bug.cgi?id=4946 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2006-09-21 20:48 --- fixed. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 4508] Problem with DRM on Alpha arch.
Please do not reply to this email: if you want to comment on the bug, go to the URL shown below and enter yourcomments there. https://bugs.freedesktop.org/show_bug.cgi?id=4508 Bug 4508 depends on bug 4946, which changed state. Bug 4946 Summary: [mga] PCI DMA is broken https://bugs.freedesktop.org/show_bug.cgi?id=4946 What|Old Value |New Value Status|NEW |RESOLVED Resolution||FIXED -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 5341] System locks up when starting X w/ DRI on a Radeon RV370 (X300)
Please do not reply to this email: if you want to comment on the bug, go to the URL shown below and enter yourcomments there. https://bugs.freedesktop.org/show_bug.cgi?id=5341 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |NEEDINFO --- Additional Comments From [EMAIL PROTECTED] 2006-09-21 20:50 --- no idea what the state of this bug is modulo the addition of a comment about something completely unrelated. author please reopon if you still have problem with latest code. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 6082] when making use of the drm r300 module al the devices that share the same interrupt stop working
http://bugzilla.kernel.org/show_bug.cgi?id=6082 [EMAIL PROTECTED] changed: What|Removed |Added Owner|[EMAIL PROTECTED] |[EMAIL PROTECTED] |bugs.osdl.org | Status|NEW |ASSIGNED --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 6870] kernel-2.6.17 on a P-IV locks up the machine: problem with 'drm:i830'
http://bugzilla.kernel.org/show_bug.cgi?id=6870 [EMAIL PROTECTED] changed: What|Removed |Added Owner|[EMAIL PROTECTED] |[EMAIL PROTECTED] |bugs.osdl.org | Status|NEW |ASSIGNED --- Additional Comments From [EMAIL PROTECTED] 2006-09-21 20:51 --- please report this bug to X.org using bugs.freedesktop.org it is not kernel related. --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 6111] ATI Radeon 9200 freezes using dri
Please do not reply to this email: if you want to comment on the bug, go to the URL shown below and enter yourcomments there. https://bugs.freedesktop.org/show_bug.cgi?id=6111 --- Additional Comments From [EMAIL PROTECTED] 2006-09-21 21:46 --- (In reply to comment #23) > (In reply to comment #22) > > Thanks. Looks more like an issue of the kernel with your AGP bridge. Does it > work with Option "BusType" "PCI"? I'm having this same error with my new Sapphire Radeon 9250 256MB and setting BusType to "PCI" allows Direct Rendering to work. I can only assume direct rendering is broken with AGP on my hardware. I am using the very latest Debian unstable (2006-09-21) with latest Debian 2.6.17 SMP amd64 kernel. I am using the latest git kernel modules (drm.ko and radeon.ko). Hardware: 2 x Opteron 244 (SMP, amd64 kernel & userland) MSI K8T Master2-FAR (VIA K8T8000 chipset) Sapphire Radeon 9250 4 x DDR-333 512MB Here's 'dmesg' from when I get the 100% CPU usage: [drm] Initialized drm 1.0.1 20051102 ACPI: PCI Interrupt :01:00.0[A] -> GSI 16 (level, low) -> IRQ 177 mtrr: type mismatch for 400,200 old: write-back new: write-combining [drm] Initialized radeon 1.25.0 20060524 on minor 0: agpgart: Found an AGP 3.0 compliant device at :00:00.0. agpgart: Device is in legacy mode, falling back to 2.x agpgart: Putting AGP V2 device at :00:00.0 into 1x mode agpgart: Putting AGP V2 device at :01:00.0 into 1x mode [drm] Setting GART location based on new memory map [drm] Loading R200 Microcode [drm] writeback test succeeded in 1 usecs During the 100% CPU, I get this over and over in strace on X: --- SIGALRM (Alarm clock) @ 0 (0) --- rt_sigreturn(0xe) = -1 EBUSY (Device or resource busy) ioctl(6, 0xc0406429, 0x7fffacceffc0)= -1 EBUSY (Device or resource busy) Thanks for any help! -s -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: R200 lockup (was Re: DRI/X error resolution)
On Fri, Sep 22, 2006 at 03:29:48PM +1000, Dave Airlie wrote: > On 9/22/06, Ryan Richter <[EMAIL PROTECTED]> wrote: > > On Thu, Sep 21, 2006 at 11:54:01PM -0500, Stephen Olander Waters wrote: > > > Here is the bug I'm working from (includes hardware, software, etc.): > > > https://bugs.freedesktop.org/show_bug.cgi?id=6111 > > > > > > DRI will work if you set: Option "BusType" "PCI" ... but that's not a > > > real solution. :) > > I really think this more AGP related a bug in the driver for the VIA > AGP chipsets what AGP chipset are you guys using? Looking at that bug though, most of the reporters are on AMD64 systems, which uses amd64-agp, not via-agp. (We leave the chipset GART alone, and just use the on-CPU one). This.. agpgart: Found an AGP 3.0 compliant device at :00:00.0. agpgart: X tried to set rate=x12. Setting to AGP3 x8 mode. agpgart: X requested AGPx8 but bridge not capable. agpgart: Putting AGP V3 device at :00:00.0 into 4x mode agpgart: Putting AGP V3 device at :01:00.0 into 4x mode should be fixed in recent Xorg/kernels. There is a v3 8x->4x fallback failure that some people trigger, but that manifests itself in other ways with different messages (where it tries to fall back to 0x mode, and madness ensues), there's a fix for that in Andrews -mm tree that should be going to Linus RSN. Other than that, I'm unaware of any outstanding nasties in the AGP drivers. I'm not really sure what to suggest for further debugging. Dave - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: drm: Branch 'master'
On Thu, Sep 21, 2006 at 08:44:47PM -0700, Dave Airlie wrote: > shared-core/drm_pciids.txt |1 + > 1 files changed, 1 insertion(+) > > New commits: > diff-tree 255f3e6f76dfd267a14765dd1293229184298d89 (from > 1f71b8d7a456fe3ec4bfc2fed70b7420cdd0d55a) > Author: Anish Mistry <[EMAIL PROTECTED]> > Date: Fri Sep 22 03:43:34 2006 +1000 > > bug 7092 : add pci ids for mach64 in Dell poweredge 4200 > > diff --git a/shared-core/drm_pciids.txt b/shared-core/drm_pciids.txt > index 9e0c099..c597708 100644 > --- a/shared-core/drm_pciids.txt > +++ b/shared-core/drm_pciids.txt > @@ -186,6 +186,7 @@ > 0x1002 0x4c51 0 "3D Rage LT Pro" > 0x1002 0x4c42 0 "3D Rage LT Pro AGP-133" > 0x1002 0x4c44 0 "3D Rage LT Pro AGP-66" > +0x1002 0x4759 0 "Rage 3D IICATI 3D RAGE IIC AGP(A12/A13) The formatting looks really strange. Also Rage IIC doesn't have a setup engine so AFAIK it should not be listed in the drm. -- Ville Syrjälä [EMAIL PROTECTED] http://www.sci.fi/~syrjala/ - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: drm: Branch 'master'
>> 0x1002 0x4c42 0 "3D Rage LT Pro AGP-133" >> 0x1002 0x4c44 0 "3D Rage LT Pro AGP-66" >> +0x1002 0x4759 0 "Rage 3D IICATI 3D RAGE IIC AGP(A12/A13) > > The formatting looks really strange. > > Also Rage IIC doesn't have a setup engine so AFAIK it should not be > listed in the drm. The bug has been open for a while with no comments, and this in a Dell Poweredge and it claims AGP, so I thought maybe it does hve enogh juice.. the string idoesn't matter so much on linux, and is from the web.. Dave -- David Airlie, Software Engineer http://www.skynet.ie/~airlied / airlied at skynet.ie Linux kernel - DRI, VAX / pam_smb / ILUG - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
R200 lockup (was Re: DRI/X error resolution)
On Thu, Sep 21, 2006 at 11:23:08PM -0500, Stephen Olander Waters wrote: > Hey, > > Did they ever fix that bug you reported here? > http://lkml.org/lkml/2005/5/11/121 > > I'm having the same problem! Argh! No, sad to say it still happens to us too. Argh is right! I'll cc this to dri-devel and lkml in case anyone wants to try hunting the bug again. FWIW, I'm still seeing the ioctl(5, 0x6444, 0) / SIGALARM behavior I reported originally. This has continued to happen regularly with all 2.6 kernels up to 2.6.17.6 and Xfree/X.org up to 6.9. -ryan - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: R200 lockup (was Re: DRI/X error resolution)
On Thu, Sep 21, 2006 at 11:54:01PM -0500, Stephen Olander Waters wrote: > Here is the bug I'm working from (includes hardware, software, etc.): > https://bugs.freedesktop.org/show_bug.cgi?id=6111 > > DRI will work if you set: Option "BusType" "PCI" ... but that's not a > real solution. :) Oh, wow. I had no idea there was a workaround. What kind of performance hit does that entail? R200 performance is pretty dismal to begin with, but it would be awfully nice to not have all our workstations crashing all the time... I wonder why that works. What chipset do you use? All our machines are AMD 8151. I'm about to leave town for several days, but I'll try that when I return. Cheers, -ryan - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: R200 lockup (was Re: DRI/X error resolution)
On 9/22/06, Ryan Richter <[EMAIL PROTECTED]> wrote: > On Thu, Sep 21, 2006 at 11:54:01PM -0500, Stephen Olander Waters wrote: > > Here is the bug I'm working from (includes hardware, software, etc.): > > https://bugs.freedesktop.org/show_bug.cgi?id=6111 > > > > DRI will work if you set: Option "BusType" "PCI" ... but that's not a > > real solution. :) I really think this more AGP related a bug in the driver for the VIA AGP chipsets what AGP chipset are you guys using? Dave. - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: R200 lockup (was Re: DRI/X error resolution)
On Fri, Sep 22, 2006 at 03:29:48PM +1000, Dave Airlie wrote: > On 9/22/06, Ryan Richter <[EMAIL PROTECTED]> wrote: > >On Thu, Sep 21, 2006 at 11:54:01PM -0500, Stephen Olander Waters wrote: > >> Here is the bug I'm working from (includes hardware, software, etc.): > >> https://bugs.freedesktop.org/show_bug.cgi?id=6111 > >> > >> DRI will work if you set: Option "BusType" "PCI" ... but that's not a > >> real solution. :) > > I really think this more AGP related a bug in the driver for the VIA > AGP chipsets what AGP chipset are you guys using? AMD 8151 here. I have yet to try Option "BusType" "PCI", so I can't say if that works here (it'll be a week or so before I have a chance to try). -ryan - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
