[Bug 43405] New: Only horizontal lines (snow) display in google earth/glxgears using current r600g on RS780M
https://bugs.freedesktop.org/show_bug.cgi?id=43405 Bug #: 43405 Summary: Only horizontal lines (snow) display in google earth/glxgears using current r600g on RS780M Classification: Unclassified Product: Mesa Version: git Platform: x86 (IA32) OS/Version: Linux (All) Status: NEW Severity: blocker Priority: medium Component: Drivers/Gallium/r600 AssignedTo: dri-devel@lists.freedesktop.org ReportedBy: idun...@lavabit.com All that shows up when I run certain OpenGL programs (glxgears and google earth, so far) is monochrome blocks with horizontal lines. Not all GL programs are affected (the other standard tests work fine). On stderr, I get this message repeated ad nauseum: radeon: The kernel rejected CS, see dmesg for more information. dmesg repeats this ad nauseum: [18811.705536] radeon :01:05.0: z/stencil buffer (2) too small (0x00BF3C8F 12240 1 4 -> 3133440 have 3104768) [18811.705543] radeon :01:05.0: r600_packet3_check:1501 invalid cmd stream 569 [18811.705547] [drm:radeon_cs_ioctl] *ERROR* Invalid command stream ! My source tree is updated to the last commit prior to failover removal; that broke compilation (bug # 43404). First saw this issue last weekend; I hadn't seen any issues during August, when I last built mesa; the binaries from then still work. Hardware: Radeon HD 3200M - RS780M/RS780MN Debian squeeze with following packages updated: Linux 3.0.10 libdrm 2.4.25 libxmu 1.1.0 x11proto-dri2 2.6-2 x11proto-gl 1.4.14 -- 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: [PATCH] drm/ttm: callback move_notify any time bo placement change v3
Updated patch
Reviewed-by: Thomas Hellstrom
On 11/20/2011 10:02 PM, Jerome Glisse wrote:
On Sat, Nov 19, 2011 at 3:45 PM, Thomas Hellstrom wrote:
On 11/19/2011 12:32 AM, j.gli...@gmail.com wrote:
From: Jerome Glisse
Previously we were calling back move_notify in error path when the
bo is returned to it's original position or when destroy the bo.
When destroying the bo set the new mem placement as NULL when calling
back in the driver.
Updating nouveau to deal with NULL placement properly.
v2: reserve the object before calling move_notify in bo destroy path
at that point ttm should be the only piece of code interacting
with the object so atomic_set is safe here.
v3: callback move notify only once the bo is in its new position
call move notify want swaping out the buffer
Reviewed-by: Jerome Glisse
---
drivers/gpu/drm/nouveau/nouveau_bo.c |4 ++--
drivers/gpu/drm/ttm/ttm_bo.c | 17 +
2 files changed, 15 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c
b/drivers/gpu/drm/nouveau/nouveau_bo.c
index 857bca4..f12dd0f 100644
--- a/drivers/gpu/drm/nouveau/nouveau_bo.c
+++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
@@ -815,10 +815,10 @@ nouveau_bo_move_ntfy(struct ttm_buffer_object *bo,
struct ttm_mem_reg *new_mem)
struct nouveau_vma *vma;
list_for_each_entry(vma,&nvbo->vma_list, head) {
- if (new_mem->mem_type == TTM_PL_VRAM) {
+ if (new_mem&&new_mem->mem_type == TTM_PL_VRAM) {
nouveau_vm_map(vma, new_mem->mm_node);
} else
- if (new_mem->mem_type == TTM_PL_TT&&
+ if (new_mem&&new_mem->mem_type == TTM_PL_TT&&
nvbo->page_shift == vma->vm->spg_shift) {
nouveau_vm_map_sg(vma, 0, new_mem->
num_pages<lru));
BUG_ON(!list_empty(&bo->ddestroy));
+ /* force bo to reserved, at this point we should be the only owner
*/
+ atomic_set(&bo->reserved, 1);
+ if (bdev->driver->move_notify)
+ bdev->driver->move_notify(bo, NULL);
+ atomic_set(&bo->reserved, 0);
We can actually do this from the top of ttm_bo_cleanup_memtype_use(). Then
we should catch all current and future use-cases and you wouldn't need the
fake reserving, because at that point, we're already reserved.
+
if (bo->ttm)
ttm_tt_destroy(bo->ttm);
atomic_dec(&bo->glob->bo_count);
@@ -404,9 +410,6 @@ static int ttm_bo_handle_move_mem(struct
ttm_buffer_object *bo,
}
}
- if (bdev->driver->move_notify)
- bdev->driver->move_notify(bo, mem);
-
if (!(old_man->flags&TTM_MEMTYPE_FLAG_FIXED)&&
!(new_man->flags&TTM_MEMTYPE_FLAG_FIXED))
ret = ttm_bo_move_ttm(bo, evict, no_wait_reserve,
no_wait_gpu, mem);
@@ -419,6 +422,9 @@ static int ttm_bo_handle_move_mem(struct
ttm_buffer_object *bo,
if (ret)
goto out_err;
+ if (bdev->driver->move_notify)
+ bdev->driver->move_notify(bo, mem);
+
moved:
if (bo->evicted) {
ret = bdev->driver->invalidate_caches(bdev,
bo->mem.placement);
@@ -1872,9 +1878,12 @@ static int ttm_bo_swapout(struct ttm_mem_shrink
*shrink)
if (bo->bdev->driver->swap_notify)
bo->bdev->driver->swap_notify(bo);
+ if (bo->bdev->driver->move_notify)
+ bo->bdev->driver->move_notify(bo, NULL);
+
Hmm. On second thought, we could use swap_notify() for this, I missed we
already had that and that's what vmwgfx once used for exactly the same
purpose.
ret = ttm_tt_swapout(bo->ttm, bo->persistent_swap_storage);
-out:
+out:
Whitespace.
/Thomas
Attached updated patch
Cheers,
Jerome
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 43395] Game running in wine stops rendering
https://bugs.freedesktop.org/show_bug.cgi?id=43395 Alex Deucher changed: What|Removed |Added Component|Drivers/DRI/R600|Drivers/Gallium/r600 -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 43395] Game running in wine stops rendering
https://bugs.freedesktop.org/show_bug.cgi?id=43395 --- Comment #1 from Alex Deucher 2011-11-30 14:39:11 PST --- please attach your xorg log and dmesg output. Does mesa from git help? -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 43395] New: Game running in wine stops rendering
https://bugs.freedesktop.org/show_bug.cgi?id=43395 Bug #: 43395 Summary: Game running in wine stops rendering Classification: Unclassified Product: Mesa Version: 7.11 Platform: x86-64 (AMD64) OS/Version: Linux (All) Status: NEW Severity: normal Priority: medium Component: Drivers/DRI/R600 AssignedTo: dri-devel at lists.freedesktop.org ReportedBy: Schlosser.T at seznam.cz When playing Gothic everything works fine for 10 - 15 minutes, then the rendering just stops and the screen is left as it was. The game works normally (I can hear sounds from game and can blindly manipulate it). The rest of the system works just fine as well (the game is running in simulated windowed mode). Fedora 16 (Verne) x86_64 Graphic card: VGA compatible controller: ATI Technologies Inc Mobility Radeon HD 2400 [tomason at odysseus ~]$ glxinfo |grep -i "\(render\|opengl\)" direct rendering: Yes OpenGL vendor string: X.Org OpenGL renderer string: Gallium 0.4 on AMD RV610 OpenGL version string: 2.1 Mesa 7.11 OpenGL shading language version string: 1.20 Using libtxc_dxtn.i686 as the game requires it to run I also tried kmod-catalyst (proprietary drivers) and running it with wine64 none of which helped. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
Re: [Linaro-mm-sig] [RFC 1/2] dma-buf: Introduce dma buffer sharing mechanism
Hi Dave, Daniel, Rob, > > On Sun, Nov 27, 2011 at 12:29 PM, Rob Clark wrote: >> >> On Sat, Nov 26, 2011 at 8:00 AM, Daniel Vetter wrote: >> > On Fri, Nov 25, 2011 at 17:28, Dave Airlie wrote: >> >> I've rebuilt my PRIME interface on top of dmabuf to see how it would >> >> work, >> >> >> >> I've got primed gears running again on top, but I expect all my object >> >> lifetime and memory ownership rules need fixing up (i.e. leaks like a >> >> sieve). >> >> >> >> http://cgit.freedesktop.org/~airlied/linux/log/?h=drm-prime-dmabuf >> >> >> >> has the i915/nouveau patches for the kernel to produce the prime >> >> interface. >> > >> > I've noticed that your implementations for get_scatterlist (at least >> > for the i915 driver) doesn't return the sg table mapped into the >> > device address space. I've checked and the documentation makes it >> > clear that this should be the case (and we really need this to support >> > certain insane hw), but the get/put_scatterlist names are a bit >> > misleading. Proposal: >> > >> > - use struct sg_table instead of scatterlist like you've already done >> > in you branch. Simply more consistent with the dma api. >> >> yup >> >> > - rename get/put_scatterlist into map/unmap for consistency with all >> > the map/unmap dma api functions. The attachement would then serve as >> > the abstract cookie to the backing storage, similar to how struct page >> > * works as an abstract cookie for dma_map/unmap_page. The only special >> > thing is that struct device * parameter because that's already part of >> > the attachment. >> >> yup >> >> > - add new wrapper functions dma_buf_map_attachment and >> > dma_buf_unmap_attachement to hide all the pointer/vtable-chasing that >> > we currently expose to users of this interface. >> >> I thought that was one of the earlier comments on the initial dmabuf >> patch, but either way: yup > Thanks for your comments; I will incorporate all of these in the next version I'll send out. >> >> >> BR, >> -R > BR, Sumit. >> >> >> > Comments? >> > >> > Cheers, Daniel >> > -- >> > Daniel Vetter >> > daniel.vet...@ffwll.ch - +41 (0) 79 364 57 48 - http://blog.ffwll.ch >> > -- >> > To unsubscribe from this list: send the line "unsubscribe linux-media" >> > in >> > the body of a message to majord...@vger.kernel.org >> > More majordomo info at http://vger.kernel.org/majordomo-info.html >> > > > ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Linaro-mm-sig] [RFC 1/2] dma-buf: Introduce dma buffer sharing mechanism
Hi Dave, Daniel, Rob, On Sun, Nov 27, 2011 at 12:29 PM, Rob Clark wrote: > On Sat, Nov 26, 2011 at 8:00 AM, Daniel Vetter wrote: > > On Fri, Nov 25, 2011 at 17:28, Dave Airlie wrote: > >> I've rebuilt my PRIME interface on top of dmabuf to see how it would > work, > >> > >> I've got primed gears running again on top, but I expect all my object > >> lifetime and memory ownership rules need fixing up (i.e. leaks like a > >> sieve). > >> > >> http://cgit.freedesktop.org/~airlied/linux/log/?h=drm-prime-dmabuf > >> > >> has the i915/nouveau patches for the kernel to produce the prime > interface. > > > > I've noticed that your implementations for get_scatterlist (at least > > for the i915 driver) doesn't return the sg table mapped into the > > device address space. I've checked and the documentation makes it > > clear that this should be the case (and we really need this to support > > certain insane hw), but the get/put_scatterlist names are a bit > > misleading. Proposal: > > > > - use struct sg_table instead of scatterlist like you've already done > > in you branch. Simply more consistent with the dma api. > > yup > > > - rename get/put_scatterlist into map/unmap for consistency with all > > the map/unmap dma api functions. The attachement would then serve as > > the abstract cookie to the backing storage, similar to how struct page > > * works as an abstract cookie for dma_map/unmap_page. The only special > > thing is that struct device * parameter because that's already part of > > the attachment. > > yup > > > - add new wrapper functions dma_buf_map_attachment and > > dma_buf_unmap_attachement to hide all the pointer/vtable-chasing that > > we currently expose to users of this interface. > > I thought that was one of the earlier comments on the initial dmabuf > patch, but either way: yup > Thanks for your comments; I will incorporate all of these in the next version I'll send out. > > BR, > -R > BR, Sumit. > > > Comments? > > > > Cheers, Daniel > > -- > > Daniel Vetter > > daniel.vet...@ffwll.ch - +41 (0) 79 364 57 48 - http://blog.ffwll.ch > > -- > > To unsubscribe from this list: send the line "unsubscribe linux-media" in > > the body of a message to majord...@vger.kernel.org > > More majordomo info at http://vger.kernel.org/majordomo-info.html > > > ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 43375] [r600g] Firefox crashes when opening Jax WebGL Demos - Materials page
https://bugs.freedesktop.org/show_bug.cgi?id=43375 --- Comment #3 from Dave Airlie 2011-11-30 12:16:25 PST --- patch on mesa mailing list [PATCH] st/mesa: only resolve is number of samples is > 1 -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 43389] Gallium3d makes firefox crash with webgl animations
https://bugs.freedesktop.org/show_bug.cgi?id=43389 Alex Deucher changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE --- Comment #1 from Alex Deucher 2011-11-30 11:29:54 PST --- *** This bug has been marked as a duplicate of bug 43375 *** -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 43375] [r600g] Firefox crashes when opening Jax WebGL Demos - Materials page
https://bugs.freedesktop.org/show_bug.cgi?id=43375 Alex Deucher changed: What|Removed |Added CC||leandrosansilva at gmail.com --- Comment #2 from Alex Deucher 2011-11-30 11:29:54 PST --- *** Bug 43389 has been marked as a duplicate of this bug. *** -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 43341] CoreBreach: Crash in r600_update_derived_state
https://bugs.freedesktop.org/show_bug.cgi?id=43341 --- Comment #4 from Vadim 2011-11-30 19:04:57 PST --- (In reply to comment #3) > hello > i am the game developer. > > the workaround for disabling indirect addressing is automatically applied if > linking the shader fails because of the indirect adressing. e.g. this happens > on the geforce 7100 under windows. > > if you let linking fail instead of crashing, the same code path will be used > here. Yes, the crash needs to be fixed, of course, but I'm afraid that just fixing it won't make everything work as expected, because it happens too late. I'll check this. > > i'm not sure whats with the talk about too many temps. this crash occurs on > 5770 / 5670 which are very capable cards. with the proprietary nvidia/ati > drivers this shader works fine even back to ancient hardware under > windows/mac/linux e.g. Radeon 2400 or GeForce 7300. The shader code with mesa is not as heavily optimized as with the proprietary drivers. There are some optimization passes that do not support indirect addressing currently, so they are disabled in this case, that's why this shader breaks the limits. > i don't want to make disable indirect addressing by default since i guess it > will be slower on recent hardware. > I'm not sure that it will be slower. Code optimization with indirect addressing is much harder, so I guess almost every compiler will produce more efficient code without indirect addressing (at least in this case). It's definitely true for mesa at the moment. Also I did a quick comparison of the generated code for this shader with AMD GPU Shader Analyzer (that is, code generated by the AMD's proprietary driver), here are some of the results for the HD5770: w/o WORKAROUND: 2864 MPixels/sec with WORKAROUND: 3629 MPixels/sec I'm not an expert in shaders performance, but afaics many apps are trying to avoid the indirect addressing, e.g. Unigine Heaven IIRR doesn't use it at all. -- 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 43389] New: Gallium3d makes firefox crash with webgl animations
https://bugs.freedesktop.org/show_bug.cgi?id=43389 Bug #: 43389 Summary: Gallium3d makes firefox crash with webgl animations Classification: Unclassified Product: DRI Version: XOrg CVS Platform: x86-64 (AMD64) OS/Version: Linux (All) Status: NEW Severity: blocker Priority: medium Component: DRM/Radeon AssignedTo: dri-devel at lists.freedesktop.org ReportedBy: leandrosansilva at gmail.com Created attachment 53982 --> https://bugs.freedesktop.org/attachment.cgi?id=53982 Backtrace from the main thread It's a bug which happens which firefox, but is gallium3d related. The report in mozilla bugzilla (which has the complete description) can be found in: https://bugzilla.mozilla.org/show_bug.cgi?id=706490#c2 -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
linux-next: Tree for Nov 29 (drm)
2011/11/30 Randy Dunlap : > On 11/30/2011 09:16 AM, S?rgio Basto wrote: >> Randy, not dri-devel at lists.sourceforge.net, anymore >> now is dri-devel at lists.freedesktop.org > > Argh, thanks. > That was thunderbird trying to be too helpful. :( Ah well I got it and it should be fixed now. Dave.
[PATCH 2/2] drm/radeon/kms: Skip ACPI call to ATIF when possible
I am under the impression that it only makes sense to call the ATIF method if the graphics device has an ACPI handle attached. So we could skip the call altogether if there is no such handle. Signed-off-by: Jean Delvare Cc: David Airlie Cc: Alex Deucher --- This is only tested on a system where the Radeon device has no ACPI handle and there is no ATIF method. This should also be tested on systems with ATIF, presumably laptops. drivers/gpu/drm/radeon/radeon_acpi.c |8 1 file changed, 4 insertions(+), 4 deletions(-) --- linux-3.2-rc3.orig/drivers/gpu/drm/radeon/radeon_acpi.c 2011-11-29 18:12:02.0 +0100 +++ linux-3.2-rc3/drivers/gpu/drm/radeon/radeon_acpi.c 2011-11-29 18:59:46.0 +0100 @@ -51,13 +51,13 @@ int radeon_acpi_init(struct radeon_devic acpi_handle handle; int ret; - /* No need to proceed if we're sure that ATIF is not supported */ - if (!ASIC_IS_AVIVO(rdev) || !rdev->bios) - return 0; - /* Get the device handle */ handle = DEVICE_ACPI_HANDLE(&rdev->pdev->dev); + /* No need to proceed if we're sure that ATIF is not supported */ + if (!ASIC_IS_AVIVO(rdev) || !rdev->bios || !handle) + return 0; + /* Call the ATIF method */ ret = radeon_atif_call(handle); if (ret) -- Jean Delvare Suse L3
[PATCH 1/2] drm/radeon/kms: Hide debugging message
Use the proper macro to issue the debugging message in
radeon_atif_call(). Otherwise we spam the log of many systems with a
message which looks like an error message of unknown origin, and could
thus confuse the user. Commit dc77de12dde95c8da39e4c417eb70c7d445cf84b
was a first step in this direction, but was not sufficient IMHO.
Signed-off-by: Jean Delvare
Cc: David Airlie
Cc: Alex Deucher
---
Might be considered for stable, this is not a critical bug but it can
waste time of users and developers alike.
drivers/gpu/drm/radeon/radeon_acpi.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- linux-3.2-rc3.orig/drivers/gpu/drm/radeon/radeon_acpi.c 2011-11-29
17:47:02.0 +0100
+++ linux-3.2-rc3/drivers/gpu/drm/radeon/radeon_acpi.c 2011-11-29
18:12:02.0 +0100
@@ -35,7 +35,8 @@ static int radeon_atif_call(acpi_handle
/* Fail only if calling the method fails and ATIF is supported */
if (ACPI_FAILURE(status) && status != AE_NOT_FOUND) {
- printk(KERN_DEBUG "failed to evaluate ATIF got %s\n",
acpi_format_exception(status));
+ DRM_DEBUG_DRIVER("failed to evaluate ATIF got %s\n",
+acpi_format_exception(status));
kfree(buffer.pointer);
return 1;
}
--
Jean Delvare
Suse L3
[PATCH] drm/nouveau: Fix module parameter description formats
Module parameter descriptions don't take a trailing \n, otherwise it breaks formatting of modinfo's output. Also remove trailing space. Signed-off-by: Jean Delvare Cc: David Airlie Cc: Ben Skeggs --- drivers/gpu/drm/nouveau/nouveau_drv.c | 12 ++-- 1 file changed, 6 insertions(+), 6 deletions(-) --- linux-3.2-rc3.orig/drivers/gpu/drm/nouveau/nouveau_drv.c2011-11-09 15:53:32.0 +0100 +++ linux-3.2-rc3/drivers/gpu/drm/nouveau/nouveau_drv.c 2011-11-29 10:33:37.0 +0100 @@ -89,7 +89,7 @@ MODULE_PARM_DESC(override_conntype, "Ign int nouveau_override_conntype = 0; module_param_named(override_conntype, nouveau_override_conntype, int, 0400); -MODULE_PARM_DESC(tv_disable, "Disable TV-out detection\n"); +MODULE_PARM_DESC(tv_disable, "Disable TV-out detection"); int nouveau_tv_disable = 0; module_param_named(tv_disable, nouveau_tv_disable, int, 0400); @@ -104,23 +104,23 @@ module_param_named(tv_norm, nouveau_tv_n MODULE_PARM_DESC(reg_debug, "Register access debug bitmask:\n" "\t\t0x1 mc, 0x2 video, 0x4 fb, 0x8 extdev,\n" "\t\t0x10 crtc, 0x20 ramdac, 0x40 vgacrtc, 0x80 rmvio,\n" - "\t\t0x100 vgaattr, 0x200 EVO (G80+). "); + "\t\t0x100 vgaattr, 0x200 EVO (G80+)"); int nouveau_reg_debug; module_param_named(reg_debug, nouveau_reg_debug, int, 0600); -MODULE_PARM_DESC(perflvl, "Performance level (default: boot)\n"); +MODULE_PARM_DESC(perflvl, "Performance level (default: boot)"); char *nouveau_perflvl; module_param_named(perflvl, nouveau_perflvl, charp, 0400); -MODULE_PARM_DESC(perflvl_wr, "Allow perflvl changes (warning: dangerous!)\n"); +MODULE_PARM_DESC(perflvl_wr, "Allow perflvl changes (warning: dangerous!)"); int nouveau_perflvl_wr; module_param_named(perflvl_wr, nouveau_perflvl_wr, int, 0400); -MODULE_PARM_DESC(msi, "Enable MSI (default: off)\n"); +MODULE_PARM_DESC(msi, "Enable MSI (default: off)"); int nouveau_msi; module_param_named(msi, nouveau_msi, int, 0400); -MODULE_PARM_DESC(ctxfw, "Use external HUB/GPC ucode (fermi)\n"); +MODULE_PARM_DESC(ctxfw, "Use external HUB/GPC ucode (fermi)"); int nouveau_ctxfw; module_param_named(ctxfw, nouveau_ctxfw, int, 0400); -- Jean Delvare Suse L3
[PATCH] drm/radeon/kms: Fix module parameter description format
From: Jean Delvare Subject: drm/radeon/kms: Fix module parameter description format Module parameter descriptions don't take a trailing \n, otherwise it breaks formatting of modinfo's output. Also add missing space after comma. Signed-off-by: Jean Delvare Cc: David Airlie Cc: Alex Deucher Cc: Jerome Glisse --- drivers/gpu/drm/radeon/radeon_drv.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- linux-3.2-rc3.orig/drivers/gpu/drm/radeon/radeon_drv.c 2011-11-24 10:13:11.0 +0100 +++ linux-3.2-rc3/drivers/gpu/drm/radeon/radeon_drv.c 2011-11-29 10:25:27.0 +0100 @@ -140,7 +140,7 @@ module_param_named(vramlimit, radeon_vra MODULE_PARM_DESC(agpmode, "AGP Mode (-1 == PCI)"); module_param_named(agpmode, radeon_agpmode, int, 0444); -MODULE_PARM_DESC(gartsize, "Size of PCIE/IGP gart to setup in megabytes (32,64, etc)\n"); +MODULE_PARM_DESC(gartsize, "Size of PCIE/IGP gart to setup in megabytes (32, 64, etc)"); module_param_named(gartsize, radeon_gart_size, int, 0600); MODULE_PARM_DESC(benchmark, "Run benchmark"); -- Jean Delvare Suse L3
linux-next: Tree for Nov 29 (drm)
Randy, not dri-devel at lists.sourceforge.net, anymore now is dri-devel at lists.freedesktop.org On Tue, 2011-11-29 at 12:33 -0800, Randy Dunlap wrote: > On 11/28/2011 08:20 PM, Stephen Rothwell wrote: > > Hi all, > > > > Changes since 2028: > > > > The drm tree lost its build failure but gained another for which I > > applied a patch. > > > ERROR: "drm_helper_get_fb_bpp_depth" [drivers/gpu/drm/vmwgfx/vmwgfx.ko] > undefined! > > Full x86_64 randconfig file is attached. > > -- > All the data continuously generated in your IT infrastructure > contains a definitive record of customers, application performance, > security threats, fraudulent activity, and more. Splunk takes this > data and makes sense of it. IT sense. And common sense. > http://p.sf.net/sfu/splunk-novd2d > -- ___ Dri-devel mailing list > Dri-devel at lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/dri-devel -- S?rgio M. B.
[Bug 43341] CoreBreach: Crash in r600_update_derived_state
https://bugs.freedesktop.org/show_bug.cgi?id=43341 --- Comment #3 from corecode 2011-11-30 07:52:32 PST --- hello i am the game developer. the workaround for disabling indirect addressing is automatically applied if linking the shader fails because of the indirect adressing. e.g. this happens on the geforce 7100 under windows. if you let linking fail instead of crashing, the same code path will be used here. i don't want to make disable indirect addressing by default since i guess it will be slower on recent hardware. i'm not sure whats with the talk about too many temps. this crash occurs on 5770 / 5670 which are very capable cards. with the proprietary nvidia/ati drivers this shader works fine even back to ancient hardware under windows/mac/linux e.g. Radeon 2400 or GeForce 7300. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 43395] Game running in wine stops rendering
https://bugs.freedesktop.org/show_bug.cgi?id=43395 Alex Deucher changed: What|Removed |Added Component|Drivers/DRI/R600|Drivers/Gallium/r600 -- 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 43395] Game running in wine stops rendering
https://bugs.freedesktop.org/show_bug.cgi?id=43395 --- Comment #1 from Alex Deucher 2011-11-30 14:39:11 PST --- please attach your xorg log and dmesg output. Does mesa from git help? -- 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 43395] New: Game running in wine stops rendering
https://bugs.freedesktop.org/show_bug.cgi?id=43395 Bug #: 43395 Summary: Game running in wine stops rendering Classification: Unclassified Product: Mesa Version: 7.11 Platform: x86-64 (AMD64) OS/Version: Linux (All) Status: NEW Severity: normal Priority: medium Component: Drivers/DRI/R600 AssignedTo: dri-devel@lists.freedesktop.org ReportedBy: schlosse...@seznam.cz When playing Gothic everything works fine for 10 - 15 minutes, then the rendering just stops and the screen is left as it was. The game works normally (I can hear sounds from game and can blindly manipulate it). The rest of the system works just fine as well (the game is running in simulated windowed mode). Fedora 16 (Verne) x86_64 Graphic card: VGA compatible controller: ATI Technologies Inc Mobility Radeon HD 2400 [tomason@odysseus ~]$ glxinfo |grep -i "\(render\|opengl\)" direct rendering: Yes OpenGL vendor string: X.Org OpenGL renderer string: Gallium 0.4 on AMD RV610 OpenGL version string: 2.1 Mesa 7.11 OpenGL shading language version string: 1.20 Using libtxc_dxtn.i686 as the game requires it to run I also tried kmod-catalyst (proprietary drivers) and running it with wine64 none of which helped. -- 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 43375] New: [r600g] Firefox crashes when opening Jax WebGL Demos - Materials page
https://bugs.freedesktop.org/show_bug.cgi?id=43375 Bug #: 43375 Summary: [r600g] Firefox crashes when opening Jax WebGL Demos - Materials page Classification: Unclassified Product: Mesa Version: git Platform: x86-64 (AMD64) OS/Version: Linux (All) Status: NEW Severity: critical Priority: medium Component: Drivers/Gallium/r600 AssignedTo: dri-devel at lists.freedesktop.org ReportedBy: jlp.bugs at gmail.com I'm using a nightly version of Firefox with WebGL enabled and when I try to visit the page http://sinisterchipmunk.github.com/materials.html Firefox crashes and says the crash happened in r600g_dri.so This is the backtrace I get when I attached gdb to Firefox: Program received signal SIGSEGV, Segmentation fault. 0x in ?? () (gdb) bt #0 0x in ?? () #1 0x7f8af39ec5ed in st_BlitFramebuffer_resolve (info=0x7fffb307a1f0, mask=16384, ctx=0x7f8b02f02000) at state_tracker/st_cb_blit.c:87 #2 st_BlitFramebuffer (ctx=0x7f8b02f02000, srcX0=0, srcY0=0, srcX1=1128, srcY1=500, dstX0=0, dstY0=0, dstX1=1128, dstY1=500, mask=16384, filter=9728) at state_tracker/st_cb_blit.c:207 #3 0x7f8af38a0ec3 in _mesa_BlitFramebufferEXT (srcX0=0, srcY0=0, srcX1=1128, srcY1=500, dstX0=0, dstY0=0, dstX1=1128, dstY1=500, mask=16384, filter=9728) at main/fbobject.c:2791 #4 0x7f8b2ba27547 in ?? () from /home/jlp/Download/firefox/libxul.so #5 0x7f8b2ba2763a in ?? () from /home/jlp/Download/firefox/libxul.so #6 0x7f8b2c24a7b3 in mozilla::gl::GLContext::ReadPixelsIntoImageSurface(int, int, int, int, gfxImageSurface*) () from /home/jlp/Download/firefox/libxul.so #7 0x7f8b2c23041a in ?? () from /home/jlp/Download/firefox/libxul.so #8 0x7f8b2c2304ff in ?? () from /home/jlp/Download/firefox/libxul.so #9 0x7f8b2c2334ac in mozilla::layers::BasicLayerManager::PaintLayer(gfxContext*, mozilla::layers::Layer*, void (*)(mozilla::layers::ThebesLayer*, gfxContext*, nsIntRegion const&, nsIntRegion const&, void*), void*, mozilla::layers::ReadbackProcessor*) () from /home/jlp/Download/firefox/libxul.so #10 0x7f8b2c22e229 in mozilla::layers::BasicLayerManager::EndTransactionInternal(void (*)(mozilla::layers::ThebesLayer*, gfxContext*, nsIntRegion const&, nsIntRegion const&, void*), void*, mozilla::layers::LayerManager::EndTransactionFlags) () from /home/jlp/Download/firefox/libxul.so #11 0x7f8b2b7affb6 in ?? () from /home/jlp/Download/firefox/libxul.so #12 0x7f8b2c234cd9 in ?? () from /home/jlp/Download/firefox/libxul.so #13 0x7f8b2c22e718 in ?? () from /home/jlp/Download/firefox/libxul.so #14 0x7f8b2c2343c3 in ?? () from /home/jlp/Download/firefox/libxul.so #15 0x7f8b2c233173 in mozilla::layers::BasicLayerManager::PaintLayer(gfxContext*, mozilla::layers::Layer*, void (*)(mozilla::layers::ThebesLayer*, gfxContext*, nsIntRegion const&, nsIntRegion const&, void*), void*, mozilla::layers::ReadbackProcessor*) () from /home/jlp/Download/firefox/libxul.so #16 0x7f8b2c2332aa in mozilla::layers::BasicLayerManager::PaintLayer(gfxContext*, mozilla::layers::Layer*, void (*)(mozilla::layers::ThebesLayer*, gfxContext*, nsIntRegion const&, nsIntRegion const&, void*), void*, mozilla::layers::ReadbackProcessor*) () from /home/jlp/Download/firefox/libxul.so #17 0x7f8b2c2332aa in mozilla::layers::BasicLayerManager::PaintLayer(gfxContext*, mozilla::layers::Layer*, void (*)(mozilla::layers::ThebesLayer*, gfxContext*, nsIntRegion const&, nsIntRegion const&, void*), void*, mozilla::layers::ReadbackProcessor*) () from /home/jlp/Download/firefox/libxul.so #18 0x7f8b2c22e229 in mozilla::layers::BasicLayerManager::EndTransactionInternal(void (*)(mozilla::layers::ThebesLayer*, gfxContext*, nsIntRegion const&, nsIntRegion const&, void*), void*, mozilla::layers::LayerManager::EndTransactionFlags) () from /home/jlp/Download/firefox/libxul.so #19 0x7f8b2c22ebd9 in ?? () from /home/jlp/Download/firefox/libxul.so #20 0x7f8b2b7dbd97 in ?? () from /home/jlp/Download/firefox/libxul.so #21 0x7f8b2b7f4455 in ?? () from /home/jlp/Download/firefox/libxul.so #22 0x7f8b2b805618 in ?? () from /home/jlp/Download/firefox/libxul.so #23 0x7f8b2bb53308 in ?? () from /home/jlp/Download/firefox/libxul.so #24 0x7f8b2bb533cd in ?? () from /home/jlp/Download/firefox/libxul.so #25 0x7f8b2bb55a50 in ?? () from /home/jlp/Download/firefox/libxul.so #26 0x7f8b2bb522aa in ?? () from /home/jlp/Download/firefox/libxul.so #27 0x7f8b2c02f94d in ?? () from /home/jlp/Download/firefox/libxul.so #28 0x7f8b2c02db60 in ?? () from /home/jlp/Download/firefox/libxul.so #29 0x003891938fb0 in _gtk_marshal_BOOLEAN__BOXED (closure=0x7f8b21a4bdf0, return_value=0x7fffb307d270, n_param_values=, param_values=0x7f8af8ed4640, invocation_hint=, marshal_data=) at gtkmarshalers.c:86 #30 0x0035abc109e2 in g_closure_invoke (closure=0x7f8b21
3.2-rc2+: Reported regressions from 3.0 and 3.1
On Tue, Nov 29, 2011 at 07:34:28PM +0100, Borislav Petkov wrote: > On Tue, Nov 29, 2011 at 01:04:14PM -0500, Konrad Rzeszutek Wilk wrote: > > This patch: Borislav, Thanks for your review comments. How does this patch look? I believe I touched upon all of the things you mentioned.
[Bug 43375] [r600g] Firefox crashes when opening Jax WebGL Demos - Materials page
https://bugs.freedesktop.org/show_bug.cgi?id=43375 --- Comment #3 from Dave Airlie 2011-11-30 12:16:25 PST --- patch on mesa mailing list [PATCH] st/mesa: only resolve is number of samples is > 1 -- 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 2/2] drm/radeon/kms: Skip ACPI call to ATIF when possible
On Wed, Nov 30, 2011 at 11:36 AM, Jean Delvare wrote: > I am under the impression that it only makes sense to call the ATIF > method if the graphics device has an ACPI handle attached. So we could > skip the call altogether if there is no such handle. > > Signed-off-by: Jean Delvare > Cc: David Airlie > Cc: Alex Deucher > --- > This is only tested on a system where the Radeon device has no ACPI > handle and there is no ATIF method. This should also be tested on > systems with ATIF, presumably laptops. I think this makes sense. Reviewed-by: Alex Deucher > > ?drivers/gpu/drm/radeon/radeon_acpi.c | ? ?8 > ?1 file changed, 4 insertions(+), 4 deletions(-) > > --- linux-3.2-rc3.orig/drivers/gpu/drm/radeon/radeon_acpi.c ? ? 2011-11-29 > 18:12:02.0 +0100 > +++ linux-3.2-rc3/drivers/gpu/drm/radeon/radeon_acpi.c ?2011-11-29 > 18:59:46.0 +0100 > @@ -51,13 +51,13 @@ int radeon_acpi_init(struct radeon_devic > ? ? ? ?acpi_handle handle; > ? ? ? ?int ret; > > - ? ? ? /* No need to proceed if we're sure that ATIF is not supported */ > - ? ? ? if (!ASIC_IS_AVIVO(rdev) || !rdev->bios) > - ? ? ? ? ? ? ? return 0; > - > ? ? ? ?/* Get the device handle */ > ? ? ? ?handle = DEVICE_ACPI_HANDLE(&rdev->pdev->dev); > > + ? ? ? /* No need to proceed if we're sure that ATIF is not supported */ > + ? ? ? if (!ASIC_IS_AVIVO(rdev) || !rdev->bios || !handle) > + ? ? ? ? ? ? ? return 0; > + > ? ? ? ?/* Call the ATIF method */ > ? ? ? ?ret = radeon_atif_call(handle); > ? ? ? ?if (ret) > > -- > Jean Delvare > Suse L3 > ___ > dri-devel mailing list > dri-devel at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel >
[PATCH 1/2] drm/radeon/kms: Hide debugging message
On Wed, Nov 30, 2011 at 11:26 AM, Jean Delvare wrote:
> Use the proper macro to issue the debugging message in
> radeon_atif_call(). Otherwise we spam the log of many systems with a
> message which looks like an error message of unknown origin, and could
> thus confuse the user. Commit dc77de12dde95c8da39e4c417eb70c7d445cf84b
> was a first step in this direction, but was not sufficient IMHO.
>
> Signed-off-by: Jean Delvare
> Cc: David Airlie
> Cc: Alex Deucher
Reviewed-by: Alex Deucher
> ---
> Might be considered for stable, this is not a critical bug but it can
> waste time of users and developers alike.
>
> ?drivers/gpu/drm/radeon/radeon_acpi.c | ? ?3 ++-
> ?1 file changed, 2 insertions(+), 1 deletion(-)
>
> --- linux-3.2-rc3.orig/drivers/gpu/drm/radeon/radeon_acpi.c ? ? 2011-11-29
> 17:47:02.0 +0100
> +++ linux-3.2-rc3/drivers/gpu/drm/radeon/radeon_acpi.c ?2011-11-29
> 18:12:02.0 +0100
> @@ -35,7 +35,8 @@ static int radeon_atif_call(acpi_handle
>
> ? ? ? ?/* Fail only if calling the method fails and ATIF is supported */
> ? ? ? ?if (ACPI_FAILURE(status) && status != AE_NOT_FOUND) {
> - ? ? ? ? ? ? ? printk(KERN_DEBUG "failed to evaluate ATIF got %s\n",
> acpi_format_exception(status));
> + ? ? ? ? ? ? ? DRM_DEBUG_DRIVER("failed to evaluate ATIF got %s\n",
> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?acpi_format_exception(status));
> ? ? ? ? ? ? ? ?kfree(buffer.pointer);
> ? ? ? ? ? ? ? ?return 1;
> ? ? ? ?}
>
> --
> Jean Delvare
> Suse L3
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>
[PATCH] drm/radeon/kms: Fix module parameter description format
On Wed, Nov 30, 2011 at 11:22 AM, Jean Delvare wrote: > From: Jean Delvare > Subject: drm/radeon/kms: Fix module parameter description format > > Module parameter descriptions don't take a trailing \n, otherwise it > breaks formatting of modinfo's output. Also add missing space after > comma. > > Signed-off-by: Jean Delvare > Cc: David Airlie > Cc: Alex Deucher > Cc: Jerome Glisse Reviewed-by: Alex Deucher > --- > ?drivers/gpu/drm/radeon/radeon_drv.c | ? ?2 +- > ?1 file changed, 1 insertion(+), 1 deletion(-) > > --- linux-3.2-rc3.orig/drivers/gpu/drm/radeon/radeon_drv.c ? ? ?2011-11-24 > 10:13:11.0 +0100 > +++ linux-3.2-rc3/drivers/gpu/drm/radeon/radeon_drv.c ? 2011-11-29 > 10:25:27.0 +0100 > @@ -140,7 +140,7 @@ module_param_named(vramlimit, radeon_vra > ?MODULE_PARM_DESC(agpmode, "AGP Mode (-1 == PCI)"); > ?module_param_named(agpmode, radeon_agpmode, int, 0444); > > -MODULE_PARM_DESC(gartsize, "Size of PCIE/IGP gart to setup in megabytes > (32,64, etc)\n"); > +MODULE_PARM_DESC(gartsize, "Size of PCIE/IGP gart to setup in megabytes (32, > 64, etc)"); > ?module_param_named(gartsize, radeon_gart_size, int, 0600); > > ?MODULE_PARM_DESC(benchmark, "Run benchmark"); > > -- > Jean Delvare > Suse L3 > ___ > dri-devel mailing list > dri-devel at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel >
[PATCH 2/2] drm/radeon/kms: wrap-up handling of floating connectors and connector unavailability status logging
Am Dienstag, den 29.11.2011, 15:53 -0500 schrieb Alex Deucher: > On Tue, Nov 29, 2011 at 1:06 PM, Thomas Reim wrote: > > Dear Alex, > > > >> On Mon, Nov 28, 2011 at 11:20 AM, Thomas Reim > >> wrote: > >> >Extended DDC probe is now default for RADEON chipsets. In case of > >> >HW bugs (e. g. floating connectors), the affected connectors will > >> >not be used, as a valid EDID header can not be detected. Another > >> >patch removed DDC detection and connector status logging during > >> >device setup. So the user is not informed anymore about HW bugs > >> >leading to connectors being unavailable. > >> >Reintroduce one-time logging of connector unavailability status > >> >when probing (single) connector modes during framebuffer > >> >initialisation. > >> > > >> >For RS690 chipsets DDC detection shall be stopped, if the i2c bus > >> >receives all-0 EDIDs (floating connectors). The introduction of > >> >extended DDC probing prevents the driver from doing this. > >> > Correctly > >> >relocate the related code. > >> > >> Is any of this needed anymore now that we do an extended probe? I > >> think the original null edid patch was just papering over the actual > >> issue which was the need for a full edid header probe. > > > > The difference, at least this is my understanding of Dave's patch, is > > that we completely stop DDC detection for the famous RS690/RS740 chips > > with missing or disabled HDMI add-on cards. We decrease latency, as we > > do not retrieve data from i2c bus anymore. Therefore, I would keep it. > > > > My only concern is that we may disable the i2c bus if there is no > monitor connected which would prevent edid fetching from working in > the future. Does the problematic ddia i2c line produce the same error > in the following cases: > The proposed solution differentiates between i2c bus responds, i. e. a DDC is available, and EDID (header) is valid. > 1. ddia hdmi connector present, no monitor attached DDC is not available: The connector is regarded as being disconnected; function drm_helper_probe_single_connector_modes() records a debug message in the logs, i. e. "HDMI-A-1 is disconnected". The connector will be probed again, when probing single connector modes (using function drm_helper_probe_single_connector_modes() about every second). > 2. ddia hdmi connector present, monitor with faulty edid attached > DDC is available, invalid EDID (header): The connector is regarded as being disconnected; If it's the first time, that this connector has been probed, usually during framebuffer initialisation, dump the faulty EDID to the logs and add an info message, that there is a problem with the monitor: e. g. "HDMI-A-1: probed a monitor, DDC responded but no|invalid EDID". In addition, the debug message of case 1 is logged. Then we have two subcases: a) General The connector will be probed again, when probing single connector modes (using function drm_helper_probe_single_connector_modes() about every second). But there will be only the debug message logged. No info message and no EDID dump. b) EDID is all zero, i. e. not more than 8 non-zero bytes have been received (RS690/RS740 chips only) Floating connector is assumed and an info message is logged: "HDMI-A-1: detected RS690 floating bus bug, stopping ddc detect". Such a connector will not be probed again, reducing latency. I believe that this is rather a theoretical case, as it requires a monitor with an erased EEPROM. > 3. ddia hdmi connector absent a) Correctly implemented HW would handle this in the same way as for case 1. The connector is part of the chipset, i2c bus is correctly terminated and will never be used, but being probed. This is a drawback of implmentations, that use a chipset wich provides more connectors than being used by the implementation. b) Buggy HW The connector's i2c has not been terminated correctly. It can't be used, but is detected. The EDID information will mainly consist of zero bytes, except of some random byte values. DDC is available, invalid EDID (header): The connector is regarded as being disconnected; If it's the first time, that this connector has been probed, usually during framebuffer initialisation, dump the received information of the not available EDID to the logs and add an info message, that there is a problem with the connector: e. g. "HDMI-A-1: probed a monitor, DDC responded but no|invalid EDID". In addition, the debug message of the first case is logged. Then we have two subcases: (1) RS690/RS740 chips Floating connector is assumed and an info message is logged: "HDMI-A-1: detected RS690 floating bus bug, stopping ddc detect". Such a connector will not be probed again, reducing latency. (2) Other chipsets The connector will be probed again, when probing single connector modes (using function drm_helper_probe_single_connector_modes() about every second). But there will be only a de
[Bug 43375] [r600g] Firefox crashes when opening Jax WebGL Demos - Materials page
https://bugs.freedesktop.org/show_bug.cgi?id=43375 Alex Deucher changed: What|Removed |Added CC||leandrosansi...@gmail.com --- Comment #2 from Alex Deucher 2011-11-30 11:29:54 PST --- *** Bug 43389 has been marked as a duplicate of this bug. *** -- 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 43389] Gallium3d makes firefox crash with webgl animations
https://bugs.freedesktop.org/show_bug.cgi?id=43389 Alex Deucher changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE --- Comment #1 from Alex Deucher 2011-11-30 11:29:54 PST --- *** This bug has been marked as a duplicate of bug 43375 *** -- 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 43341] CoreBreach: Crash in r600_update_derived_state
https://bugs.freedesktop.org/show_bug.cgi?id=43341 --- Comment #2 from Vadim 2011-11-30 03:05:40 PST --- The shader translation is failed because of too many temps used. They could be optimized away in theory, but this shader also uses indirect addressing, and some optimization passes in mesa are disabled due to this. The shader also contains alternative code that afaics does the same calculations without indirect addressing, you may check if it helps by adding the line: #define WORKAROUND 1 in the beginning of the ./CoreBreach.app/Resources/postprocessing.frag -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 43389] New: Gallium3d makes firefox crash with webgl animations
https://bugs.freedesktop.org/show_bug.cgi?id=43389 Bug #: 43389 Summary: Gallium3d makes firefox crash with webgl animations Classification: Unclassified Product: DRI Version: XOrg CVS Platform: x86-64 (AMD64) OS/Version: Linux (All) Status: NEW Severity: blocker Priority: medium Component: DRM/Radeon AssignedTo: dri-devel@lists.freedesktop.org ReportedBy: leandrosansi...@gmail.com Created attachment 53982 --> https://bugs.freedesktop.org/attachment.cgi?id=53982 Backtrace from the main thread It's a bug which happens which firefox, but is gallium3d related. The report in mozilla bugzilla (which has the complete description) can be found in: https://bugzilla.mozilla.org/show_bug.cgi?id=706490#c2 -- 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
linux-next: Tree for Nov 29 (drm)
On 11/30/2011 09:16 AM, S?rgio Basto wrote: > Randy, not dri-devel at lists.sourceforge.net, anymore > now is dri-devel at lists.freedesktop.org Argh, thanks. That was thunderbird trying to be too helpful. :( > On Tue, 2011-11-29 at 12:33 -0800, Randy Dunlap wrote: >> On 11/28/2011 08:20 PM, Stephen Rothwell wrote: >>> Hi all, >>> >>> Changes since 2028: >>> >>> The drm tree lost its build failure but gained another for which I >>> applied a patch. >> >> >> ERROR: "drm_helper_get_fb_bpp_depth" [drivers/gpu/drm/vmwgfx/vmwgfx.ko] >> undefined! >> >> Full x86_64 randconfig file is attached. >> >> -- >> -- ___ Dri-devel mailing list >> Dri-devel at lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/dri-devel > -- ~Randy *** Remember to use Documentation/SubmitChecklist when testing your code ***
Re: 3.2-rc2+: Reported regressions from 3.0 and 3.1
On Tue, Nov 29, 2011 at 07:34:28PM +0100, Borislav Petkov wrote:
> On Tue, Nov 29, 2011 at 01:04:14PM -0500, Konrad Rzeszutek Wilk wrote:
> > This patch:
Borislav,
Thanks for your review comments. How does this patch look? I believe
I touched upon all of the things you mentioned.
>From eb6dbd80078312c428dde69e9313606b7513a2e6 Mon Sep 17 00:00:00 2001
From: Konrad Rzeszutek Wilk
Date: Mon, 21 Nov 2011 18:02:02 -0500
Subject: [PATCH] xen/pm_idle: Make pm_idle be default_idle under Xen.
This patch:
commit d91ee5863b71e8c90eaf6035bff3078a85e2e7b5
Author: Len Brown
Date: Fri Apr 1 18:28:35 2011 -0400
cpuidle: replace xen access to x86 pm_idle and default_idle
..scribble on pm_idle and access default_idle,
have it simply disable_cpuidle() so acpi_idle will not load and
architecture default HLT will be used.
idea was to have one call - disable_cpuidle() which would make
pm_idle not be molested by other code. It disallows cpuidle_idle_call
to be set to pm_idle (which is excellent). But in the select_idle_routine()
and idle_setup(), the pm_idle can still be set to either:
amd_e400_idle, mwait_idle or default_idle. This depends on some
CPU flags (MWAIT) and in AMD case on the type of CPU.
In case of mwait_idle we can hit some instances where the hypervisor
(Amazon EC2 specifically) sets the MWAIT and we get:
Brought up 2 CPUs
invalid opcode: [#1] SMP
CPU 1
Modules linked in:
Pid: 0, comm: swapper Not tainted 3.1.0-0.rc6.git0.3.fc16.x86_64 #1
RIP: e030:[] [] mwait_idle+0x6f/0xb4
RSP: e02b:8801d28ddf10 EFLAGS: 00010082
RAX: 8801d28dc010 RBX: 8801d28ddfd8 RCX:
RDX: RSI: 0001 RDI: 0001
RBP: 8801d28ddf10 R08: R09: 0001
R10: 0001 R11: 8801d28ddfd8 R12: 81b590d0
R13: R14: R15:
FS: () GS:8801dff81000() knlGS:
CS: e033 DS: 002b ES: 002b CR0: 8005003b
CR2: CR3: 01a05000 CR4: 2660
DR0: DR1: DR2:
DR3: DR6: 0ff0 DR7:
Process swapper (pid: 0, threadinfo 8801d28dc000, task 8801d28cae60)
Stack:
8801d28ddf40 8100e2ed 8801dff8e390 c136dfe72feab515
8801d28ddf50 8149ee78
Call Trace:
[] cpu_idle+0xae/0xe8
[] cpu_bringup_and_idle+0xe/0x10
RIP [] mwait_idle+0x6f/0xb4
RSP
In case of amd_e400_idle we don't get so spectacular crashes, but
we do end up making an MSR which is trapped in the hypervisor,
and then follow it up with a yield hypercall. Meaning we end up
going to hypervisor twice instead of just once.
The previous behavior before v3.0 was that pm_idle was set
to default_idle irregardless of select_idle_routine/idle_setup.
We want to do that, but only for one specific case: Xen.
This patch does that.
Fixes RH BZ #739499 and Ubuntu #881076
Reported-by: Stefan Bader
Signed-off-by: Konrad Rzeszutek Wilk
---
arch/x86/include/asm/system.h |1 +
arch/x86/kernel/process.c |8
arch/x86/xen/setup.c |2 +-
3 files changed, 10 insertions(+), 1 deletions(-)
diff --git a/arch/x86/include/asm/system.h b/arch/x86/include/asm/system.h
index c2ff2a1..2d2f01c 100644
--- a/arch/x86/include/asm/system.h
+++ b/arch/x86/include/asm/system.h
@@ -401,6 +401,7 @@ extern unsigned long arch_align_stack(unsigned long sp);
extern void free_init_pages(char *what, unsigned long begin, unsigned long
end);
void default_idle(void);
+bool set_pm_idle_to_default(void);
void stop_this_cpu(void *dummy);
diff --git a/arch/x86/kernel/process.c b/arch/x86/kernel/process.c
index 1f7f8c8..31f47ba 100644
--- a/arch/x86/kernel/process.c
+++ b/arch/x86/kernel/process.c
@@ -404,6 +404,14 @@ void default_idle(void)
EXPORT_SYMBOL(default_idle);
#endif
+bool set_pm_idle_to_default(void)
+{
+ bool ret = !!pm_idle;
+
+ pm_idle = default_idle;
+
+ return ret;
+}
void stop_this_cpu(void *dummy)
{
local_irq_disable();
diff --git a/arch/x86/xen/setup.c b/arch/x86/xen/setup.c
index 46d6d21..79dfb57 100644
--- a/arch/x86/xen/setup.c
+++ b/arch/x86/xen/setup.c
@@ -448,6 +448,6 @@ void __init xen_arch_setup(void)
#endif
disable_cpuidle();
boot_option_idle_override = IDLE_HALT;
-
+ WARN_ON(set_pm_idle_to_default());
fiddle_vdso();
}
--
1.7.7.3
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: linux-next: Tree for Nov 29 (drm)
2011/11/30 Randy Dunlap : > On 11/30/2011 09:16 AM, Sérgio Basto wrote: >> Randy, not dri-de...@lists.sourceforge.net, anymore >> now is dri-devel@lists.freedesktop.org > > Argh, thanks. > That was thunderbird trying to be too helpful. :( Ah well I got it and it should be fixed now. Dave. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: linux-next: Tree for Nov 29 (drm)
Randy, not dri-de...@lists.sourceforge.net, anymore now is dri-devel@lists.freedesktop.org On Tue, 2011-11-29 at 12:33 -0800, Randy Dunlap wrote: > On 11/28/2011 08:20 PM, Stephen Rothwell wrote: > > Hi all, > > > > Changes since 2028: > > > > The drm tree lost its build failure but gained another for which I > > applied a patch. > > > ERROR: "drm_helper_get_fb_bpp_depth" [drivers/gpu/drm/vmwgfx/vmwgfx.ko] > undefined! > > Full x86_64 randconfig file is attached. > > -- > All the data continuously generated in your IT infrastructure > contains a definitive record of customers, application performance, > security threats, fraudulent activity, and more. Splunk takes this > data and makes sense of it. IT sense. And common sense. > http://p.sf.net/sfu/splunk-novd2d > -- ___ Dri-devel mailing list > dri-de...@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/dri-devel -- Sérgio M. B. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: linux-next: Tree for Nov 29 (drm)
On 11/30/2011 09:16 AM, Sérgio Basto wrote: > Randy, not dri-de...@lists.sourceforge.net, anymore > now is dri-devel@lists.freedesktop.org Argh, thanks. That was thunderbird trying to be too helpful. :( > On Tue, 2011-11-29 at 12:33 -0800, Randy Dunlap wrote: >> On 11/28/2011 08:20 PM, Stephen Rothwell wrote: >>> Hi all, >>> >>> Changes since 2028: >>> >>> The drm tree lost its build failure but gained another for which I >>> applied a patch. >> >> >> ERROR: "drm_helper_get_fb_bpp_depth" [drivers/gpu/drm/vmwgfx/vmwgfx.ko] >> undefined! >> >> Full x86_64 randconfig file is attached. >> >> -- >> -- ___ Dri-devel mailing list >> dri-de...@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/dri-devel > -- ~Randy *** Remember to use Documentation/SubmitChecklist when testing your code *** ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/2] drm/radeon/kms: Skip ACPI call to ATIF when possible
On Wed, Nov 30, 2011 at 11:36 AM, Jean Delvare wrote: > I am under the impression that it only makes sense to call the ATIF > method if the graphics device has an ACPI handle attached. So we could > skip the call altogether if there is no such handle. > > Signed-off-by: Jean Delvare > Cc: David Airlie > Cc: Alex Deucher > --- > This is only tested on a system where the Radeon device has no ACPI > handle and there is no ATIF method. This should also be tested on > systems with ATIF, presumably laptops. I think this makes sense. Reviewed-by: Alex Deucher > > drivers/gpu/drm/radeon/radeon_acpi.c | 8 > 1 file changed, 4 insertions(+), 4 deletions(-) > > --- linux-3.2-rc3.orig/drivers/gpu/drm/radeon/radeon_acpi.c 2011-11-29 > 18:12:02.0 +0100 > +++ linux-3.2-rc3/drivers/gpu/drm/radeon/radeon_acpi.c 2011-11-29 > 18:59:46.0 +0100 > @@ -51,13 +51,13 @@ int radeon_acpi_init(struct radeon_devic > acpi_handle handle; > int ret; > > - /* No need to proceed if we're sure that ATIF is not supported */ > - if (!ASIC_IS_AVIVO(rdev) || !rdev->bios) > - return 0; > - > /* Get the device handle */ > handle = DEVICE_ACPI_HANDLE(&rdev->pdev->dev); > > + /* No need to proceed if we're sure that ATIF is not supported */ > + if (!ASIC_IS_AVIVO(rdev) || !rdev->bios || !handle) > + return 0; > + > /* Call the ATIF method */ > ret = radeon_atif_call(handle); > if (ret) > > -- > Jean Delvare > Suse L3 > ___ > dri-devel mailing list > dri-devel@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel > ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/2] drm/radeon/kms: Hide debugging message
On Wed, Nov 30, 2011 at 11:26 AM, Jean Delvare wrote:
> Use the proper macro to issue the debugging message in
> radeon_atif_call(). Otherwise we spam the log of many systems with a
> message which looks like an error message of unknown origin, and could
> thus confuse the user. Commit dc77de12dde95c8da39e4c417eb70c7d445cf84b
> was a first step in this direction, but was not sufficient IMHO.
>
> Signed-off-by: Jean Delvare
> Cc: David Airlie
> Cc: Alex Deucher
Reviewed-by: Alex Deucher
> ---
> Might be considered for stable, this is not a critical bug but it can
> waste time of users and developers alike.
>
> drivers/gpu/drm/radeon/radeon_acpi.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> --- linux-3.2-rc3.orig/drivers/gpu/drm/radeon/radeon_acpi.c 2011-11-29
> 17:47:02.0 +0100
> +++ linux-3.2-rc3/drivers/gpu/drm/radeon/radeon_acpi.c 2011-11-29
> 18:12:02.0 +0100
> @@ -35,7 +35,8 @@ static int radeon_atif_call(acpi_handle
>
> /* Fail only if calling the method fails and ATIF is supported */
> if (ACPI_FAILURE(status) && status != AE_NOT_FOUND) {
> - printk(KERN_DEBUG "failed to evaluate ATIF got %s\n",
> acpi_format_exception(status));
> + DRM_DEBUG_DRIVER("failed to evaluate ATIF got %s\n",
> + acpi_format_exception(status));
> kfree(buffer.pointer);
> return 1;
> }
>
> --
> Jean Delvare
> Suse L3
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/radeon/kms: Fix module parameter description format
On Wed, Nov 30, 2011 at 11:22 AM, Jean Delvare wrote: > From: Jean Delvare > Subject: drm/radeon/kms: Fix module parameter description format > > Module parameter descriptions don't take a trailing \n, otherwise it > breaks formatting of modinfo's output. Also add missing space after > comma. > > Signed-off-by: Jean Delvare > Cc: David Airlie > Cc: Alex Deucher > Cc: Jerome Glisse Reviewed-by: Alex Deucher > --- > drivers/gpu/drm/radeon/radeon_drv.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > --- linux-3.2-rc3.orig/drivers/gpu/drm/radeon/radeon_drv.c 2011-11-24 > 10:13:11.0 +0100 > +++ linux-3.2-rc3/drivers/gpu/drm/radeon/radeon_drv.c 2011-11-29 > 10:25:27.0 +0100 > @@ -140,7 +140,7 @@ module_param_named(vramlimit, radeon_vra > MODULE_PARM_DESC(agpmode, "AGP Mode (-1 == PCI)"); > module_param_named(agpmode, radeon_agpmode, int, 0444); > > -MODULE_PARM_DESC(gartsize, "Size of PCIE/IGP gart to setup in megabytes > (32,64, etc)\n"); > +MODULE_PARM_DESC(gartsize, "Size of PCIE/IGP gart to setup in megabytes (32, > 64, etc)"); > module_param_named(gartsize, radeon_gart_size, int, 0600); > > MODULE_PARM_DESC(benchmark, "Run benchmark"); > > -- > Jean Delvare > Suse L3 > ___ > dri-devel mailing list > dri-devel@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel > ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/2] drm/radeon/kms: Skip ACPI call to ATIF when possible
I am under the impression that it only makes sense to call the ATIF method if the graphics device has an ACPI handle attached. So we could skip the call altogether if there is no such handle. Signed-off-by: Jean Delvare Cc: David Airlie Cc: Alex Deucher --- This is only tested on a system where the Radeon device has no ACPI handle and there is no ATIF method. This should also be tested on systems with ATIF, presumably laptops. drivers/gpu/drm/radeon/radeon_acpi.c |8 1 file changed, 4 insertions(+), 4 deletions(-) --- linux-3.2-rc3.orig/drivers/gpu/drm/radeon/radeon_acpi.c 2011-11-29 18:12:02.0 +0100 +++ linux-3.2-rc3/drivers/gpu/drm/radeon/radeon_acpi.c 2011-11-29 18:59:46.0 +0100 @@ -51,13 +51,13 @@ int radeon_acpi_init(struct radeon_devic acpi_handle handle; int ret; - /* No need to proceed if we're sure that ATIF is not supported */ - if (!ASIC_IS_AVIVO(rdev) || !rdev->bios) - return 0; - /* Get the device handle */ handle = DEVICE_ACPI_HANDLE(&rdev->pdev->dev); + /* No need to proceed if we're sure that ATIF is not supported */ + if (!ASIC_IS_AVIVO(rdev) || !rdev->bios || !handle) + return 0; + /* Call the ATIF method */ ret = radeon_atif_call(handle); if (ret) -- Jean Delvare Suse L3 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/2] drm/radeon/kms: Hide debugging message
Use the proper macro to issue the debugging message in
radeon_atif_call(). Otherwise we spam the log of many systems with a
message which looks like an error message of unknown origin, and could
thus confuse the user. Commit dc77de12dde95c8da39e4c417eb70c7d445cf84b
was a first step in this direction, but was not sufficient IMHO.
Signed-off-by: Jean Delvare
Cc: David Airlie
Cc: Alex Deucher
---
Might be considered for stable, this is not a critical bug but it can
waste time of users and developers alike.
drivers/gpu/drm/radeon/radeon_acpi.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- linux-3.2-rc3.orig/drivers/gpu/drm/radeon/radeon_acpi.c 2011-11-29
17:47:02.0 +0100
+++ linux-3.2-rc3/drivers/gpu/drm/radeon/radeon_acpi.c 2011-11-29
18:12:02.0 +0100
@@ -35,7 +35,8 @@ static int radeon_atif_call(acpi_handle
/* Fail only if calling the method fails and ATIF is supported */
if (ACPI_FAILURE(status) && status != AE_NOT_FOUND) {
- printk(KERN_DEBUG "failed to evaluate ATIF got %s\n",
acpi_format_exception(status));
+ DRM_DEBUG_DRIVER("failed to evaluate ATIF got %s\n",
+acpi_format_exception(status));
kfree(buffer.pointer);
return 1;
}
--
Jean Delvare
Suse L3
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/nouveau: Fix module parameter description formats
Module parameter descriptions don't take a trailing \n, otherwise it breaks formatting of modinfo's output. Also remove trailing space. Signed-off-by: Jean Delvare Cc: David Airlie Cc: Ben Skeggs --- drivers/gpu/drm/nouveau/nouveau_drv.c | 12 ++-- 1 file changed, 6 insertions(+), 6 deletions(-) --- linux-3.2-rc3.orig/drivers/gpu/drm/nouveau/nouveau_drv.c2011-11-09 15:53:32.0 +0100 +++ linux-3.2-rc3/drivers/gpu/drm/nouveau/nouveau_drv.c 2011-11-29 10:33:37.0 +0100 @@ -89,7 +89,7 @@ MODULE_PARM_DESC(override_conntype, "Ign int nouveau_override_conntype = 0; module_param_named(override_conntype, nouveau_override_conntype, int, 0400); -MODULE_PARM_DESC(tv_disable, "Disable TV-out detection\n"); +MODULE_PARM_DESC(tv_disable, "Disable TV-out detection"); int nouveau_tv_disable = 0; module_param_named(tv_disable, nouveau_tv_disable, int, 0400); @@ -104,23 +104,23 @@ module_param_named(tv_norm, nouveau_tv_n MODULE_PARM_DESC(reg_debug, "Register access debug bitmask:\n" "\t\t0x1 mc, 0x2 video, 0x4 fb, 0x8 extdev,\n" "\t\t0x10 crtc, 0x20 ramdac, 0x40 vgacrtc, 0x80 rmvio,\n" - "\t\t0x100 vgaattr, 0x200 EVO (G80+). "); + "\t\t0x100 vgaattr, 0x200 EVO (G80+)"); int nouveau_reg_debug; module_param_named(reg_debug, nouveau_reg_debug, int, 0600); -MODULE_PARM_DESC(perflvl, "Performance level (default: boot)\n"); +MODULE_PARM_DESC(perflvl, "Performance level (default: boot)"); char *nouveau_perflvl; module_param_named(perflvl, nouveau_perflvl, charp, 0400); -MODULE_PARM_DESC(perflvl_wr, "Allow perflvl changes (warning: dangerous!)\n"); +MODULE_PARM_DESC(perflvl_wr, "Allow perflvl changes (warning: dangerous!)"); int nouveau_perflvl_wr; module_param_named(perflvl_wr, nouveau_perflvl_wr, int, 0400); -MODULE_PARM_DESC(msi, "Enable MSI (default: off)\n"); +MODULE_PARM_DESC(msi, "Enable MSI (default: off)"); int nouveau_msi; module_param_named(msi, nouveau_msi, int, 0400); -MODULE_PARM_DESC(ctxfw, "Use external HUB/GPC ucode (fermi)\n"); +MODULE_PARM_DESC(ctxfw, "Use external HUB/GPC ucode (fermi)"); int nouveau_ctxfw; module_param_named(ctxfw, nouveau_ctxfw, int, 0400); -- Jean Delvare Suse L3 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/radeon/kms: Fix module parameter description format
From: Jean Delvare Subject: drm/radeon/kms: Fix module parameter description format Module parameter descriptions don't take a trailing \n, otherwise it breaks formatting of modinfo's output. Also add missing space after comma. Signed-off-by: Jean Delvare Cc: David Airlie Cc: Alex Deucher Cc: Jerome Glisse --- drivers/gpu/drm/radeon/radeon_drv.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- linux-3.2-rc3.orig/drivers/gpu/drm/radeon/radeon_drv.c 2011-11-24 10:13:11.0 +0100 +++ linux-3.2-rc3/drivers/gpu/drm/radeon/radeon_drv.c 2011-11-29 10:25:27.0 +0100 @@ -140,7 +140,7 @@ module_param_named(vramlimit, radeon_vra MODULE_PARM_DESC(agpmode, "AGP Mode (-1 == PCI)"); module_param_named(agpmode, radeon_agpmode, int, 0444); -MODULE_PARM_DESC(gartsize, "Size of PCIE/IGP gart to setup in megabytes (32,64, etc)\n"); +MODULE_PARM_DESC(gartsize, "Size of PCIE/IGP gart to setup in megabytes (32, 64, etc)"); module_param_named(gartsize, radeon_gart_size, int, 0600); MODULE_PARM_DESC(benchmark, "Run benchmark"); -- Jean Delvare Suse L3 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 43341] CoreBreach: Crash in r600_update_derived_state
https://bugs.freedesktop.org/show_bug.cgi?id=43341 --- Comment #3 from corecode 2011-11-30 07:52:32 PST --- hello i am the game developer. the workaround for disabling indirect addressing is automatically applied if linking the shader fails because of the indirect adressing. e.g. this happens on the geforce 7100 under windows. if you let linking fail instead of crashing, the same code path will be used here. i don't want to make disable indirect addressing by default since i guess it will be slower on recent hardware. i'm not sure whats with the talk about too many temps. this crash occurs on 5770 / 5670 which are very capable cards. with the proprietary nvidia/ati drivers this shader works fine even back to ancient hardware under windows/mac/linux e.g. Radeon 2400 or GeForce 7300. -- 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 43375] [r600g] Firefox crashes when opening Jax WebGL Demos - Materials page
https://bugs.freedesktop.org/show_bug.cgi?id=43375 --- Comment #1 from Jure Repinc 2011-11-30 06:57:57 UTC --- A bit better backtrace with Firefox's debug symbols included: Program received signal SIGSEGV, Segmentation fault. 0x in ?? () (gdb) bt #0 0x in ?? () #1 0x7f1e298ec5ed in st_BlitFramebuffer_resolve (info=0x7fff2cfd91b0, mask=16384, ctx=0x7f1e37a3d000) at state_tracker/st_cb_blit.c:87 #2 st_BlitFramebuffer (ctx=0x7f1e37a3d000, srcX0=0, srcY0=0, srcX1=1128, srcY1=500, dstX0=0, dstY0=0, dstX1=1128, dstY1=500, mask=16384, filter=9728) at state_tracker/st_cb_blit.c:207 #3 0x7f1e297a0ec3 in _mesa_BlitFramebufferEXT (srcX0=0, srcY0=0, srcX1=1128, srcY1=500, dstX0=0, dstY0=0, dstX1=1128, dstY1=500, mask=16384, filter=9728) at main/fbobject.c:2791 #4 0x7f1e56924ae7 in raw_fBlitFramebuffer (filter=9728, mask=16384, dstY1=, dstX1=, dstY0=0, dstX0=0, srcY1=, srcX1=, srcY0=0, srcX0=0, this=0x7f1e2c383000) at ../../../dist/include/GLContext.h:2385 #5 mozilla::gl::GLContext::BeforeGLReadCall (this=0x7f1e2c383000) at ../../../dist/include/GLContext.h:927 #6 0x7f1e56924bda in mozilla::gl::GLContext::fReadPixels (this=0x7f1e2c383000, x=0, y=0, width=1128, height=500, format=32993, type=33639, pixels=0x7f1e4c50) at ../../../dist/include/GLContext.h:966 #7 0x7f1e57146a43 in mozilla::gl::GLContext::ReadPixelsIntoImageSurface (this=0x7f1e2c383000, aX=, aY=, aWidth=, aHeight=500, aDest= 0x7f1e2de56a10) at /builds/slave/m-cen-lnx64-ntly/build/gfx/gl/GLContext.cpp:1707 #8 0x7f1e5712c6a4 in mozilla::layers::BasicCanvasLayer::UpdateSurface (this=0x7f1e2b674ed0, aDestSurface=0x0) at /builds/slave/m-cen-lnx64-ntly/build/gfx/layers/basic/BasicLayers.cpp:1156 #9 0x7f1e5712c789 in mozilla::layers::BasicCanvasLayer::Paint (this=0x7f1e2b674ed0, aContext=0x7f1e2fe69060) at /builds/slave/m-cen-lnx64-ntly/build/gfx/layers/basic/BasicLayers.cpp:1182 #10 0x7f1e5712f72c in mozilla::layers::BasicLayerManager::PaintLayer (this=0x7f1e2af45f90, aTarget=0x7f1e2fe69060, aLayer=0x7f1e2b674ed0, aCallback= 0x7f1e566acf90 , aCallbackData=0x7fff2cfdb3a0, aReadback=0x0) at /builds/slave/m-cen-lnx64-ntly/build/gfx/layers/basic/BasicLayers.cpp:1900 #11 0x7f1e5712a5c9 in mozilla::layers::BasicLayerManager::EndTransactionInternal (this=0x7f1e2af45f90, aCallback=0x7f1e566acf90 , aCallbackData=0x7fff2cfdb3a0, aFlags=) at /builds/slave/m-cen-lnx64-ntly/build/gfx/layers/basic/BasicLayers.cpp:1610 #12 0x7f1e566ad8ff in PaintInactiveLayer (aContext=, aItem=, aBuilder=) at /builds/slave/m-cen-lnx64-ntly/build/layout/base/FrameLayerBuilder.cpp:1323 #13 mozilla::FrameLayerBuilder::DrawThebesLayer (aLayer=, aContext=0x7f1e2fe69060, aRegionToDraw=, aRegionToInvalidate=, aCallbackData=0x7fff2cfdb3a0) at /builds/slave/m-cen-lnx64-ntly/build/layout/base/FrameLayerBuilder.cpp:2137 #14 0x7f1e57130f59 in mozilla::layers::BasicThebesLayer::PaintBuffer(gfxContext*, nsIntRegion const&, nsIntRegion const&, nsIntRegion const&, bool, void (*)(mozilla::layers::ThebesLayer*, gfxContext*, nsIntRegion const&, nsIntRegion const&, void*), void*) () from /home/jlp/Download/firefox/libxul.so #15 0x7f1e5712aab8 in mozilla::layers::BasicShadowableThebesLayer::PaintBuffer (this=0x7f1e2b3ec000, aContext=, aRegionToDraw=..., aExtendedRegionToDraw=, aRegionToInvalidate=, aDidSelfCopy=false, aCallback=0x7f1e566acf90 , aCallbackData=0x7fff2cfdb3a0) at /builds/slave/m-cen-lnx64-ntly/build/gfx/layers/basic/BasicLayers.cpp:2332 #16 0x7f1e57130643 in mozilla::layers::BasicThebesLayer::PaintThebes (this=0x7f1e2b3ec000, aContext=0x7f1e2ec90340, aCallback=0x7f1e566acf90 , aCallbackData=0x7fff2cfdb3a0, aReadback=) at /builds/slave/m-cen-lnx64-ntly/build/gfx/layers/basic/BasicLayers.cpp:745 #17 0x7f1e5712f3f3 in mozilla::layers::BasicLayerManager::PaintLayer (this=0x7f1e379df790, aTarget=0x7f1e2ec90340, aLayer=0x7f1e2b3ec000, aCallback=0x7f1e566acf90 , aCallbackData=0x7fff2cfdb3a0, aReadback=0x7fff2cfdaaa0) at /builds/slave/m-cen-lnx64-ntly/build/gfx/layers/basic/BasicLayers.cpp:1898 #18 0x7f1e5712f52a in mozilla::layers::BasicLayerManager::PaintLayer (this=0x7f1e379df790, aTarget=0x7f1e2b33a0e0, aLayer=0x7f1e2b734af0, aCallback=0x7f1e566acf90 , aCallbackData=0x7fff2cfdb3a0, aReadback=0x7fff2cfdaaa0) at /builds/slave/m-cen-lnx64-ntly/build/gfx/layers/basic/BasicLayers.cpp:1913 #19 0x7f1e5712f52a in mozilla::layers::BasicLayerManager::PaintLayer (this=0x7f1e379df790, aTarget=0x7f1e2b33a0e0, aLayer=0x7f1e2f0660c0, aCallback=0x7f1e566acf90 , aCallbackData=0x7fff2cfdb3a0, aReadback=0x7fff2cfdafa0) at /builds/slave/m-cen-lnx64-ntly/build/gfx/layers/basic/BasicLayers.cpp:1913 #20 0x7f1e5712a5c9 in mozilla::layers::BasicLayerManager::EndTransactionInternal (this=0x7f1e379df790, aCallback=0x7f1e566acf90 , aCallbackData=0x7fff2cfdb3a0, aFlags=) at /builds/slave/m-cen-lnx64-ntly/build/g
[Bug 43375] [r600g] Firefox crashes when opening Jax WebGL Demos - Materials page
https://bugs.freedesktop.org/show_bug.cgi?id=43375 --- Comment #1 from Jure Repinc 2011-11-30 06:57:57 UTC --- A bit better backtrace with Firefox's debug symbols included: Program received signal SIGSEGV, Segmentation fault. 0x in ?? () (gdb) bt #0 0x in ?? () #1 0x7f1e298ec5ed in st_BlitFramebuffer_resolve (info=0x7fff2cfd91b0, mask=16384, ctx=0x7f1e37a3d000) at state_tracker/st_cb_blit.c:87 #2 st_BlitFramebuffer (ctx=0x7f1e37a3d000, srcX0=0, srcY0=0, srcX1=1128, srcY1=500, dstX0=0, dstY0=0, dstX1=1128, dstY1=500, mask=16384, filter=9728) at state_tracker/st_cb_blit.c:207 #3 0x7f1e297a0ec3 in _mesa_BlitFramebufferEXT (srcX0=0, srcY0=0, srcX1=1128, srcY1=500, dstX0=0, dstY0=0, dstX1=1128, dstY1=500, mask=16384, filter=9728) at main/fbobject.c:2791 #4 0x7f1e56924ae7 in raw_fBlitFramebuffer (filter=9728, mask=16384, dstY1=, dstX1=, dstY0=0, dstX0=0, srcY1=, srcX1=, srcY0=0, srcX0=0, this=0x7f1e2c383000) at ../../../dist/include/GLContext.h:2385 #5 mozilla::gl::GLContext::BeforeGLReadCall (this=0x7f1e2c383000) at ../../../dist/include/GLContext.h:927 #6 0x7f1e56924bda in mozilla::gl::GLContext::fReadPixels (this=0x7f1e2c383000, x=0, y=0, width=1128, height=500, format=32993, type=33639, pixels=0x7f1e4c50) at ../../../dist/include/GLContext.h:966 #7 0x7f1e57146a43 in mozilla::gl::GLContext::ReadPixelsIntoImageSurface (this=0x7f1e2c383000, aX=, aY=, aWidth=, aHeight=500, aDest= 0x7f1e2de56a10) at /builds/slave/m-cen-lnx64-ntly/build/gfx/gl/GLContext.cpp:1707 #8 0x7f1e5712c6a4 in mozilla::layers::BasicCanvasLayer::UpdateSurface (this=0x7f1e2b674ed0, aDestSurface=0x0) at /builds/slave/m-cen-lnx64-ntly/build/gfx/layers/basic/BasicLayers.cpp:1156 #9 0x7f1e5712c789 in mozilla::layers::BasicCanvasLayer::Paint (this=0x7f1e2b674ed0, aContext=0x7f1e2fe69060) at /builds/slave/m-cen-lnx64-ntly/build/gfx/layers/basic/BasicLayers.cpp:1182 #10 0x7f1e5712f72c in mozilla::layers::BasicLayerManager::PaintLayer (this=0x7f1e2af45f90, aTarget=0x7f1e2fe69060, aLayer=0x7f1e2b674ed0, aCallback= 0x7f1e566acf90 , aCallbackData=0x7fff2cfdb3a0, aReadback=0x0) at /builds/slave/m-cen-lnx64-ntly/build/gfx/layers/basic/BasicLayers.cpp:1900 #11 0x7f1e5712a5c9 in mozilla::layers::BasicLayerManager::EndTransactionInternal (this=0x7f1e2af45f90, aCallback=0x7f1e566acf90 , aCallbackData=0x7fff2cfdb3a0, aFlags=) at /builds/slave/m-cen-lnx64-ntly/build/gfx/layers/basic/BasicLayers.cpp:1610 #12 0x7f1e566ad8ff in PaintInactiveLayer (aContext=, aItem=, aBuilder=) at /builds/slave/m-cen-lnx64-ntly/build/layout/base/FrameLayerBuilder.cpp:1323 #13 mozilla::FrameLayerBuilder::DrawThebesLayer (aLayer=, aContext=0x7f1e2fe69060, aRegionToDraw=, aRegionToInvalidate=, aCallbackData=0x7fff2cfdb3a0) at /builds/slave/m-cen-lnx64-ntly/build/layout/base/FrameLayerBuilder.cpp:2137 #14 0x7f1e57130f59 in mozilla::layers::BasicThebesLayer::PaintBuffer(gfxContext*, nsIntRegion const&, nsIntRegion const&, nsIntRegion const&, bool, void (*)(mozilla::layers::ThebesLayer*, gfxContext*, nsIntRegion const&, nsIntRegion const&, void*), void*) () from /home/jlp/Download/firefox/libxul.so #15 0x7f1e5712aab8 in mozilla::layers::BasicShadowableThebesLayer::PaintBuffer (this=0x7f1e2b3ec000, aContext=, aRegionToDraw=..., aExtendedRegionToDraw=, aRegionToInvalidate=, aDidSelfCopy=false, aCallback=0x7f1e566acf90 , aCallbackData=0x7fff2cfdb3a0) at /builds/slave/m-cen-lnx64-ntly/build/gfx/layers/basic/BasicLayers.cpp:2332 #16 0x7f1e57130643 in mozilla::layers::BasicThebesLayer::PaintThebes (this=0x7f1e2b3ec000, aContext=0x7f1e2ec90340, aCallback=0x7f1e566acf90 , aCallbackData=0x7fff2cfdb3a0, aReadback=) at /builds/slave/m-cen-lnx64-ntly/build/gfx/layers/basic/BasicLayers.cpp:745 #17 0x7f1e5712f3f3 in mozilla::layers::BasicLayerManager::PaintLayer (this=0x7f1e379df790, aTarget=0x7f1e2ec90340, aLayer=0x7f1e2b3ec000, aCallback=0x7f1e566acf90 , aCallbackData=0x7fff2cfdb3a0, aReadback=0x7fff2cfdaaa0) at /builds/slave/m-cen-lnx64-ntly/build/gfx/layers/basic/BasicLayers.cpp:1898 #18 0x7f1e5712f52a in mozilla::layers::BasicLayerManager::PaintLayer (this=0x7f1e379df790, aTarget=0x7f1e2b33a0e0, aLayer=0x7f1e2b734af0, aCallback=0x7f1e566acf90 , aCallbackData=0x7fff2cfdb3a0, aReadback=0x7fff2cfdaaa0) at /builds/slave/m-cen-lnx64-ntly/build/gfx/layers/basic/BasicLayers.cpp:1913 #19 0x7f1e5712f52a in mozilla::layers::BasicLayerManager::PaintLayer (this=0x7f1e379df790, aTarget=0x7f1e2b33a0e0, aLayer=0x7f1e2f0660c0, aCallback=0x7f1e566acf90 , aCallbackData=0x7fff2cfdb3a0, aReadback=0x7fff2cfdafa0) at /builds/slave/m-cen-lnx64-ntly/build/gfx/layers/basic/BasicLayers.cpp:1913 #20 0x7f1e5712a5c9 in mozilla::layers::BasicLayerManager::EndTransactionInternal (this=0x7f1e379df790, aCallback=0x7f1e566acf90 , aCallbackData=0x7fff2cfdb3a0, aFlags=) at /builds/slave/m-cen-lnx64-ntly/build/
[Bug 43375] New: [r600g] Firefox crashes when opening Jax WebGL Demos - Materials page
https://bugs.freedesktop.org/show_bug.cgi?id=43375 Bug #: 43375 Summary: [r600g] Firefox crashes when opening Jax WebGL Demos - Materials page Classification: Unclassified Product: Mesa Version: git Platform: x86-64 (AMD64) OS/Version: Linux (All) Status: NEW Severity: critical Priority: medium Component: Drivers/Gallium/r600 AssignedTo: dri-devel@lists.freedesktop.org ReportedBy: jlp.b...@gmail.com I'm using a nightly version of Firefox with WebGL enabled and when I try to visit the page http://sinisterchipmunk.github.com/materials.html Firefox crashes and says the crash happened in r600g_dri.so This is the backtrace I get when I attached gdb to Firefox: Program received signal SIGSEGV, Segmentation fault. 0x in ?? () (gdb) bt #0 0x in ?? () #1 0x7f8af39ec5ed in st_BlitFramebuffer_resolve (info=0x7fffb307a1f0, mask=16384, ctx=0x7f8b02f02000) at state_tracker/st_cb_blit.c:87 #2 st_BlitFramebuffer (ctx=0x7f8b02f02000, srcX0=0, srcY0=0, srcX1=1128, srcY1=500, dstX0=0, dstY0=0, dstX1=1128, dstY1=500, mask=16384, filter=9728) at state_tracker/st_cb_blit.c:207 #3 0x7f8af38a0ec3 in _mesa_BlitFramebufferEXT (srcX0=0, srcY0=0, srcX1=1128, srcY1=500, dstX0=0, dstY0=0, dstX1=1128, dstY1=500, mask=16384, filter=9728) at main/fbobject.c:2791 #4 0x7f8b2ba27547 in ?? () from /home/jlp/Download/firefox/libxul.so #5 0x7f8b2ba2763a in ?? () from /home/jlp/Download/firefox/libxul.so #6 0x7f8b2c24a7b3 in mozilla::gl::GLContext::ReadPixelsIntoImageSurface(int, int, int, int, gfxImageSurface*) () from /home/jlp/Download/firefox/libxul.so #7 0x7f8b2c23041a in ?? () from /home/jlp/Download/firefox/libxul.so #8 0x7f8b2c2304ff in ?? () from /home/jlp/Download/firefox/libxul.so #9 0x7f8b2c2334ac in mozilla::layers::BasicLayerManager::PaintLayer(gfxContext*, mozilla::layers::Layer*, void (*)(mozilla::layers::ThebesLayer*, gfxContext*, nsIntRegion const&, nsIntRegion const&, void*), void*, mozilla::layers::ReadbackProcessor*) () from /home/jlp/Download/firefox/libxul.so #10 0x7f8b2c22e229 in mozilla::layers::BasicLayerManager::EndTransactionInternal(void (*)(mozilla::layers::ThebesLayer*, gfxContext*, nsIntRegion const&, nsIntRegion const&, void*), void*, mozilla::layers::LayerManager::EndTransactionFlags) () from /home/jlp/Download/firefox/libxul.so #11 0x7f8b2b7affb6 in ?? () from /home/jlp/Download/firefox/libxul.so #12 0x7f8b2c234cd9 in ?? () from /home/jlp/Download/firefox/libxul.so #13 0x7f8b2c22e718 in ?? () from /home/jlp/Download/firefox/libxul.so #14 0x7f8b2c2343c3 in ?? () from /home/jlp/Download/firefox/libxul.so #15 0x7f8b2c233173 in mozilla::layers::BasicLayerManager::PaintLayer(gfxContext*, mozilla::layers::Layer*, void (*)(mozilla::layers::ThebesLayer*, gfxContext*, nsIntRegion const&, nsIntRegion const&, void*), void*, mozilla::layers::ReadbackProcessor*) () from /home/jlp/Download/firefox/libxul.so #16 0x7f8b2c2332aa in mozilla::layers::BasicLayerManager::PaintLayer(gfxContext*, mozilla::layers::Layer*, void (*)(mozilla::layers::ThebesLayer*, gfxContext*, nsIntRegion const&, nsIntRegion const&, void*), void*, mozilla::layers::ReadbackProcessor*) () from /home/jlp/Download/firefox/libxul.so #17 0x7f8b2c2332aa in mozilla::layers::BasicLayerManager::PaintLayer(gfxContext*, mozilla::layers::Layer*, void (*)(mozilla::layers::ThebesLayer*, gfxContext*, nsIntRegion const&, nsIntRegion const&, void*), void*, mozilla::layers::ReadbackProcessor*) () from /home/jlp/Download/firefox/libxul.so #18 0x7f8b2c22e229 in mozilla::layers::BasicLayerManager::EndTransactionInternal(void (*)(mozilla::layers::ThebesLayer*, gfxContext*, nsIntRegion const&, nsIntRegion const&, void*), void*, mozilla::layers::LayerManager::EndTransactionFlags) () from /home/jlp/Download/firefox/libxul.so #19 0x7f8b2c22ebd9 in ?? () from /home/jlp/Download/firefox/libxul.so #20 0x7f8b2b7dbd97 in ?? () from /home/jlp/Download/firefox/libxul.so #21 0x7f8b2b7f4455 in ?? () from /home/jlp/Download/firefox/libxul.so #22 0x7f8b2b805618 in ?? () from /home/jlp/Download/firefox/libxul.so #23 0x7f8b2bb53308 in ?? () from /home/jlp/Download/firefox/libxul.so #24 0x7f8b2bb533cd in ?? () from /home/jlp/Download/firefox/libxul.so #25 0x7f8b2bb55a50 in ?? () from /home/jlp/Download/firefox/libxul.so #26 0x7f8b2bb522aa in ?? () from /home/jlp/Download/firefox/libxul.so #27 0x7f8b2c02f94d in ?? () from /home/jlp/Download/firefox/libxul.so #28 0x7f8b2c02db60 in ?? () from /home/jlp/Download/firefox/libxul.so #29 0x003891938fb0 in _gtk_marshal_BOOLEAN__BOXED (closure=0x7f8b21a4bdf0, return_value=0x7fffb307d270, n_param_values=, param_values=0x7f8af8ed4640, invocation_hint=, marshal_data=) at gtkmarshalers.c:86 #30 0x0035abc109e2 in g_closure_invoke (closure=0x7f8b21a4bdf0
[Bug 43341] CoreBreach: Crash in r600_update_derived_state
https://bugs.freedesktop.org/show_bug.cgi?id=43341 --- Comment #2 from Vadim 2011-11-30 03:05:40 PST --- The shader translation is failed because of too many temps used. They could be optimized away in theory, but this shader also uses indirect addressing, and some optimization passes in mesa are disabled due to this. The shader also contains alternative code that afaics does the same calculations without indirect addressing, you may check if it helps by adding the line: #define WORKAROUND 1 in the beginning of the ./CoreBreach.app/Resources/postprocessing.frag -- 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: [PATCH 2/2] drm/radeon/kms: wrap-up handling of floating connectors and connector unavailability status logging
Am Dienstag, den 29.11.2011, 15:53 -0500 schrieb Alex Deucher: > On Tue, Nov 29, 2011 at 1:06 PM, Thomas Reim wrote: > > Dear Alex, > > > >> On Mon, Nov 28, 2011 at 11:20 AM, Thomas Reim > >> wrote: > >> >Extended DDC probe is now default for RADEON chipsets. In case of > >> >HW bugs (e. g. floating connectors), the affected connectors will > >> >not be used, as a valid EDID header can not be detected. Another > >> >patch removed DDC detection and connector status logging during > >> >device setup. So the user is not informed anymore about HW bugs > >> >leading to connectors being unavailable. > >> >Reintroduce one-time logging of connector unavailability status > >> >when probing (single) connector modes during framebuffer > >> >initialisation. > >> > > >> >For RS690 chipsets DDC detection shall be stopped, if the i2c bus > >> >receives all-0 EDIDs (floating connectors). The introduction of > >> >extended DDC probing prevents the driver from doing this. > >> > Correctly > >> >relocate the related code. > >> > >> Is any of this needed anymore now that we do an extended probe? I > >> think the original null edid patch was just papering over the actual > >> issue which was the need for a full edid header probe. > > > > The difference, at least this is my understanding of Dave's patch, is > > that we completely stop DDC detection for the famous RS690/RS740 chips > > with missing or disabled HDMI add-on cards. We decrease latency, as we > > do not retrieve data from i2c bus anymore. Therefore, I would keep it. > > > > My only concern is that we may disable the i2c bus if there is no > monitor connected which would prevent edid fetching from working in > the future. Does the problematic ddia i2c line produce the same error > in the following cases: > The proposed solution differentiates between i2c bus responds, i. e. a DDC is available, and EDID (header) is valid. > 1. ddia hdmi connector present, no monitor attached DDC is not available: The connector is regarded as being disconnected; function drm_helper_probe_single_connector_modes() records a debug message in the logs, i. e. "HDMI-A-1 is disconnected". The connector will be probed again, when probing single connector modes (using function drm_helper_probe_single_connector_modes() about every second). > 2. ddia hdmi connector present, monitor with faulty edid attached > DDC is available, invalid EDID (header): The connector is regarded as being disconnected; If it's the first time, that this connector has been probed, usually during framebuffer initialisation, dump the faulty EDID to the logs and add an info message, that there is a problem with the monitor: e. g. "HDMI-A-1: probed a monitor, DDC responded but no|invalid EDID". In addition, the debug message of case 1 is logged. Then we have two subcases: a) General The connector will be probed again, when probing single connector modes (using function drm_helper_probe_single_connector_modes() about every second). But there will be only the debug message logged. No info message and no EDID dump. b) EDID is all zero, i. e. not more than 8 non-zero bytes have been received (RS690/RS740 chips only) Floating connector is assumed and an info message is logged: "HDMI-A-1: detected RS690 floating bus bug, stopping ddc detect". Such a connector will not be probed again, reducing latency. I believe that this is rather a theoretical case, as it requires a monitor with an erased EEPROM. > 3. ddia hdmi connector absent a) Correctly implemented HW would handle this in the same way as for case 1. The connector is part of the chipset, i2c bus is correctly terminated and will never be used, but being probed. This is a drawback of implmentations, that use a chipset wich provides more connectors than being used by the implementation. b) Buggy HW The connector's i2c has not been terminated correctly. It can't be used, but is detected. The EDID information will mainly consist of zero bytes, except of some random byte values. DDC is available, invalid EDID (header): The connector is regarded as being disconnected; If it's the first time, that this connector has been probed, usually during framebuffer initialisation, dump the received information of the not available EDID to the logs and add an info message, that there is a problem with the connector: e. g. "HDMI-A-1: probed a monitor, DDC responded but no|invalid EDID". In addition, the debug message of the first case is logged. Then we have two subcases: (1) RS690/RS740 chips Floating connector is assumed and an info message is logged: "HDMI-A-1: detected RS690 floating bus bug, stopping ddc detect". Such a connector will not be probed again, reducing latency. (2) Other chipsets The connector will be probed again, when probing single connector modes (using function drm_helper_probe_single_connector_modes() about every second). But there will be only a de
[Bug 24047] s3tc broken on r600
https://bugs.freedesktop.org/show_bug.cgi?id=24047 --- Comment #25 from Matt McHenry 2011-11-29 17:01:07 PST --- Awesome -- 'emerge -av media-libs/libtxc_dxtn' got SC2 working for me on gentoo. Thanks! -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
Re: linux-next: Tree for Nov 29 (drm)
On 11/28/2011 08:20 PM, Stephen Rothwell wrote: > Hi all, > > Changes since 2028: > > The drm tree lost its build failure but gained another for which I > applied a patch. ERROR: "drm_helper_get_fb_bpp_depth" [drivers/gpu/drm/vmwgfx/vmwgfx.ko] undefined! Full x86_64 randconfig file is attached. -- ~Randy *** Remember to use Documentation/SubmitChecklist when testing your code *** # # Automatically generated file; DO NOT EDIT. # Linux/x86_64 3.2.0-rc3 Kernel Configuration # CONFIG_64BIT=y # CONFIG_X86_32 is not set CONFIG_X86_64=y CONFIG_X86=y CONFIG_INSTRUCTION_DECODER=y CONFIG_OUTPUT_FORMAT="elf64-x86-64" CONFIG_ARCH_DEFCONFIG="arch/x86/configs/x86_64_defconfig" CONFIG_GENERIC_CMOS_UPDATE=y CONFIG_CLOCKSOURCE_WATCHDOG=y CONFIG_GENERIC_CLOCKEVENTS=y CONFIG_ARCH_CLOCKSOURCE_DATA=y CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y CONFIG_LOCKDEP_SUPPORT=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_HAVE_LATENCYTOP_SUPPORT=y CONFIG_MMU=y # CONFIG_ZONE_DMA is not set CONFIG_NEED_DMA_MAP_STATE=y CONFIG_NEED_SG_DMA_LENGTH=y CONFIG_GENERIC_ISA_DMA=y CONFIG_GENERIC_BUG=y CONFIG_GENERIC_BUG_RELATIVE_POINTERS=y CONFIG_GENERIC_HWEIGHT=y CONFIG_GENERIC_GPIO=y CONFIG_ARCH_MAY_HAVE_PC_FDC=y # CONFIG_RWSEM_GENERIC_SPINLOCK is not set CONFIG_RWSEM_XCHGADD_ALGORITHM=y CONFIG_ARCH_HAS_CPU_IDLE_WAIT=y CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_GENERIC_TIME_VSYSCALL=y CONFIG_ARCH_HAS_CPU_RELAX=y CONFIG_ARCH_HAS_DEFAULT_IDLE=y CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y CONFIG_HAVE_SETUP_PER_CPU_AREA=y CONFIG_NEED_PER_CPU_EMBED_FIRST_CHUNK=y CONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK=y CONFIG_ARCH_HIBERNATION_POSSIBLE=y CONFIG_ARCH_SUSPEND_POSSIBLE=y CONFIG_ZONE_DMA32=y CONFIG_ARCH_POPULATES_NODE_MAP=y CONFIG_AUDIT_ARCH=y CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING=y CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y CONFIG_ARCH_HWEIGHT_CFLAGS="-fcall-saved-rdi -fcall-saved-rsi -fcall-saved-rdx -fcall-saved-rcx -fcall-saved-r8 -fcall-saved-r9 -fcall-saved-r10 -fcall-saved-r11" # CONFIG_KTIME_SCALAR is not set CONFIG_ARCH_SUPPORTS_UPROBES=y CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config" CONFIG_HAVE_IRQ_WORK=y CONFIG_IRQ_WORK=y # # General setup # CONFIG_EXPERIMENTAL=y CONFIG_BROKEN_ON_SMP=y CONFIG_INIT_ENV_ARG_LIMIT=32 CONFIG_CROSS_COMPILE="" CONFIG_LOCALVERSION="" # CONFIG_LOCALVERSION_AUTO is not set CONFIG_HAVE_KERNEL_GZIP=y CONFIG_HAVE_KERNEL_BZIP2=y CONFIG_HAVE_KERNEL_LZMA=y CONFIG_HAVE_KERNEL_XZ=y CONFIG_HAVE_KERNEL_LZO=y # CONFIG_KERNEL_GZIP is not set # CONFIG_KERNEL_BZIP2 is not set # CONFIG_KERNEL_LZMA is not set CONFIG_KERNEL_XZ=y # CONFIG_KERNEL_LZO is not set CONFIG_DEFAULT_HOSTNAME="(none)" CONFIG_SYSVIPC=y CONFIG_BSD_PROCESS_ACCT=y CONFIG_BSD_PROCESS_ACCT_V3=y CONFIG_FHANDLE=y CONFIG_HAVE_GENERIC_HARDIRQS=y # # IRQ subsystem # CONFIG_GENERIC_HARDIRQS=y CONFIG_HAVE_SPARSE_IRQ=y CONFIG_GENERIC_IRQ_PROBE=y CONFIG_GENERIC_IRQ_SHOW=y CONFIG_GENERIC_IRQ_CHIP=y CONFIG_IRQ_FORCED_THREADING=y CONFIG_SPARSE_IRQ=y # # RCU Subsystem # CONFIG_TINY_PREEMPT_RCU=y CONFIG_PREEMPT_RCU=y # CONFIG_RCU_TRACE is not set # CONFIG_TREE_RCU_TRACE is not set CONFIG_RCU_BOOST=y CONFIG_RCU_BOOST_PRIO=1 CONFIG_RCU_BOOST_DELAY=500 CONFIG_IKCONFIG=m # CONFIG_IKCONFIG_PROC is not set CONFIG_LOG_BUF_SHIFT=17 CONFIG_HAVE_UNSTABLE_SCHED_CLOCK=y # CONFIG_CGROUPS is not set CONFIG_NAMESPACES=y # CONFIG_UTS_NS is not set # CONFIG_IPC_NS is not set CONFIG_USER_NS=y # CONFIG_PID_NS is not set # CONFIG_SCHED_AUTOGROUP is not set CONFIG_RELAY=y # CONFIG_BLK_DEV_INITRD is not set # CONFIG_CC_OPTIMIZE_FOR_SIZE is not set CONFIG_ANON_INODES=y CONFIG_EXPERT=y CONFIG_KALLSYMS=y CONFIG_KALLSYMS_ALL=y CONFIG_HOTPLUG=y CONFIG_PRINTK=y CONFIG_BUG=y # CONFIG_ELF_CORE is not set # CONFIG_PCSPKR_PLATFORM is not set CONFIG_HAVE_PCSPKR_PLATFORM=y # CONFIG_BASE_FULL is not set # CONFIG_FUTEX is not set CONFIG_EPOLL=y CONFIG_SIGNALFD=y CONFIG_TIMERFD=y CONFIG_EVENTFD=y # CONFIG_SHMEM is not set # CONFIG_AIO is not set # CONFIG_EMBEDDED is not set CONFIG_HAVE_PERF_EVENTS=y CONFIG_PERF_USE_VMALLOC=y # # Kernel Performance Events And Counters # CONFIG_PERF_EVENTS=y # CONFIG_PERF_COUNTERS is not set CONFIG_DEBUG_PERF_USE_VMALLOC=y CONFIG_VM_EVENT_COUNTERS=y # CONFIG_PCI_QUIRKS is not set # CONFIG_COMPAT_BRK is not set # CONFIG_SLAB is not set CONFIG_SLUB=y # CONFIG_SLOB is not set CONFIG_PROFILING=y CONFIG_TRACEPOINTS=y CONFIG_OPROFILE=m CONFIG_OPROFILE_EVENT_MULTIPLEX=y CONFIG_HAVE_OPROFILE=y CONFIG_OPROFILE_NMI_TIMER=y CONFIG_KPROBES=y # CONFIG_JUMP_LABEL is not set CONFIG_UPROBES=y CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS=y CONFIG_KRETPROBES=y CONFIG_HAVE_IOREMAP_PROT=y CONFIG_HAVE_KPROBES=y CONFIG_HAVE_KRETPROBES=y CONFIG_HAVE_OPTPROBES=y CONFIG_HAVE_ARCH_TRACEHOOK=y CONFIG_HAVE_DMA_ATTRS=y CONFIG_HAVE_REGS_AND_STACK_ACCESS_API=y CONFIG_HAVE_DMA_API_DEBUG=y CONFIG_HAVE_HW_BREAKPOINT=y CONFIG_HAVE_MIXED_BREAKPOINTS_REGS=y CONFIG_HAVE_USER_RETURN_NOTIFIER=y CONFIG_HAVE_PERF_EVENTS_NMI=y CONFIG_HAVE_ARCH_JUMP_LABEL=y CONFIG_ARCH_HAVE_NMI_SAFE_CMPXCHG=y CONFIG_HAVE_ALIGNED_STRUCT_PAGE=y CONFIG_HAVE_
Re: 3.2-rc2+: Reported regressions from 3.0 and 3.1
On Tue, Nov 29, 2011 at 01:04:14PM -0500, Konrad Rzeszutek Wilk wrote:
> This patch:
>
> commit d91ee5863b71e8c90eaf6035bff3078a85e2e7b5
> Author: Len Brown
> Date: Fri Apr 1 18:28:35 2011 -0400
>
> cpuidle: replace xen access to x86 pm_idle and default_idle
>
> ..scribble on pm_idle and access default_idle,
>have it simply disable_cpuidle() so acpi_idle will not load and
>architecture default HLT will be used.
>
> idea was to have one call - disable_cpuidle() which would make
> pm_idle not be molested by other code. It disallows cpuidle_idle_call
> and acpi_idle_call to not set pm_idle (which is excellent). But the
what is acpi_idle_call, I can't find it anywhere.
> amd_e400_idle and mwait_idle can still setup pm_idle which we really
> do not want.
This is not the case: rather select_idle_routine()/idle_setup() sets
pm_idle.
[..]
> +bool set_pm_idle_to_default()
> +{
> + if (!pm_idle) {
> + pm_idle = default_idle;
> + return true;
> + }
> + return false;
> +}
I don't understand what you're trying to achieve here? Do you want
default_idle to be always the pm_idle for xen or what is the deal here?
If yes, then simply do:
bool set_pm_idle_to_default(void) // remember to add "void" for no
function args
{
bool ret = !!pm_idle;
pm_idle = default_idle;
return ret;
}
...
> void stop_this_cpu(void *dummy)
> {
> local_irq_disable();
> diff --git a/arch/x86/xen/setup.c b/arch/x86/xen/setup.c
> index 46d6d21..7506181 100644
> --- a/arch/x86/xen/setup.c
> +++ b/arch/x86/xen/setup.c
> @@ -448,6 +448,6 @@ void __init xen_arch_setup(void)
> #endif
> disable_cpuidle();
> boot_option_idle_override = IDLE_HALT;
> -
> + WARN_ON(!set_pm_idle_to_default());
and then do
WARN_ON(set_pm_idle_to_default());
instead of having arbitrary confusing logic. This way you can warn
whether something else set pm_idle already. Or?
Thanks.
--
Regards/Gruss,
Boris.
Advanced Micro Devices GmbH
Einsteinring 24, 85609 Dornach
GM: Alberto Bozzo
Reg: Dornach, Landkreis Muenchen
HRB Nr. 43632 WEEE Registernr: 129 19551
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
