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, and that has a serial port :-)
- AGP: locks
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
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 b...@kernel.crashing.org
---
drivers/gpu/drm/radeon/radeon_clocks.c | 81
1 files changed, 81 insertions(+), 0
On Mon, 2010-08-09 at 03:18 -0400, Alex Deucher wrote:
2010/8/9 Benjamin Herrenschmidt b...@kernel.crashing.org:
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 this either
and I
- 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, handoff doesn't
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 b...@kernel.crashing.org
---
drivers/gpu/drm/radeon/radeon_device.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu
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 b...@kernel.crashing.org
---
xf86drm.c | 30
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 b...@kernel.crashing.org
---
drivers/gpu/drm/drm_ioctl.c |1
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=/nouveau/xxx.ctxprog nouveau/yyy.ctxvals
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 loads as a
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
of it:
Acked-by: Benjamin Herrenschmidt b...@kernel.crashing.org
---
Note that I do believe we still have some kind of race vs. the default
VGA device going away but it's rather minor, something to fix at some
stase though.
---
drivers/gpu/Makefile |2 +-
drivers/gpu/vga/Kconfig
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 copying data from user
space while doing
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 no. If
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 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 consoles
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 b...@kernel.crashing.org
---
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
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 b...@kernel.crashing.org
---
That replaces my previous attempt. This is safer and cleaner and still
fixes the radeon problem. Other
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 proper
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 drm_vm.c :
/* Check
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
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 work if
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, it
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
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 now,
we'll hit
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 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 the swapper of the engine, not the fb one
This is usedul when you have multiple cards to figure out which
one is which minor.
Signed-off-by: Benjamin Herrenschmidt b...@kernel.crashing.org
---
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
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 b...@kernel.crashing.org
---
drivers/gpu/drm/i810/i810_drv.h |4
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
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 each
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 {
-
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.
This is broken on 32-bit platforms
typedef
so I left those bits in.
Signed-off-by: Benjamin Herrenschmidt b...@kernel.crashing.org
---
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
such a resource in drivers.
Signed-off-by: Benjamin Herrenschmidt b...@kernel.crashing.org
---
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
() 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 driver.
Signed-off-by: Benjamin Herrenschmidt b
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 linux/kmap.h or something. Or just
expose this
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 and
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: linux-work
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 up
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().
Interestingly
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_GART_MAIN) {
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
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 insertions(+), 6
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
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 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 that
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 in
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 in
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
* 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
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
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
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
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 vram to
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
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. (asm/agp.h)
Possibly. We sort-of ignore the issue for now on PowerPC
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
lock
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,
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 by
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 some
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[0x01F82] = 0x011A;
ptr[0x01FC2] = 0x151557FF;
ptr[0x01F82] =
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...
That
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 redo the
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 drm
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 between mesa context.c and r300_tex.c
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
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 investigate later
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
closely later as I
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-ppc in it,
what hapens is that
- mesa
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 built properly, one has to build first, make
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.
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
had some stale junk I
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
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).
Rebuilt with up
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
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 the
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
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 help...
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 reproducable
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
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 runs
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 runs
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
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
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
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
to use Xorg's DRI drivers
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 (heavy flicker). This is without
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 (heavy flicker). This is without
On Thu, 2006-02-16 at 10:05 +0100, Dario Laera wrote:
Benjamin Herrenschmidt wrote:
It could be some other thing ... The radeonfb kernel driver tries to
save restore as much registers as it knows about on sleep / wakeup but
it might be missing one or two ... it would be interesting to do
On Tue, 2006-02-14 at 14:16 +0100, Dario Laera wrote:
Hi all,
I'm running r300 driver on my powerbook with ati 9600, and I've noted
this problem: if I run glxgears after boot I get ~2600 fps, while after
a sleep/resume I get ~1600 fps. I don't know if it's due to the dri
driver, to the xorg
Current DRM CVS HEAD doesn't work for me. However it does work with a
small patch applied:
https://bugs.freedesktop.org/show_bug.cgi?id=5450#c3
Does it make sense to test that DRM code with the new X patch?
You mean the DRM without my old patch doesn't work ? What was the
symptom ? lockups
On Mon, 2006-02-13 at 11:53 -0800, Donnie Berkholz wrote:
Kevin Shanahan wrote:
All seems good. No regressions on my Radeon Mobility M6 LY and Radeon
64MB DDR (7200). VT switch problems from #2 now fixed. Radeon 9800 Pro
still locks up with 3D, but that's not a regression.
I just had
Can you try all combinations of my old patch, new patch, X patch !X
patch and let me know what the results are ?
If it's perfectly stable with your latest patch and without that one bad
Mesa patch, would that convince you it's not a bug in DRM/DDX? :)
Well, I'm navigating between lots
On Sun, 2006-02-12 at 19:25 +0100, Tilman Sauerbeck wrote:
Tilman Sauerbeck [2006-02-12 13:39]:
Benjamin Herrenschmidt [2006-02-10 18:12]:
Here's a 3rd set of patches. Please report regressions ASAP as I intend
to merge those in the various CVS trees real soon now
On Sat, 2006-02-11 at 09:04 +1030, Kevin Shanahan wrote:
On Fri, Feb 10, 2006 at 06:12:24PM +1100, Benjamin Herrenschmidt wrote:
Here's a 3rd set of patches. Please report regressions ASAP as I intend
to merge those in the various CVS trees real soon now.
Thanks Ben, compiling now - I just
Here's a 3rd set of patches. Please report regressions ASAP as I intend
to merge those in the various CVS trees real soon now.
I fixed a couple of possible segfaults I found due to initialisation
issues (places relying on pScrn-pScreen from within ScreenInit() and
incorrect ordering of colormap
On Thu, 2006-02-02 at 07:08 +1030, Kevin Shanahan wrote:
On Mon, Jan 30, 2006 at 09:41:30AM +1030, Kevin Shanahan wrote:
On Sun, Jan 29, 2006 at 04:04:50PM +1100, Benjamin Herrenschmidt wrote:
On Sun, 2006-01-29 at 10:06 +1030, Kevin Shanahan wrote:
I also tested on my desktop
1 - 100 of 295 matches
Mail list logo
