On Tue, 2010-08-10 at 14:56 +0200, Michel Dänzer wrote:
> On Mon, 2010-08-09 at 16:16 +1000, Benjamin Herrenschmidt wrote:
> >
> > I'm currently testing on a rv350 based aluminium powerbooks.
>
> Same here. :)
Heh. Well, I also have the G5 with rv350,
0 is a valid DMA address from pci_map_page(), use pci_dma_mapping_error()
instead to check for errors
Signed-off-by: Benjamin Herrenschmidt
---
drivers/gpu/drm/radeon/radeon_device.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/radeon
> > - transition from offb. If both kms and offb are built-in, the transition
> > leads to panel blooming. Note that it seems broken with nouveau on the G5 as
> > well, I suspect we are passing a crap mode when picking up from offb at
> > boot.
> >
>
> wierd offb->nouveau worked on my G5, hando
On Mon, 2010-08-09 at 03:18 -0400, Alex Deucher wrote:
> 2010/8/9 Benjamin Herrenschmidt :
> > Just a quick status in case others are interested and want to help
> > as I have -very- little time.
> >
>
> Unfortunately, I don't have much spare time to dedicate to th
When we find no ROM we understand and a device-tree is present, see
if we can retreive clock info from there.
Signed-off-by: Benjamin Herrenschmidt
---
drivers/gpu/drm/radeon/radeon_clocks.c | 81
1 files changed, 81 insertions(+), 0 deletions(-)
diff --git
Just a quick status in case others are interested and want to help
as I have -very- little time.
I'm currently testing on a rv350 based aluminium powerbooks.
The basic stuff works provided you stay away from AGP. Here's
things in no special order I noticed:
- AGP: locks up before the console sh
proper domain numbers
instead of 0 to userspace.
The newer libdrm will then try 1.4 first, and fallback to 1.1, along with
ignoring domains in the later case (well, except on alpha of course)
Signed-off-by: Benjamin Herrenschmidt
---
drivers/gpu/drm/drm_ioctl.c |1 +
include/drm/drmP.h
This works in conjunction with newer kernels. If we succeed in requesting
interface 1.4, the we know the kernel provides proper domain numbers. If
not, ignore the domain number as it's bogus (except on Alpha).
Signed-off-by: Benjamin Herrenschmidt
---
xf86drm.c |
On Fri, 2009-12-11 at 15:19 -0800, Linus Torvalds wrote:
>
> On Fri, 11 Dec 2009, Dave Airlie wrote:
> >
> > Please pull the 'drm-nouveau-pony' branch from
>
> PONIES! Yay! I lurve ponies!
>
> And it works for me too. Needed to get the firmware from the fedora
> project, and make sure that it
On Mon, 2009-12-14 at 14:35 +1100, Benjamin Herrenschmidt wrote:
> And built-in works beautifully with kms & fbdev on top of it etc...
> (real fast console switches ! yay !) if I do
>
> CONFIG_EXTRA_FIRMWARE_DIR="/lib/firmware"
> CONFIG_EXTRA_FIRMWARE="/nouve
ddress
> assignments conflict. Therefore an arbitration scheme _outside_ of the X
> server is needed to control the sharing of these resources. This document
> introduces the operation of the VGA arbiter implemented for Linux kernel.
>
> Signed-off-by: Tiago Vignatti
> Signed-off
On Tue, 2009-08-11 at 16:17 -0700, Jesse Barnes wrote:
> Ok, applied this to my linux-next branch, but I'd like to get Ben's
> s-o-b before pushing it to Linus.
Well, S-O-B is if the code went through my hands... though in this case
I wrote the original version so I suppose it did :-) An ack for
On Mon, 2009-06-22 at 19:07 -0700, Jesse Barnes wrote:
> Yeah I don't think we should try to change the mode, unless we really
> have to for whatever reason. fbcon should generally be able to paint
> to whatever we have up as long as we set it up properly.
Well... it may not. IE. The text consol
On Mon, 2009-06-22 at 18:18 -0700, Jesse Barnes wrote:
> I think it could work, but ideally we'd keep the kernel fbcon object
> pinned, and keep printing into it even while some other gfx app is
> running. That way we don't have to dump the whole queue into it when
> a
> panic occurs, we can just
On Sun, 2009-06-21 at 12:47 -0700, Linus Torvalds wrote:
>
> What *has* changed is that we have a newradeon driver, and it looks
> like
> that new radeon driver is crap, and does this:
>
> info->fix.smem_start = (unsigned long)fbptr;
>
> which is totally screwed up. It assigns a _virtua
On Mon, 2009-06-22 at 10:18 +0200, Thomas Hellström wrote:
> It would be very helpful if we could introduce an fbdev mutex that
> protects fbdev accesses to the kernel map and to the fbdev acceleration
> functions.
As far as I can remember, all fbdev operations are done under the
console semaph
On Mon, 2009-06-22 at 11:22 -0700, Linus Torvalds wrote:
> Not going to happen.
>
> Why? 'printk'.
>
> If you can't handle printk, then you're basically useless. And printk
> absolutely -has- to work in bad situations (the most important
> messages could happen in any context).
Well... yes and
On Mon, 2009-06-22 at 17:24 -0700, Linus Torvalds wrote:
>
> On Tue, 23 Jun 2009, Benjamin Herrenschmidt wrote:
> >
> > As far as I can remember, all fbdev operations are done under the
> > console semaphore.
>
> Yeah, and some of them are horribly broken (ie c
> So, in order to fix a problem with the SAREA you align the map size
> for all added maps? Sounds bogus to me, especially since the range of
> possible page sizes is potentially unbounded.
Only the requested size from userspace, most drivers create the map from
the kernel anyway.
> IMO the prop
uld have failed (-EINVAL) will no succeed at the
cost of a little bit more memory used if that happens to be when the map is
created.
Signed-off-by: Benjamin Herrenschmidt
---
That replaces my previous attempt. This is safer and cleaner and still
fixes the radeon problem. Other drivers having other
y checks here if the map is actually too small to be
mapped. We also only do that fir the ioctl, not the in-kernel call.
Signed-off-by: Benjamin Herrenschmidt
---
This fixes DRM with 16K and 64K pages on PowerPC embedded machines. Dunno
if you want that in 2.6.30, I would personally like that
On Fri, 2009-05-15 at 14:46 +1000, Benjamin Herrenschmidt wrote:
> Hi Jesse !
>
> Haven't had much time to investigate the problem I've been talking to
> you and David about but from what I can see in the code, we're probably
> hitting this in drm_mmap_locked() in
Hi Jesse !
Haven't had much time to investigate the problem I've been talking to
you and David about but from what I can see in the code, we're probably
hitting this in drm_mmap_locked() in drm_vm.c :
/* Check for valid size. */
if (map->size < vma->vm_end - vma->vm_start)
On Wed, 2009-02-18 at 01:35 -0800, David Miller wrote:
> Ben, I'm pretty sure you're hitting this too on powerpc. Every time a
> 32-bit process tries to upload cliprects it's going to fail with
> -EFAULT or similar.
Heh, quite possibly
Could that be related to the kernel spewing a bunch of
[drm
> The only think I can think to do is use a surface instead of the
> aperture swappers
> and make the surface cover all the VRAM except the GART table which is
> at the end.
Why not use a surface to cover the GART ? At least this would ensure a
known swapper setting for it.
> That's interesting
> So I've narrowed down the final problems I'm having. It's the surface
> swapping settings indeed.
>
> Running Xorg at depth 8, the CP can execute indirect buffers just
> fine, no code changes necessary.
>
> However, the CP hangs on indirect execution for depth 16 and 24. But
> these depths w
On Fri, 2009-02-13 at 08:26 +1100, Benjamin Herrenschmidt wrote:
> > 1) The kernel radeon framebuffer driver doesn't mess with
> >the framebuffer endianness setting.
> >
> > 2) On >= R300 (which my chip is), Xorg leaves it alone too.
>
> They leave alone
> 1) The kernel radeon framebuffer driver doesn't mess with
>the framebuffer endianness setting.
>
> 2) On >= R300 (which my chip is), Xorg leaves it alone too.
They leave alone the swapper of the engine, not the fb one
(SURFACE_CNTL) afaik.
I dbl checked the other day and it seems that we
On Thu, 2009-02-12 at 21:37 +1100, Benjamin Herrenschmidt wrote:
> Similar comment about potential swapper setting when accessing the RPTR
> via the framebuffer. David (Airlied), what's the current status with
> that stuff ? I know you work on cleaning that shit up in kms, right no
On Thu, 2009-02-12 at 02:15 -0800, David Miller wrote:
> The memory behind ring_rptr can either be in ioremapped memory
> or a vmalloc() normal kernel memory buffer.
>
> However, the code unconditionally uses DRM_{READ,WRITE}32() (and thus
> readl() and writel()) to access it.
>
> Basically, if R
On Thu, 2009-02-12 at 02:15 -0800, David Miller wrote:
> The PCI GART table initialization code treats the GART table mapping
> unconditionally as a kernel virtual address.
>
> But it could be in the framebuffer, for example, and thus we're
> dealing with a PCI MEM space ioremap() cookie. Treatin
Now that linus has real separate struct drm_map and struct drm_local_map,
the drm_local_map_t typedef is gratuituous and I don't like typedefs of
structs that much so remove it.
Signed-off-by: Benjamin Herrenschmidt
---
drivers/gpu/drm/i810/i810_drv.h |4 ++--
drivers/gpu/drm
This is usedul when you have multiple cards to figure out which
one is which minor.
Signed-off-by: Benjamin Herrenschmidt
---
drivers/gpu/drm/drm_stub.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- linux-work.orig/drivers/gpu/drm/drm_stub.c 2009-02-04 17:18:21.0
> Don't worry I've applied the patches with Erics comment replacing your one.
>
> All 3 are queued in drm-next.
Thanks !
I'll let you know when I finally get a chance to tackle the other
issues.
BTW. Do you guys want me to remove the drm_local_map_t typedef
completely in favor of struct drm_lo
On Mon, 2009-02-02 at 11:02 -0800, Eric Anholt wrote:
> On Mon, 2009-02-02 at 16:55 +1100, Benjamin Herrenschmidt wrote:
> > The DRM uses its own wrappers to obtain resources from PCI devices,
> > which currently convert the resource_size_t into an unsigned long.
> >
> &g
>2009-02-02 14:16:04.0 +1100
> > @@ -599,8 +599,8 @@ int savage_driver_firstopen(struct drm_d
> >drm_mtrr_add(dev_priv->mtrr[2].base,
> > dev_priv->mtrr[2].size,
> > DRM_MTRR_WC);
> >} else {
> > -
>
> Could this comment instead be maybe:
>
> Because the kernel-userspace ABI is fixed at a 32-bit offset, while PCI
> resources may live above that, we ignore the map offset for maps of type
> _DRM_FRAMEBUFFER or _DRM_REGISTERS. It is assumed that each driver will
> have only one resource of e
I had to modify drm_find_matching_map() to ignore the offset passed
in for maps of type _DRM_FRAMEBUFFER or _DRM_REGISTERS.
If we ever support multiple _DRM_FRAMEBUFFER or _DRM_REGISTERS maps
for a given device, we might have to change that trick, but I don't
think that happens on any current dri
h a resource in drivers.
Signed-off-by: Benjamin Herrenschmidt
---
drivers/gpu/drm/drm_bufs.c |4 ++--
drivers/gpu/drm/i915/i915_dma.c |2 +-
drivers/gpu/drm/mga/mga_drv.h |4 ++--
drivers/gpu/drm/radeon/radeon_drv.h |2 +-
drivers/gpu/drm/savage/savage_bci.c |
y kill the drm_local_map_t typedef
so I left those bits in.
Signed-off-by: Benjamin Herrenschmidt
---
drivers/gpu/drm/drm_bufs.c | 46 ++-
drivers/gpu/drm/drm_context.c |4 +--
drivers/gpu/drm/drm_drv.c |2 -
drivers/gpu/drm/drm_gem.c
On Thu, 2008-10-23 at 19:48 -0700, Linus Torvalds wrote:
> Then, there's the issue of 64-bit, and just mapping everything there, and
> the interface to that. I liked the trivial extension to "struct resource"
> to have a "cached mapping" pointer. So if we can just make it pass
> resources around
On Thu, 2008-10-23 at 14:24 -0700, Linus Torvalds wrote:
> The whole point of that function has absolutely nothing to do with
> highmem, and it *must* be useful on non-highmem configurations to be
> appropriate.
>
> So I'd much rather create a new or something. Or just
> expose this from to o
until we have more useful
generic kernel API.
Signed-off-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
---
This version of the patch removes the use of GFP_HIGHMEM on powerpc
as our implementation of some of the DMA mapping ops on non cache
coherent platforms don't work on highmem.
Index:
On Mon, 2008-03-03 at 20:51 +0100, Gerhard Pircher wrote:
> > Remove the GFP_HIGHMEM from the above. It looks like our cache
> > flushing isn't going to work for highmem, it would need some
> > kmap's for that.
> Yes, it looks like this was the problem. No kernel oops anymore.
> The machine locks
Bah, I think I found the problem:
+static inline void *drm_vmalloc_dma(unsigned long size)
+{
+#if defined(__powerpc__) && defined(CONFIG_NOT_COHERENT_CACHE)
+ return __vmalloc(size, GFP_KERNEL | __GFP_HIGHMEM,
+PAGE_KERNEL | _PAGE_NO_CACHE);
+#else
+ return vma
> Okay, I changed the code to this:
>
> >DRM_DEBUG("dev = 0x%x, bus_address = 0x%x, bus_to_virt = 0x%lx, max_pages =
> >0x%x\n",
> > (unsigned int)&dev->pdev->dev, bus_address,
> > (unsigned long)virt_to_bus(bus_address), max_pages);
> >
> >if (gart_info->gart_table_location == DRM_ATI_G
> Xorg (v7.1.1, Debian Etch) crashes with this patch (applied to 2.6.25-rc3)
> on my AmigaOne with a Radeon 9200 (PCIGART mode enabled). See the attached
> log file for the stack trace.
That doesn't look possible, which is weird... looks like we are passing
0 to clean_dcache_range().
Interesting
until we have more useful
generic kernel API.
Signed-off-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
---
drivers/char/drm/ati_pcigart.c |6 ++
drivers/char/drm/drm_scatter.c | 12 +++-
drivers/char/drm/drm_vm.c | 20 +++-
3 files changed, 32 inse
On Tue, 2007-05-22 at 08:39 -0700, Jesse Barnes wrote:
>
> The current code does its best to figure out what modes are available and
> tries to pick a good one for each display. It sounds like you're mainly
> concerned with the actual mode picking, not the mode and output detection
> and enume
On Mon, 2007-05-21 at 17:51 -0700, Keith Packard wrote:
>
> That's the plan; the kernel just provides mechanism. The architecture
> used in the X server splits precisely at this point with the mechanism
> in the driver and the configuration and policy up in the X server
> proper. Quite a bit of th
> In collaboration with the FB guys, we've been working on enhancing
> the
> kernel's graphics subsystem in an attempt to bring some sanity to the
> Linux graphics world and avoid the situation we have now where
> several
> kernel and userspace drivers compete for control of graphics devices.
On Thu, 2006-10-05 at 17:52 +0200, Thomas Hellström wrote:
> Ben,
>
> I've implemented a version of the drm_mm code that unmaps ptes using
> unmap_mapping_range, and remaps IO space using io_remap_pfn_range() for
> a single page in nopage. This has the side effect that I need to double
> check
On Thu, 2006-10-05 at 17:52 +0200, Thomas Hellström wrote:
> Ben,
>
> I've implemented a version of the drm_mm code that unmaps ptes using
> unmap_mapping_range, and remaps IO space using io_remap_pfn_range() for
> a single page in nopage. This has the side effect that I need to double
> check
> 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
> 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
> 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
> * 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
> 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 most
> I don't think so.
> We are not doing vram yet in the TTM code, but I think a general
> "eviction" would consist of
>
> 1) locking mmap_sems for all processes mapping the buffer.
> 2) zap the page table. Any attempt to access will be blocked by
> mmap_sem in nopage().
> 3) Copy contents from v
On Tue, 2006-09-19 at 12:49 +0200, Thomas Hellström wrote:
> Benjamin Herrenschmidt wrote:
> > On Tue, 2006-09-19 at 11:27 +0200, Thomas Hellström wrote:
> >
> >
> > > But this should be the same problem encountered by the agpgart driver?
> > > x86 and
On Tue, 2006-09-19 at 11:27 +0200, Thomas Hellström wrote:
> But this should be the same problem encountered by the agpgart driver?
> x86 and x86-64 calls change_page_attr() to take care of this.
> On powerpc it is simply a noop. ()
Possibly. We sort-of ignore the issue for now on PowerPC and hap
On Mon, 2006-09-18 at 16:46 +0200, Thomas Hellström wrote:
> Unfortunately this leads to rather costly cache and TLB flushes.
> Particularly on SMP.
>
> I think Keith was referring to the drawbacks with buffers pinned in
> AGP or VRAM space.
What about a futex-like approach:
A shared are mapped
> Actually, the TTM memory manager already does this,
> but also changes the caching policy of the linear kernel map.
The later is not portable unfortunately, and can have other serious
performance impacts.
Typically, the kernel linear map is mapped using larger page sizes, or
in some cases, ev
> Yes, this is really a different hardware model than we're used to
> dealing with for DRI drivers, however it's not a problem for the most
> part - if you don't need to take the lock, don't. But then you need
> some other way of dealing with the other hacky stuff we get away with by
>loc
On Sun, 2006-06-25 at 19:57 +0400, Elie Morisse wrote:
> Nope, doesn't help :'(
> It still get corrupted after i commented out the 0x0140 stuff. I
> localized the nasty lines, though :
>
> ptr[0x01F8>>2] = 0x011A;
> ptr[0x01FC>>2] = 0x151557FF;
> ptr[0x01F8>
> First, I think, you shouldn't touch register 0x140, you write value 0x22
> there. For my card there is 0x2D (this is power on default and is not
> changed by fglrx). When value 0x22 is written there, I have got
> corrupted console and X desktop too.
This is the MC_CNTL register. It contains som
> Well, the only time I have immediate lockups are when I use nearly
> anything other than glxgears and I haven't started X with fglrx first.
> And, even then, the lockups are simply X, not the full machine. I can
> remotely log in and reboot (though I can't kill the GL application...
> Tha
> > It should probably be infinite if no hw lock is being held.
> > Lock should be dropped in case of longer waits so that user is given a
> > chance to stop the process.
> Well, the current behaviour (i.e. return EBUSY after 3 seconds) would
> make sense too, the user-space driver could simply r
On Sat, 2006-04-22 at 17:40 -0700, Jesse Allen wrote:
> Hi,
>
> There has been a patch to 2.6.17-rc1
> [PATCH] mm: make __put_page internal
> http://www.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=0f8053a509ceba4a077a50ea7b77039b5559b428
>
> I believe this is causing
On Fri, 2006-04-14 at 15:31 +1000, Benjamin Herrenschmidt wrote:
> On Fri, 2006-04-14 at 15:15 +1000, Benjamin Herrenschmidt wrote:
> > > Not sure at this point, but the problem ends up being ctx->DriverCtx at
> > > a different offset
> > > within GLcontext betw
On Fri, 2006-04-14 at 15:15 +1000, Benjamin Herrenschmidt wrote:
> > Not sure at this point, but the problem ends up being ctx->DriverCtx at
> > a different offset
> > within GLcontext between mesa context.c and r300_tex.c.
> >
> > Looks like to get the stuff
> Not sure at this point, but the problem ends up being ctx->DriverCtx at
> a different offset
> within GLcontext between mesa context.c and r300_tex.c.
>
> Looks like to get the stuff built properly, one has to build first, make
> install, make clean and rebuild, and finally re-make install
O
On Thu, 2006-04-13 at 22:04 -0700, Ian Romanick wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Benjamin Herrenschmidt wrote:
>
> > Ok, I got bitten by the build system again...
> >
> > Checking out a fresh mesa source tree, doing a make linux-dri-p
On Fri, 2006-04-14 at 11:00 +1000, Benjamin Herrenschmidt wrote:
> On Fri, 2006-04-14 at 10:38 +1000, Benjamin Herrenschmidt wrote:
> > With an r300 DRI checked out a couple of days ago I get a SEGV with the
> > backtrace below, I will try updating from CVS and looking at it more
&g
On Fri, 2006-04-14 at 10:38 +1000, Benjamin Herrenschmidt wrote:
> With an r300 DRI checked out a couple of days ago I get a SEGV with the
> backtrace below, I will try updating from CVS and looking at it more
> closely later as I find some time...
Same with current CVS, will investig
With an r300 DRI checked out a couple of days ago I get a SEGV with the
backtrace below, I will try updating from CVS and looking at it more
closely later as I find some time...
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 805425952 (LWP 6928)]
r300NewTextureObject (ct
Ok, I rebuild it all from fresh CVS checkouts today and made sure the
trees had no stale .o file or anything. Result is, it doesn't crash, but
doesn't work very well neither.
Machine is a ppc32 laptop, Mesa/DRI built with TLS enabled and X built
with the new enable-glx-tls option from Kristian.
S
On Thu, 2006-03-30 at 10:36 +0300, Daniel Stone wrote:
> On Thu, Mar 30, 2006 at 04:50:52PM +1100, Benjamin Herrenschmidt wrote:
> > On Thu, 2006-03-30 at 16:23 +1100, Benjamin Herrenschmidt wrote:
> > > The one used to build libGL and the DRI was a bit less up to date and
&g
On Thu, 2006-03-30 at 16:23 +1100, Benjamin Herrenschmidt wrote:
> The one used to build libGL and the DRI was a bit less up to date and
> had some stale junk I missed, so I think the problem is my fault. (I've
> been hacking on a native ppc dispatch but it's still incomplete
> Update your Mesa CVS and try again. I checked in some changes a few
> hours ago.
Ok, in fact, I have 2 Mesa trees, one used to build the server and one
used to build libGL, DRI, etc... :) (the later because I use it for
experimenting with the DRI).
The one used to build the server is up to d
Haven't had time to investigate much yet (and probably won't for a
couple of weeks) but with a build of today's CVS Mesa, r300 DRI, and X
against that Mesa version (the whole lot), the server blows up right
away when launching glxinfo or glxgears.
The latest log I got (with glxgears) shows this ba
> > Load DRM with option no_wb=1
> what is it for and how do I do it?
Well... it tells your DRM to not try to do writeback through AGP (that
is to not let the video card write various status informations back to
memory via the AGP bus). Doing AGP writeback is faster, but on some
chipsets, it does
On Sat, 2006-03-25 at 02:26 +0100, Luca Dionisi wrote:
> I'm having problems with Xorg built from cvs sources very recently.
> I've also built from cvs sources libdrm and the latest kernel (2.6.16)
> with the drm enabled for my card (radeon)
> I don't know for sure, but I think my problem is with t
> nvidia-agp is loaded long time before drm.ko and radeon.ko here, so
> this can not be the reason.
Can you try with the driver in ati-1-0-branch from CVS ? You may need a
7.0 server tho ..
Ben.
---
This SF.Net email is sponsored by xPML, a
> Me stupid, there is a module-path in xorg.conf and I forgot to change i
> to the new path.
> Now nwn looks nice, and all games works (ut2k? still have corruption(?)
> on some textures).
I've seen heavy desktop & texture corruption when using mergedfb with
dri too which makes me suspect we mig
On Fri, 2006-03-10 at 10:12 +, Aapo Tahkola wrote:
> On Thu, 02 Mar 2006 09:27:37 +0100
> Christoph Brill <[EMAIL PROTECTED]> wrote:
>
> > Hi list,
> >
> > I'm still seeing lots of lockups with my r300 (Radeon 9700Pro) with
> > current drm/mesa/xf86-video-ati cvs. I think I found a reproduca
> I have not rebuilt xserver, however I looked into cvs today and I noticed :
>
> "Stop using xf86PciInfo.h, instead use a local copy of the PCI IDs
> we need in atipciids.h so we can update the ATI driver independently
> of the server when new chips are added"
>
> Well that did
> I was unable to run a completely naked X, as if I try to run glxgears
> without a window manager I get a strange result...
> http://laera.web.cs.unibo.it/no-wm.png
> Using vtwm if I run glxgears I get ~ 2600 fps, then if I run 3ddesk
> (http://desk3d.sourceforge.net/) and restart glxgears it run
> I was unable to run a completely naked X, as if I try to run glxgears
> without a window manager I get a strange result...
> http://laera.web.cs.unibo.it/no-wm.png
> Using vtwm if I run glxgears I get ~ 2600 fps, then if I run 3ddesk
> (http://desk3d.sourceforge.net/) and restart glxgears it run
> I was unable to run a completely naked X, as if I try to run glxgears
> without a window manager I get a strange result...
> http://laera.web.cs.unibo.it/no-wm.png
Does this still happen with latest DRI from CVS ?
> Using vtwm if I run glxgears I get ~ 2600 fps, then if I run 3ddesk
> (http://
> For Q1, the status is that it should work, but apparently it locks up
> for some unknown reason for some people. There was a significant fix for
> potential lockup problems in the radeon ddx driver in xorg modular cvs,
> which may or not help you. You should try the snapshots, you can try
>
een, not the preview in the conf window, and 3ddesk. When
> they runs I had to reboot to get normal performance. I've tried also
> neverball, bzflag and foobillard, but that were fine.
>
> Benjamin Herrenschmidt wrote:
> > I don't have time to work on that with your at the mo
I found the problem I introduced with Page Flipping, I pushed a fix to
CVS, however, I still see a (different) issue. I don't think it was
introduced by my patch but I don't have an old X to test with at the
moment...
When using Page Flipping, I launch glxgears, it's all fine.
Now I move the wind
> Well I already looked at it and thought it's impossible this happens
> ;-). Just for completeness, I tested with the drm patches too which
> didn't change anything.
Unless I missed something in my tests... RADEONDRIRefreshArea() is never
called. I verified that ShadowFBInit() does succeed tho
On Wed, 2006-02-22 at 03:01 -0500, Patrick McFarland wrote:
> On Tuesday 21 February 2006 01:29, Benjamin Herrenschmidt wrote:
> > On Sat, 2006-02-18 at 21:45 -0500, Patrick McFarland wrote:
> > > Well, I finally upgraded my Radeon 8500 to a Radeon 9600, however trying
>
On Sat, 2006-02-18 at 21:45 -0500, Patrick McFarland wrote:
> Well, I finally upgraded my Radeon 8500 to a Radeon 9600, however trying to
> use Xorg's DRI drivers with it causes X to completely lock up on startup.
> ATI's binary drivers work fine, however. Also, starting Xorg without Load
> "dri
On Fri, 2006-02-17 at 19:37 +0100, Roland Scheidegger wrote:
> Benjamin Herrenschmidt wrote:
> > I finally commited the X driver side of the radeon memory map patches to
> > the xorg CVS.
> I just noticed this breaks page flipping here (rv250), obviously with
> xaa only (he
On Fri, 2006-02-17 at 19:37 +0100, Roland Scheidegger wrote:
> Benjamin Herrenschmidt wrote:
> > I finally commited the X driver side of the radeon memory map patches to
> > the xorg CVS.
> I just noticed this breaks page flipping here (rv250), obviously with
> xaa only (he
I finally commited the X driver side of the radeon memory map patches to
the xorg CVS. This is the matching DRM patch. David, please commit to
DRM CVS if you are ok with it.
http://gate.crashing.org/~benh/radeon-memmap-drm-5.diff
Ben.
---
Th
1 - 100 of 323 matches
Mail list logo
