dri-devel October 2011

dri-devel@lists.freedesktop.org

82 participants
530 discussions

The controlD device
by Thomas Hellstrom 21 Oct '11

21 Oct '11

Dave, What is the drm control device nodes really used for? On my fc14 system it seems like it has world rw privileges, and full access to all modesetting ioctls. Is that the intention? /Thomas

2 5

Re: Question about Radeon 5450
by Boszormenyi Zoltan 21 Oct '11

21 Oct '11

Hi, today I upgraded from Radeon X700 to HD6570. It works very well on my Fedora 15/x86_64. Thank you very much to everyone working on the new Radeon driver generations. Best regards, Zoltán Böszörményi 2010-02-06 19:55 keltezéssel, Corbin Simpson írta: > > Not yet. Work is in progress. > > Posting from a mobile, pardon my terseness. ~ C. > >> On Feb 6, 2010 10:27 AM, "Zoltan Boszormenyi" <zboszor(a)dunaweb.hu >> <mailto:zboszor@dunaweb.hu>> wrote: >> >> Hi, >> >> I would like to ask whether current Mesa and xf86-drv-ati >> supports the new low cost, passively cooled Radeon 5450? >> >> Thanks in advance, >> Zoltán Böszörményi >> >> >> ------------------------------------------------------------------------------ >> The Planet: dedicated and managed hosting, cloud storage, colocation >> Stay online with enterprise data centers and the best network in the business >> Choose flexible plans and management services without long-term contracts >> Personal 24x7 support from experience hosting pros just a phone call away. >> http://p.sf.net/sfu/theplanet-com >> -- >> _______________________________________________ >> Dri-devel mailing list >> Dri-devel(a)lists.sourceforge.net <mailto:Dri-devel@lists.sourceforge.net> >> https://lists.sourceforge.net/lists/listinfo/dri-devel ------------------------------------------------------------------------------ The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Cisco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev -- _______________________________________________ Dri-devel mailing list Dri-devel(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel

1 0

[Bug 42050] New: Maximizing glxgears -> texture_desc_init: The buffer is not large enough
by bugzilla-daemon＠freedesktop.org 20 Oct '11

20 Oct '11

https://bugs.freedesktop.org/show_bug.cgi?id=42050 Bug #: 42050 Summary: Maximizing glxgears -> texture_desc_init: The buffer is not large enough Classification: Unclassified Product: Mesa Version: git Platform: x86 (IA32) OS/Version: Linux (All) Status: NEW Severity: minor Priority: medium Component: Drivers/Gallium/r300 AssignedTo: dri-devel(a)lists.freedesktop.org ReportedBy: curaga(a)operamail.com Mobility X1600 / 128mb r300g git (2.1 Mesa 7.12-devel (git-6235846) / Gallium 0.4 on ATI RV530) Linux 3.0.3 When I maximize glxgears, I get the following errors: r300: texture_desc_init: The buffer is not large enough. Got: 4972544, Need: 4976640, Info: r300: texture_desc_init: Macro: NO, Micro: YES, Pitch: 1440, Dim: 1438x863x1, LastLevel: 0, Size: 4976640, Format: x8z24_unorm r300: ERROR: Cannot set texture properties. When maximized, it also stutters about every second, which may or may not be related. This may also be a kernel bug, if so, please reassign. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.

1 1

Re: Re:[mipsel+rs780e]Occasionally "GPU lockup" after resuming from suspend.
by Chen Jie 20 Oct '11

20 Oct '11

Hi, 在 2011年10月17日下午2:34， <chenhc(a)lemote.com>写道： > If I start X but switch to the console, then do suspend & resume, "GPU > reset" hardly happen. but there is a new problem that the IRQ of radeon > card is disabled. Maybe "GPU reset" has something to do with "IRQ > disabled"? > > I have tried "irqpoll", it doesn't fix this problem. > > [ 571.914062] irq 6: nobody cared (try booting with the "irqpoll" option) > [ 571.914062] Call Trace: > [ 571.914062] [<ffffffff806f3248>] dump_stack+0x8/0x34 > [ 571.914062] [<ffffffff8027e1e4>] __report_bad_irq.clone.6+0x44/0x15c > [ 571.914062] [<ffffffff8027e584>] note_interrupt+0x204/0x2a0 > [ 571.914062] [<ffffffff8027c7cc>] handle_irq_event_percpu+0x19c/0x1f8 > [ 571.914062] [<ffffffff8027c890>] handle_irq_event+0x68/0xa8 > [ 571.914062] [<ffffffff8027f038>] handle_level_irq+0xd8/0x13c > [ 571.914062] [<ffffffff8027bec8>] generic_handle_irq+0x48/0x58 > [ 571.914062] [<ffffffff80204574>] do_IRQ+0x18/0x24 > [ 571.914062] [<ffffffff8020152c>] mach_irq_dispatch+0xf0/0x194 > [ 571.914062] [<ffffffff80202a40>] ret_from_irq+0x0/0x4 > [ 571.914062] > [ 571.914062] handlers: > [ 571.914062] [<ffffffff8053bba8>] radeon_driver_irq_handler_kms > > P.S.: use the latest kernel from git, and irq6 is not shared by other > devices. > > Does fence_wait depends on GPU's interrupt? If yes, then can I say "GPU lockup" is caused by unexpected disabling of GPU's irq? > > Hi Alex, Michel > > > > 2011/10/5 Alex Deucher <alexdeucher(a)gmail.com> > > > >> 2011/10/5 Michel D鋘zer <michel(a)daenzer.net>: > >> > On Don, 2011-09-29 at 17:17 +0800, Chen Jie wrote: > >> >> > >> >> We got occasionally "GPU lockup" after resuming from suspend(on > >> mipsel > >> >> platform with a mips64 compatible CPU and rs780e, the kernel is > >> >> 3.1.0-rc8 64bit). Related kernel message: > >> > > >> > [...] > >> > > >> >> [ 177.085937] radeon 0000:01:05.0: GPU lockup CP stall for more than > >> >> 10019msec > >> >> [ 177.089843] ------------[ cut here ]------------ > >> >> [ 177.097656] WARNING: at drivers/gpu/drm/radeon/radeon_fence.c:267 > >> >> radeon_fence_wait+0x25c/0x33c() > >> >> [ 177.105468] GPU lockup (waiting for 0x000013C3 last fence id > >> >> 0x000013AD) > >> >> [ 177.113281] Modules linked in: psmouse serio_raw > >> >> [ 177.117187] Call Trace: > >> >> [ 177.121093] [<ffffffff806f3e7c>] dump_stack+0x8/0x34 > >> >> [ 177.125000] [<ffffffff8022e4f4>] warn_slowpath_common+0x78/0xa0 > >> >> [ 177.132812] [<ffffffff8022e5b8>] warn_slowpath_fmt+0x38/0x44 > >> >> [ 177.136718] [<ffffffff80522ed8>] radeon_fence_wait+0x25c/0x33c > >> >> [ 177.144531] [<ffffffff804e9e70>] ttm_bo_wait+0x108/0x220 > >> >> [ 177.148437] [<ffffffff8053b478>] radeon_gem_wait_idle_ioctl > >> >> +0x80/0x114 > >> >> [ 177.156250] [<ffffffff804d2fe8>] drm_ioctl+0x2e4/0x3fc > >> >> [ 177.160156] [<ffffffff805a1820>] radeon_kms_compat_ioctl+0x28/0x38 > >> >> [ 177.167968] [<ffffffff80311a04>] compat_sys_ioctl+0x120/0x35c > >> >> [ 177.171875] [<ffffffff80211d18>] handle_sys+0x118/0x138 > >> >> [ 177.179687] ---[ end trace 92f63d998efe4c6d ]--- > >> >> [ 177.187500] radeon 0000:01:05.0: GPU softreset > >> >> [ 177.191406] radeon 0000:01:05.0: R_008010_GRBM_STATUS=0xF57C2030 > >> >> [ 177.195312] radeon 0000:01:05.0: > >> R_008014_GRBM_STATUS2=0x00111103 > >> >> [ 177.203125] radeon 0000:01:05.0: R_000E50_SRBM_STATUS=0x20023040 > >> >> [ 177.363281] radeon 0000:01:05.0: Wait for MC idle timedout ! > >> > > >> > [...] > >> > > >> >> What may cause a "GPU lockup"? > >> > > >> > Lots of things... The most common cause is an incorrect command stream > >> > sent to the GPU by userspace or the kernel. > >> > > >> >> Why reset didn't work? > >> > > >> > Might be related to 'Wait for MC idle timedout !', but I don't know > >> > offhand what could be up with that. > >> > > >> > > >> >> BTW, one question: > >> >> I got 'RADEON_IS_PCI | RADEON_IS_IGP' in rdev->flags, which causes > >> >> need_dma32 was set. > >> >> Is it correct? (drivers/char/agp is not available on mips, could that > >> >> be the reason?) > >> > > >> > Not sure, Alex? > >> > >> You don't AGP for newer IGP cards (rs4xx+). It gets set by default if > >> the card is not AGP or PCIE. That should be changed as only the > >> legacy r1xx PCI GART block has that limitation. I'll send a patch out > >> shortly. > >> > >> Got it, thanks for the reply. > > >

2 1

[Bug 41846] New: hitting software fallbacks when using xorg state tracker
by bugzilla-daemon＠freedesktop.org 19 Oct '11

19 Oct '11

https://bugs.freedesktop.org/show_bug.cgi?id=41846 Bug #: 41846 Summary: hitting software fallbacks when using xorg state tracker Classification: Unclassified Product: Mesa Version: git Platform: Other OS/Version: All Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/r300 AssignedTo: dri-devel(a)lists.freedesktop.org ReportedBy: martinstolpe(a)gmail.com Hello, I'm using the xorg state tracker driver r300_drv.so and some functions seem to not accelerated. Here is the perf output when moving a window: - 68,56% X libc-2.14.so [.] memcpy - memcpy - 99,70% fbCopyWindowProc miCopyRegion fbCopyWindow ExaCheckCopyWindow exaCopyWindow damageCopyWindow miSpriteCopyWindow compCopyWindow miMoveWindow compMoveWindow ConfigureWindow ProcConfigureWindow Dispatch main __libc_start_main - 17,95% X libfb.so [.] fbBlt - fbBlt + 97,07% fbCopyWindowProc - 2,93% fbBltStip fbPutZImage ExaCheckPutImage exaPutImage damagePutImage ProcPutImage Dispatch main __libc_start_main and here is the output when scrolling in notepad++ running in wine: - 63,01% X libpixman-1.so.0.22.2 [.] pixman_blt_sse2.part.10 - pixman_blt_sse2.part.10 - 99,98% sse2_blt pixman_blt fbCopyNtoN miCopyRegion miDoCopy fbCopyArea ExaCheckCopyNtoN miCopyRegion miDoCopy exaCopyArea - damageCopyArea - 99,99% ProcCopyArea Dispatch main __libc_start_main - 23,10% X libc-2.14.so [.] memcpy - memcpy - 98,41% fbCopyNtoN miCopyRegion miDoCopy fbCopyArea ExaCheckCopyNtoN miCopyRegion miDoCopy exaCopyArea damageCopyArea ProcCopyArea Dispatch main __libc_start_main - 1,49% ExaUploadToScreen - exaHWCopyNtoN - 98,06% exaComposite damageComposite ProcRenderComposite Dispatch main __libc_start_main - 1,94% exaCopyNtoN miCopyRegion miDoCopy exaCopyArea damageCopyArea ProcShmPutImage ProcShmDispatch Dispatch main __libc_start_main -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.

1 7

vmwgfx + libkms on VMware hardware 8
by Aani kitita 19 Oct '11

19 Oct '11

Hi, I 'm trying to test KMS functionality of latest vmwgfx module. I tried the code from http://permalink.gmane.org/gmane.comp.video.dri.devel/42908 as a simple test case, but all I get is a black screen instead of white as would be expected. Setup: VMWare Workstation 8.0.0 Host & Guest distro: kubuntu oneiric (11.10) libdrm: 2.4.26+git20111003.c82ef03e from xorg-edgers ppa vmwgfx module: latest git version from freedesktop.org dmesg output (vmwgfx initialization / capabilities) [ 3.696893] vmwgfx 0000:00:0f.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16 [ 3.697188] [vmwgfx] Capabilities: [ 3.697191] [vmwgfx] Rect copy. [ 3.697193] [vmwgfx] Cursor. [ 3.697196] [vmwgfx] Cursor bypass. [ 3.697198] [vmwgfx] Cursor bypass 2. [ 3.697200] [vmwgfx] 8bit emulation. [ 3.697202] [vmwgfx] Alpha cursor. [ 3.697204] [vmwgfx] 3D. [ 3.697206] [vmwgfx] Extended Fifo. [ 3.697208] [vmwgfx] Multimon. [ 3.697210] [vmwgfx] Pitchlock. [ 3.697212] [vmwgfx] Irq mask. [ 3.697214] [vmwgfx] Display Topology. [ 3.697216] [vmwgfx] GMR. [ 3.697218] [vmwgfx] Traces. [ 3.697220] [vmwgfx] GMR2. [ 3.697222] [vmwgfx] Screen Object 2. [ 3.697224] [vmwgfx] Max GMR ids is 64 [ 3.697226] [vmwgfx] Max GMR descriptors is 4096 [ 3.697229] [vmwgfx] Max number of GMR pages is 196608 [ 3.697231] [vmwgfx] Max dedicated hypervisor surface memory is 786432 kiB [ 3.697234] [vmwgfx] VRAM at 0xd0000000 size is 131072 kiB [ 3.697236] [vmwgfx] MMIO at 0xc8800000 size is 2048 kiB [ 3.697239] [vmwgfx] global init. [ 3.700262] [vmwgfx] width 640 [ 3.700276] [vmwgfx] height 480 [ 3.700289] [vmwgfx] bpp 32 [ 3.704308] [vmwgfx] Fifo max 0x00200000 min 0x00001000 cap 0x0000077f [ 3.728297] [vmwgfx] Screen objects system initialized [ 3.728303] [vmwgfx] Detected device 3D availability. [ 3.728401] [vmwgfx] Initialized vmwgfx 2.1.0 20110927 for 0000:00:0f.0 on minor 0 I 'm trying with ./modeset -s 4@6:1024x768 Running the above under strace shows that all underlying ioctls succeed, so it looks like this code should work. It looks like the update command is not sent to the card because if I add the parameter svga.forceTraces = "TRUE" to the .vmx file of the VM, I see a white rectangle as expected (the mode still doesn't look right though, it looks like the size of the rectangle is 640x480 instead of 1024x768) I also get in the vmware.log when I run the above: 2011-10-18T19:21:30.849+02:00| vcpu-0| I120: MKS enabling SVGA 2011-10-18T19:21:30.909+02:00| vcpu-0| I120: Guest display topology changed: numDisplays 0 2011-10-18T19:21:30.910+02:00| vcpu-0| I120: Guest display topology changed: numDisplays 0 2011-10-18T19:21:30.934+02:00| vcpu-0| I120: Guest display topology changed: numDisplays 0 2011-10-18T19:21:30.935+02:00| vcpu-0| I120: Guest display topology changed: numDisplays 0 2011-10-18T19:21:30.957+02:00| vcpu-0| I120: Guest display topology changed: numDisplays 0 2011-10-18T19:21:30.974+02:00| mks| W110: MKS-EmuSVGA: Unsupported GMR image format 0x00002020 2011-10-18T19:21:38.837+02:00| vcpu-0| I120: Guest display topology changed: numDisplays 0 2011-10-18T19:21:38.940+02:00| mks| I120: MKS disabling SVGA Any ideas on what may be going wrong? VMWare would make a pretty cool platform to experiment with several features of the modern open graphics stack like wayland, plymouth, flickerless boot, integrated kernel debugger, multiseat etc etc. I 'll be happy to provide more debugging information on this problem as needed. Thanks in advance, Aani

2 2

[git pull] drm fixes
by Dave Airlie 19 Oct '11

19 Oct '11

Hi Linus, one quite urgent fixes for AMD Llano APU users, one earlier patch uncovered a bug in the atom parsing code that resulted in semi-random memory corruption when executing load detection tables. I spent a few days scratching my head and Alex figured it out once I got enough debug logs. We've also added bounds checking so it can't happen again. The other fixes are radeon modesetting fixes and a ttm fix. Dave. The following changes since commit 899e3ee404961a90b828ad527573aaaac39f0ab1: Linux 3.1-rc10 (2011-10-17 21:06:23 -0700) are available in the git repository at: git://people.freedesktop.org/~/linux drm-fixes Alex Deucher (4): drm/radeon/kms/DCE4.1: fix dig encoder to transmitter mapping drm/radeon/kms/DCE4.1: ss is not supported on the internal pplls drm/radeon/kms/DCE4.1: fix Select_CrtcSource EncodeMode setting for DP bridges (v2) drm/radeon/kms/atom: fix handling of FB scratch indices Thomas Hellstrom (1): ttm: Fix error-path using an uninitialized value drivers/gpu/drm/radeon/atom.c | 15 +++++++++++++-- drivers/gpu/drm/radeon/atom.h | 1 + drivers/gpu/drm/radeon/atombios_crtc.c | 2 +- drivers/gpu/drm/radeon/radeon_encoders.c | 25 ++++++++++++++++++++----- drivers/gpu/drm/ttm/ttm_bo_util.c | 2 +- 5 files changed, 36 insertions(+), 9 deletions(-)

1 0

[PATCH] drm/radeon/kms/atom: check fb scratch array access
by alexdeucher＠gmail.com 19 Oct '11

19 Oct '11

From: Alex Deucher <alexander.deucher(a)amd.com> Check access to the fb scratch array to avoid accessing memory past the end of the array. Signed-off-by: Alex Deucher <alexander.deucher(a)amd.com> Cc: stable(a)kernel.org --- drivers/gpu/drm/radeon/atom.c | 15 +++++++++++++-- drivers/gpu/drm/radeon/atom.h | 1 + 2 files changed, 14 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/radeon/atom.c b/drivers/gpu/drm/radeon/atom.c index e88c644..f69b852 100644 --- a/drivers/gpu/drm/radeon/atom.c +++ b/drivers/gpu/drm/radeon/atom.c @@ -277,7 +277,12 @@ static uint32_t atom_get_src_int(atom_exec_context *ctx, uint8_t attr, case ATOM_ARG_FB: idx = U8(*ptr); (*ptr)++; - val = gctx->scratch[((gctx->fb_base + idx) / 4)]; + if ((gctx->fb_base + idx) > gctx->scratch_size_bytes) { + DRM_DEBUG_KMS("ATOM: fb read beyond scratch region: %d vs. %d\n", + gctx->fb_base + idx, gctx->scratch_size_bytes); + val = 0; + } else + val = gctx->scratch[((gctx->fb_base + idx) / 4)]; if (print) DEBUG("FB[0x%02X]", idx); break; @@ -531,7 +536,11 @@ static void atom_put_dst(atom_exec_context *ctx, int arg, uint8_t attr, case ATOM_ARG_FB: idx = U8(*ptr); (*ptr)++; - gctx->scratch[((gctx->fb_base + idx) / 4)] = val; + if ((gctx->fb_base + idx) > gctx->scratch_size_bytes) { + DRM_DEBUG_KMS("ATOM: fb write beyond scratch region: %d vs. %d\n", + gctx->fb_base + idx, gctx->scratch_size_bytes); + } else + gctx->scratch[((gctx->fb_base + idx) / 4)] = val; DEBUG("FB[0x%02X]", idx); break; case ATOM_ARG_PLL: @@ -1370,11 +1379,13 @@ int atom_allocate_fb_scratch(struct atom_context *ctx) usage_bytes = firmware_usage->asFirmwareVramReserveInfo[0].usFirmwareUseInKb * 1024; } + ctx->scratch_size_bytes = 0; if (usage_bytes == 0) usage_bytes = 20 * 1024; /* allocate some scratch memory */ ctx->scratch = kzalloc(usage_bytes, GFP_KERNEL); if (!ctx->scratch) return -ENOMEM; + ctx->scratch_size_bytes = usage_bytes; return 0; } diff --git a/drivers/gpu/drm/radeon/atom.h b/drivers/gpu/drm/radeon/atom.h index a589a55..93cfe20 100644 --- a/drivers/gpu/drm/radeon/atom.h +++ b/drivers/gpu/drm/radeon/atom.h @@ -137,6 +137,7 @@ struct atom_context { int cs_equal, cs_above; int io_mode; uint32_t *scratch; + int scratch_size_bytes; }; extern int atom_debug; -- 1.7.1.1

2 2

drm_fb_helper question
by Ilija Hadzic 18 Oct '11

18 Oct '11

While hacking something else, I stumbled upon two potential issues in drm_fb_helper. Could someone who knows this better than me enlighten whether the problem is realistic or whether I am overseeing something ? If the problem is real (or a potential trouble waiting to happen), I have cut some patches that address this and I can send them. First, in drm_fb_helper_init, the size of crtc_info allocated is for crtc_count entries, the loop that populates crtc_info at the end of the _init function scans the whole list of connectors. So if GPU specifies crtc_count that is smaller than the total number of CRTCs, the loop will overrun the allocated space and corrupt memory. Although no GPU driver in current tree does that, I could imagine a GPU using the smaller number for crtc_count if it does not want some CRTCs used for fbcon. Second (similar in nature) problem is the loop at the end of drm_setup_crtcs function that populates modeset->connectors array. The size of that array is fb_helper->max_conn_count (which is specified by the GPU driver and can be anything), while the the loop runs for fb_helper->connector_count iterations which can include all available connectors (per drm_fb_helper_single_add_all_connectors). So at least in theory that loop can overrun the modset->connectors array and corrupt memory too. Both cases may be theoretical at this time, but they look like a trouble waiting to happen (e.g., future GPUs may have a mix of CRTCs and connectors that could evoke the described error). If those who know better, agree with my analysis, I'll be glad to send some patchwork. thanks, Ilija

1 0

[Bug 41913] [865] intel/intel_bufmgr_gem.c:1361: do_bo_emit_reloc: Assertion `offset <= bo->size - 4' failed.
by bugzilla-daemon＠freedesktop.org 18 Oct '11

18 Oct '11

https://bugs.freedesktop.org/show_bug.cgi?id=41913 Chris Wilson <chris(a)chris-wilson.co.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|intel/intel_bufmgr_gem.c:13 |[865] |61: do_bo_emit_reloc: |intel/intel_bufmgr_gem.c:13 |Assertion `offset <= |61: do_bo_emit_reloc: |bo->size - 4' failed. |Assertion `offset <= | |bo->size - 4' failed. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.

1 0

← Newer
1
...
39
40
41
42
43
44
45
...
53
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel October 2011