g33: GPU hangs
On 12/01/2011 01:47 PM, Chris Wilson wrote: > On Thu, 01 Dec 2011 13:30:18 +0100, Jiri Slaby wrote: >> Hi, >> >> both yesterday and today, my GPU hung. Both happened when I opened >> google front page in firefox. >> >> I'm running 3.2.0-rc3-next-2030. Given it happened twice in the past >> 24 hours, it looks like a regression from next-2024. Or is this a >> userspace issue (I might updated some packages)? >> >> i915_error_state dumps from the two hangs are here: >> http://www.fi.muni.cz/~xslaby/sklad/panics/915_error_state_0 >> http://www.fi.muni.cz/~xslaby/sklad/panics/915_error_state_second > > Both error states contain the same bug: a fence register in conflict > with the command stream. The batch is using the buffer at 0x03d > as an untiled 40x40 rgba buffer with pitch 192. However, a fence > register is programmed to > fence[3] = 03d1 > valid, x-tiled, pitch: 512, start: 0x03d0, size: 1048576 > > Also note that buffer is also not listed as currently active, so > presumably we reused the buffer as tiled (and so reprogrammed the > fence registered) before the GPU retired the batch. That sounds eerily > similar to this bug: Hi, it seems like it's fixed by the patch. Thanks. > From 2b76187d2f5fc2352e391914b1828f91f93bb356 Mon Sep 17 00:00:00 2001 > From: Chris Wilson > Date: Tue, 29 Nov 2011 15:12:16 + > Subject: [PATCH] drm/i915: Only clear the GPU domains upon a successful > finish -- js suse labs
[Bug 43504] New: tex2D() artifacts (tiling related?) on AMD RV670
https://bugs.freedesktop.org/show_bug.cgi?id=43504 Bug #: 43504 Summary: tex2D() artifacts (tiling related?) on AMD RV670 Classification: Unclassified Product: Mesa Version: git Platform: Other OS/Version: All Status: NEW Severity: major Priority: medium Component: Drivers/Gallium/r600 AssignedTo: dri-devel at lists.freedesktop.org ReportedBy: kam1kaz3 at gmail.com Created attachment 54101 --> https://bugs.freedesktop.org/attachment.cgi?id=54101 Screenshot showing problem This is what I'm doing: 1) render scene to render target texture A 2) render quad on screen to show RTT A data When on the second step, I am using a fragment shader that calls tex2D() to retrieve the RTT color data, however I get artifacts as shown on the attached screenshot. Whenever I restart the application, I get different corruption. I'm not sure the problem is when reading from the texture, or writing on it. If I output colors without using tex2D() it all works fine. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
i915: eDP regression
Hi, Commit dc22ee6 introduces regression on my laptop HP EliteBook 8440p. I see nothing on the panel after mode setting. Reverting the commit fixes the issue. $ sudo lspci -vv - -s 00:02.0 00:02.0 VGA compatible controller: Intel Corporation Core Processor Integrated Graphics Controller (rev 02) (prog-if 00 [VGA controller]) Subsystem: Hewlett-Packard Company Device 172a Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- [disabled] Capabilities: [90] MSI: Enable+ Count=1/1 Maskable- 64bit- Address: fee0f00c Data: 4179 Capabilities: [d0] Power Management version 2 Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME- Capabilities: [a4] PCI Advanced Features AFCap: TP+ FLR+ AFCtrl: FLR- AFStatus: TP- Kernel driver in use: i915 00: 86 80 46 00 07 04 90 00 02 00 00 03 00 00 00 00 10: 04 00 00 d0 00 00 00 00 0c 00 00 c0 00 00 00 00 20: 59 50 00 00 00 00 00 00 00 00 00 00 3c 10 2a 17 30: 00 00 00 00 90 00 00 00 00 00 00 00 0a 01 00 00 40: 09 00 0c 01 26 61 21 00 88 00 40 00 0f 17 17 17 50: 00 00 50 0b 09 00 00 00 00 00 00 00 00 00 00 be 60: 00 00 02 02 00 00 00 00 00 00 00 00 00 00 00 00 70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 90: 05 d0 01 00 0c f0 e0 fe 79 41 00 00 00 00 00 00 a0: 11 11 11 00 13 00 06 03 00 00 14 60 25 04 3a 30 b0: 00 00 00 00 00 00 00 00 00 02 00 00 00 00 00 00 c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 d0: 01 a4 22 00 00 00 00 00 00 00 00 00 00 01 02 00 e0: 00 00 00 00 01 00 00 00 00 80 00 00 00 00 00 00 f0: 00 00 00 00 00 00 00 00 ab 0f 18 00 18 d0 6f bb -- Kirill A. Shutemov
ttm: merge ttm_backend & ttm_tt, introduce ttm dma allocator V7
On Sat, Dec 3, 2011 at 4:41 PM, Jerome Glisse wrote: > On Sat, Dec 3, 2011 at 9:52 AM, David Airlie wrote: >> >> >> - Original Message - >>> From: "Konrad Rzeszutek Wilk" >>> To: "Jerome Glisse" , dri-devel at >>> lists.freedesktop.org, "konrad wilk" , >>> thellstrom at vmware.com, airlied at gmail.com, "Jerome Glisse" >> redhat.com> >>> Sent: Friday, 2 December, 2011 2:19:01 PM >>> Subject: Re: ttm: merge ttm_backend & ttm_tt, introduce ttm dma allocator V7 >>> >>> On Fri, Nov 18, 2011 at 08:08:36PM -0500, Jerome Glisse wrote: >>> > On Fri, Nov 18, 2011 at 08:04:47PM -0500, j.glisse at gmail.com >>> > wrote: >>> > > Important fix to patch 14, fix accounting of ghost bo. When >>> > > creating a >>> > > ghost bo we don't account it, so set its acc_size to 0 so that >>> > > when >>> > > ghost is release we don't overfree. >>> > > >>> > > I wonder how i didn't run into this before. >>> > > >>> > > Patch are also at >>> > > >>> > > http://people.freedesktop.org/~glisse/ttmdma/ >>> > > >>> > > Cheers, >>> > > Jerome >>> > > >>> > >>> > Oh i forgot to add some of the reviewed by, i updated patches on >>> > fdo, >>> > i don't resend to the ml. >>> >>> Great! How should we ask Dave to pull them? Does he prefer to do it >>> via git >>> tree? In which I can create a branch with those patches and send him >>> a GIT PULL >>> email? Or is there a more convient way? >> >> If someone could suck them all into a git tree + all the Reviewed-by tags >> from the people who reviewed them it would make it a lot easier, >> >> I lost track of where this ended up as Jerome had a few balls in the air and >> I know Thomas wasn't liking some of them. >> >> So please send me a git url and I'll go review that next week. >> >> Dave. > > http://cgit.freedesktop.org/~glisse/linux/log/ > > I need to add last reviewed by from Thomas. Note this tree also has > other patches (multi ring lastest patchset) which we want for next too > i believe. > > I will update this tree on monday with all the missing reviewed by > > Cheers, > Jerome Just to be extra informative my tree has: drm/ttm: callback move_notify any time bo placement change v4 Got the reviewed by recently from Thomas drm/ttm: simplify memory accounting for ttm user v2 Thomas reviewed version1, version2 only fix a bug so i think it's safe to assume i have reviewed by Thomas for v2. Cheers, Jerome
ttm: merge ttm_backend & ttm_tt, introduce ttm dma allocator V7
On Sat, Dec 3, 2011 at 9:52 AM, David Airlie wrote: > > > - Original Message - >> From: "Konrad Rzeszutek Wilk" >> To: "Jerome Glisse" , dri-devel at >> lists.freedesktop.org, "konrad wilk" , >> thellstrom at vmware.com, airlied at gmail.com, "Jerome Glisse" > redhat.com> >> Sent: Friday, 2 December, 2011 2:19:01 PM >> Subject: Re: ttm: merge ttm_backend & ttm_tt, introduce ttm dma allocator V7 >> >> On Fri, Nov 18, 2011 at 08:08:36PM -0500, Jerome Glisse wrote: >> > On Fri, Nov 18, 2011 at 08:04:47PM -0500, j.glisse at gmail.com >> > wrote: >> > > Important fix to patch 14, fix accounting of ghost bo. When >> > > creating a >> > > ghost bo we don't account it, so set its acc_size to 0 so that >> > > when >> > > ghost is release we don't overfree. >> > > >> > > I wonder how i didn't run into this before. >> > > >> > > Patch are also at >> > > >> > > http://people.freedesktop.org/~glisse/ttmdma/ >> > > >> > > Cheers, >> > > Jerome >> > > >> > >> > Oh i forgot to add some of the reviewed by, i updated patches on >> > fdo, >> > i don't resend to the ml. >> >> Great! How should we ask Dave to pull them? Does he prefer to do it >> via git >> tree? In which I can create a branch with those patches and send him >> a GIT PULL >> email? Or is there a more convient way? > > If someone could suck them all into a git tree + all the Reviewed-by tags > from the people who reviewed them it would make it a lot easier, > > I lost track of where this ended up as Jerome had a few balls in the air and > I know Thomas wasn't liking some of them. > > So please send me a git url and I'll go review that next week. > > Dave. http://cgit.freedesktop.org/~glisse/linux/log/ I need to add last reviewed by from Thomas. Note this tree also has other patches (multi ring lastest patchset) which we want for next too i believe. I will update this tree on monday with all the missing reviewed by Cheers, Jerome
WARNING: at mm/slub.c:3357, kernel BUG at mm/slub.c:3413
On Sat, Dec 3, 2011 at 2:31 PM, Jerome Glisse wrote: > On Sat, Dec 3, 2011 at 7:29 AM, Markus Trippelsdorf > wrote: >> On 2011.12.03 at 12:20 +, Dave Airlie wrote: >>> >> > > > > FIX idr_layer_cache: Marking all objects used >>> >> > > > >>> >> > > > Yesterday I couldn't reproduce the issue at all. But today I've hit >>> >> > > > exactly the same spot again. (CCing the drm list) >>> >>> If I had to guess it looks like 0 is getting written back to some >>> random page by the GPU maybe, it could be that the GPU is in some half >>> setup state at boot or on a reboot does it happen from a cold boot or >>> just warm boot or kexec? >> >> Only happened with kexec thus far. Cold boot seems to be fine. >> >> -- >> Markus > > Can you add radeon.no_wb=1 to your kexec kernel paramater an see if > you can reproduce. > > Cheers, > Jerome Also cold boot with radeon.no_wb=1 :) Cheers, Jerome
WARNING: at mm/slub.c:3357, kernel BUG at mm/slub.c:3413
On Sat, Dec 3, 2011 at 7:29 AM, Markus Trippelsdorf wrote: > On 2011.12.03 at 12:20 +, Dave Airlie wrote: >> >> > > > > FIX idr_layer_cache: Marking all objects used >> >> > > > >> >> > > > Yesterday I couldn't reproduce the issue at all. But today I've hit >> >> > > > exactly the same spot again. (CCing the drm list) >> >> If I had to guess it looks like 0 is getting written back to some >> random page by the GPU maybe, it could be that the GPU is in some half >> setup state at boot or on a reboot does it happen from a cold boot or >> just warm boot or kexec? > > Only happened with kexec thus far. Cold boot seems to be fine. > > -- > Markus Can you add radeon.no_wb=1 to your kexec kernel paramater an see if you can reproduce. Cheers, Jerome
WARNING: at mm/slub.c:3357, kernel BUG at mm/slub.c:3413
On 2011.12.03 at 12:20 +, Dave Airlie wrote: > >> > > > > FIX idr_layer_cache: Marking all objects used > >> > > > > >> > > > Yesterday I couldn't reproduce the issue at all. But today I've hit > >> > > > exactly the same spot again. (CCing the drm list) > > If I had to guess it looks like 0 is getting written back to some > random page by the GPU maybe, it could be that the GPU is in some half > setup state at boot or on a reboot does it happen from a cold boot or > just warm boot or kexec? Only happened with kexec thus far. Cold boot seems to be fine. -- Markus
[Bug 43395] Game running in wine stops rendering
https://bugs.freedesktop.org/show_bug.cgi?id=43395 --- Comment #9 from Tomas Schlosser 2011-12-03 04:58:36 PST --- (In reply to comment #1) > Does mesa from git help? Could you please point me to some tutorial as to how to do that? Thank you -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
WARNING: at mm/slub.c:3357, kernel BUG at mm/slub.c:3413
>> > > > > FIX idr_layer_cache: Marking all objects used >> > > > >> > > > Yesterday I couldn't reproduce the issue at all. But today I've hit >> > > > exactly the same spot again. (CCing the drm list) If I had to guess it looks like 0 is getting written back to some random page by the GPU maybe, it could be that the GPU is in some half setup state at boot or on a reboot does it happen from a cold boot or just warm boot or kexec? Jerome, might be worth checking the ordering for when bus master gets enabled or if we turn off the writeback producers before writeback is enabled. Dave.
[Bug 43487] [HD6320] Corrupted displays (LVDS and HDMI) after connecting HDMI
https://bugs.freedesktop.org/show_bug.cgi?id=43487 Rafa? Mi?ecki changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Comment #4 from Rafa? Mi?ecki 2011-12-03 04:09:12 PST --- Just call me an idiot. I've been using fglrx Xorg driver with radeon kernel module... Plain radeon + radeon works OK! -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 43487] [HD6320] Corrupted displays (LVDS and HDMI) after connecting HDMI
https://bugs.freedesktop.org/show_bug.cgi?id=43487 --- Comment #3 from Rafa? Mi?ecki 2011-12-03 03:47:35 PST --- ** HDMI corruption ** After connecting HDMI (and waiting second or two) my TV starts displaying something. That looks like green and white vertical stripes. However xrandr displays HDMI (DFP1) as disconnected and it really seems that DFP1 is not programmed at all. When I compare regs between radeon and (fglrx or radeon-with-DFP1-attached-at-boot-time) [always with HDMI attached], there are a lot of differences. About 30 in low registers and over 100 differences in registers 0x28... and 0x29... -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 43477] rendering errors in unigine tropics and sanctuary (regression)
https://bugs.freedesktop.org/show_bug.cgi?id=43477 --- Comment #3 from almos 2011-12-03 03:35:29 PST --- (In reply to comment #2) > Probably this is a known bug with GL_EXT_TEXTURE_ARRAY in Unigine engines and > glsl < 1.30. IIRR they are using the extension without enabling it in the > shaders. > > Disabling the extension completely with the environment variable should help: > > MESA_EXTENSION_OVERRIDE=-GL_EXT_texture_array Yes, disabling that extension fixes the problem. Is it so rare that an opengl implementation supports GL_EXT_TEXTURE_ARRAY but not glsl 1.30? The extension spec is written against glsl 1.10. BTW, how far is r600g from supporting glsl 1.30? AFAIK the intel driver already advertises glsl 1.30 support. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 43487] [HD6320] Corrupted displays (LVDS and HDMI) after connecting HDMI
https://bugs.freedesktop.org/show_bug.cgi?id=43487 --- Comment #1 from Rafa? Mi?ecki 2011-12-03 03:23:42 PST --- ** LVDS corruption ** LVDS corruption consists of two problems: 1) Display is corrupted 2) Everything is moved (bottom and right parts of display are black) Ad 1 After booting (without HDMI connected) register 0x6818 is set to 0x0640. When I connect HDMI, driver changes it to 0x0580. I have no idea why does it happen, but it's source of the corruption. Setting it back with: avivotool regset 0x6818 0x0640 removes corruption. I believe register is defined as: #define EVERGREEN_GRPH_PITCH0x6818 With fglrx register 0x6818 is set to 0x640 all the time (with HDMI and without) Ad 2 After booting (without HDMI connected) register 0x6810 is set to 0x. When I connect HDMI, driver changes it to 0x00142000. It's the source of moved display. Setting it back with: avivotool regset 0x6810 0x removes movement. I believe register is defined as: #define EVERGREEN_GRPH_PRIMARY_SURFACE_ADDRESS 0x6810 With fglrx register 0x6810 is set to 0 all the time (with HDMI and without) -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 43487] New: [HD6320] Corrupted displays (LVDS and HDMI) after connecting HDMI
https://bugs.freedesktop.org/show_bug.cgi?id=43487 Bug #: 43487 Summary: [HD6320] Corrupted displays (LVDS and HDMI) after connecting HDMI Classification: Unclassified Product: DRI Version: unspecified Platform: Other OS/Version: All Status: NEW Severity: normal Priority: medium Component: DRM/Radeon AssignedTo: dri-devel at lists.freedesktop.org ReportedBy: zajec5 at gmail.com I've netbook Asus 1215B with AMD E-450 and HD6320. When I connect my TV over HDMI I get 2 corrupted displays after a second or two. I'm using drm-next branch of git://people.freedesktop.org/~airlied/linux from yesterday (04b3924db60f974d2b4af0b2e19a0ae7ca202dc7). -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
WARNING: at mm/slub.c:3357, kernel BUG at mm/slub.c:3413
On 2011.12.02 at 18:04 -0500, Jerome Glisse wrote: > On Thu, Nov 24, 2011 at 09:50:40AM +0100, Markus Trippelsdorf wrote: > > On 2011.11.23 at 10:06 -0600, Christoph Lameter wrote: > > > On Wed, 23 Nov 2011, Markus Trippelsdorf wrote: > > > > > > > > FIX idr_layer_cache: Marking all objects used > > > > > > > > Yesterday I couldn't reproduce the issue at all. But today I've hit > > > > exactly the same spot again. (CCing the drm list) > > > > > > Well this is looks like write after free. > > > > > > > = > > > > BUG idr_layer_cache: Poison overwritten > > > > - > > > > Object 8802156487c0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b > > > > 6b > > > > Object 8802156487d0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b > > > > 6b > > > > Object 8802156487e0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b > > > > 6b > > > > Object 8802156487f0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b > > > > 6b > > > > Object 880215648800: 00 00 00 00 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b > > > > 6b > > > > Object 880215648810: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b > > > > 6b > > > > > > And its an integer sized write of 0. If you look at the struct definition > > > and lookup the offset you should be able to locate the field that > > > was modified. > > > I really don't think that drm or radeon is guilty. I tried to reproduce > with rc3+ & rc4+ with slub or slab, did more then 20 kexec cycle with > same kernel parameter and no issue. > > To confirm that radeon or drm is not to blame can you trigger the issue > by using nomodeset kernel option (your fb rotate option is then > useless). If with nomodeset you can trigger the issue can you then try > to trigger it with KMS enabled and with attached patch (real ugly printk > debuging) > > Note that i walked over the drm mode init code and i believe the root > issue is that some code in the kernel do a double idr_remove/destroy > which trigger the idr slub/slab error. It just happen that radeon/drm > is call after the idr double free but is not the one guilty. > > Note that i don't understand the idr code much, so my theory can be > completely wrong but attached patch might help to shed some light. Thanks for the debugging patch Jerome. I couldn't trigger the issue with the ?nomodeset? kernel option yet. But I've triggered it with KMS enabled and your patch applied: Linux version 3.2.0-rc4-00089-g621fc1e-dirty (markus at x4.trippels.de) (gcc version 4.7.0 20111201 (experimental) (GCC) ) #137 SMP PREEMPT Sat Dec 3 06:43:05 CET 2011 Command line: root=PARTUUID=6d6a4009-3a90-40df-806a-e63f48189719 init=/sbin/minit rootflags=logbsize=262144 fbcon=rotate:3 drm_kms_helper.poll=0 quiet KERNEL supported cpus: AMD AuthenticAMD BIOS-provided physical RAM map: BIOS-e820: 0100 - 0009fc00 (usable) BIOS-e820: 0009fc00 - 000a (reserved) BIOS-e820: 000e6000 - 0010 (reserved) BIOS-e820: 0010 - dfe9 (usable) BIOS-e820: dfe9 - dfea8000 (ACPI data) BIOS-e820: dfea8000 - dfed (ACPI NVS) BIOS-e820: dfed - dff0 (reserved) BIOS-e820: fff0 - 0001 (reserved) BIOS-e820: 0001 - 00022000 (usable) NX (Execute Disable) protection: active DMI present. DMI: System manufacturer System Product Name/M4A78T-E, BIOS 340608/20/2010 e820 update range: - 0001 (usable) ==> (reserved) e820 remove range: 000a - 0010 (usable) last_pfn = 0x22 max_arch_pfn = 0x4 MTRR default type: uncachable MTRR fixed ranges enabled: 0-9 write-back A-E uncachable F-F write-protect MTRR variable ranges enabled: 0 base mask 8000 write-back 1 base 8000 mask C000 write-back 2 base C000 mask E000 write-back 3 base F000 mask F800 write-combining 4 disabled 5 disabled 6 disabled 7 disabled TOM2: 00022000 aka 8704M x86 PAT enabled: cpu 0, old 0x7010600070106, new 0x7010600070106 last_pfn = 0xdfe90 max_arch_pfn = 0x4 initial memory mapped : 0 - 2000 Base memory trampoline at [8809d000] 9d000 size 8192 Using GB pages for direct mapping init_memory_mapping: -dfe9 00 - 00c000 page 1G 00c000 - 00dfe0 page 2M 00dfe0 - 00dfe9 page 4k kernel direct mapping tables up to dfe9 @ 1fffd000-2000 init_memory_mapping: 0001-00022000 01 - 02 page 1G 02 - 022000 page 2M kernel direct mapping tables up to 22000 @ dfe8e000-dfe9 ACPI: RSDP
ttm: merge ttm_backend & ttm_tt, introduce ttm dma allocator V7
- Original Message - > From: "Konrad Rzeszutek Wilk" > To: "Jerome Glisse" , dri-devel at > lists.freedesktop.org, "konrad wilk" , > thellstrom at vmware.com, airlied at gmail.com, "Jerome Glisse" redhat.com> > Sent: Friday, 2 December, 2011 2:19:01 PM > Subject: Re: ttm: merge ttm_backend & ttm_tt, introduce ttm dma allocator V7 > > On Fri, Nov 18, 2011 at 08:08:36PM -0500, Jerome Glisse wrote: > > On Fri, Nov 18, 2011 at 08:04:47PM -0500, j.glisse at gmail.com > > wrote: > > > Important fix to patch 14, fix accounting of ghost bo. When > > > creating a > > > ghost bo we don't account it, so set its acc_size to 0 so that > > > when > > > ghost is release we don't overfree. > > > > > > I wonder how i didn't run into this before. > > > > > > Patch are also at > > > > > > http://people.freedesktop.org/~glisse/ttmdma/ > > > > > > Cheers, > > > Jerome > > > > > > > Oh i forgot to add some of the reviewed by, i updated patches on > > fdo, > > i don't resend to the ml. > > Great! How should we ask Dave to pull them? Does he prefer to do it > via git > tree? In which I can create a branch with those patches and send him > a GIT PULL > email? Or is there a more convient way? If someone could suck them all into a git tree + all the Reviewed-by tags from the people who reviewed them it would make it a lot easier, I lost track of where this ended up as Jerome had a few balls in the air and I know Thomas wasn't liking some of them. So please send me a git url and I'll go review that next week. Dave.
[Bug 34462] 180 second hang on boot, DRM doesn't seem to initialize (firmware issue?)
https://bugs.freedesktop.org/show_bug.cgi?id=34462 --- Comment #6 from Jonathan Nieder 2011-12-03 00:16:17 PST --- Owen, can you bisect? Just trying a few intermediate versions from http://snapshot.debian.org/ would already be useful. For narrowing down the regression range beyond that, "git bisect" can help: git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git cd linux git bisect start -- drivers/gpu/drm/radeon git checkout (bad version) make localmodconfig; # minimal configuration make -j2 deb-pkg dpkg -i ../(package).deb reboot # confirm that it is actually bad git bisect bad git checkout (good version) make silentoldconfig; # reuse configuration make -j2 deb-pkg dpkg -i ../(package).deb reboot # confirm that it is good git bisect good # now it checks out an intermediate version to test make silentoldconfig make -j2 deb-pkg dpkg -i ../(package).deb reboot git bisect bad; # if it hangs in the same way git bisect good; # if it boots correctly git bisect skip; # if some other problem makes it hard to test ... rinse and repeat ... git bisect visualize; # to watch the regression range narrowing git bisect log; # to summarize partial results if you get bored -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 43487] [HD6320] Corrupted displays (LVDS and HDMI) after connecting HDMI
https://bugs.freedesktop.org/show_bug.cgi?id=43487 --- Comment #2 from Rafa? Mi?ecki 2011-12-03 03:33:17 UTC --- ** LVDS corruption ** After disconnecting HDMI corruption does not disappear. Switching to console (ALT+CTRL+F1) does not fix corruption. However switching back to X (ALT+CTRL+F7) fixes the corruption. One more interesting thing: DFP1 seems to be disconnected all the time according to xrandr: DFP1 disconnected (normal left inverted right x axis y axis) -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 43477] rendering errors in unigine tropics and sanctuary (regression)
https://bugs.freedesktop.org/show_bug.cgi?id=43477 --- Comment #2 from Vadim 2011-12-02 17:04:58 PST --- Probably this is a known bug with GL_EXT_TEXTURE_ARRAY in Unigine engines and glsl < 1.30. IIRR they are using the extension without enabling it in the shaders. Disabling the extension completely with the environment variable should help: MESA_EXTENSION_OVERRIDE=-GL_EXT_texture_array -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 43481] DVI-0 with unknown connection but available modes
https://bugs.freedesktop.org/show_bug.cgi?id=43481 --- Comment #1 from Alex Deucher 2011-12-02 16:24:48 PST --- It's on a docking station. As to why it's suddenly getting detected, can you bisect? -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 34462] 180 second hang on boot, DRM doesn't seem to initialize (firmware issue?)
https://bugs.freedesktop.org/show_bug.cgi?id=34462 --- Comment #6 from Jonathan Nieder jrnie...@gmail.com 2011-12-03 00:16:17 PST --- Owen, can you bisect? Just trying a few intermediate versions from http://snapshot.debian.org/ would already be useful. For narrowing down the regression range beyond that, git bisect can help: git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git cd linux git bisect start -- drivers/gpu/drm/radeon git checkout (bad version) make localmodconfig; # minimal configuration make -j2 deb-pkg dpkg -i ../(package).deb reboot # confirm that it is actually bad git bisect bad git checkout (good version) make silentoldconfig; # reuse configuration make -j2 deb-pkg dpkg -i ../(package).deb reboot # confirm that it is good git bisect good # now it checks out an intermediate version to test make silentoldconfig make -j2 deb-pkg dpkg -i ../(package).deb reboot git bisect bad; # if it hangs in the same way git bisect good; # if it boots correctly git bisect skip; # if some other problem makes it hard to test ... rinse and repeat ... git bisect visualize; # to watch the regression range narrowing git bisect log; # to summarize partial results if you get bored -- 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 43487] New: [HD6320] Corrupted displays (LVDS and HDMI) after connecting HDMI
https://bugs.freedesktop.org/show_bug.cgi?id=43487 Bug #: 43487 Summary: [HD6320] Corrupted displays (LVDS and HDMI) after connecting HDMI Classification: Unclassified Product: DRI Version: unspecified Platform: Other OS/Version: All Status: NEW Severity: normal Priority: medium Component: DRM/Radeon AssignedTo: dri-devel@lists.freedesktop.org ReportedBy: zaj...@gmail.com I've netbook Asus 1215B with AMD E-450 and HD6320. When I connect my TV over HDMI I get 2 corrupted displays after a second or two. I'm using drm-next branch of git://people.freedesktop.org/~airlied/linux from yesterday (04b3924db60f974d2b4af0b2e19a0ae7ca202dc7). -- 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 43487] [HD6320] Corrupted displays (LVDS and HDMI) after connecting HDMI
https://bugs.freedesktop.org/show_bug.cgi?id=43487 --- Comment #1 from Rafał Miłecki zaj...@gmail.com 2011-12-03 03:23:42 PST --- ** LVDS corruption ** LVDS corruption consists of two problems: 1) Display is corrupted 2) Everything is moved (bottom and right parts of display are black) Ad 1 After booting (without HDMI connected) register 0x6818 is set to 0x0640. When I connect HDMI, driver changes it to 0x0580. I have no idea why does it happen, but it's source of the corruption. Setting it back with: avivotool regset 0x6818 0x0640 removes corruption. I believe register is defined as: #define EVERGREEN_GRPH_PITCH0x6818 With fglrx register 0x6818 is set to 0x640 all the time (with HDMI and without) Ad 2 After booting (without HDMI connected) register 0x6810 is set to 0x. When I connect HDMI, driver changes it to 0x00142000. It's the source of moved display. Setting it back with: avivotool regset 0x6810 0x removes movement. I believe register is defined as: #define EVERGREEN_GRPH_PRIMARY_SURFACE_ADDRESS 0x6810 With fglrx register 0x6810 is set to 0 all the time (with HDMI and without) -- 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 43487] [HD6320] Corrupted displays (LVDS and HDMI) after connecting HDMI
https://bugs.freedesktop.org/show_bug.cgi?id=43487 --- Comment #2 from Rafał Miłecki zaj...@gmail.com 2011-12-03 03:33:17 UTC --- ** LVDS corruption ** After disconnecting HDMI corruption does not disappear. Switching to console (ALT+CTRL+F1) does not fix corruption. However switching back to X (ALT+CTRL+F7) fixes the corruption. One more interesting thing: DFP1 seems to be disconnected all the time according to xrandr: DFP1 disconnected (normal left inverted right x axis y axis) -- 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 43477] rendering errors in unigine tropics and sanctuary (regression)
https://bugs.freedesktop.org/show_bug.cgi?id=43477 --- Comment #3 from almos aaalmo...@gmail.com 2011-12-03 03:35:29 PST --- (In reply to comment #2) Probably this is a known bug with GL_EXT_TEXTURE_ARRAY in Unigine engines and glsl 1.30. IIRR they are using the extension without enabling it in the shaders. Disabling the extension completely with the environment variable should help: MESA_EXTENSION_OVERRIDE=-GL_EXT_texture_array Yes, disabling that extension fixes the problem. Is it so rare that an opengl implementation supports GL_EXT_TEXTURE_ARRAY but not glsl 1.30? The extension spec is written against glsl 1.10. BTW, how far is r600g from supporting glsl 1.30? AFAIK the intel driver already advertises glsl 1.30 support. -- 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 43487] [HD6320] Corrupted displays (LVDS and HDMI) after connecting HDMI
https://bugs.freedesktop.org/show_bug.cgi?id=43487 Rafał Miłecki zaj...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Comment #4 from Rafał Miłecki zaj...@gmail.com 2011-12-03 04:09:12 PST --- Just call me an idiot. I've been using fglrx Xorg driver with radeon kernel module... Plain radeon + radeon works OK! -- 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: WARNING: at mm/slub.c:3357, kernel BUG at mm/slub.c:3413
FIX idr_layer_cache: Marking all objects used Yesterday I couldn't reproduce the issue at all. But today I've hit exactly the same spot again. (CCing the drm list) If I had to guess it looks like 0 is getting written back to some random page by the GPU maybe, it could be that the GPU is in some half setup state at boot or on a reboot does it happen from a cold boot or just warm boot or kexec? Jerome, might be worth checking the ordering for when bus master gets enabled or if we turn off the writeback producers before writeback is enabled. Dave. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: WARNING: at mm/slub.c:3357, kernel BUG at mm/slub.c:3413
On 2011.12.03 at 12:20 +, Dave Airlie wrote: FIX idr_layer_cache: Marking all objects used Yesterday I couldn't reproduce the issue at all. But today I've hit exactly the same spot again. (CCing the drm list) If I had to guess it looks like 0 is getting written back to some random page by the GPU maybe, it could be that the GPU is in some half setup state at boot or on a reboot does it happen from a cold boot or just warm boot or kexec? Only happened with kexec thus far. Cold boot seems to be fine. -- Markus ___ 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 #9 from Tomas Schlosser schlosse...@seznam.cz 2011-12-03 04:58:36 PST --- (In reply to comment #1) Does mesa from git help? Could you please point me to some tutorial as to how to do that? Thank you -- 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: ttm: merge ttm_backend ttm_tt, introduce ttm dma allocator V7
On Fri, Nov 18, 2011 at 08:08:36PM -0500, Jerome Glisse wrote: On Fri, Nov 18, 2011 at 08:04:47PM -0500, j.glisse at gmail.com wrote: Important fix to patch 14, fix accounting of ghost bo. When creating a ghost bo we don't account it, so set its acc_size to 0 so that when ghost is release we don't overfree. I wonder how i didn't run into this before. Patch are also at http://people.freedesktop.org/~glisse/ttmdma/ Cheers, Jerome Oh i forgot to add some of the reviewed by, i updated patches on fdo, i don't resend to the ml. Great! How should we ask Dave to pull them? Does he prefer to do it via git tree? In which I can create a branch with those patches and send him a GIT PULL email? Or is there a more convient way? Cheers, Jerome ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC v2 1/2] dma-buf: Introduce dma buffer sharing mechanism
On Fri, Dec 02, 2011 at 02:27:31PM +0530, Sumit Semwal wrote: This is the first step in defining a dma buffer sharing mechanism. A new buffer object dma_buf is added, with operations and API to allow easy sharing of this buffer object across devices. The framework allows: - different devices to 'attach' themselves to this buffer, to facilitate backing storage negotiation, using dma_buf_attach() API. - association of a file pointer with each user-buffer and associated allocator-defined operations on that buffer. This operation is called the 'export' operation. - this exported buffer-object to be shared with the other entity by asking for its 'file-descriptor (fd)', and sharing the fd across. - a received fd to get the buffer object back, where it can be accessed using the associated exporter-defined operations. - the exporter and user to share the scatterlist using map_dma_buf and unmap_dma_buf operations. Atleast one 'attach()' call is required to be made prior to calling the map_dma_buf() operation. Couple of building blocks in map_dma_buf() are added to ease introduction of sync'ing across exporter and users, and late allocation by the exporter. *OPTIONALLY*: mmap() file operation is provided for the associated 'fd', as wrapper over the optional allocator defined mmap(), to be used by devices that might need one. More details are there in the documentation patch. This is based on design suggestions from many people at the mini-summits[1], most notably from Arnd Bergmann a...@arndb.de, Rob Clark r...@ti.com and Daniel Vetter dan...@ffwll.ch. The implementation is inspired from proof-of-concept patch-set from Tomasz Stanislawski t.stanisl...@samsung.com, who demonstrated buffer sharing between two v4l2 devices. [2] [1]: https://wiki.linaro.org/OfficeofCTO/MemoryManagement [2]: http://lwn.net/Articles/454389 Signed-off-by: Sumit Semwal sumit.sem...@linaro.org Signed-off-by: Sumit Semwal sumit.sem...@ti.com You have a clone? You only need one SOB. --- drivers/base/Kconfig| 10 ++ drivers/base/Makefile |1 + drivers/base/dma-buf.c | 290 +++ include/linux/dma-buf.h | 176 4 files changed, 477 insertions(+), 0 deletions(-) create mode 100644 drivers/base/dma-buf.c create mode 100644 include/linux/dma-buf.h diff --git a/drivers/base/Kconfig b/drivers/base/Kconfig index 21cf46f..07d8095 100644 --- a/drivers/base/Kconfig +++ b/drivers/base/Kconfig @@ -174,4 +174,14 @@ config SYS_HYPERVISOR source drivers/base/regmap/Kconfig +config DMA_SHARED_BUFFER + bool Buffer framework to be shared between drivers + default n + depends on ANON_INODES + help + This option enables the framework for buffer-sharing between + multiple drivers. A buffer is associated with a file using driver + APIs extension; the file's descriptor can then be passed on to other + driver. + endmenu diff --git a/drivers/base/Makefile b/drivers/base/Makefile index 99a375a..d0df046 100644 --- a/drivers/base/Makefile +++ b/drivers/base/Makefile @@ -8,6 +8,7 @@ obj-$(CONFIG_DEVTMPFS)+= devtmpfs.o obj-y+= power/ obj-$(CONFIG_HAS_DMA)+= dma-mapping.o obj-$(CONFIG_HAVE_GENERIC_DMA_COHERENT) += dma-coherent.o +obj-$(CONFIG_DMA_SHARED_BUFFER) += dma-buf.o obj-$(CONFIG_ISA)+= isa.o obj-$(CONFIG_FW_LOADER) += firmware_class.o obj-$(CONFIG_NUMA) += node.o diff --git a/drivers/base/dma-buf.c b/drivers/base/dma-buf.c new file mode 100644 index 000..4b9005e --- /dev/null +++ b/drivers/base/dma-buf.c @@ -0,0 +1,290 @@ +/* + * Framework for buffer objects that can be shared across devices/subsystems. + * + * Copyright(C) 2011 Linaro Limited. All rights reserved. + * Author: Sumit Semwal sumit.sem...@ti.com OK, so the SOB should be from @ti.com then. + * + * Many thanks to linaro-mm-sig list, and specially + * Arnd Bergmann a...@arndb.de, Rob Clark r...@ti.com and + * Daniel Vetter dan...@ffwll.ch for their support in creation and + * refining of this idea. + * + * This program is free software; you can redistribute it and/or modify it + * under the terms of the GNU General Public License version 2 as published by + * the Free Software Foundation. + * + * This program is distributed in the hope that it will be useful, but WITHOUT + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or + * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for + * more details. + * + * You should have received a copy of the GNU General Public License along with + * this program. If not, see http://www.gnu.org/licenses/. + */ + +#include linux/fs.h +#include linux/slab.h +#include linux/dma-buf.h +#include linux/anon_inodes.h +#include linux/export.h + +static inline int is_dma_buf_file(struct
Re: 3.2-rc2+: Reported regressions from 3.0 and 3.1
From what I can see, you get the following callchain: start_kernel |- setup_arch |- x86_init.oem.arch_setup = xen_arch_setup |- check_bugs |- identify_boot_cpu |- identify_cpu |- select_idle_routine so xen_arch_setup will set pm_idle and select_idle_routine will honour it. I'm being told this is run either in the dom0 or the paravirt guest and if so, I don't see any issue with this for baremetal. So you can have my ACK provided this is tested on baremetal too. Tested on baremetal and there were no abnormalities. Thanks! ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: WARNING: at mm/slub.c:3357, kernel BUG at mm/slub.c:3413
On Sat, Dec 3, 2011 at 2:31 PM, Jerome Glisse j.gli...@gmail.com wrote: On Sat, Dec 3, 2011 at 7:29 AM, Markus Trippelsdorf mar...@trippelsdorf.de wrote: On 2011.12.03 at 12:20 +, Dave Airlie wrote: FIX idr_layer_cache: Marking all objects used Yesterday I couldn't reproduce the issue at all. But today I've hit exactly the same spot again. (CCing the drm list) If I had to guess it looks like 0 is getting written back to some random page by the GPU maybe, it could be that the GPU is in some half setup state at boot or on a reboot does it happen from a cold boot or just warm boot or kexec? Only happened with kexec thus far. Cold boot seems to be fine. -- Markus Can you add radeon.no_wb=1 to your kexec kernel paramater an see if you can reproduce. Cheers, Jerome Also cold boot with radeon.no_wb=1 :) Cheers, Jerome ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: ttm: merge ttm_backend ttm_tt, introduce ttm dma allocator V7
On Sat, Dec 3, 2011 at 9:52 AM, David Airlie airl...@redhat.com wrote: - Original Message - From: Konrad Rzeszutek Wilk konrad.w...@oracle.com To: Jerome Glisse j.gli...@gmail.com, dri-devel@lists.freedesktop.org, konrad wilk konrad.w...@oracle.com, thellst...@vmware.com, airl...@gmail.com, Jerome Glisse jgli...@redhat.com Sent: Friday, 2 December, 2011 2:19:01 PM Subject: Re: ttm: merge ttm_backend ttm_tt, introduce ttm dma allocator V7 On Fri, Nov 18, 2011 at 08:08:36PM -0500, Jerome Glisse wrote: On Fri, Nov 18, 2011 at 08:04:47PM -0500, j.glisse at gmail.com wrote: Important fix to patch 14, fix accounting of ghost bo. When creating a ghost bo we don't account it, so set its acc_size to 0 so that when ghost is release we don't overfree. I wonder how i didn't run into this before. Patch are also at http://people.freedesktop.org/~glisse/ttmdma/ Cheers, Jerome Oh i forgot to add some of the reviewed by, i updated patches on fdo, i don't resend to the ml. Great! How should we ask Dave to pull them? Does he prefer to do it via git tree? In which I can create a branch with those patches and send him a GIT PULL email? Or is there a more convient way? If someone could suck them all into a git tree + all the Reviewed-by tags from the people who reviewed them it would make it a lot easier, I lost track of where this ended up as Jerome had a few balls in the air and I know Thomas wasn't liking some of them. So please send me a git url and I'll go review that next week. Dave. http://cgit.freedesktop.org/~glisse/linux/log/ I need to add last reviewed by from Thomas. Note this tree also has other patches (multi ring lastest patchset) which we want for next too i believe. I will update this tree on monday with all the missing reviewed by Cheers, Jerome ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: g33: GPU hangs
On 12/01/2011 01:47 PM, Chris Wilson wrote: On Thu, 01 Dec 2011 13:30:18 +0100, Jiri Slaby jsl...@suse.cz wrote: Hi, both yesterday and today, my GPU hung. Both happened when I opened google front page in firefox. I'm running 3.2.0-rc3-next-2030. Given it happened twice in the past 24 hours, it looks like a regression from next-2024. Or is this a userspace issue (I might updated some packages)? i915_error_state dumps from the two hangs are here: http://www.fi.muni.cz/~xslaby/sklad/panics/915_error_state_0 http://www.fi.muni.cz/~xslaby/sklad/panics/915_error_state_second Both error states contain the same bug: a fence register in conflict with the command stream. The batch is using the buffer at 0x03d as an untiled 40x40 rgba buffer with pitch 192. However, a fence register is programmed to fence[3] = 03d1 valid, x-tiled, pitch: 512, start: 0x03d0, size: 1048576 Also note that buffer is also not listed as currently active, so presumably we reused the buffer as tiled (and so reprogrammed the fence registered) before the GPU retired the batch. That sounds eerily similar to this bug: Hi, it seems like it's fixed by the patch. Thanks. From 2b76187d2f5fc2352e391914b1828f91f93bb356 Mon Sep 17 00:00:00 2001 From: Chris Wilson ch...@chris-wilson.co.uk Date: Tue, 29 Nov 2011 15:12:16 + Subject: [PATCH] drm/i915: Only clear the GPU domains upon a successful finish -- js suse labs ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: WARNING: at mm/slub.c:3357, kernel BUG at mm/slub.c:3413
On 2011.12.03 at 14:31 -0500, Jerome Glisse wrote: On Sat, Dec 3, 2011 at 7:29 AM, Markus Trippelsdorf mar...@trippelsdorf.de wrote: On 2011.12.03 at 12:20 +, Dave Airlie wrote: FIX idr_layer_cache: Marking all objects used Yesterday I couldn't reproduce the issue at all. But today I've hit exactly the same spot again. (CCing the drm list) If I had to guess it looks like 0 is getting written back to some random page by the GPU maybe, it could be that the GPU is in some half setup state at boot or on a reboot does it happen from a cold boot or just warm boot or kexec? Only happened with kexec thus far. Cold boot seems to be fine. -- Markus Can you add radeon.no_wb=1 to your kexec kernel paramater an see if you can reproduce. No, I cannot reproduce the issue with radeon.no_wb=1. (I write this after 700 successful kexec iterations...) -- Markus ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 43504] New: tex2D() artifacts (tiling related?) on AMD RV670
https://bugs.freedesktop.org/show_bug.cgi?id=43504 Bug #: 43504 Summary: tex2D() artifacts (tiling related?) on AMD RV670 Classification: Unclassified Product: Mesa Version: git Platform: Other OS/Version: All Status: NEW Severity: major Priority: medium Component: Drivers/Gallium/r600 AssignedTo: dri-devel@lists.freedesktop.org ReportedBy: kam1k...@gmail.com Created attachment 54101 -- https://bugs.freedesktop.org/attachment.cgi?id=54101 Screenshot showing problem This is what I'm doing: 1) render scene to render target texture A 2) render quad on screen to show RTT A data When on the second step, I am using a fragment shader that calls tex2D() to retrieve the RTT color data, however I get artifacts as shown on the attached screenshot. Whenever I restart the application, I get different corruption. I'm not sure the problem is when reading from the texture, or writing on it. If I output colors without using tex2D() it all works fine. -- 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 43504] render to texture artifacts (tiling related?) on AMD RV670
https://bugs.freedesktop.org/show_bug.cgi?id=43504 Micael Dias kam1k...@gmail.com changed: What|Removed |Added Summary|tex2D() artifacts (tiling |render to texture artifacts |related?) on AMD RV670 |(tiling related?) on AMD ||RV670 -- 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 43504] render to texture artifacts (tiling related?) on AMD RV670
https://bugs.freedesktop.org/show_bug.cgi?id=43504 --- Comment #1 from Micael Dias kam1k...@gmail.com 2011-12-03 21:26:41 PST --- Created attachment 54102 -- https://bugs.freedesktop.org/attachment.cgi?id=54102 Contents of RTT After some more messing around I have proof that the problem is when rendering to the texture. Not when reading from it. See attachment. -- 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 43504] render to texture artifacts (tiling related?) on AMD RV670
https://bugs.freedesktop.org/show_bug.cgi?id=43504 Micael Dias kam1k...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||NOTABUG --- Comment #2 from Micael Dias kam1k...@gmail.com 2011-12-03 21:33:32 PST --- The bug was on my app. Sorry. -- 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
