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/
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 "Bus
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
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 l
>> 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 b
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]>
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.freedeskt
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 r
http://bugzilla.kernel.org/show_bug.cgi?id=6870
[EMAIL PROTECTED] changed:
What|Removed |Added
Owner|[EMAIL PROTECTED] |[EMAIL PROTECTED]
|bugs.osdl.o
http://bugzilla.kernel.org/show_bug.cgi?id=6082
[EMAIL PROTECTED] changed:
What|Removed |Added
Owner|[EMAIL PROTECTED] |[EMAIL PROTECTED]
|bugs.osdl.o
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
--
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 i
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
--
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
--
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 r
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_ page
> 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
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 unto
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 b
> 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 th
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'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 ca
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
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 o
> * 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
> 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 manage
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() i
27 matches
Mail list logo
