dri-devel November 2012

dri-devel@lists.freedesktop.org

126 participants
797 discussions

[Bug 57350] New: [nouveau, linux-3.7-rc] Broken cursor and kernel log swamped with "PAGE_NOT_PRESENT" errors
by bugzilla-daemon＠freedesktop.org 18 Dec '12

18 Dec '12

https://bugs.freedesktop.org/show_bug.cgi?id=57350 Priority: medium Bug ID: 57350 Assignee: dri-devel(a)lists.freedesktop.org Summary: [nouveau, linux-3.7-rc] Broken cursor and kernel log swamped with "PAGE_NOT_PRESENT" errors Severity: normal Classification: Unclassified OS: All Reporter: bonbons67(a)internet.lu Hardware: Other Status: NEW Version: XOrg CVS Component: DRM/other Product: DRI On a MacBookAir with GeForce 9400M (C79) when X starts after booting (using Enlightenment with compositing) a horizontal bar in the middle of cursor (about 1/3 of cursor height) is transparent instead of showing cursor. At the same time, kernel log is being filled with following error: nouveau E[ PFB][0000:02:00.0] trapped read at $addr on channel $fixed_addr BAR/PFIFO_READ/FB reason: PAGE_NOT_PRESENT $fixed_addr is always the same (0x0000fee0) and $addr changes each time (e.g. 0x000040fe00 then 0x000040fe0c then 0x000040fe14 and continues incrementing) Doing a suspend to ram and resume makes the cursor show correctly and error message not appearing anymore in kernel log. Software versions: linux-3.7-rc5, linux-3.7-rc6 xorg-server-1.13.0 xf86-video-nouveau-1.0.4 libdrm-2.4.40 mesa-9.0 It was also the case with xorg-server-1.12.2, xf86-video-nouveau GIT snapshot from march 2012, libdrm-2.4.33, mesa-8.0.3) but did not happen with this setup with older kernel (linux-3.5.x, not sure anymore about linux-3.6.x) -- You are receiving this mail because: You are the assignee for the bug.

1 8

[Bug 57670] New: segfault with etqw.demo
by bugzilla-daemon＠freedesktop.org 17 Dec '12

17 Dec '12

https://bugs.freedesktop.org/show_bug.cgi?id=57670 Priority: medium Bug ID: 57670 Assignee: dri-devel(a)lists.freedesktop.org Summary: segfault with etqw.demo Severity: normal Classification: Unclassified OS: Linux (All) Reporter: pitamila(a)free.fr Hardware: x86-64 (AMD64) Status: NEW Version: 8.0 Component: Drivers/Gallium/r600 Product: Mesa Hi, I use debian unstable with: Gallium 0.4 on AMD RV770 and libgl1-mesa-glx 8.0.5 and libtxc-dxtn-s2tc0 Version: 0~git20110809-3 When I launch etqw demo I get this backtrace in gdb: Program received signal SIGSEGV, Segmentation fault. 0xblahh in rgb565_image () from /usr/lib/i386-linux-gnu/libtxc_dxtn.so (gdb) bt #0 0xblahhh in rgb565_image () from /usr/lib/i386-linux-gnu/libtxc_dxtn.so #1 0xblahhh in tx_compress_dxtn () from /usr/lib/i386-linux-gnu/libtxc_dxtn.so #2 0xblahhh in ?? () from /usr/lib/i386-linux-gnu/dri/r600_dri.so #3 ... . . . (gdb) I saw on https://github.com/divVerent/s2tc/issues/1 I will try quake4 later to see if it could be the same bug. Does somebody maintain this alternative s3tc lib? I hope this is a usefull place to report this bug thx for support and at your disposal for further testing Pitamila -- You are receiving this mail because: You are the assignee for the bug.

1 2

[Bug 57741] New: [regression] Resolution crippled for HD4870X2
by bugzilla-daemon＠freedesktop.org 15 Dec '12

15 Dec '12

https://bugs.freedesktop.org/show_bug.cgi?id=57741 Priority: medium Bug ID: 57741 Assignee: dri-devel(a)lists.freedesktop.org Summary: [regression] Resolution crippled for HD4870X2 Severity: major Classification: Unclassified OS: Linux (All) Reporter: dev(a)blackshard.net Hardware: x86-64 (AMD64) Status: NEW Version: unspecified Component: DRM/Radeon Product: DRI Created attachment 70837 --> https://bugs.freedesktop.org/attachment.cgi?id=70837&action=edit output of lspci -v Using in-kernel DRM with my Radeon HD4870X2, resolutions above 1024x768 no longer function. Selecting a higher resolution results in a blank, black screen. Sometimes my monitor reports 'frequency out of range', but usually it does not. Xorg otherwise functions as normal - if I blindly pull up a terminal and switch resolution via xrandr, I regain my display. Various combinations of xorg.conf options, including no xorg.conf at all, do not fix the problem. This problem surfaced with v3.7.0-rc5, and is not fixed the version of DRM present in current kernel git (3.7.0-rc7+). The problematic file is drivers/gpu/drm/radeon/atombios_crtc.c - using the version of this file included in 3.7.0-rc4 resolves my problem. Steps to Reproduce: Install kernel version > 3.7.0-rc4 on relevant hardware startx Actual Results: Blank Screen Expected Results: X should display my desktop, rather than shutting off my display. Platform: Linux Xorg 1.8.2* xf86-video-ati 6.14.1* libdrm 2.4.26* mesalib 7.11.1* * Version of these packages does not appear relevant to this bug Additional Information: See attached lscpi for my hardware dmesg and Xorg.0.log have not been attached, as their output is identical between working and non-working versions of this file. I will happily provide any additional information or testing that would help resolve this bug. -- You are receiving this mail because: You are the assignee for the bug.

1 2

[PATCH 00/17] DRM/KMS/EDID: Various EDID handling related fixes.
by Egbert Eich 14 Dec '12

14 Dec '12

This patchset fixes issues about EDID and EDID Extension block handling: 1. We currently don't return any EDID information if there are issues with reading extension blocks. There are devices however which announce to have EDID extension blocks although these are not readable. If reading extension blocks fails we should at least return the base block (with a corrected extension blcok flag). 2. There are broken legacy DDC devices around which wrongly announce to have ED extension blocks. Since the segment address is ignored on these devices we will get a base block returned for any uneven block number. Detect this situation and abort reading further blocks. 3. When we read EDID extension blocks but fail to validate them we discard them and correct the EDID block count in the base block. There may however be a block map in the first extesion block which we should also fix. Similarly, don't fail if we cannot allocate enough contiguous memory for all EDID extension blocks: rather than failing completely, it is better to return at least the base block and if possible all extension blocks for which there is memory. 4. EDID 'firmware'-files: * Treat the, the same way as EDIDs read from DDC channels: - use the same routines to validate and fix them. - feed them when reading * Support different EDID files for different connectors. 5. Consolidate EDID error handling: Store information about the error status of the last DDC read in the drm_connector structure. This data can be used: - in the driver to detect certain issues with DDC read out. - provide a finer control over repeated error logging - instead of disabling EDID error logging entirely if an EDID error has been detected, only disable it for those errors which have been seen also on the previous DDC read cycle. 6. Move EDID-related functions to drm_edid.h The handling of EDID related DRM functions seemed to be a bit arbitrary: although drm_edid.h had been created, new functions were often added to drm_crtc.h Egbert Eich (17): DRM/KMS/EDID: Mask out Segment Bits when calculating Offset. DRM/KMS/EDID: 0x7e -> EDID_EXTENSION_FLAG_OFFSET DRM/KMS/EDID: Return Base EDID block if reading EEDID Blocks fails. DRM/KMS/EDID: Test EDDC if EDID announces more than one Extension Block. DRM/KMS/EDID: Fix up EEDID Map Blocks if Extension block count has changed. DRM/exynos: Fix Memory Leak: free EDID blcok returned by drm_get_edid(). DRM/KMS/EDID: Move drm_edid_load.o to drm.ko DRM/KMS/EDID: Use Extension Block Fixup Code also for 'firmware' EDID. DRM/KMS/EDID: Feed 'firmware' supplied EDID blocks whenever the EDID is read. DRM/KMS/EDID: Cache EDID blobs with extensions. DRM/KMS/EDID: Avoid failing on krealloc on EDID blocks. DRM/KMS/EDID: Consolidate EDID Error Handling. DRM/KMS/EDID: Allow for multiple Connectors when specifying 'firmware'-EDID Files. DRM/KMS/ast: Include drm_edid.h in file using drm_get_edid(). DRM/KMS/gma500: Include drm_edid.h in file using drm_get_edid(). DRM/KMS/mgag200: Include drm_edid.h in file using drm_get_edid(). DRM/KMS/EDID: Move EDID related Functions to drm_edid.h. drivers/gpu/drm/Makefile | 2 +- drivers/gpu/drm/ast/ast_mode.c | 1 + drivers/gpu/drm/drm_crtc.c | 1 + drivers/gpu/drm/drm_crtc_helper.c | 6 +- drivers/gpu/drm/drm_edid.c | 303 ++++++++++++++++++++++++---- drivers/gpu/drm/drm_edid_load.c | 115 +++++------ drivers/gpu/drm/exynos/exynos_hdmi.c | 1 + drivers/gpu/drm/gma500/cdv_intel_dp.c | 1 + drivers/gpu/drm/gma500/oaktrail_lvds.c | 1 + drivers/gpu/drm/gma500/psb_intel_modes.c | 1 + drivers/gpu/drm/mgag200/mgag200_mode.c | 1 + drivers/gpu/drm/radeon/radeon_connectors.c | 2 +- include/drm/drm_crtc.h | 13 +- include/drm/drm_edid.h | 24 ++- 14 files changed, 348 insertions(+), 124 deletions(-) -- 1.7.7

7 54

[PATCH 0/3] drm/exynos: add runtime pm support for hdmi and mixer.
by Rahul Sharma 14 Dec '12

14 Dec '12

This patch set adds support for runtime power management for hdmi and mixer devices. Its also adds support for hdmiphy power control. It has been tested for hot plugin-plugout and dpms scenarios. Based on exynos-drm-next branch of http://git.kernel.org/?p=linux/kernel/git/daeinki/drm-exynos.git Rahul Sharma (3): drm/exynos: added runtime pm support for hdmi drm/exynos: add runtime pm support for mixer drm/exynos: add support for hdmiphy power control for exynos5 drivers/gpu/drm/exynos/exynos_hdmi.c | 81 +++++++++++++++++++++++++++++--- drivers/gpu/drm/exynos/exynos_mixer.c | 65 +++++++++++++++++++++++--- drivers/gpu/drm/exynos/regs-hdmi.h | 5 ++ 3 files changed, 136 insertions(+), 15 deletions(-)

2 4

[Bug 50208] New: X does not start on Linux kernel 3.2.0-24, works on 3.0.0-19
by bugzilla-daemon＠freedesktop.org 13 Dec '12

13 Dec '12

https://bugs.freedesktop.org/show_bug.cgi?id=50208 Bug #: 50208 Summary: X does not start on Linux kernel 3.2.0-24, works on 3.0.0-19 Classification: Unclassified Product: DRI Version: XOrg CVS Platform: x86 (IA32) OS/Version: Linux (All) Status: NEW Severity: major Priority: medium Component: DRM/Radeon AssignedTo: dri-devel(a)lists.freedesktop.org ReportedBy: freedesktop(a)teknico.net Created attachment 61952 --> https://bugs.freedesktop.org/attachment.cgi?id=61952 Archive with "Xorg.log" and "dmesg" logs for both versions, and "lspci -v" and "glxinfo" for 3.0.0-19 Operating system: Ubuntu 12.04 Linux kernel: 3.2.0-24-generic-pae libdrm-radeon1: 2.4.32-1ubuntu1 xserver-xorg: 1:7.6+12ubuntu1 xserver-xorg-video-radeon: 1:6.14.99~git20111219.aacbd629-0ubuntu2 Notebook: Dell Studio XPS 1640 Graphics card: AMD/ATI Mobility Radeon HD3670 RAM memory size: 4GB X does not start: after some flicker, the screen remains black. X starts correctly, with OpenGL and DRI, with kernel 3.0.0-19-generic-pae. Attached archive with "Xorg.log" and "dmesg" logs for both versions, and "lspci -v" and "glxinfo" for 3.0.0-19. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.

1 4

[RFC] improve memory placement for radeon
by j.glisse＠gmail.com 11 Dec '12

11 Dec '12

So as a followup is 2 patch. The first one just stop trying to move object at each cs ioctl i believe it could be included in 3.7 as it improve performances (especialy with vram change from userspace). The second one implement a vram eviction policy. It's a simple one, buffer used for write operation are more important than buffer used for read operation. Buffer get evicted from vram only if they haven't been use in the last 50ms (so in the last few frames) and only if there is buffer that have been recently use and that could be move into vram. This is mostly were i believe discussion should be, what kind of heuristic would work better than tat. So without first patch and with mesa master xonotic high is at 17fps, with first patch it goes to 40fps, with second patch it goes to 48fps. Cheers, Jerome

4 6

[Bug 32131] New: small corruption around opengl window while using compize cube effect.
by bugzilla-daemon＠freedesktop.org 11 Dec '12

11 Dec '12

https://bugs.freedesktop.org/show_bug.cgi?id=32131 Summary: small corruption around opengl window while using compize cube effect. Product: Mesa Version: unspecified Platform: Other OS/Version: All Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/r300 AssignedTo: dri-devel(a)lists.freedesktop.org ReportedBy: roman.elshin(a)gmail.com 2.6.36.1 + drm/radeon/kms: MC vram map needs to be >= pci aperture size patch) + current r300g + current xf86-video-ati. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.

1 9

[Bug 55416] New: [R600g] Torchlight gives GPU lockup
by bugzilla-daemon＠freedesktop.org 11 Dec '12

11 Dec '12

https://bugs.freedesktop.org/show_bug.cgi?id=55416 Priority: medium Bug ID: 55416 Assignee: dri-devel(a)lists.freedesktop.org Summary: [R600g] Torchlight gives GPU lockup Severity: normal Classification: Unclassified OS: Linux (All) Reporter: lordheavym(a)gmail.com Hardware: x86-64 (AMD64) Status: NEW Version: git Component: Drivers/Gallium/r600 Product: Mesa When i try to play the game (after character selection),i've got several GPU lockup until i kill the game: dmesg: --8<-- [ 900.867633] radeon 0000:01:00.0: GPU lockup CP stall for more than 10000msec [ 900.867645] radeon 0000:01:00.0: GPU lockup (waiting for 0x0000000000012fb4 last fence id 0x0000000000012faa) [ 900.868726] radeon 0000:01:00.0: GPU softreset [ 900.868732] radeon 0000:01:00.0: GRBM_STATUS=0xE7730828 [ 900.868737] radeon 0000:01:00.0: GRBM_STATUS_SE0=0xFC000001 [ 900.868743] radeon 0000:01:00.0: GRBM_STATUS_SE1=0xFC000001 [ 900.868748] radeon 0000:01:00.0: SRBM_STATUS=0x200000C0 [ 900.868756] radeon 0000:01:00.0: GRBM_SOFT_RESET=0x00007F6B [ 900.868863] radeon 0000:01:00.0: GRBM_STATUS=0x00003828 [ 900.868868] radeon 0000:01:00.0: GRBM_STATUS_SE0=0x00000007 [ 900.868873] radeon 0000:01:00.0: GRBM_STATUS_SE1=0x00000007 [ 900.868878] radeon 0000:01:00.0: SRBM_STATUS=0x200000C0 [ 900.869884] radeon 0000:01:00.0: GPU reset succeed [ 900.878264] [drm] PCIE GART of 512M enabled (table at 0x0000000000040000). [ 900.878371] radeon 0000:01:00.0: WB enabled [ 900.878379] radeon 0000:01:00.0: fence driver on ring 0 use gpu addr 0x0000000040000c00 and cpu addr 0xffff8802218a5c00 [ 900.894717] [drm] ring test on 0 succeeded in 2 usecs [ 900.894770] [drm] ib test on ring 0 succeeded in 0 usecs [ 911.968025] radeon 0000:01:00.0: GPU lockup CP stall for more than 10000msec [ 911.968038] radeon 0000:01:00.0: GPU lockup (waiting for 0x0000000000013018 last fence id 0x0000000000013014) [ 911.969149] radeon 0000:01:00.0: GPU softreset [ 911.969155] radeon 0000:01:00.0: GRBM_STATUS=0xE7730828 [ 911.969161] radeon 0000:01:00.0: GRBM_STATUS_SE0=0xFC000001 [ 911.969167] radeon 0000:01:00.0: GRBM_STATUS_SE1=0xFC000001 [ 911.969172] radeon 0000:01:00.0: SRBM_STATUS=0x200000C0 [ 911.969183] radeon 0000:01:00.0: GRBM_SOFT_RESET=0x00007F6B [ 911.969291] radeon 0000:01:00.0: GRBM_STATUS=0x00003828 [ 911.969297] radeon 0000:01:00.0: GRBM_STATUS_SE0=0x00000007 [ 911.969302] radeon 0000:01:00.0: GRBM_STATUS_SE1=0x00000007 [ 911.969307] radeon 0000:01:00.0: SRBM_STATUS=0x200000C0 [ 911.970313] radeon 0000:01:00.0: GPU reset succeed [ 911.978920] [drm] PCIE GART of 512M enabled (table at 0x0000000000040000). [ 911.979030] radeon 0000:01:00.0: WB enabled [ 911.979039] radeon 0000:01:00.0: fence driver on ring 0 use gpu addr 0x0000000040000c00 and cpu addr 0xffff8802218a5c00 [ 911.995378] [drm] ring test on 0 succeeded in 2 usecs [ 911.995432] [drm] ib test on ring 0 succeeded in 0 usecs -->8-- uname -a: Linux archMain 3.5.4-1-ARCH #1 SMP PREEMPT Sat Sep 15 08:12:04 CEST 2012 x86_64 GNU/Linux glxinfo: OpenGL vendor string: X.Org OpenGL renderer string: Gallium 0.4 on AMD BARTS OpenGL version string: 2.1 Mesa 9.1-devel (git-124b214) OpenGL shading language version string: 1.30 libdrm: local/libdrm 2.4.39-1 I've got similar lockup with kernel 3.6rc6 -- You are receiving this mail because: You are the assignee for the bug.

1 10

[PATCH] drm/nouveau: fix takedown in move_notify
by Maarten Lankhorst 10 Dec '12

10 Dec '12

move_notify is called by ttm after the the object is idle and about to be destroyed. Clean up the vm list properly in that case. This is not a problem right now, since the list should already be empty, but if it wasn't empty, vm_put was not called which leads to random corruption later. With this fix, nouveau_gem_object_close can be safely changed to a noop, forcing the vm bindings to be removed when the original object is. This is not done in this patch since it may lead to the object staying mapped in the vm space until the gem object refcount drops to 0. This shouldn't be a big issue however. If we choose to do so does allow us to use ttm's delayed destruction mechanism to unmap vm after object is idle, resulting in ioread32 no longer taking up 30% of cpu in Team Fortress 2 if I don't do the vma unmap in nouveau_gem_object_close. Signed-off-by: Maarten Lankhorst <maarten.lankhorst(a)canonical.com> --- diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c b/drivers/gpu/drm/nouveau/nouveau_bo.c index 35ac57f..e8a47f0 100644 --- a/drivers/gpu/drm/nouveau/nouveau_bo.c +++ b/drivers/gpu/drm/nouveau/nouveau_bo.c @@ -1139,12 +1139,22 @@ nouveau_bo_move_ntfy(struct ttm_buffer_object *bo, struct ttm_mem_reg *new_mem) if (bo->destroy != nouveau_bo_del_ttm) return; + if (!new_mem) { + while (!list_empty(&nvbo->vma_list)) { + vma = list_first_entry(&nvbo->vma_list, struct nouveau_vma, head); + + nouveau_vm_unmap(vma); + nouveau_vm_put(vma); + list_del(&vma->head); + } + return; + } + list_for_each_entry(vma, &nvbo->vma_list, head) { - if (new_mem && new_mem->mem_type == TTM_PL_VRAM) { + if (new_mem->mem_type == TTM_PL_VRAM) { nouveau_vm_map(vma, new_mem->mm_node); - } else - if (new_mem && new_mem->mem_type == TTM_PL_TT && - nvbo->page_shift == vma->vm->vmm->spg_shift) { + } else if (new_mem->mem_type == TTM_PL_TT && + nvbo->page_shift == vma->vm->vmm->spg_shift) { if (((struct nouveau_mem *)new_mem->mm_node)->sg) nouveau_vm_map_sg_table(vma, 0, new_mem-> num_pages << PAGE_SHIFT, @@ -1153,8 +1163,6 @@ nouveau_bo_move_ntfy(struct ttm_buffer_object *bo, struct ttm_mem_reg *new_mem) nouveau_vm_map_sg(vma, 0, new_mem-> num_pages << PAGE_SHIFT, new_mem->mm_node); - } else { - nouveau_vm_unmap(vma); } } }

2 3

← Newer
1
...
40
41
42
43
44
45
46
...
80
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel November 2012