Re: Problems with alpha/pci + radeon/ttm
On Thu, 24 Jun 2010 10:53:52 -0400
Matt Turner wrote:
> > Seems that the IOMMU can't find 128 pages. It's likely due to:
> >
> > - out of the IOMMU space (possibly someone doesn't free the IOMMU
> > space).
> >
> > or
> >
> > - the mapping parameters (such as align) aren't appropriate so the
> > IOMMU can't find space.
> >
> >
> >> Is this the cause of the bug we're seeing in the report [1]?
> >>
> >> Anyone know what's going wrong here?
> >
> >
> > I've attached a patch to print the debug info about the mapping
> > parameters.
> >
> >
> > diff --git a/arch/alpha/kernel/pci_iommu.c b/arch/alpha/kernel/pci_iommu.c
> > index d1dbd9a..17cf0d8 100644
> > --- a/arch/alpha/kernel/pci_iommu.c
> > +++ b/arch/alpha/kernel/pci_iommu.c
> > @@ -187,6 +187,10 @@ iommu_arena_alloc(struct device *dev, struct
> > pci_iommu_arena *arena, long n,
> > /* Search for N empty ptes */
> > ptes = arena->ptes;
> > mask = max(align, arena->align_entry) - 1;
> > +
> > + printk("%s: %p, %p, %d, %ld, %lx, %u\n", __func__, dev, arena,
> > arena->size,
> > + n, mask, align);
> > +
> > p = iommu_arena_find_pages(dev, arena, n, mask);
> > if (p < 0) {
> > spin_unlock_irqrestore(&arena->lock, flags);
>
> Using this patch, I log the attached output.
Your system has 1GB iommu address space. I guess that it's enough for
KSM?
The parameters in the log looks good. But you got this log before you
started X?
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Problems with alpha/pci + radeon/ttm
On Thu, 24 Jun 2010 21:51:40 +1200 Michael Cree wrote: > >> Is this a regression (what kernel version worked)? > >> > >> Seems that the IOMMU can't find 128 pages. It's likely due to: > >> > >> - out of the IOMMU space (possibly someone doesn't free the IOMMU > >> space). > >> > >> or > >> > >> - the mapping parameters (such as align) aren't appropriate so the > >> IOMMU can't find space. > > > > I don't think KMS drivers have ever worked on alpha so its not a > > regression, they are working fine on x86 + powerpc and sparc has been > > run at least once. > > KMS on the console boot up has worked since about 2.6.32, but starting > up the X server has always failed and, in my case, the system becomes > unstable and eventually OOPs. > > > I suspect we are simply hitting the limits of the iommu, how big an > > address space does it handle? since generally graphics drivers try to > > bind a lot of things to the GART. > > No idea on the address space limit. I applied the patch of Fujita that > logs all IOMMU allocations, and also inserted some extra printks in the > ttm kernel code so that I could see which routines failed and the error > code returned. Running the radeon test on boot exhibits the following: > > [ 238.712768] [drm] Tested GTT->VRAM and VRAM->GTT copy for GTT offset > 0x1a312000 > [ 239.281127] [drm] Tested GTT->VRAM and VRAM->GTT copy for GTT offset > 0x1a412000 > [ 239.281127] ttm_tt_bind belched -12 > [ 239.282104] ttm_bo_handle_move_mem belched -12 > [ 239.282104] ttm_bo_move_buffer belched -12 > [ 239.282104] ttm_bo_validate belched -12 > [ 239.282104] radeon :01:00.0: object_init failed for (1048576, > 0x0002) err=-12 > [ 239.282104] [drm:radeon_test_moves] *ERROR* Failed to create GTT > object 419 > [ 239.399291] Error while testing BO move. > > Note that no IOMMU allocations are printed while radeon_test_moves is > running so iommu_arena_alloc doesn't appear to be called. Also the > error code returned up to radeon_test_moves is -12 which is ENOMEM. So > does appear to be some memory limit. Hmm, not related with IOMMU? looks like ttm_tt_populate could return ENOMEM too. Can we locate where we hit ENOMEM first? ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Problems with alpha/pci + radeon/ttm
On Sun, Jun 27, 2010 at 12:20 AM, FUJITA Tomonori
wrote:
> On Thu, 24 Jun 2010 10:53:52 -0400
> Matt Turner wrote:
>
>> > Seems that the IOMMU can't find 128 pages. It's likely due to:
>> >
>> > - out of the IOMMU space (possibly someone doesn't free the IOMMU
>> > space).
>> >
>> > or
>> >
>> > - the mapping parameters (such as align) aren't appropriate so the
>> > IOMMU can't find space.
>> >
>> >
>> >> Is this the cause of the bug we're seeing in the report [1]?
>> >>
>> >> Anyone know what's going wrong here?
>> >
>> >
>> > I've attached a patch to print the debug info about the mapping
>> > parameters.
>> >
>> >
>> > diff --git a/arch/alpha/kernel/pci_iommu.c b/arch/alpha/kernel/pci_iommu.c
>> > index d1dbd9a..17cf0d8 100644
>> > --- a/arch/alpha/kernel/pci_iommu.c
>> > +++ b/arch/alpha/kernel/pci_iommu.c
>> > @@ -187,6 +187,10 @@ iommu_arena_alloc(struct device *dev, struct
>> > pci_iommu_arena *arena, long n,
>> > /* Search for N empty ptes */
>> > ptes = arena->ptes;
>> > mask = max(align, arena->align_entry) - 1;
>> > +
>> > + printk("%s: %p, %p, %d, %ld, %lx, %u\n", __func__, dev, arena,
>> > arena->size,
>> > + n, mask, align);
>> > +
>> > p = iommu_arena_find_pages(dev, arena, n, mask);
>> > if (p < 0) {
>> > spin_unlock_irqrestore(&arena->lock, flags);
>>
>> Using this patch, I log the attached output.
>
> Your system has 1GB iommu address space. I guess that it's enough for
> KSM?
I would definitely think so. The video card I'm using here is a 64MB
Radeon 9100 PCI, with a 128MB BAR.
> The parameters in the log looks good. But you got this log before you
> started X?
Yes, that's right.
I'll see if I can isolate where the first -ENOMEM is coming from.
Thanks Fujita for helping with this!
Matt
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Problems with alpha/pci + radeon/ttm
On 27/06/10 16:20, FUJITA Tomonori wrote: On Thu, 24 Jun 2010 21:51:40 +1200 Michael Cree wrote: Is this a regression (what kernel version worked)? Seems that the IOMMU can't find 128 pages. It's likely due to: - out of the IOMMU space (possibly someone doesn't free the IOMMU space). or - the mapping parameters (such as align) aren't appropriate so the IOMMU can't find space. I don't think KMS drivers have ever worked on alpha so its not a regression, they are working fine on x86 + powerpc and sparc has been run at least once. KMS on the console boot up has worked since about 2.6.32, but starting up the X server has always failed and, in my case, the system becomes unstable and eventually OOPs. I suspect we are simply hitting the limits of the iommu, how big an address space does it handle? since generally graphics drivers try to bind a lot of things to the GART. No idea on the address space limit. I applied the patch of Fujita that logs all IOMMU allocations, and also inserted some extra printks in the ttm kernel code so that I could see which routines failed and the error code returned. Running the radeon test on boot exhibits the following: [ 238.712768] [drm] Tested GTT->VRAM and VRAM->GTT copy for GTT offset 0x1a312000 [ 239.281127] [drm] Tested GTT->VRAM and VRAM->GTT copy for GTT offset 0x1a412000 [ 239.281127] ttm_tt_bind belched -12 [ 239.282104] ttm_bo_handle_move_mem belched -12 [ 239.282104] ttm_bo_move_buffer belched -12 [ 239.282104] ttm_bo_validate belched -12 [ 239.282104] radeon :01:00.0: object_init failed for (1048576, 0x0002) err=-12 [ 239.282104] [drm:radeon_test_moves] *ERROR* Failed to create GTT object 419 [ 239.399291] Error while testing BO move. Note that no IOMMU allocations are printed while radeon_test_moves is running so iommu_arena_alloc doesn't appear to be called. Also the error code returned up to radeon_test_moves is -12 which is ENOMEM. So does appear to be some memory limit. Hmm, not related with IOMMU? looks like ttm_tt_populate could return ENOMEM too. Can we locate where we hit ENOMEM first? Yeah, in ttm_mem_global_reserve while it is walking glob->zones: [ 239.303588] [drm] Tested GTT->VRAM and VRAM->GTT copy for GTT offset 0x1a412000 [ 239.304564] ttm_mem_global_reserve zone used_mem (0x1a5f) exceeds limit (0x1a5ef000) [ 239.304564] ttm_mem_global_reserve zone used_mem (0x1a5f) exceeds limit (0x1a5ef000) [ 239.304564] ttm_mem_global_reserve zone used_mem (0x1a5f) exceeds limit (0x1a5ef000) [ 239.304564] ttm_mem_global_reserve zone used_mem (0x1a5f) exceeds limit (0x1a5ef000) [ 239.304564] ttm_mem_global_reserve zone used_mem (0x1a5f) exceeds limit (0x1a5ef000) [ 239.304564] ttm_mem_global_reserve return non-zero count decs to zero [ 239.304564] ttm_mem_global_alloc_page belched -12 [ 239.304564] __ttm_tt_get_page coughed NULL [ 239.304564] ttm_tt_populate belched -12 [ 239.304564] ttm_tt_bind belched -12 [ 239.304564] ttm_bo_handle_move_mem belched -12 [ 239.304564] ttm_bo_move_buffer belched -12 [ 239.304564] ttm_bo_validate belched -12 On a hunch that we are chasing a red herring I installed another 256MB of memory into the machine (was 576MB for the test reported above) for a total of 832MB. Now radeon_test_moves runs to completion without error. OK, now a test of starting up the X server - ah, a bus error again but now it looks like it's in the radeon driver: [ 1435.014] (II) EXA(0): Driver allocated offscreen pixmaps [ 1435.014] (II) EXA(0): Driver registered support for the following operations: [ 1435.014] (II) Solid [ 1435.014] (II) Copy [ 1435.014] (II) Composite (RENDER acceleration) [ 1435.014] (II) UploadToScreen [ 1435.014] (II) DownloadFromScreen [ 1435.030] Backtrace: [ 1435.032] 0: /opt/xorg-ev56/bin/X (xorg_backtrace+0x54) [0x120070884] [ 1435.032] 1: /opt/xorg-ev56/bin/X (0x12000+0x65608) [0x120065608] [ 1435.033] 2: /lib/libc.so.6.1 (0x231+0x3d610) [0x234d610] [ 1435.034] 3: /opt/xorg-ev56/lib/xorg/modules/drivers/radeon_drv.so (0x2758000+0x15b890) [0x28b3890] [ 1435.034] 4: /opt/xorg-ev56/lib/xorg/modules/drivers/radeon_drv.so (0x2758000+0x1392a0) [0x28912a0] [ 1435.034] 5: /opt/xorg-ev56/lib/xorg/modules/drivers/radeon_drv.so (0x2758000+0x139bec) [0x2891bec] [ 1435.034] 6: /opt/xorg-ev56/lib/xorg/modules/drivers/radeon_drv.so (0x2758000+0x4f088) [0x27a7088] [ 1435.035] 7: /opt/xorg-ev56/lib/xorg/modules/drivers/radeon_drv.so (0x2758000+0x16f0f8) [0x28c70f8] [ 1435.035] 8: /opt/xorg-ev56/bin/X (AddScreen+0x1c0) [0x1200532b0] [ 1435.036] 9: /opt/xorg-ev56/bin/X (InitOutput+0x29c) [0x12008c6ec] [ 1435.036] 10: /opt/xorg-ev56/bin/X (0x12000+0x24b48) [0x120024b48] [ 1435.037] 11: /lib/libc.so.6.1 (__libc_start_main+0xec) [0x233267c] [ 1435.037] 12: /opt/xorg-ev56/bin/X (__start+0x38) [0x120024788] [ 1435.038] Bus erro
Re: Problems with alpha/pci + radeon/ttm
On Sun, Jun 27, 2010 at 8:46 PM, Michael Cree wrote: > On 27/06/10 16:20, FUJITA Tomonori wrote: >> >> On Thu, 24 Jun 2010 21:51:40 +1200 >> Michael Cree wrote: >> > Is this a regression (what kernel version worked)? > > Seems that the IOMMU can't find 128 pages. It's likely due to: > > - out of the IOMMU space (possibly someone doesn't free the IOMMU > space). > > or > > - the mapping parameters (such as align) aren't appropriate so the > IOMMU can't find space. I don't think KMS drivers have ever worked on alpha so its not a regression, they are working fine on x86 + powerpc and sparc has been run at least once. >>> >>> KMS on the console boot up has worked since about 2.6.32, but starting >>> up the X server has always failed and, in my case, the system becomes >>> unstable and eventually OOPs. >>> I suspect we are simply hitting the limits of the iommu, how big an address space does it handle? since generally graphics drivers try to bind a lot of things to the GART. >>> >>> No idea on the address space limit. I applied the patch of Fujita that >>> logs all IOMMU allocations, and also inserted some extra printks in the >>> ttm kernel code so that I could see which routines failed and the error >>> code returned. Running the radeon test on boot exhibits the following: >>> >>> [ 238.712768] [drm] Tested GTT->VRAM and VRAM->GTT copy for GTT offset >>> 0x1a312000 >>> [ 239.281127] [drm] Tested GTT->VRAM and VRAM->GTT copy for GTT offset >>> 0x1a412000 >>> [ 239.281127] ttm_tt_bind belched -12 >>> [ 239.282104] ttm_bo_handle_move_mem belched -12 >>> [ 239.282104] ttm_bo_move_buffer belched -12 >>> [ 239.282104] ttm_bo_validate belched -12 >>> [ 239.282104] radeon :01:00.0: object_init failed for (1048576, >>> 0x0002) err=-12 >>> [ 239.282104] [drm:radeon_test_moves] *ERROR* Failed to create GTT >>> object 419 >>> [ 239.399291] Error while testing BO move. >>> >>> Note that no IOMMU allocations are printed while radeon_test_moves is >>> running so iommu_arena_alloc doesn't appear to be called. Also the >>> error code returned up to radeon_test_moves is -12 which is ENOMEM. So >>> does appear to be some memory limit. >> >> Hmm, not related with IOMMU? looks like ttm_tt_populate could return >> ENOMEM too. Can we locate where we hit ENOMEM first? > > Yeah, in ttm_mem_global_reserve while it is walking glob->zones: > > [ 239.303588] [drm] Tested GTT->VRAM and VRAM->GTT copy for GTT offset > 0x1a412000 > [ 239.304564] ttm_mem_global_reserve zone used_mem (0x1a5f) exceeds > limit (0x1a5ef000) > [ 239.304564] ttm_mem_global_reserve zone used_mem (0x1a5f) exceeds > limit (0x1a5ef000) > [ 239.304564] ttm_mem_global_reserve zone used_mem (0x1a5f) exceeds > limit (0x1a5ef000) > [ 239.304564] ttm_mem_global_reserve zone used_mem (0x1a5f) exceeds > limit (0x1a5ef000) > [ 239.304564] ttm_mem_global_reserve zone used_mem (0x1a5f) exceeds > limit (0x1a5ef000) > [ 239.304564] ttm_mem_global_reserve return non-zero count decs to zero > [ 239.304564] ttm_mem_global_alloc_page belched -12 > [ 239.304564] __ttm_tt_get_page coughed NULL > [ 239.304564] ttm_tt_populate belched -12 > [ 239.304564] ttm_tt_bind belched -12 > [ 239.304564] ttm_bo_handle_move_mem belched -12 > [ 239.304564] ttm_bo_move_buffer belched -12 > [ 239.304564] ttm_bo_validate belched -12 > > On a hunch that we are chasing a red herring I installed another 256MB of > memory into the machine (was 576MB for the test reported above) for a total > of 832MB. > > Now radeon_test_moves runs to completion without error. > > OK, now a test of starting up the X server - ah, a bus error again but now > it looks like it's in the radeon driver: > > [ 1435.014] (II) EXA(0): Driver allocated offscreen pixmaps > [ 1435.014] (II) EXA(0): Driver registered support for the following > operations: > [ 1435.014] (II) Solid > [ 1435.014] (II) Copy > [ 1435.014] (II) Composite (RENDER acceleration) > [ 1435.014] (II) UploadToScreen > [ 1435.014] (II) DownloadFromScreen > [ 1435.030] > Backtrace: > [ 1435.032] 0: /opt/xorg-ev56/bin/X (xorg_backtrace+0x54) [0x120070884] > [ 1435.032] 1: /opt/xorg-ev56/bin/X (0x12000+0x65608) [0x120065608] > [ 1435.033] 2: /lib/libc.so.6.1 (0x231+0x3d610) [0x234d610] > [ 1435.034] 3: /opt/xorg-ev56/lib/xorg/modules/drivers/radeon_drv.so > (0x2758000+0x15b890) [0x28b3890] > [ 1435.034] 4: /opt/xorg-ev56/lib/xorg/modules/drivers/radeon_drv.so > (0x2758000+0x1392a0) [0x28912a0] > [ 1435.034] 5: /opt/xorg-ev56/lib/xorg/modules/drivers/radeon_drv.so > (0x2758000+0x139bec) [0x2891bec] > [ 1435.034] 6: /opt/xorg-ev56/lib/xorg/modules/drivers/radeon_drv.so > (0x2758000+0x4f088) [0x27a7088] > [ 1435.035] 7: /opt/xorg-ev56/lib/xorg/modules/drivers/radeon_drv.so > (0x2758000+0x16f0f8) [0x28c70f8] > [ 1435.035] 8: /
Re: Problems with alpha/pci + radeon/ttm
On 28/06/10 11:14, Dave Airlie wrote: The bus error is caused by the kernel, its something alpha specific with how mmap works, I'm not sure if alpha needs some special mmap flags or something, Neither am I. All I know is that Alpha reorders CPU instructions more aggressively than most other architectures, the page map size is 8kB, and memory accesses must be aligned to the datum size. Maybe Ivan or Richard can comment on any relevant Alpha mmap specific issues. BTW, I discovered a couple of weeks ago that DRI is broken under UMS. It was working a year or so ago so something has happened to it. Am I correct in thinking that the DRM code has pretty much been shifted into the kernel even for UMS? On the Alpha I have been testing on (PWS600au, EV56 cpu and a radeon RV710 graphics card) running glxgears under UMS displays artefacts in rendering the gears, that is, some facets are not clipped to the rotating gear but extend to the edge of the window. On another Alpha (XP1000, EV67 cpu and a radeon RV610 card) it locked up completely (couldn't even ping it) when I ran glxgears. They are both running Debian unstable. Cheers Michael. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 03/16] trivial: use ARRAY_SIZE
Change sizeof(x) / sizeof(*x) to ARRAY_SIZE(x).
Signed-off-by: Kulikov Vasiliy
---
drivers/gpu/drm/drm_edid.c |7 ++-
1 files changed, 2 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index c198186..da06476 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -929,13 +929,11 @@ drm_mode_do_interlace_quirk(struct drm_display_mode *mode,
{ 1440, 576 },
{ 2880, 576 },
};
- static const int n_sizes =
- sizeof(cea_interlaced)/sizeof(cea_interlaced[0]);
if (!(pt->misc & DRM_EDID_PT_INTERLACED))
return;
- for (i = 0; i < n_sizes; i++) {
+ for (i = 0; i < ARRAY_SIZE(cea_interlaced); i++) {
if ((mode->hdisplay == cea_interlaced[i].w) &&
(mode->vdisplay == cea_interlaced[i].h / 2)) {
mode->vdisplay *= 2;
@@ -1375,7 +1373,6 @@ static const struct {
{ 1920, 1440, 60, 0 },
{ 1920, 1440, 75, 0 },
};
-static const int num_est3_modes = sizeof(est3_modes) / sizeof(est3_modes[0]);
static int
drm_est3_modes(struct drm_connector *connector, struct detailed_timing *timing)
@@ -1387,7 +1384,7 @@ drm_est3_modes(struct drm_connector *connector, struct
detailed_timing *timing)
for (i = 0; i < 6; i++) {
for (j = 7; j > 0; j--) {
m = (i * 8) + (7 - j);
- if (m >= num_est3_modes)
+ if (m >= ARRAY_SIZE(est3_modes))
break;
if (est[i] & (1 << j)) {
mode = drm_mode_find_dmt(connector->dev,
--
1.7.0.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 04/16] trivial: use ARRAY_SIZE
Change sizeof(x) / sizeof(*x) to ARRAY_SIZE(x).
Signed-off-by: Kulikov Vasiliy
---
drivers/gpu/drm/i915/intel_sdvo.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_sdvo.c
b/drivers/gpu/drm/i915/intel_sdvo.c
index 76993ac..03c231b 100644
--- a/drivers/gpu/drm/i915/intel_sdvo.c
+++ b/drivers/gpu/drm/i915/intel_sdvo.c
@@ -392,13 +392,13 @@ static void intel_sdvo_debug_write(struct intel_encoder
*intel_encoder, u8 cmd,
DRM_LOG_KMS("%02X ", ((u8 *)args)[i]);
for (; i < 8; i++)
DRM_LOG_KMS(" ");
- for (i = 0; i < sizeof(sdvo_cmd_names) / sizeof(sdvo_cmd_names[0]);
i++) {
+ for (i = 0; i < ARRAY_SIZE(sdvo_cmd_names); i++) {
if (cmd == sdvo_cmd_names[i].cmd) {
DRM_LOG_KMS("(%s)", sdvo_cmd_names[i].name);
break;
}
}
- if (i == sizeof(sdvo_cmd_names)/ sizeof(sdvo_cmd_names[0]))
+ if (i == ARRAY_SIZE(sdvo_cmd_names))
DRM_LOG_KMS("(%02X)", cmd);
DRM_LOG_KMS("\n");
}
--
1.7.0.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 05/16] trivial: use ARRAY_SIZE
Change sizeof(x) / sizeof(*x) to ARRAY_SIZE(x).
Signed-off-by: Kulikov Vasiliy
---
drivers/gpu/drm/i915/intel_tv.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_tv.c b/drivers/gpu/drm/i915/intel_tv.c
index 6d553c2..d2d4e40 100644
--- a/drivers/gpu/drm/i915/intel_tv.c
+++ b/drivers/gpu/drm/i915/intel_tv.c
@@ -1424,7 +1424,7 @@ intel_tv_get_modes(struct drm_connector *connector)
int j, count = 0;
u64 tmp;
- for (j = 0; j < sizeof(input_res_table) / sizeof(input_res_table[0]);
+ for (j = 0; j < ARRAY_SIZE(input_res_table);
j++) {
struct input_res *input = &input_res_table[j];
unsigned int hactive_s = input->w;
--
1.7.0.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 28771] Vsync always on
https://bugs.freedesktop.org/show_bug.cgi?id=28771 --- Comment #1 from Jesse Barnes 2010-06-28 09:31:56 PDT --- You need both: commit 234286c0f8b7d30ed49223c648d4c73c1a517ab3 Author: Jesse Barnes Date: Thu Apr 22 12:47:41 2010 -0700 DRI2: add config query extension and commit 45e2b51c853471b79004a954ce3092a253b20b77 Author: Jesse Barnes Date: Thu Apr 22 12:49:03 2010 -0700 DRI2/GLX: check for vblank_mode in DRI2 GLX code for vblank_mode to work. Does your Mesa build have those? -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Problems with alpha/pci + radeon/ttm
On 06/28/2010 02:03 AM, Michael Cree wrote: > On 28/06/10 11:14, Dave Airlie wrote: >> The bus error is caused by the kernel, its something alpha specific >> with how mmap works, >> I'm not sure if alpha needs some special mmap flags or something, > > Neither am I. All I know is that Alpha reorders CPU instructions more > aggressively than most other architectures, the page map size is 8kB, > and memory accesses must be aligned to the datum size. There are no special mmap flags on alpha. The non-cacheable property is a function of the physical address (e.g. bit 40 set for ev5), and this has already been taken care of by the kernel. r~ ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 28800] New: [r300c] Texture corruption with World of Warcraft
https://bugs.freedesktop.org/show_bug.cgi?id=28800 Summary: [r300c] Texture corruption with World of Warcraft Product: Mesa Version: git Platform: x86 (IA32) OS/Version: Linux (All) Status: NEW Severity: normal Priority: medium Component: Drivers/DRI/r300 AssignedTo: dri-devel@lists.freedesktop.org ReportedBy: ranki...@googlemail.com Created an attachment (id=36583) --> (https://bugs.freedesktop.org/attachment.cgi?id=36583) Screenshot of corrupt textures A large number of textures are rendered incorrectly in World of Warcraft. (The game appears otherwise stable and moderately playable, although the frame rate isn't particularly high.) This is with an AGP RV350, running Linux 2.6.33.5, xorg-xf86-drv-ati from git and Fedora 13. My theory is that this is related to bug 28033, which has been fixed for r300g. However it is impossible to confirm this due to WoW crashing with r300g before I can enter the game. (See bug 28630.) -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 28630] [r300g] tiling / texture transfer crash in World of Warcraft
https://bugs.freedesktop.org/show_bug.cgi?id=28630 --- Comment #2 from Chris Rankin 2010-06-28 13:15:33 PDT --- Created an attachment (id=36584) --> (https://bugs.freedesktop.org/attachment.cgi?id=36584) Recent backtrace using mesa git with -gdwarf-2 -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 28771] Vsync always on
https://bugs.freedesktop.org/show_bug.cgi?id=28771 --- Comment #2 from Sven Arvidsson 2010-06-28 13:18:51 PDT --- Yes, I'm using git master, so they're both there. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 28630] [r300g] tiling / texture transfer crash in World of Warcraft
https://bugs.freedesktop.org/show_bug.cgi?id=28630
--- Comment #3 from Chris Rankin 2010-06-28 13:49:19
PDT ---
In src/gallium/drivers/r300/r300_context.c
static void r300_flush_cb(void *data)
{
struct r300_context* const cs_context_copy = data;
cs_context_copy->context.flush(&cs_context_copy->context, 0, NULL);
}
The crash happens when the context.flush function pointer does not contain a
valid value.
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 28671] Seg. fault and Oops with Radeon KMS (v2.6.34) on PPC ATI Radeon AGP r420 JH.
https://bugs.freedesktop.org/show_bug.cgi?id=28671 --- Comment #25 from Brett Witherspoon 2010-06-28 13:51:33 PDT --- Ok seems to work well. How will I know when we have the correct combinations for the connector table? It seems that multiple combinations work. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 28671] Seg. fault and Oops with Radeon KMS (v2.6.34) on PPC ATI Radeon AGP r420 JH.
https://bugs.freedesktop.org/show_bug.cgi?id=28671 --- Comment #26 from Alex Deucher 2010-06-28 14:09:52 PDT --- Ideally you'd test both a digital and analog monitor on both ports and make sure it works on each. Can you attach your xorg log and dmesg from the final version of the patch? Also, make sure dpms works. when X is running, try 'xset dpms force off' and make sure the montior goes off properly. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH -next] drm: ttm_page_alloc, fix all sparse warnings
From: Randy Dunlap
Fix all sparse warnings in ttm_page_alloc.c.
Signed-off-by: Randy Dunlap
Cc: David Airlie
Cc: dri-devel@lists.freedesktop.org
---
drivers/gpu/drm/ttm/ttm_page_alloc.c |8
1 file changed, 4 insertions(+), 4 deletions(-)
drivers/gpu/drm/ttm/ttm_page_alloc.c:819:26: warning: non-ANSI function
declaration of function 'ttm_page_alloc_fini'
drivers/gpu/drm/ttm/ttm_page_alloc.c:499:21: warning: incorrect type in
argument 1 (different base types)
drivers/gpu/drm/ttm/ttm_page_alloc.c:499:21:expected restricted gfp_t
[usertype] gfp_mask
drivers/gpu/drm/ttm/ttm_page_alloc.c:499:21:got int [signed] gfp_flags
drivers/gpu/drm/ttm/ttm_page_alloc.c:670:25: warning: incorrect type in
initializer (different base types)
drivers/gpu/drm/ttm/ttm_page_alloc.c:670:25:expected int [signed] gfp_flags
drivers/gpu/drm/ttm/ttm_page_alloc.c:670:25:got restricted gfp_t
drivers/gpu/drm/ttm/ttm_page_alloc.c:675:27: warning: invalid assignment: |=
drivers/gpu/drm/ttm/ttm_page_alloc.c:675:27:left side has type int
drivers/gpu/drm/ttm/ttm_page_alloc.c:675:27:right side has type restricted
gfp_t
drivers/gpu/drm/ttm/ttm_page_alloc.c:680:35: warning: invalid assignment: |=
drivers/gpu/drm/ttm/ttm_page_alloc.c:680:35:left side has type int
drivers/gpu/drm/ttm/ttm_page_alloc.c:680:35:right side has type restricted
gfp_t
drivers/gpu/drm/ttm/ttm_page_alloc.c:682:35: warning: invalid assignment: |=
drivers/gpu/drm/ttm/ttm_page_alloc.c:682:35:left side has type int
drivers/gpu/drm/ttm/ttm_page_alloc.c:682:35:right side has type restricted
gfp_t
drivers/gpu/drm/ttm/ttm_page_alloc.c:685:29: warning: incorrect type in
argument 1 (different base types)
drivers/gpu/drm/ttm/ttm_page_alloc.c:685:29:expected restricted gfp_t
[usertype] gfp_mask
drivers/gpu/drm/ttm/ttm_page_alloc.c:685:29:got int [signed] gfp_flags
drivers/gpu/drm/ttm/ttm_page_alloc.c:793:54: warning: incorrect type in
argument 2 (different base types)
drivers/gpu/drm/ttm/ttm_page_alloc.c:793:54:expected int [signed] flags
drivers/gpu/drm/ttm/ttm_page_alloc.c:793:54:got restricted gfp_t
drivers/gpu/drm/ttm/ttm_page_alloc.c:795:54: warning: incorrect type in
argument 2 (different base types)
drivers/gpu/drm/ttm/ttm_page_alloc.c:795:54:expected int [signed] flags
drivers/gpu/drm/ttm/ttm_page_alloc.c:795:54:got restricted gfp_t
drivers/gpu/drm/ttm/ttm_page_alloc.c:797:69: warning: incorrect type in
argument 2 (different base types)
drivers/gpu/drm/ttm/ttm_page_alloc.c:797:69:expected int [signed] flags
drivers/gpu/drm/ttm/ttm_page_alloc.c:797:69:got restricted gfp_t
drivers/gpu/drm/ttm/ttm_page_alloc.c:800:69: warning: incorrect type in
argument 2 (different base types)
drivers/gpu/drm/ttm/ttm_page_alloc.c:800:69:expected int [signed] flags
drivers/gpu/drm/ttm/ttm_page_alloc.c:800:69:got restricted gfp_t
--- linux-next-20100625.orig/drivers/gpu/drm/ttm/ttm_page_alloc.c
+++ linux-next-20100625/drivers/gpu/drm/ttm/ttm_page_alloc.c
@@ -67,7 +67,7 @@ struct ttm_page_pool {
spinlock_t lock;
boolfill_lock;
struct list_headlist;
- int gfp_flags;
+ gfp_t gfp_flags;
unsignednpages;
char*name;
unsigned long nfrees;
@@ -476,7 +476,7 @@ static void ttm_handle_caching_state_fai
* This function is reentrant if caller updates count depending on number of
* pages returned in pages array.
*/
-static int ttm_alloc_new_pages(struct list_head *pages, int gfp_flags,
+static int ttm_alloc_new_pages(struct list_head *pages, gfp_t gfp_flags,
int ttm_flags, enum ttm_caching_state cstate, unsigned count)
{
struct page **caching_array;
@@ -667,7 +667,7 @@ int ttm_get_pages(struct list_head *page
{
struct ttm_page_pool *pool = ttm_get_pool(flags, cstate);
struct page *p = NULL;
- int gfp_flags = GFP_USER;
+ gfp_t gfp_flags = GFP_USER;
int r;
/* set zero flag for page allocation if required */
@@ -771,7 +771,7 @@ void ttm_put_pages(struct list_head *pag
ttm_page_pool_free(pool, page_count);
}
-static void ttm_page_pool_init_locked(struct ttm_page_pool *pool, int flags,
+static void ttm_page_pool_init_locked(struct ttm_page_pool *pool, gfp_t flags,
char *name)
{
spin_lock_init(&pool->lock);
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 28771] Vsync always on
https://bugs.freedesktop.org/show_bug.cgi?id=28771 --- Comment #3 from Jesse Barnes 2010-06-28 15:41:03 PDT --- Oh, for the DRI2 radeon driver you'll probably need to add an explicit option somewhere; maybe the code path that used to check the vblank_mode flags is no longer called. See intel_screen.c: ... DRI_CONF_VBLANK_MODE(DRI_CONF_VBLANK_ALWAYS_SYNC) ... there's probably a similar section in the radeon driver somewhere. You'll also need to add support for the new DRI2 config extension to the driver, again see intel_screen.c's intelScreenExtensions array: ... &dri2ConfigQueryExtension.base, ... Hope that helps. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 28630] [r300g] tiling / texture transfer crash in World of Warcraft
https://bugs.freedesktop.org/show_bug.cgi?id=28630 --- Comment #4 from Marek Olšák 2010-06-28 17:02:00 PDT --- I believe the "data" pointer is not valid. I have committed some fixes, can you please test latest mesa git? -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 27858] [r300g] Panzers II crashes in wine
https://bugs.freedesktop.org/show_bug.cgi?id=27858 --- Comment #6 from Marek Olšák 2010-06-28 18:11:27 PDT --- Could you test the game with latest mesa git? There are some new fixes. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 28774] RS780: No picture over HDMI
https://bugs.freedesktop.org/show_bug.cgi?id=28774 --- Comment #11 from Alex Deucher 2010-06-28 22:38:29 PDT --- On avivo chips, the display regs start at 0x6000 (crtcs/grph/cur/etc.) and the output regs start at 0x7000 (dacs/dig/etc.). They only relevant register in your dump that's different is 0x75a0 (DIG_CNTL) and the only difference is that dig mode (DVI vs HDMI) either of which should work fine. I think the problem lies in the north bridge pcie config regs as the HDMI port uses the PCIEPHY transmitter which shares lanes with the northbrigde. I'm trying to get some better info on how it's supposed to work to help debug it. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
ttm use pages don't need to populate?
ttm_tt_set_user has "ttm->state = tt_unbound" which will cause the following ttm_tt_populate return directly because of bellow check: if (ttm->state != tt_unpopulated) return 0; Does it mean we don't need to populate user pages? Here is the patch if it is not the case Thanks Austin >From 91ca6f8a5bb84a9375033d7df1cf7c0d1568e6ce Mon Sep 17 00:00:00 2001 From: Austin Yuan Date: Tue, 29 Jun 2010 14:15:34 +0800 Subject: [PATCH] TTM: fix the issue that user buffers are not populuated due to the wrong state Signed-off-by: Austin Yuan Signed-off-by: Elaine Wang --- drivers/gpu/drm/ttm/ttm_tt.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/gpu/drm/ttm/ttm_tt.c b/drivers/gpu/drm/ttm/ttm_tt.c index a7bab87..4ea44c2 100644 --- a/drivers/gpu/drm/ttm/ttm_tt.c +++ b/drivers/gpu/drm/ttm/ttm_tt.c @@ -367,7 +367,7 @@ int ttm_tt_set_user(struct ttm_tt *ttm, ttm->tsk = tsk; ttm->start = start; - ttm->state = tt_unbound; + ttm->state = tt_unpopulated; return 0; } -- 1.6.0.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Problems with alpha/pci + radeon/ttm
On Sun, Jun 27, 2010 at 8:46 PM, Michael Cree wrote: > On 27/06/10 16:20, FUJITA Tomonori wrote: >> >> On Thu, 24 Jun 2010 21:51:40 +1200 >> Michael Cree ?wrote: >> > Is this a regression (what kernel version worked)? > > Seems that the IOMMU can't find 128 pages. It's likely due to: > > - out of the IOMMU space (possibly someone doesn't free the IOMMU > ? space). > > or > > - the mapping parameters (such as align) aren't appropriate so the > ? IOMMU can't find space. I don't think KMS drivers have ever worked on alpha so its not a regression, they are working fine on x86 + powerpc and sparc has been run at least once. >>> >>> KMS on the console boot up has worked since about 2.6.32, but starting >>> up the X server has always failed and, in my case, the system becomes >>> unstable and eventually OOPs. >>> I suspect we are simply hitting the limits of the iommu, how big an address space does it handle? since generally graphics drivers try to bind a lot of things to the GART. >>> >>> No idea on the address space limit. ?I applied the patch of Fujita that >>> logs all IOMMU allocations, and also inserted some extra printks in the >>> ttm kernel code so that I could see which routines failed and the error >>> code returned. ?Running the radeon test on boot exhibits the following: >>> >>> [ ?238.712768] [drm] Tested GTT->VRAM and VRAM->GTT copy for GTT offset >>> 0x1a312000 >>> [ ?239.281127] [drm] Tested GTT->VRAM and VRAM->GTT copy for GTT offset >>> 0x1a412000 >>> [ ?239.281127] ttm_tt_bind belched -12 >>> [ ?239.282104] ttm_bo_handle_move_mem belched -12 >>> [ ?239.282104] ttm_bo_move_buffer belched -12 >>> [ ?239.282104] ttm_bo_validate belched -12 >>> [ ?239.282104] radeon :01:00.0: object_init failed for (1048576, >>> 0x0002) err=-12 >>> [ ?239.282104] [drm:radeon_test_moves] *ERROR* Failed to create GTT >>> object 419 >>> [ ?239.399291] Error while testing BO move. >>> >>> Note that no IOMMU allocations are printed while radeon_test_moves is >>> running so iommu_arena_alloc doesn't appear to be called. ?Also the >>> error code returned up to radeon_test_moves is -12 which is ENOMEM. ?So >>> does appear to be some memory limit. >> >> Hmm, not related with IOMMU? looks like ttm_tt_populate could return >> ENOMEM too. Can we locate where we hit ENOMEM first? > > Yeah, in ttm_mem_global_reserve while it is walking glob->zones: > > [ ?239.303588] [drm] Tested GTT->VRAM and VRAM->GTT copy for GTT offset > 0x1a412000 > [ ?239.304564] ttm_mem_global_reserve zone used_mem (0x1a5f) exceeds > limit (0x1a5ef000) > [ ?239.304564] ttm_mem_global_reserve zone used_mem (0x1a5f) exceeds > limit (0x1a5ef000) > [ ?239.304564] ttm_mem_global_reserve zone used_mem (0x1a5f) exceeds > limit (0x1a5ef000) > [ ?239.304564] ttm_mem_global_reserve zone used_mem (0x1a5f) exceeds > limit (0x1a5ef000) > [ ?239.304564] ttm_mem_global_reserve zone used_mem (0x1a5f) exceeds > limit (0x1a5ef000) > [ ?239.304564] ttm_mem_global_reserve return non-zero count decs to zero > [ ?239.304564] ttm_mem_global_alloc_page belched -12 > [ ?239.304564] __ttm_tt_get_page coughed NULL > [ ?239.304564] ttm_tt_populate belched -12 > [ ?239.304564] ttm_tt_bind belched -12 > [ ?239.304564] ttm_bo_handle_move_mem belched -12 > [ ?239.304564] ttm_bo_move_buffer belched -12 > [ ?239.304564] ttm_bo_validate belched -12 > > On a hunch that we are chasing a red herring I installed another 256MB of > memory into the machine (was 576MB for the test reported above) for a total > of 832MB. > > Now radeon_test_moves runs to completion without error. > > OK, now a test of starting up the X server - ah, a bus error again but now > it looks like it's in the radeon driver: > > [ ?1435.014] (II) EXA(0): Driver allocated offscreen pixmaps > [ ?1435.014] (II) EXA(0): Driver registered support for the following > operations: > [ ?1435.014] (II) ? ? ? ? Solid > [ ?1435.014] (II) ? ? ? ? Copy > [ ?1435.014] (II) ? ? ? ? Composite (RENDER acceleration) > [ ?1435.014] (II) ? ? ? ? UploadToScreen > [ ?1435.014] (II) ? ? ? ? DownloadFromScreen > [ ?1435.030] > Backtrace: > [ ?1435.032] 0: /opt/xorg-ev56/bin/X (xorg_backtrace+0x54) [0x120070884] > [ ?1435.032] 1: /opt/xorg-ev56/bin/X (0x12000+0x65608) [0x120065608] > [ ?1435.033] 2: /lib/libc.so.6.1 (0x231+0x3d610) [0x234d610] > [ ?1435.034] 3: /opt/xorg-ev56/lib/xorg/modules/drivers/radeon_drv.so > (0x2758000+0x15b890) [0x28b3890] > [ ?1435.034] 4: /opt/xorg-ev56/lib/xorg/modules/drivers/radeon_drv.so > (0x2758000+0x1392a0) [0x28912a0] > [ ?1435.034] 5: /opt/xorg-ev56/lib/xorg/modules/drivers/radeon_drv.so > (0x2758000+0x139bec) [0x2891bec] > [ ?1435.034] 6: /opt/xorg-ev56/lib/xorg/modules/drivers/radeon_drv.so > (0x2758000+0x4f088) [0x27a7088] > [ ?1435.035] 7: /opt/xorg-ev56/lib/xorg/modules/drivers/radeon_drv.so > (0x2758000+0x16f0f8) [0x28c70f8] > [ ?1435.035] 8: /
Problems with alpha/pci + radeon/ttm
On 28/06/10 11:14, Dave Airlie wrote: > The bus error is caused by the kernel, its something alpha specific > with how mmap works, > I'm not sure if alpha needs some special mmap flags or something, Neither am I. All I know is that Alpha reorders CPU instructions more aggressively than most other architectures, the page map size is 8kB, and memory accesses must be aligned to the datum size. Maybe Ivan or Richard can comment on any relevant Alpha mmap specific issues. BTW, I discovered a couple of weeks ago that DRI is broken under UMS. It was working a year or so ago so something has happened to it. Am I correct in thinking that the DRM code has pretty much been shifted into the kernel even for UMS? On the Alpha I have been testing on (PWS600au, EV56 cpu and a radeon RV710 graphics card) running glxgears under UMS displays artefacts in rendering the gears, that is, some facets are not clipped to the rotating gear but extend to the edge of the window. On another Alpha (XP1000, EV67 cpu and a radeon RV610 card) it locked up completely (couldn't even ping it) when I ran glxgears. They are both running Debian unstable. Cheers Michael.
[PATCH 03/16] trivial: use ARRAY_SIZE
Change sizeof(x) / sizeof(*x) to ARRAY_SIZE(x).
Signed-off-by: Kulikov Vasiliy
---
drivers/gpu/drm/drm_edid.c |7 ++-
1 files changed, 2 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index c198186..da06476 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -929,13 +929,11 @@ drm_mode_do_interlace_quirk(struct drm_display_mode *mode,
{ 1440, 576 },
{ 2880, 576 },
};
- static const int n_sizes =
- sizeof(cea_interlaced)/sizeof(cea_interlaced[0]);
if (!(pt->misc & DRM_EDID_PT_INTERLACED))
return;
- for (i = 0; i < n_sizes; i++) {
+ for (i = 0; i < ARRAY_SIZE(cea_interlaced); i++) {
if ((mode->hdisplay == cea_interlaced[i].w) &&
(mode->vdisplay == cea_interlaced[i].h / 2)) {
mode->vdisplay *= 2;
@@ -1375,7 +1373,6 @@ static const struct {
{ 1920, 1440, 60, 0 },
{ 1920, 1440, 75, 0 },
};
-static const int num_est3_modes = sizeof(est3_modes) / sizeof(est3_modes[0]);
static int
drm_est3_modes(struct drm_connector *connector, struct detailed_timing *timing)
@@ -1387,7 +1384,7 @@ drm_est3_modes(struct drm_connector *connector, struct
detailed_timing *timing)
for (i = 0; i < 6; i++) {
for (j = 7; j > 0; j--) {
m = (i * 8) + (7 - j);
- if (m >= num_est3_modes)
+ if (m >= ARRAY_SIZE(est3_modes))
break;
if (est[i] & (1 << j)) {
mode = drm_mode_find_dmt(connector->dev,
--
1.7.0.4
[PATCH 04/16] trivial: use ARRAY_SIZE
Change sizeof(x) / sizeof(*x) to ARRAY_SIZE(x).
Signed-off-by: Kulikov Vasiliy
---
drivers/gpu/drm/i915/intel_sdvo.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_sdvo.c
b/drivers/gpu/drm/i915/intel_sdvo.c
index 76993ac..03c231b 100644
--- a/drivers/gpu/drm/i915/intel_sdvo.c
+++ b/drivers/gpu/drm/i915/intel_sdvo.c
@@ -392,13 +392,13 @@ static void intel_sdvo_debug_write(struct intel_encoder
*intel_encoder, u8 cmd,
DRM_LOG_KMS("%02X ", ((u8 *)args)[i]);
for (; i < 8; i++)
DRM_LOG_KMS(" ");
- for (i = 0; i < sizeof(sdvo_cmd_names) / sizeof(sdvo_cmd_names[0]);
i++) {
+ for (i = 0; i < ARRAY_SIZE(sdvo_cmd_names); i++) {
if (cmd == sdvo_cmd_names[i].cmd) {
DRM_LOG_KMS("(%s)", sdvo_cmd_names[i].name);
break;
}
}
- if (i == sizeof(sdvo_cmd_names)/ sizeof(sdvo_cmd_names[0]))
+ if (i == ARRAY_SIZE(sdvo_cmd_names))
DRM_LOG_KMS("(%02X)", cmd);
DRM_LOG_KMS("\n");
}
--
1.7.0.4
[PATCH 05/16] trivial: use ARRAY_SIZE
Change sizeof(x) / sizeof(*x) to ARRAY_SIZE(x).
Signed-off-by: Kulikov Vasiliy
---
drivers/gpu/drm/i915/intel_tv.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_tv.c b/drivers/gpu/drm/i915/intel_tv.c
index 6d553c2..d2d4e40 100644
--- a/drivers/gpu/drm/i915/intel_tv.c
+++ b/drivers/gpu/drm/i915/intel_tv.c
@@ -1424,7 +1424,7 @@ intel_tv_get_modes(struct drm_connector *connector)
int j, count = 0;
u64 tmp;
- for (j = 0; j < sizeof(input_res_table) / sizeof(input_res_table[0]);
+ for (j = 0; j < ARRAY_SIZE(input_res_table);
j++) {
struct input_res *input = &input_res_table[j];
unsigned int hactive_s = input->w;
--
1.7.0.4
[Bug 28771] Vsync always on
https://bugs.freedesktop.org/show_bug.cgi?id=28771 --- Comment #1 from Jesse Barnes 2010-06-28 09:31:56 PDT --- You need both: commit 234286c0f8b7d30ed49223c648d4c73c1a517ab3 Author: Jesse Barnes Date: Thu Apr 22 12:47:41 2010 -0700 DRI2: add config query extension and commit 45e2b51c853471b79004a954ce3092a253b20b77 Author: Jesse Barnes Date: Thu Apr 22 12:49:03 2010 -0700 DRI2/GLX: check for vblank_mode in DRI2 GLX code for vblank_mode to work. Does your Mesa build have those? -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
Problems with alpha/pci + radeon/ttm
On 06/28/2010 02:03 AM, Michael Cree wrote: > On 28/06/10 11:14, Dave Airlie wrote: >> The bus error is caused by the kernel, its something alpha specific >> with how mmap works, >> I'm not sure if alpha needs some special mmap flags or something, > > Neither am I. All I know is that Alpha reorders CPU instructions more > aggressively than most other architectures, the page map size is 8kB, > and memory accesses must be aligned to the datum size. There are no special mmap flags on alpha. The non-cacheable property is a function of the physical address (e.g. bit 40 set for ev5), and this has already been taken care of by the kernel. r~
[Bug 28800] New: [r300c] Texture corruption with World of Warcraft
https://bugs.freedesktop.org/show_bug.cgi?id=28800 Summary: [r300c] Texture corruption with World of Warcraft Product: Mesa Version: git Platform: x86 (IA32) OS/Version: Linux (All) Status: NEW Severity: normal Priority: medium Component: Drivers/DRI/r300 AssignedTo: dri-devel at lists.freedesktop.org ReportedBy: rankincj at googlemail.com Created an attachment (id=36583) --> (https://bugs.freedesktop.org/attachment.cgi?id=36583) Screenshot of corrupt textures A large number of textures are rendered incorrectly in World of Warcraft. (The game appears otherwise stable and moderately playable, although the frame rate isn't particularly high.) This is with an AGP RV350, running Linux 2.6.33.5, xorg-xf86-drv-ati from git and Fedora 13. My theory is that this is related to bug 28033, which has been fixed for r300g. However it is impossible to confirm this due to WoW crashing with r300g before I can enter the game. (See bug 28630.) -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 28630] [r300g] tiling / texture transfer crash in World of Warcraft
https://bugs.freedesktop.org/show_bug.cgi?id=28630 --- Comment #2 from Chris Rankin 2010-06-28 13:15:33 PDT --- Created an attachment (id=36584) --> (https://bugs.freedesktop.org/attachment.cgi?id=36584) Recent backtrace using mesa git with -gdwarf-2 -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 28771] Vsync always on
https://bugs.freedesktop.org/show_bug.cgi?id=28771 --- Comment #2 from Sven Arvidsson 2010-06-28 13:18:51 PDT --- Yes, I'm using git master, so they're both there. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 28630] [r300g] tiling / texture transfer crash in World of Warcraft
https://bugs.freedesktop.org/show_bug.cgi?id=28630
--- Comment #3 from Chris Rankin 2010-06-28
13:49:19 PDT ---
In src/gallium/drivers/r300/r300_context.c
static void r300_flush_cb(void *data)
{
struct r300_context* const cs_context_copy = data;
cs_context_copy->context.flush(&cs_context_copy->context, 0, NULL);
}
The crash happens when the context.flush function pointer does not contain a
valid value.
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
[Bug 28671] Seg. fault and Oops with Radeon KMS (v2.6.34) on PPC ATI Radeon AGP r420 JH.
https://bugs.freedesktop.org/show_bug.cgi?id=28671 --- Comment #25 from Brett Witherspoon 2010-06-28 13:51:33 PDT --- Ok seems to work well. How will I know when we have the correct combinations for the connector table? It seems that multiple combinations work. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 28671] Seg. fault and Oops with Radeon KMS (v2.6.34) on PPC ATI Radeon AGP r420 JH.
https://bugs.freedesktop.org/show_bug.cgi?id=28671 --- Comment #26 from Alex Deucher 2010-06-28 14:09:52 PDT --- Ideally you'd test both a digital and analog monitor on both ports and make sure it works on each. Can you attach your xorg log and dmesg from the final version of the patch? Also, make sure dpms works. when X is running, try 'xset dpms force off' and make sure the montior goes off properly. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[PATCH -next] drm: ttm_page_alloc, fix all sparse warnings
From: Randy Dunlap
Fix all sparse warnings in ttm_page_alloc.c.
Signed-off-by: Randy Dunlap
Cc: David Airlie
Cc: dri-devel at lists.freedesktop.org
---
drivers/gpu/drm/ttm/ttm_page_alloc.c |8
1 file changed, 4 insertions(+), 4 deletions(-)
drivers/gpu/drm/ttm/ttm_page_alloc.c:819:26: warning: non-ANSI function
declaration of function 'ttm_page_alloc_fini'
drivers/gpu/drm/ttm/ttm_page_alloc.c:499:21: warning: incorrect type in
argument 1 (different base types)
drivers/gpu/drm/ttm/ttm_page_alloc.c:499:21:expected restricted gfp_t
[usertype] gfp_mask
drivers/gpu/drm/ttm/ttm_page_alloc.c:499:21:got int [signed] gfp_flags
drivers/gpu/drm/ttm/ttm_page_alloc.c:670:25: warning: incorrect type in
initializer (different base types)
drivers/gpu/drm/ttm/ttm_page_alloc.c:670:25:expected int [signed] gfp_flags
drivers/gpu/drm/ttm/ttm_page_alloc.c:670:25:got restricted gfp_t
drivers/gpu/drm/ttm/ttm_page_alloc.c:675:27: warning: invalid assignment: |=
drivers/gpu/drm/ttm/ttm_page_alloc.c:675:27:left side has type int
drivers/gpu/drm/ttm/ttm_page_alloc.c:675:27:right side has type restricted
gfp_t
drivers/gpu/drm/ttm/ttm_page_alloc.c:680:35: warning: invalid assignment: |=
drivers/gpu/drm/ttm/ttm_page_alloc.c:680:35:left side has type int
drivers/gpu/drm/ttm/ttm_page_alloc.c:680:35:right side has type restricted
gfp_t
drivers/gpu/drm/ttm/ttm_page_alloc.c:682:35: warning: invalid assignment: |=
drivers/gpu/drm/ttm/ttm_page_alloc.c:682:35:left side has type int
drivers/gpu/drm/ttm/ttm_page_alloc.c:682:35:right side has type restricted
gfp_t
drivers/gpu/drm/ttm/ttm_page_alloc.c:685:29: warning: incorrect type in
argument 1 (different base types)
drivers/gpu/drm/ttm/ttm_page_alloc.c:685:29:expected restricted gfp_t
[usertype] gfp_mask
drivers/gpu/drm/ttm/ttm_page_alloc.c:685:29:got int [signed] gfp_flags
drivers/gpu/drm/ttm/ttm_page_alloc.c:793:54: warning: incorrect type in
argument 2 (different base types)
drivers/gpu/drm/ttm/ttm_page_alloc.c:793:54:expected int [signed] flags
drivers/gpu/drm/ttm/ttm_page_alloc.c:793:54:got restricted gfp_t
drivers/gpu/drm/ttm/ttm_page_alloc.c:795:54: warning: incorrect type in
argument 2 (different base types)
drivers/gpu/drm/ttm/ttm_page_alloc.c:795:54:expected int [signed] flags
drivers/gpu/drm/ttm/ttm_page_alloc.c:795:54:got restricted gfp_t
drivers/gpu/drm/ttm/ttm_page_alloc.c:797:69: warning: incorrect type in
argument 2 (different base types)
drivers/gpu/drm/ttm/ttm_page_alloc.c:797:69:expected int [signed] flags
drivers/gpu/drm/ttm/ttm_page_alloc.c:797:69:got restricted gfp_t
drivers/gpu/drm/ttm/ttm_page_alloc.c:800:69: warning: incorrect type in
argument 2 (different base types)
drivers/gpu/drm/ttm/ttm_page_alloc.c:800:69:expected int [signed] flags
drivers/gpu/drm/ttm/ttm_page_alloc.c:800:69:got restricted gfp_t
--- linux-next-20100625.orig/drivers/gpu/drm/ttm/ttm_page_alloc.c
+++ linux-next-20100625/drivers/gpu/drm/ttm/ttm_page_alloc.c
@@ -67,7 +67,7 @@ struct ttm_page_pool {
spinlock_t lock;
boolfill_lock;
struct list_headlist;
- int gfp_flags;
+ gfp_t gfp_flags;
unsignednpages;
char*name;
unsigned long nfrees;
@@ -476,7 +476,7 @@ static void ttm_handle_caching_state_fai
* This function is reentrant if caller updates count depending on number of
* pages returned in pages array.
*/
-static int ttm_alloc_new_pages(struct list_head *pages, int gfp_flags,
+static int ttm_alloc_new_pages(struct list_head *pages, gfp_t gfp_flags,
int ttm_flags, enum ttm_caching_state cstate, unsigned count)
{
struct page **caching_array;
@@ -667,7 +667,7 @@ int ttm_get_pages(struct list_head *page
{
struct ttm_page_pool *pool = ttm_get_pool(flags, cstate);
struct page *p = NULL;
- int gfp_flags = GFP_USER;
+ gfp_t gfp_flags = GFP_USER;
int r;
/* set zero flag for page allocation if required */
@@ -771,7 +771,7 @@ void ttm_put_pages(struct list_head *pag
ttm_page_pool_free(pool, page_count);
}
-static void ttm_page_pool_init_locked(struct ttm_page_pool *pool, int flags,
+static void ttm_page_pool_init_locked(struct ttm_page_pool *pool, gfp_t flags,
char *name)
{
spin_lock_init(&pool->lock);
[Bug 28771] Vsync always on
https://bugs.freedesktop.org/show_bug.cgi?id=28771 --- Comment #3 from Jesse Barnes 2010-06-28 15:41:03 PDT --- Oh, for the DRI2 radeon driver you'll probably need to add an explicit option somewhere; maybe the code path that used to check the vblank_mode flags is no longer called. See intel_screen.c: ... DRI_CONF_VBLANK_MODE(DRI_CONF_VBLANK_ALWAYS_SYNC) ... there's probably a similar section in the radeon driver somewhere. You'll also need to add support for the new DRI2 config extension to the driver, again see intel_screen.c's intelScreenExtensions array: ... &dri2ConfigQueryExtension.base, ... Hope that helps. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 28630] [r300g] tiling / texture transfer crash in World of Warcraft
https://bugs.freedesktop.org/show_bug.cgi?id=28630 --- Comment #4 from Marek Ol??k 2010-06-28 17:02:00 PDT --- I believe the "data" pointer is not valid. I have committed some fixes, can you please test latest mesa git? -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 27858] [r300g] Panzers II crashes in wine
https://bugs.freedesktop.org/show_bug.cgi?id=27858 --- Comment #6 from Marek Ol??k 2010-06-28 18:11:27 PDT --- Could you test the game with latest mesa git? There are some new fixes. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 28774] RS780: No picture over HDMI
https://bugs.freedesktop.org/show_bug.cgi?id=28774 --- Comment #11 from Alex Deucher 2010-06-28 22:38:29 PDT --- On avivo chips, the display regs start at 0x6000 (crtcs/grph/cur/etc.) and the output regs start at 0x7000 (dacs/dig/etc.). They only relevant register in your dump that's different is 0x75a0 (DIG_CNTL) and the only difference is that dig mode (DVI vs HDMI) either of which should work fine. I think the problem lies in the north bridge pcie config regs as the HDMI port uses the PCIEPHY transmitter which shares lanes with the northbrigde. I'm trying to get some better info on how it's supposed to work to help debug it. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
