[Bug 25630] Segfault in nexuiz when trying to run the tutorial.
http://bugs.freedesktop.org/show_bug.cgi?id=25630 --- Comment #1 from Laurent carlier lordhea...@gmail.com 2009-12-14 00:34:17 PST --- http://thread.gmane.org/gmane.comp.video.dri.devel/41114 This patch fix the segfault, bug some textures are *borked* -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 25630] Segfault in nexuiz when trying to run the tutorial.
http://bugs.freedesktop.org/show_bug.cgi?id=25630 --- Comment #2 from Laurent carlier lordhea...@gmail.com 2009-12-14 00:50:25 PST --- Created an attachment (id=32057) -- (http://bugs.freedesktop.org/attachment.cgi?id=32057) desktop corruption Running nexuiz give some texture corruption in the game and some corruption when back to the desktop (kde running without effect composition) -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] drm/radeon/kms: add dynamic engine reclocking (v3)
Addendum Up-/Downclocking: # cat /sys/module/radeon/parameters/dynclks -1 Value of -1 means dynamic clocking (dynclks) is not set. Two options to activate dynamic clocking: [1] At modprobe-time: (tested in runlevel-3: booted with nomodeset): # modprobe -r -v radeon --- unload kernel-module # modprobe -v radeon modeset=1 dynclks=1 --- load with new module-options # dmesg | egrep -i 'dynamic clocking|power management' [drm] radeon: dynamic clocking enabled [drm] radeon: power management initialized [2] At boot-time: Add modeset=1 and dynclks=1 to your Kernel-command-line (in most cases grub, see grub documentation). Depending on distribution and kernel it might be radeon.modeset=1 and radeon.dynclks=1. Unfortunately, with dynamic clocking enabled, I have still no luck with upclocking: # cat /sys/kernel/debug/dri/*/radeon_pm_info engine clock: 391500 kHz memory clock: 297000 kHz engine clock: 391500 kHz memory clock: 297000 kHz Thanks Rafal (sorry don't know how to activate that crossed L-sign in your first name) Zajec for explanation on IRC. - Sedat - On Sun, Dec 13, 2009 at 11:00 PM, Sedat Dilek sedat.di...@googlemail.com wrote: Hi, I tried v3 of the radeon PM patch from [1]. Here my feeback: # lspci -nnvv | grep VGA controller 01:00.0 VGA compatible controller [0300]: ATI Technologies Inc M52 [Mobility Radeon X1300] [1002:714a] (prog-if 00 [VGA controller]) # mount -t debugfs none /sys/kernel/debug/ # ln -s /sys/kernel/debug /debug # find /debug/ -name radeon_pm_info /debug/dri/0/radeon_pm_info /debug/dri/64/radeon_pm_info # cat /sys/kernel/debug/dri/*/radeon_pm_info engine clock: 391500 kHz memory clock: 297000 kHz engine clock: 391500 kHz memory clock: 297000 kHz From the backlog [3]: 13:32 #radeon: Zajec dileX: Wikipedia says your default engine clock is 450MHz... your logs shows 391MHz which should mean downclocking working :) While starting glxgears upclocking seems not to work, yet. Good job, anyway! Kind Regards, - Sedat - [1] 0001-drm-radeon-kms-add-dynamic-engine-reclocking-v3.patch http://marc.info/?l=dri-develm=126063445301253w=2 [2] debugfs mount point http://lwn.net/Articles/323307/ [3] Backlog #radeon/freenode http://people.freedesktop.org/~cbrill/dri-log/index.php?date=2009-12-13channel=radeon -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 14801] radeon.modeset=1 boot option crashes system with ATI rc410 card producing garbled system logs
http://bugzilla.kernel.org/show_bug.cgi?id=14801 Alex Deucher alexdeuc...@gmail.com changed: What|Removed |Added CC||alexdeuc...@gmail.com --- Comment #4 from Alex Deucher alexdeuc...@gmail.com 2009-12-14 14:35:31 --- Can you try 2.6.32 or Dave's drm-radeon-testing branch? http://git.kernel.org/?p=linux/kernel/git/airlied/drm-2.6.git;a=shortlog;h=refs/heads/drm-radeon-testing There have been a lot of bug fixes since 2.6.31. -- Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 14801] radeon.modeset=1 boot option crashes system with ATI rc410 card producing garbled system logs
http://bugzilla.kernel.org/show_bug.cgi?id=14801 --- Comment #5 from Evgeniy eumos...@gmail.com 2009-12-14 16:20:23 --- Thanks Alex, It might Sorry, I should have mentioned it before Since 1.6.32.rc7 when booting to GNOME I get no further than gdm. The system gets locked with a black screen and not SysRq keys working. Moreover, 2.6.32 stable and drm-next from http://kernel.ubuntu.com/~kernel-ppa/mainline/ gave me this even worse situation. Please see this report http://bugzilla.kernel.org/show_bug.cgi?id=14331 Another thing is how can a bug be fixed, if no one knew of it, it seems, before I reported it? I have not seen garbled logs bugs since 2002, let me know if you had. Please let me know Thanks -- Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
TTM eviction ghost object
Hi Thomas, Dave find out the root of a strange oops we did encouter. I spend sometimes today trying to hack ttm around but in the end my solution is wrong. So when we move an object a ttm ghost object is created. If GPU takes time to evict the bo the ghost object endup on the destroy list stay on the lru list (unless i have missunderstood the code the whole day). No if ghost is in GTT (similar issue can happen in different configuration, bottom line is evicting a ghost object) it can get evicted and that's when trouble start. The driver callback get call with the ghost object but ghost object haven't been created by the driver and thus driver will more than likely endup oupsing trying to access its private bo structure (ttm_bo structure is embeded in radeon_bo structure and any driver relying on accessing the driver structure will hit this issue). I see 2 solutions : - Don't put ghost on lru list - Add a flag so we know if we can call driver callback on object or not. I will send the first solution patch but i haven't yet found an easy way to exercise this path. My concern is that when in ttm_bo_mem_force_space we might fail because we don't wait for the ghost object to actualy die and free space (issue only if no_wait=false). Also i wonder if letting a ghost bo object on lru might not lead to infinite eviction loop. Case i am thinking of : - VRAM is full only 1 object we can evict, we evict it and create a ghost object holding the vram space the eviction is long enough that we put the ghost on lru. ttm_bo_mem_force_space evict the ghost_object and we loop on this. Anyway, what is your thought on this. Cheers, Jerome on the lru and just let it stay on the destroy list, but that doesn't endup that well. -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH] drm/ttm: don't add ghost object to lru
Ghost object shouldn't endup on lru to avoid an infinite loop when evicting or to avoid calling driver callback on the ghost object (which isn't a valid driver object). Signed-off-by: Jerome Glisse jgli...@redhat.com --- drivers/gpu/drm/ttm/ttm_bo_util.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/gpu/drm/ttm/ttm_bo_util.c b/drivers/gpu/drm/ttm/ttm_bo_util.c index ceae52f..286e261 100644 --- a/drivers/gpu/drm/ttm/ttm_bo_util.c +++ b/drivers/gpu/drm/ttm/ttm_bo_util.c @@ -592,7 +592,7 @@ int ttm_bo_move_accel_cleanup(struct ttm_buffer_object *bo, else bo-ttm = NULL; - ttm_bo_unreserve(ghost_obj); + ttm_bo_unblock_reservation(ghost_obj); ttm_bo_unref(ghost_obj); } -- 1.6.5.2 -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [BISECTED] drm: random hang since 620f378 drm: prune modes when ...
On Mon, 14 Dec 2009 07:54:05 +1000 Dave Airlie airl...@redhat.com wrote: On Sun, 2009-12-13 at 21:31 +, Arnd Bergmann wrote: On Sunday 13 December 2009 20:00:18 Daniel Vetter wrote: On Sun, Dec 13, 2009 at 12:30:25PM +, Arnd Bergmann wrote: And now it's obvious that my computer hates me. 12 hours of uptime, one reboot to check the old other version is broken, it crashes. I reboot into the good version, send out the above email and the next minute it crashes again. c05422d52ee6b is not the culprit. Sorry Daniel for blaming your patch. No problem. Looks like your hunting a pretty ugly Heisenbug. There's quite a interesting blog post by Paul McKenney, esp. the solution to Quick Quiz 1 might be usefull in your case: http://paulmck.livejournal.com/14639.html Thanks! In fact I've actually read that post on the kernel planet and decided to do basically a linear search through the i915 patches merged into 2.6.32. The current result is 67cf781bea5 drm/i915: Make the downclocking debug code be under DRM_DEBUG not DRM_ERROR. is known bad, while 043029655 drm/i915: Support IGD EOS is probably good, pointing to Jesses 652c393a33 drm/i915: add dynamic clock frequency control as the next best guess. Unfortunately, that is a rather large change that is not easy to revert on current kernels. That seems the most likely, perhaps jbarnes can comment. You can disable most of that code by loading i915 with 'powersave=0'. If that patch really is at fault the powersave=0 should work around the issue as well. It's been implicated in another issue (some display flicker and underruns) so I'm pretty sure there's something wrong with it in some configurations at least... -- Jesse Barnes, Intel Open Source Technology Center -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] drm/radeon/kms: fix r100-r500 CS checker for compressed textures. (v2)
Reviewed-by: Maciej Cencora m.cenc...@gmail.com
Dnia poniedziałek, 14 grudnia 2009 o 03:26:31 Dave Airlie napisał(a):
From: Dave Airlie airl...@redhat.com
This adds support for compressed textures to the r100-r500 CS
checker, it lets me run openarena and the demos in mesa fine.
Thanks to Maciej Cencora for initial comments.
Changes since v1:
fix calculations with Maciej formulas
Signed-off-by: Dave Airlie airl...@redhat.com
---
drivers/gpu/drm/radeon/r100.c | 52
--- drivers/gpu/drm/radeon/r100_track.h |
5 +++
drivers/gpu/drm/radeon/r200.c | 10 +-
drivers/gpu/drm/radeon/r300.c | 12 ++--
4 files changed, 70 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/radeon/r100.c b/drivers/gpu/drm/radeon/r100.c
index 824cc64..62532f6 100644
--- a/drivers/gpu/drm/radeon/r100.c
+++ b/drivers/gpu/drm/radeon/r100.c
@@ -1374,7 +1374,6 @@ static int r100_packet0_check(struct radeon_cs_parser
*p, case RADEON_TXFORMAT_ARGB:
case RADEON_TXFORMAT_VYUY422:
case RADEON_TXFORMAT_YVYU422:
- case RADEON_TXFORMAT_DXT1:
case RADEON_TXFORMAT_SHADOW16:
case RADEON_TXFORMAT_LDUDV655:
case RADEON_TXFORMAT_DUDV88:
@@ -1382,12 +1381,19 @@ static int r100_packet0_check(struct
radeon_cs_parser *p, break;
case RADEON_TXFORMAT_ARGB:
case RADEON_TXFORMAT_RGBA:
- case RADEON_TXFORMAT_DXT23:
- case RADEON_TXFORMAT_DXT45:
case RADEON_TXFORMAT_SHADOW32:
case RADEON_TXFORMAT_LDUDUV:
track-textures[i].cpp = 4;
break;
+ case RADEON_TXFORMAT_DXT1:
+ track-textures[i].cpp = 1;
+ track-textures[i].compress_format =
R100_TRACK_COMP_DXT1;
+ break;
+ case RADEON_TXFORMAT_DXT23:
+ case RADEON_TXFORMAT_DXT45:
+ track-textures[i].cpp = 1;
+ track-textures[i].compress_format =
R100_TRACK_COMP_DXT35;
+ break;
}
track-textures[i].cube_info[4].width = 1 ((idx_value 16)
0xf);
track-textures[i].cube_info[4].height = 1 ((idx_value
20) 0xf);
@@ -2731,6 +2737,7 @@ static inline void r100_cs_track_texture_print(struct
r100_cs_track_texture *t) DRM_ERROR(coordinate type%d\n,
t-tex_coord_type); DRM_ERROR(width round to power of 2 %d\n,
t-roundup_w);
DRM_ERROR(height round to power of 2 %d\n, t-roundup_h);
+ DRM_ERROR(compress format%d\n, t-compress_format);
}
static int r100_cs_track_cube(struct radeon_device *rdev,
@@ -2760,6 +2767,36 @@ static int r100_cs_track_cube(struct radeon_device
*rdev, return 0;
}
+static int r100_track_compress_size(int compress_format, int w, int h)
+{
+ int block_width, block_height, block_bytes;
+ int wblocks, hblocks;
+ int min_wblocks;
+ int sz;
+
+ block_width = 4;
+ block_height = 4;
+
+ switch (compress_format) {
+ case R100_TRACK_COMP_DXT1:
+ block_bytes = 8;
+ min_wblocks = 4;
+ break;
+ default:
+ case R100_TRACK_COMP_DXT35:
+ block_bytes = 16;
+ min_wblocks = 2;
+ break;
+ }
+
+ hblocks = (h + block_height - 1) / block_height;
+ wblocks = (w + block_width - 1) / block_width;
+ if (wblocks min_wblocks)
+ wblocks = min_wblocks;
+ sz = wblocks * hblocks * block_bytes;
+ return sz;
+}
+
static int r100_cs_track_texture_check(struct radeon_device *rdev,
struct r100_cs_track *track)
{
@@ -2797,9 +2834,15 @@ static int r100_cs_track_texture_check(struct
radeon_device *rdev, h = h / (1 i);
if (track-textures[u].roundup_h)
h = roundup_pow_of_two(h);
- size += w * h;
+ if (track-textures[u].compress_format) {
+
+ size +=
r100_track_compress_size(track-textures[u].compress_format,
w, h); + /* compressed textures are block based
*/
+ } else
+ size += w * h;
}
size *= track-textures[u].cpp;
+
switch (track-textures[u].tex_coord_type) {
case 0:
break;
@@ -2967,6 +3010,7 @@ void r100_cs_track_clear(struct radeon_device *rdev,
struct r100_cs_track *track track-arrays[i].esize = 0x7F;
}
for (i = 0; i track-num_texture; i++) {
+ track-textures[i].compress_format = R100_TRACK_COMP_NONE;
track-textures[i].pitch = 16536;
track-textures[i].width = 16536;
Re: Display corruption/distortion with KMS and R700_rlc.bin
2009/12/13 nez...@allurelinux.org: On Sun, Dec 13, 2009 at 11:38:04PM +0200, nez...@allurelinux.org wrote: Hi, I hope you don't mind me posting this directly as bugs are forwarded to the list anyway. I grabbed a kernel snapshot from drm-radeon-testing head yesterday and built it. I grabbed R700_rlc.bin too as It's apparently necessary to enable mesa hardware acceleration with KMS. That resulted in what you can see in this screenshot: http://omploader.org/vMnpoMA It should normally look like this: http://omploader.org/vMnpoMQ Disabling KMS re-enables hardware acceleration and shows no corruption. When I remove R700_rlc.bin I get no corruption but hardware acceleration is disabled. I just thought the words I used to describe the problem are not accurate. The distortion seems to affect text(all text). You can see the wallpaper displayed properly. Also forgot to mention the card model: 01:00.0 VGA compatible controller: ATI Technologies Inc M92 [Mobility Radeon HD 4500 Series] -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel I'm seeing corruption and colour changes -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: TTM eviction ghost object
Jerome Glisse wrote: Hi Thomas, Dave find out the root of a strange oops we did encouter. I spend sometimes today trying to hack ttm around but in the end my solution is wrong. So when we move an object a ttm ghost object is created. If GPU takes time to evict the bo the ghost object endup on the destroy list stay on the lru list (unless i have missunderstood the code the whole day). No if ghost is in GTT (similar issue can happen in different configuration, bottom line is evicting a ghost object) it can get evicted and that's when trouble start. The driver callback get call with the ghost object but ghost object haven't been created by the driver and thus driver will more than likely endup oupsing trying to access its private bo structure (ttm_bo structure is embeded in radeon_bo structure and any driver relying on accessing the driver structure will hit this issue). I see 2 solutions : - Don't put ghost on lru list - Add a flag so we know if we can call driver callback on object or not. Jerome, In general, since the driver bo is *derived* from the ttm bo, and the callback takes the base type, ttm bos as arguments, The driver needs to check the object type before typecasting. We do a similar check in the vmwgfx driver by checking the bo destroy function, to see whether it's the driver specific destroy, so this first problem should be viewed as a driver bug, as I see it. Note that if you need driver private per-bo information to be added to a bo in order for move() to work, you should carefully review if it's *really* needed, and in that case we must set up a callback to add that information at bo creation, but in general the driver specific move function should be able to handle the base object type. I will send the first solution patch but i haven't yet found an easy way to exercise this path. My concern is that when in ttm_bo_mem_force_space we might fail because we don't wait for the ghost object to actualy die and free space (issue only if no_wait=false). Also i wonder if letting a ghost bo object on lru might not lead to infinite eviction loop. Case i am thinking of : - VRAM is full only 1 object we can evict, we evict it and create a ghost object holding the vram space the eviction is long enough that we put the ghost on lru. ttm_bo_mem_force_space evict the ghost_object and we loop on this. Anyway, what is your thought on this. This situation is actually handled by the evict bool. When @evict==true, no ghost object is created, and eviction is synchronous, so rather than being incorrect, we're being suboptimal. I admit this isn't the most optimal solution. My plan when I get time is to implement fully asynchronous memory management. That means that the managers are in sync with the CPU and not the GPU, and all buffer moves are pipelined, provided that the driver supports it. This also means that I will hang a sync object on each memory type manager, so that if we need to switch hw engine, and sync the manager with the GPU, we can wait on that sync object. This will mean that when you evict a buffer object, its space will immediately show up as free, although it really isn't free yet, but it *will* be free when the gpu executes a move to that memory region, since the eviction will be scheduled before the move to memory. Thanks, Thomas Cheers, Jerome -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH] drm/radeon/kms: Check if bo we got from ttm are radeon object or not
If they are not radeon object don't do anythings special for them,
this avoid rare oops than can happen in a complex use case.
Signed-off-by: Jerome Glisse jgli...@redhat.com
---
drivers/gpu/drm/radeon/radeon.h|1 +
drivers/gpu/drm/radeon/radeon_object.c |9 +
drivers/gpu/drm/radeon/radeon_ttm.c| 11 +++
3 files changed, 21 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
index d4c786f..854294c 100644
--- a/drivers/gpu/drm/radeon/radeon.h
+++ b/drivers/gpu/drm/radeon/radeon.h
@@ -1038,6 +1038,7 @@ extern void radeon_atom_set_clock_gating(struct
radeon_device *rdev, int enable)
extern void radeon_ttm_placement_from_domain(struct radeon_bo *rbo, u32
domain);
extern void radeon_mc_init_vram_location(struct radeon_device *rdev, u64 base);
extern void radeon_mc_init_gtt_location(struct radeon_device *rdev);
+extern bool radeon_ttm_bo_is_radeon_bo(struct ttm_buffer_object *bo);
/* r100,rv100,rs100,rv200,rs200,r200,rv250,rs300,rv280 */
struct r100_mc_save {
diff --git a/drivers/gpu/drm/radeon/radeon_object.c
b/drivers/gpu/drm/radeon/radeon_object.c
index 132130f..115222e 100644
--- a/drivers/gpu/drm/radeon/radeon_object.c
+++ b/drivers/gpu/drm/radeon/radeon_object.c
@@ -56,6 +56,13 @@ static void radeon_ttm_bo_destroy(struct ttm_buffer_object
*tbo)
kfree(bo);
}
+bool radeon_ttm_bo_is_radeon_bo(struct ttm_buffer_object *bo)
+{
+ if (bo-destroy == radeon_ttm_bo_destroy)
+ return true;
+ return false;
+}
+
void radeon_ttm_placement_from_domain(struct radeon_bo *rbo, u32 domain)
{
u32 c = 0;
@@ -486,6 +493,8 @@ void radeon_bo_move_notify(struct ttm_buffer_object *bo,
struct ttm_mem_reg *mem)
{
struct radeon_bo *rbo = container_of(bo, struct radeon_bo, tbo);
+ if (!radeon_ttm_bo_is_radeon_bo(bo))
+ return;
radeon_bo_check_tiling(rbo, 0, 1);
}
diff --git a/drivers/gpu/drm/radeon/radeon_ttm.c
b/drivers/gpu/drm/radeon/radeon_ttm.c
index 74a6a9f..c288e86 100644
--- a/drivers/gpu/drm/radeon/radeon_ttm.c
+++ b/drivers/gpu/drm/radeon/radeon_ttm.c
@@ -201,6 +201,17 @@ static void radeon_evict_flags(struct ttm_buffer_object
*bo,
struct ttm_placement *placement)
{
struct radeon_bo *rbo = container_of(bo, struct radeon_bo, tbo);
+ static u32 placements = TTM_PL_MASK_CACHING | TTM_PL_FLAG_SYSTEM;
+
+ if (!radeon_ttm_bo_is_radeon_bo(bo)) {
+ placement-fpfn = 0;
+ placement-lpfn = 0;
+ placement-placement = placements;
+ placement-busy_placement = placements;
+ placement-num_placement = 1;
+ placement-num_busy_placement = 1;
+ return;
+ }
switch (bo-mem.mem_type) {
case TTM_PL_VRAM:
radeon_ttm_placement_from_domain(rbo, RADEON_GEM_DOMAIN_GTT);
--
1.6.5.2
--
Return on Information:
Google Enterprise Search pays you back
Get the facts.
http://p.sf.net/sfu/google-dev2dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] drm/ttm: fix two bugs in new placement routines.
On Mon, Dec 14, 2009 at 02:52:45PM +1000, Dave Airlie wrote: From: Dave Airlie airl...@redhat.com a) the loops were going to = not , leading to illegal memory access b) the busy placement checks were using the placement arrays not the busy placement ones. Signed-off-by: Dave Airlie airl...@redhat.com Ack-by: Jerome Glisse jgli...@redhat.com -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Fw: [Bugme-new] [Bug 14811] New: case NOUVEAU_GART_AGP: not used if not set CONFIG_AGP
Begin forwarded message:
Date: Mon, 14 Dec 2009 20:18:18 GMT
From: bugzilla-dae...@bugzilla.kernel.org
To: bugme-...@lists.osdl.org
Subject: [Bugme-new] [Bug 14811] New: case NOUVEAU_GART_AGP: not used if not
set CONFIG_AGP
http://bugzilla.kernel.org/show_bug.cgi?id=14811
Summary: case NOUVEAU_GART_AGP: not used if not set CONFIG_AGP
Product: Drivers
Version: 2.5
Kernel Version: 2.6.32-git10
Platform: All
OS/Version: Linux
Tree: Mainline
Status: NEW
Severity: normal
Priority: P1
Component: Video(Other)
AssignedTo: drivers_video-ot...@kernel-bugs.osdl.org
ReportedBy: pa...@pavlinux.ru
Regression: No
static struct ttm_backend *
nouveau_bo_create_ttm_backend_entry(struct ttm_bo_device *bdev)
{
struct drm_nouveau_private *dev_priv = nouveau_bdev(bdev);
struct drm_device *dev = dev_priv-dev;
switch (dev_priv-gart_info.type) {
case NOUVEAU_GART_AGP:
return ttm_agp_backend_init(bdev, dev-agp-bridge);
error: implicit declaration of function 'ttm_agp_backend_init'
warning: return makes pointer from integer without a cast
CONFIG_AGP is not set in my config
--
Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.
--
Return on Information:
Google Enterprise Search pays you back
Get the facts.
http://p.sf.net/sfu/google-dev2dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [BISECTED] drm: random hang since 620f378 drm: prune modes when ...
On Mon, 14 Dec 2009 20:38:09 +
Arnd Bergmann a...@arndb.de wrote:
On Monday 14 December 2009 18:20:15 Jesse Barnes wrote:
You can disable most of that code by loading i915 with
'powersave=0'. If that patch really is at fault the powersave=0
should work around the issue as well.
Ok, I'll try that and let you know. Running the kernel before your
patch has not crashed yet after two days of uptime. Now running
with your patch but nothing else. When that crashes, I'll try
the latest mainline with powersave=0.
Ok great.
It's been implicated in another issue (some display flicker and
underruns) so I'm pretty sure there's something wrong with it in
some configurations at least...
I haven't seen that yet. FWIW, the device in question is
[snip 4 series pci info]
Let me know if you have a patch you want me to test.
This patch removes the suspect portion of the dynamic clock control
code. Hopefully it'll be as stable as powersave=0 in your config
(assuming powersave=0 works :).
--
Jesse Barnes, Intel Open Source Technology Center
diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_d
index 279dc96..b8730de 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -3825,8 +3825,6 @@ void intel_decrease_renderclock(struct drm_device *dev)
/* Down to minimum... */
gcfgc = ~GM45_GC_RENDER_CLOCK_MASK;
gcfgc |= GM45_GC_RENDER_CLOCK_266_MHZ;
-
- pci_write_config_word(dev-pdev, GCFGC, gcfgc);
} else if (IS_I965G(dev)) {
u16 gcfgc;
--
Return on Information:
Google Enterprise Search pays you back
Get the facts.
http://p.sf.net/sfu/google-dev2dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH] drm/ttm: fix incorrect logic in ttm_bo_io path
From: Dave Airlie airl...@redhat.com
This path isn't used by radeon yet, but future drivers will want it,
so fix it right.
Reported-by: Luca Barbieri l...@luca-barbieri.com
Signed-off-by: Dave Airlie airl...@redhat.com
---
drivers/gpu/drm/ttm/ttm_bo_vm.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo_vm.c b/drivers/gpu/drm/ttm/ttm_bo_vm.c
index 609a85a..668dbe8 100644
--- a/drivers/gpu/drm/ttm/ttm_bo_vm.c
+++ b/drivers/gpu/drm/ttm/ttm_bo_vm.c
@@ -320,7 +320,7 @@ ssize_t ttm_bo_io(struct ttm_bo_device *bdev, struct file
*filp,
return -EFAULT;
driver = bo-bdev-driver;
- if (unlikely(driver-verify_access)) {
+ if (unlikely(!driver-verify_access)) {
ret = -EPERM;
goto out_unref;
}
--
1.6.5.2
--
Return on Information:
Google Enterprise Search pays you back
Get the facts.
http://p.sf.net/sfu/google-dev2dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Testing an AGPGART driver with radeon.test=1
Hi,
A long time ago I was working on an AGPGART driver for my PPC machine,
but couldn't get it working due to missing datasheet, etc. Now I started
working on it again, as Radeon KMS works well on my machine so far and I
also rediscovered an old binary-only AGPGART driver for which objdump
revealed some interesting information.
Well, the current driver code is basically a copy of the UniNorth AGPGART
driver. The driver initializes fine, as the excerpt below shows:
calling agp_init+0x0/0x54 @ 1
Linux agpgart interface v0.103
initcall agp_init+0x0/0x54 returned 0 after 2749 usecs
calling agp_articias_init+0x0/0x58 @ 1
agpgart-articias :00:00.0: MAI Logic Articia S chipset
agpgart-articias :00:00.0: configuring for size idx: 1
agpgart-articias :00:00.0: AGP aperture is 4M @ 0xc000
initcall agp_articias_init+0x0/0x58 returned 0 after 19494 usecs
calling drm_core_init+0x0/0x158 @ 1
[drm] Initialized drm 1.1.0 20060810
initcall drm_core_init+0x0/0x158 returned 0 after 4526 usecs
calling ttm_init+0x0/0x8c @ 1
initcall ttm_init+0x0/0x8c returned 0 after 1170 usecs
calling radeon_init+0x0/0x100 @ 1
[drm] radeon defaulting to kernel modesetting.
[drm] radeon kernel modesetting enabled.
[drm] radeon: Initializing kernel modesetting.
[drm] register mmio base: 0x8800
[drm] register mmio size: 65536
[drm] GPU reset succeed (RBBM_STATUS=0x0140)
[drm] Generation 2 PCI interface, using max accessible memory
[drm] AGP mode requested: 1
agpgart-articias :00:00.0: AGP 1.0 bridge
agpgart-articias :00:00.0: putting AGP V2 device into 1x mode
radeon :01:00.0: putting AGP V2 device into 1x mode
[drm] radeon: VRAM 128M
[drm] radeon: VRAM from 0x to 0x07FF
[drm] radeon: GTT 4M
[drm] radeon: GTT from 0xC000 to 0xC03F
[drm] radeon: irq initialized.
[drm] Detected VRAM RAM=128M, BAR=128M
[drm] RAM width 128bits DDR
[TTM] Zone kernel: Available graphics memory: 377416 kiB.
[TTM] Zone highmem: Available graphics memory: 770632 kiB.
[drm] radeon: 128M of VRAM memory ready
[drm] radeon: 4M of GTT memory ready.
[drm] radeon: cp idle (0x02000603)
[drm] Loading R200 Microcode
platform radeon_cp.0: firmware: using built-in firmware radeon/R200_cp.bin
agpgart-articias :00:00.0: TLB flush!
[drm] radeon: ring at 0xC000
[drm] ring test succeeded in 0 usecs
agpgart-articias :00:00.0: TLB flush!
agpgart-articias :00:00.0: TLB flush!
[drm] radeon: ib pool ready.
[drm] ib test succeeded in 0 usecs
[drm] DFP table revision: 3
[drm] Radeon Display Connectors
[drm] Connector 0:
[drm] VGA
[drm] DDC: 0x60 0x60 0x60 0x60 0x60 0x60 0x60 0x60
[drm] Encoders:
[drm] CRT1: INTERNAL_DAC1
[drm] Connector 1:
[drm] DVI-I
[drm] DDC: 0x64 0x64 0x64 0x64 0x64 0x64 0x64 0x64
[drm] Encoders:
[drm] CRT2: INTERNAL_DAC2
[drm] DFP1: INTERNAL_TMDS1
[drm] fb mappable at 0x8004
[drm] vram apper at 0x8000
[drm] size 768
[drm] fb depth is 24
[drm]pitch is 6400
[drm] TMDS-12: set mode 1600x1200 24
Console: switching to colour frame buffer device 200x75
fb0: radeondrmfb frame buffer device
registered panic notifier
[drm] Initialized radeon 2.0.0 20080528 for :01:00.0 on minor 0
initcall radeon_init+0x0/0x100 returned 0 after 635215 usecs
Judging from what the log says, I would expect that the radeon driver
can make use of the AGP aperture (as the the ring and ib test succeed -
is this assumption correct?).
Next I booted the kernel with radeon.test=1 and this test fails
immediately with a message like this:
[drm:radeon_test_moves] *ERROR* Incorrect GTT-VRAM copy 0: Got 0xf14a88f0,
expected 0xf14a6680 (GTT map 0xf14a6000-0xf15a6000)
A different aperture size doesn't make any difference. However the test
works in PCIGART mode.
Now I wonder what the problem could be, as I don't have a clue about
the radeon/DRM code. Can somebody explain me, how the test works and
what the error message means for the AGPGART driver?
Thanks!
best regards,
Gerhard
PS: Please put me on CC:.
articias-agp.c:
/*
* Articia S AGPGART routines.
*/
#include linux/module.h
#include linux/pci.h
#include linux/init.h
#include linux/pagemap.h
#include linux/vmalloc.h
#include linux/agp_backend.h
#include agp.h
#define ARTICIAS_GARTCTRL 0x58/* bit 6 - GART enable */
#define ARTICIAS_APSIZE 0x59/* bit 2:0 - aperture size */
#define ARTICIAS_TLBCTRL0xe0/* bit 5 - TLB flush */
#define ARTICIAS_GATTBASE 0x58/* 31:12 GATT base address */
static int articias_fetch_size(void)
{
int i;
u8 temp;
struct aper_size_info_8 *values;
values = A_SIZE_8(agp_bridge-driver-aperture_sizes);
pci_read_config_byte(agp_bridge-dev, ARTICIAS_APSIZE, temp);
temp = 0x07;
for (i = 0; i agp_bridge-driver-num_aperture_sizes; i++) {
if (temp == values[i].size_value) {
agp_bridge-previous_size =
agp_bridge-current_size = (void *)
Re: [BISECTED] drm: random hang since 620f378 drm: prune modes when ...
On Monday 14 December 2009 18:20:15 Jesse Barnes wrote: You can disable most of that code by loading i915 with 'powersave=0'. If that patch really is at fault the powersave=0 should work around the issue as well. Ok, I'll try that and let you know. Running the kernel before your patch has not crashed yet after two days of uptime. Now running with your patch but nothing else. When that crashes, I'll try the latest mainline with powersave=0. It's been implicated in another issue (some display flicker and underruns) so I'm pretty sure there's something wrong with it in some configurations at least... I haven't seen that yet. FWIW, the device in question is 00:02.0 VGA compatible controller: Intel Corporation 4 Series Chipset Integrated Graphics Controller (rev 03) Subsystem: ASUSTeK Computer Inc. Device 8276 Flags: bus master, fast devsel, latency 0, IRQ 27 Memory at fe40 (64-bit, non-prefetchable) [size=4M] Memory at d000 (64-bit, prefetchable) [size=256M] I/O ports at cc00 [size=8] Capabilities: [90] Message Signalled Interrupts: Mask- 64bit- Queue=0/0 Enable+ Capabilities: [d0] Power Management version 2 Capabilities: [a4] PCIe advanced features ? Kernel driver in use: i915 00: 86 80 22 2e 07 04 90 00 03 00 00 03 00 00 80 00 10: 04 00 40 fe 00 00 00 00 0c 00 00 d0 00 00 00 00 20: 01 cc 00 00 00 00 00 00 00 00 00 00 43 10 76 82 30: 00 00 00 00 90 00 00 00 00 00 00 00 0a 01 00 00 00:02.1 Display controller: Intel Corporation 4 Series Chipset Integrated Graphics Controller (rev 03) Subsystem: ASUSTeK Computer Inc. Device 8276 Flags: bus master, fast devsel, latency 0 Memory at fe80 (64-bit, non-prefetchable) [size=1M] Capabilities: [d0] Power Management version 2 00: 86 80 23 2e 07 00 90 00 03 00 80 03 00 00 80 00 10: 04 00 80 fe 00 00 00 00 00 00 00 00 00 00 00 00 20: 00 00 00 00 00 00 00 00 00 00 00 00 43 10 76 82 30: 00 00 00 00 d0 00 00 00 00 00 00 00 00 00 00 00 Let me know if you have a patch you want me to test. Thanks, Arnd -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[git pull] vmware drm/kms driver under staging
Hi Linus, Please pull the 'drm-vmware-staging' branch from ssh://master.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6.git drm-vmware-staging This adds the VMware KMS driver for their virtual GPU, the Kconfig is under staging until they are happy with the ioctl interface to the 3D driver, which may be quite soon. We now have 4 KMS drivers, hopefully it'll quieten down for a while, while we fix them all up. Dave. drivers/gpu/drm/Makefile |1 + drivers/gpu/drm/vmwgfx/Kconfig | 13 + drivers/gpu/drm/vmwgfx/Makefile |9 + drivers/gpu/drm/vmwgfx/svga3d_reg.h | 1793 ++ drivers/gpu/drm/vmwgfx/svga_escape.h | 89 ++ drivers/gpu/drm/vmwgfx/svga_overlay.h| 201 drivers/gpu/drm/vmwgfx/svga_reg.h| 1346 ++ drivers/gpu/drm/vmwgfx/svga_types.h | 45 + drivers/gpu/drm/vmwgfx/vmwgfx_buffer.c | 229 drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 735 drivers/gpu/drm/vmwgfx/vmwgfx_drv.h | 511 + drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c | 516 + drivers/gpu/drm/vmwgfx/vmwgfx_fb.c | 742 drivers/gpu/drm/vmwgfx/vmwgfx_fifo.c | 521 + drivers/gpu/drm/vmwgfx/vmwgfx_gmr.c | 213 drivers/gpu/drm/vmwgfx/vmwgfx_ioctl.c| 81 ++ drivers/gpu/drm/vmwgfx/vmwgfx_irq.c | 295 + drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 872 +++ drivers/gpu/drm/vmwgfx/vmwgfx_kms.h | 102 ++ drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c | 516 + drivers/gpu/drm/vmwgfx/vmwgfx_overlay.c | 634 +++ drivers/gpu/drm/vmwgfx/vmwgfx_reg.h | 57 + drivers/gpu/drm/vmwgfx/vmwgfx_resource.c | 1192 drivers/gpu/drm/vmwgfx/vmwgfx_ttm_glue.c | 99 ++ drivers/staging/Kconfig |2 + include/drm/Kbuild |1 + include/drm/ttm/ttm_object.h |6 +- include/drm/vmwgfx_drm.h | 574 ++ 28 files changed, 11394 insertions(+), 1 deletions(-) create mode 100644 drivers/gpu/drm/vmwgfx/Kconfig create mode 100644 drivers/gpu/drm/vmwgfx/Makefile create mode 100644 drivers/gpu/drm/vmwgfx/svga3d_reg.h create mode 100644 drivers/gpu/drm/vmwgfx/svga_escape.h create mode 100644 drivers/gpu/drm/vmwgfx/svga_overlay.h create mode 100644 drivers/gpu/drm/vmwgfx/svga_reg.h create mode 100644 drivers/gpu/drm/vmwgfx/svga_types.h create mode 100644 drivers/gpu/drm/vmwgfx/vmwgfx_buffer.c create mode 100644 drivers/gpu/drm/vmwgfx/vmwgfx_drv.c create mode 100644 drivers/gpu/drm/vmwgfx/vmwgfx_drv.h create mode 100644 drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c create mode 100644 drivers/gpu/drm/vmwgfx/vmwgfx_fb.c create mode 100644 drivers/gpu/drm/vmwgfx/vmwgfx_fifo.c create mode 100644 drivers/gpu/drm/vmwgfx/vmwgfx_gmr.c create mode 100644 drivers/gpu/drm/vmwgfx/vmwgfx_ioctl.c create mode 100644 drivers/gpu/drm/vmwgfx/vmwgfx_irq.c create mode 100644 drivers/gpu/drm/vmwgfx/vmwgfx_kms.c create mode 100644 drivers/gpu/drm/vmwgfx/vmwgfx_kms.h create mode 100644 drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c create mode 100644 drivers/gpu/drm/vmwgfx/vmwgfx_overlay.c create mode 100644 drivers/gpu/drm/vmwgfx/vmwgfx_reg.h create mode 100644 drivers/gpu/drm/vmwgfx/vmwgfx_resource.c create mode 100644 drivers/gpu/drm/vmwgfx/vmwgfx_ttm_glue.c create mode 100644 include/drm/vmwgfx_drm.h commit fb1d9738ca053ea8afa5e86af6463155f983b01c Author: Jakob Bornecrantz ja...@vmware.com Date: Thu Dec 10 00:19:58 2009 + drm/vmwgfx: Add DRM driver for VMware Virtual GPU This commit adds the vmwgfx driver for the VWware Virtual GPU aka SVGA. The driver is under staging the same as Nouveau and Radeon KMS. Hopefully the 2D ioctls are bug free and don't need changing, so that part of the API should be stable. But there there is a pretty big chance that the 3D API will change in the future. Signed-off-by: Thomas Hellström thellst...@vmware.com Signed-off-by: Jakob Bornecrantz ja...@vmware.com Signed-off-by: Dave Airlie airl...@redhat.com commit 632f61178d0473861ba77e774bb654b37bc7eccc Author: Jakob Bornecrantz ja...@vmware.com Date: Thu Dec 10 00:19:10 2009 + drm/vmwgfx: Add svga headers for vmwgfx driver These headers are shared between multiple place where different coding standards apply. They will be fixed up at a later time. Signed-off-by: Thomas Hellström thellst...@vmware.com Signed-off-by: Jakob Bornecrantz ja...@vmware.com Signed-off-by: Dave Airlie airl...@redhat.com commit be1cb8689c480228ffd2e4bfccc0dab7156cd9ea Author: Jakob Bornecrantz ja...@vmware.com Date: Mon Dec 14 22:07:45 2009 + drm/ttm: Add more driver type enums Signed-off-by: Jakob Bornecrantz ja...@vmware.com Signed-off-by: Dave Airlie airl...@redhat.com-- Return on
Re: Testing an AGPGART driver with radeon.test=1
On Mon, 2009-12-14 at 23:21 +0100, Gerhard Pircher wrote: Next I booted the kernel with radeon.test=1 and this test fails immediately with a message like this: [drm:radeon_test_moves] *ERROR* Incorrect GTT-VRAM copy 0: Got 0xf14a88f0, expected 0xf14a6680 (GTT map 0xf14a6000-0xf15a6000) A different aperture size doesn't make any difference. However the test works in PCIGART mode. Now I wonder what the problem could be, as I don't have a clue about the radeon/DRM code. Can somebody explain me, how the test works and what the error message means for the AGPGART driver? The test output is a little cryptic and could be improved... The failing phase of the test fills the GTT memory with the kernel virtual addresses of itself, copies it to VRAM with the GPU, reads it back again with the CPU and verifies the contents. It read back 0xf14a88f0 when it expected 0xf14a6680, so the latter is the kernel virtual address of the first word which wasn't copied correctly. Subtracting the start of the GTT map (0xf14a6000) yields that only 1664 bytes (+ 2, as the first two bytes of the incorrect word are correct) were copied correctly. The normal ring and IB tests are probably too simple to catch that kind of problem. I don't suppose higher transfer rates work any better? :) I guess there could be many possible causes for the problem, but the most likely seems some kind of coherency issue between the CPU writes and GPU reads. Hope this helps, -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 14769] Radeon 9600 chip set on NC6000 laptop
http://bugzilla.kernel.org/show_bug.cgi?id=14769 Jesse Barnes jbar...@virtuousgeek.org changed: What|Removed |Added Component|Video(DRI - Intel) |Video(DRI - non Intel) AssignedTo|jbar...@virtuousgeek.org|drivers_video-...@kernel-bu ||gs.osdl.org -- Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 24124] Massive flickering with KMS enabled at 1600x1...@85 and 1280x1...@85
http://bugs.freedesktop.org/show_bug.cgi?id=24124 --- Comment #6 from Alex Deucher ag...@yahoo.com 2009-12-14 15:36:56 PST --- Is this still an issue with the new pll code in drm-radeon-next? -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 14769] Radeon 9600 chip set on NC6000 laptop
http://bugzilla.kernel.org/show_bug.cgi?id=14769 Alex Deucher alexdeuc...@gmail.com changed: What|Removed |Added CC||alexdeuc...@gmail.com --- Comment #4 from Alex Deucher alexdeuc...@gmail.com 2009-12-14 23:41:02 --- First, you are getting an oops in the apic setup which isn't radeon related: [ cut here ] WARNING: at arch/x86/kernel/apic/apic.c:249 native_apic_write_dummy+0x32/0x3e() Hardware name: HP Compaq nc6000 (DP894A#ABA) Modules linked in: Pid: 0, comm: swapper Not tainted 2.6.32 #1 Call Trace: [c043a973] warn_slowpath_common+0x6a/0x81 [c0418327] ? native_apic_write_dummy+0x32/0x3e [c043a99c] warn_slowpath_null+0x12/0x15 [c0418327] native_apic_write_dummy+0x32/0x3e [c0410a1b] intel_init_thermal+0xec/0x191 [c04102c4] mce_intel_feature_init+0x10/0x50 [c040e803] mce_cpu_features+0x1b/0x24 [c077d687] mcheck_init+0x264/0x2b2 [c077b969] identify_cpu+0x371/0x380 [c09c92c9] identify_boot_cpu+0xd/0x23 [c09c9496] check_bugs+0xb/0xdc [c04880e3] ? delayacct_init+0x47/0x4c [c09c2813] start_kernel+0x2df/0x2f3 [c09c2097] i386_start_kernel+0x97/0x9e ---[ end trace 4eaa2a86a8e2da22 ]--- Secondly, you are not using a KMS-aware xorg radeon ddx driver which won't work if KMS is active in the drm which is the case on your system. Boot with radeon.modeset=0 to load the drm without KMS support or upgrade your ddx to one with KMS support. -- Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH] drm/radeon/kms: fix bo leak on ERESTARTSYS.
From: Dave Airlie airl...@redhat.com If we get ERESTARTSYS we leaked the radeon_bo object here. Signed-off-by: Dave Airlie airl...@redhat.com --- drivers/gpu/drm/radeon/radeon_object.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/drivers/gpu/drm/radeon/radeon_object.c b/drivers/gpu/drm/radeon/radeon_object.c index 115222e..af77168 100644 --- a/drivers/gpu/drm/radeon/radeon_object.c +++ b/drivers/gpu/drm/radeon/radeon_object.c @@ -119,6 +119,7 @@ int radeon_bo_create(struct radeon_device *rdev, struct drm_gem_object *gobj, dev_err(rdev-dev, object_init failed for (%lu, 0x%08X)\n, size, domain); + kfree(bo); return r; } *bo_ptr = bo; -- 1.6.5.2 -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH] drm/radeon/kms: don't report allocate failure on ERESTARTSYS
From: Dave Airlie airl...@redhat.com
if we fail with ERESTARTSYS during alloc, we'll get a retry from
userspace so don't report it in dmesg.
Signed-off-by: Dave Airlie airl...@redhat.com
---
drivers/gpu/drm/radeon/radeon_gem.c |5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_gem.c
b/drivers/gpu/drm/radeon/radeon_gem.c
index 2944486..ee827cc 100644
--- a/drivers/gpu/drm/radeon/radeon_gem.c
+++ b/drivers/gpu/drm/radeon/radeon_gem.c
@@ -66,8 +66,9 @@ int radeon_gem_object_create(struct radeon_device *rdev, int
size,
}
r = radeon_bo_create(rdev, gobj, size, kernel, initial_domain, robj);
if (r) {
- DRM_ERROR(Failed to allocate GEM object (%d, %d, %u)\n,
- size, initial_domain, alignment);
+ if (r != -ERESTARTSYS)
+ DRM_ERROR(Failed to allocate GEM object (%d, %d, %u,
%d)\n,
+ size, initial_domain, alignment, r);
mutex_lock(rdev-ddev-struct_mutex);
drm_gem_object_unreference(gobj);
mutex_unlock(rdev-ddev-struct_mutex);
--
1.6.5.2
--
Return on Information:
Google Enterprise Search pays you back
Get the facts.
http://p.sf.net/sfu/google-dev2dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
