Hi, Jesse,
When compiled drm module against kernel 2.6.21, it complaint that :
WARNING: __you_cannot_kmalloc_that_much
[/GFX/build/component/Drm/drm/linux-core/i915.ko] undefined!
And when started up XOrg, it reported below error and DRI was disabled:
FATAL: Error inserting i915
Hi,
We've uncovered a need when using the new memory manager to flush the
chipset global write buffers on certain intel chipset due to a lack of
coherency..
The attached patches add a new AGP interface for this purpose and
implements this in the Intel AGP driver. This stuff is based of some
On Fri, 2007-10-26 at 10:59 -0700, Jesse Barnes wrote:
diff --git a/src/glx/x11/glxcmds.c b/src/glx/x11/glxcmds.c
index 707e398..25eaccc 100644
--- a/src/glx/x11/glxcmds.c
+++ b/src/glx/x11/glxcmds.c
@@ -2919,8 +2928,10 @@ int __glXGetInternalVersion(void)
*any DRI
On Mon, 2007-10-29 at 08:15 +, Dave Airlie wrote:
The attached patches add a new AGP interface for this purpose and
implements this in the Intel AGP driver. This stuff is based of some
guesswork in the 915 case from comments in the documentation :).
The relevant register lives in
Sorry about that, a piece of code snuck into that commit that shouldn't
have. Fixed in 6342e0507be177be309774aff0c31746beab73f6.
Jesse
On Monday, October 29, 2007 1:49 am Wu, Nian wrote:
Hi, Jesse,
When compiled drm module against kernel 2.6.21, it complaint that :
WARNING:
On 10/29/07, Michel Dänzer [EMAIL PROTECTED] wrote:
On Fri, 2007-10-26 at 10:59 -0700, Jesse Barnes wrote:
diff --git a/src/glx/x11/glxcmds.c b/src/glx/x11/glxcmds.c
index 707e398..25eaccc 100644
--- a/src/glx/x11/glxcmds.c
+++ b/src/glx/x11/glxcmds.c
@@ -2919,8 +2928,10 @@ int
In this case, we're performing basically a dma_sync*(...DMA_TO_DEVICE)
right? Can we be sure that a single flush is sufficient? Is there any
window between when we flush and when we start accessing memory with
the device that we could get into more caching trouble?
Not that I can
On Monday, October 29, 2007 1:15 am Dave Airlie wrote:
Hi,
We've uncovered a need when using the new memory manager to flush the
chipset global write buffers on certain intel chipset due to a lack
of coherency..
The attached patches add a new AGP interface for this purpose and
implements
On Monday, October 29, 2007 12:52 pm Dave Airlie wrote:
In this case, we're performing basically a
dma_sync*(...DMA_TO_DEVICE) right? Can we be sure that a single
flush is sufficient? Is there any window between when we flush and
when we start accessing memory with the device that we
On Monday, October 29, 2007 1:12 pm Keith Packard wrote:
On Mon, 2007-10-29 at 12:47 -0700, Jesse Barnes wrote:
In this case, we're performing basically a
dma_sync*(...DMA_TO_DEVICE) right?
But this is just for the GPU; every other DMA device in the system is
cache-coherent.
Right.
On Mon, 2007-10-29 at 12:47 -0700, Jesse Barnes wrote:
In this case, we're performing basically a dma_sync*(...DMA_TO_DEVICE)
right?
But this is just for the GPU; every other DMA device in the system is
cache-coherent.
Can we be sure that a single flush is sufficient? Is there any
Hi
I can't run Gtkradiant
(http://www.qeradiant.com/cgi-bin/trac.cgi) with the radeon
driver and the following hardware/software:
01:00.0 VGA compatible controller: ATI Technologies Inc RV350
[Mobility Radeon 9600 M10]
Libraries and driver from Debian testing (6.6.193-3 driver's
version)
Jose Rodriguez wrote:
Hi
I can't run Gtkradiant
(http://www.qeradiant.com/cgi-bin/trac.cgi) with the radeon
driver and the following hardware/software:
01:00.0 VGA compatible controller: ATI Technologies Inc RV350
[Mobility Radeon 9600 M10]
Libraries and driver from Debian testing
http://bugs.freedesktop.org/show_bug.cgi?id=12877
--- Comment #4 from [EMAIL PROTECTED] 2007-10-29 16:02 PST ---
I was wondering - could this bug be the result of heap corruption within Mesa
that slowly kills the X server?
--
Configure bugmail:
Arg, eventually I'll send this mail correctly (last one was rejected
since my @intel.com address isn't a subscriber).
How does this one look?
Thanks,
Jesse
On Monday, October 29, 2007 2:17 pm Chris Rankin wrote:
Hi,
A NULL pointer is killing OpenGL for my Radeon 9200; here's a quick
fix.
http://bugs.freedesktop.org/show_bug.cgi?id=12877
--- Comment #5 from [EMAIL PROTECTED] 2007-10-29 16:20 PST ---
(In reply to comment #4)
I was wondering - could this bug be the result of heap corruption within Mesa
that slowly kills the X server?
since dri clients have their own
http://bugs.freedesktop.org/show_bug.cgi?id=12877
--- Comment #7 from [EMAIL PROTECTED] 2007-10-29 17:35 PST ---
(In reply to comment #6)
And no, switching to a console and back doesn't reset the problem. I actually
need to restart X to do that.
Hmm, to clarify: restarting X
http://bugs.freedesktop.org/show_bug.cgi?id=12877
--- Comment #6 from [EMAIL PROTECTED] 2007-10-29 16:53 PST ---
It is not a new issue; I first noticed it a while ago, but it has been getting
steadily worse recently.
And no, switching to a console and back doesn't reset the problem.
Hi,
So currently the TTM interface allows the user specify a cacheable
allocation, and on Intel hardware this gets conflated with using the intel
snooped memory type in the GART. This is bad as the intel snooped memory
type comes with its own set of special rules and sucks for lots of things.
On Mon, 29 Oct 2007 22:50:06 +0100
Roland Scheidegger [EMAIL PROTECTED] wrote:
Jose Rodriguez wrote:
Hi
I can't run Gtkradiant
(http://www.qeradiant.com/cgi-bin/trac.cgi) with the radeon
driver and the following hardware/software:
01:00.0 VGA compatible controller: ATI
--- Jesse Barnes [EMAIL PROTECTED] wrote:
Arg, eventually I'll send this mail correctly (last one was rejected
since my @intel.com address isn't a subscriber).
How does this one look?
Well, it compiles and doesn't crash... ;-)
Cheers,
Chris
21 matches
Mail list logo
