dri-devel May 2013

dri-devel@lists.freedesktop.org

116 participants
705 discussions

Re: every 10s I get "[drm:drm_edid_block_valid] *ERROR* EDID checksum is invalid ..."
by Jonathan Nieder 17 Feb '14

17 Feb '14

Hi dri developers, Two corrupt-EDID/dmesg-spam puzzles for you. Seems to be a regression, though I'm not sure from when. Stuart Pook writes[1]: > Every 10 seconds I get the messages at the end of my bug report in > /var/log/kern.log. My /var/log/kern.log is very big! [...] > I have a Benq Product Name FP241W manufactured February 2007 Revision > B4-125 and used to use the DVI input. The EDID data in the DVI input > suddenly failed and the my PC would not longer boot. I plugged my PC > into the HDMI input of the monitor and the machine boots but X does not > start at the correct resolution. It appears that the EDID data from HMDI > input does not propose "1920x1200". [...] > So once X is running > I unplug my PC from the HDMI input and plug it into the DVI input. All > works well, the screen saver makes the screen go into standby mode, > except that the kernel tells me that the EDID data is not correct every > 10 seconds. Is there a way to make it stop? [...] > [drm:drm_edid_block_valid] *ERROR* EDID checksum is invalid, remainder is 34 > [drm:drm_edid_block_valid] *ERROR* Raw EDID: > <3>a1 80 ff ff ff ff ff 00 09 d1 db 76 be 0f 00 00 ...........v.... > <3>07 11 01 03 80 34 21 78 ea 5a d5 a7 56 4b 9b 24 .....4!x.Z..VK.$ > <3>13 50 54 bd ef 80 71 4f 81 90 81 80 81 8c a9 40 .PT...qO.......@ > <3>b3 00 01 01 01 01 28 3c 80 a0 70 b0 23 40 30 20 ......(<..p.#@0 > <3>36 00 07 44 21 00 00 1e d5 09 80 a0 20 5e 63 10 6..D!....... ^c. > <3>10 60 52 08 78 2d 11 00 00 1a 00 00 00 fd 00 38 .`R.x-.........8 > <3>4c 1e 53 11 00 0a 20 20 20 20 20 20 00 00 00 fc L.S... .... > <3>00 42 65 6e 51 20 32 34 31 57 0a 20 20 20 00 dc .BenQ 241W. .. Lisandro Damián Nicanor Pérez Meyer writes[1]: > With a dual screen setup. Not so long ago (less than a week) both monitors > (ViewSonic VG2021wm) were working fine. Somehow the monitor connected to the > DVI port started not being detected correctly on boot (wrong edid?). Dmesg > shows: > > [drm:drm_edid_block_valid] *ERROR* EDID checksum is invalid, remainder is 54 > [drm:drm_edid_block_valid] *ERROR* Raw EDID: > <3>00 ff ff ff ff ff ff 00 5a 63 1e d9 01 01 01 01 ........Zc...... > <3>18 11 01 03 0e 2b 1b 78 2e cf c5 a3 5a 49 a0 25 .....+.x....ZI.% > <3>12 50 54 bf ef 80 81 80 81 40 71 4f 01 01 01 01 .PT......@qO.... > <3>01 01 01 01 01 01 21 39 90 30 62 1a 27 40 68 b0 ......!9.0b.'@h. > <3>36 00 b1 0e 11 00 00 1c 36 00 00 ff 00 51 44 57 6.......6....QDW > <3>30 37 32 34 36 30 38 36 37 0a 00 00 00 fd 00 32 072460867......2 > <3>4b 1e 52 11 00 0a 20 20 20 20 20 20 00 00 00 fc K.R... .... > <3>00 56 47 32 30 32 31 77 6d 2d 32 0a 20 20 00 64 .VG2021wm-2. .d > > And so I can't go more than 1024x768 on a 1680x1050 capable LCD. As this was > working some days ago, there must have been a regression somewhere :-/ [...] > On Vie 29 Abr 2011 22:08:09 Jonathan Nieder escribió: >> Thanks. Could you try the patch from >> >> https://bugs.freedesktop.org/show_bug.cgi?id=27708#c7 >> >> and see what happens when booting with the drm.edid_strict=0 option? > > The patch works perfectly, so at least I have a workaround :-) Thank you! > > Now the question is why the DVI port gets a corrupt EDID while the VGA port > gets it right. Or maybe the code processing the EDID of the DVI port is wrong? > > Don't heasitate in contacting me if I can be of any further help. Known problem? Ideas? Jonathan [1] There are many more details in the original reports, at http://bugs.debian.org/622993 https://bugs.freedesktop.org/show_bug.cgi?id=31943 looks vaguely similar.

5 13

[Bug 56534] New: All anti-aliasing methods buggy at cayman
by bugzilla-daemon＠freedesktop.org 04 Feb '14

04 Feb '14

https://bugs.freedesktop.org/show_bug.cgi?id=56534 Priority: medium Bug ID: 56534 Assignee: dri-devel(a)lists.freedesktop.org Summary: All anti-aliasing methods buggy at cayman Severity: normal Classification: Unclassified OS: Linux (All) Reporter: v10lator(a)myway.de Hardware: x86-64 (AMD64) Status: NEW Version: XOrg CVS Component: DRM/Radeon Product: DRI Created attachment 69244 --> https://bugs.freedesktop.org/attachment.cgi?id=69244&action=edit A in-game screenshot without any anti-aliasing method active. MSAA looks just ugly (not like anti-aliasing should look like) and Oil Rush spams "OpenGL error: invalid operation", MLAA doesn't seem to do anything and FXAA just gives a white screen. All anti-aliasing methods where tested with Oil Rush. Exact settings: MSAA: 8x, setted from the game launcher. FXAA: Setted from the game launcher. MLAA: 32x (for both, 2D and 3D) forced by drirc. -- You are receiving this mail because: You are the assignee for the bug.

1 29

[Bug 58354] New: r600g locks up in Unigine Tropics with drm-next
by bugzilla-daemon＠freedesktop.org 26 Jan '14

26 Jan '14

https://bugs.freedesktop.org/show_bug.cgi?id=58354 Priority: medium Bug ID: 58354 Assignee: dri-devel(a)lists.freedesktop.org Summary: r600g locks up in Unigine Tropics with drm-next Severity: critical Classification: Unclassified OS: All Reporter: alexandre.f.demers(a)gmail.com Hardware: Other Status: NEW Version: git Component: Drivers/Gallium/r600 Product: Mesa Testing with drm-next with latest mesa, ddx and drm, Unigine Tropics locks up when launching the demo. The problem appears somewhere between a636a9829175987e74ddd28a2e87ed17ff7adfdc (locks) and 1a1494def7eacbd25db05185aa2e81ef90892460 (OK). I'll pinpoint it tomorrow. -- You are receiving this mail because: You are the assignee for the bug.

1 30

[Bug 58667] New: Random crashes on CAYMAN
by bugzilla-daemon＠freedesktop.org 26 Jan '14

26 Jan '14

https://bugs.freedesktop.org/show_bug.cgi?id=58667 Priority: medium Bug ID: 58667 Assignee: dri-devel(a)lists.freedesktop.org Summary: Random crashes on CAYMAN Severity: normal Classification: Unclassified OS: All Reporter: v10lator(a)myway.de Hardware: Other Status: NEW Version: DRI CVS Component: DRM/Radeon Product: DRI This is with newest mesa from git with kernel 3.8-rc1 (+ this patch: http://cgit.freedesktop.org/~agd5f/linux/commit/?h=drm-fixes-3.8&id=668bbc8… ) The screen first freezes (mouse still movable, keyboard not responding, not even to MagSysRQ), then the monitor goes off (standby) and back on with only garbage on the screen. Not sure if this has anything to do with it (but it should get fixed anyway) but dmesg gets spammed with this: [ 533.928472] radeon 0000:03:00.0: GPU fault detected: 146 0x00335514 [ 533.928477] radeon 0000:03:00.0: VM_CONTEXT1_PROTECTION_FAULT_ADDR 0x00000000 [ 533.928483] radeon 0000:03:00.0: VM_CONTEXT1_PROTECTION_FAULT_STATUS 0x00000000 where the address isn't always the same, example: [ 533.928374] radeon 0000:03:00.0: GPU fault detected: 146 0x0033ed14 [ 533.928379] radeon 0000:03:00.0: VM_CONTEXT1_PROTECTION_FAULT_ADDR 0x00000000 [ 533.928385] radeon 0000:03:00.0: VM_CONTEXT1_PROTECTION_FAULT_STATUS 0x00000000 -- You are receiving this mail because: You are the assignee for the bug.

1 51

[Bug 62311] New: (kernel) memory leak
by bugzilla-daemon＠freedesktop.org 23 Jan '14

23 Jan '14

https://bugs.freedesktop.org/show_bug.cgi?id=62311 Priority: medium Bug ID: 62311 Assignee: dri-devel(a)lists.freedesktop.org Summary: (kernel) memory leak Severity: major Classification: Unclassified OS: Linux (All) Reporter: fdo(a)won2.de Hardware: x86-64 (AMD64) Status: NEW Version: unspecified Component: DRM/Radeon Product: DRI I'm experiencing a (kernel) memory leak for several months now and it seems to got worse. I found a bug on https://bugzilla.kernel.org/show_bug.cgi?id=43751#c11 but no solution yet (disregard command 12, it's not true ;)). I asked on IRC #fdo and #radeon and got told to file a bug here on fdo. At some point I always run out of main memory and got lots of kernel messages like those: [drm:radeon_gem_object_create] *ERROR* Failed to allocate GEM object (4096, 6, 4096, -12) [TTM] Out of kernel memory [TTM] Out of kernel memory Repeating over and over again. I'm currently running radeon driver 7.1.0, mesa 9.0.1, xorg-server 1.13.1, KDE 4.9.5 (tried with compositing enabled and disabled). I don't know what to do or how to debug this, could anybody please help? -- You are receiving this mail because: You are the assignee for the bug.

1 5

[Bug 50892] New: Invalid command stream with TURKS running Cinnamon
by bugzilla-daemon＠freedesktop.org 23 Jan '14

23 Jan '14

https://bugs.freedesktop.org/show_bug.cgi?id=50892 Bug #: 50892 Summary: Invalid command stream with TURKS running Cinnamon Classification: Unclassified Product: DRI Version: XOrg CVS Platform: x86-64 (AMD64) OS/Version: Linux (All) Status: NEW Severity: major Priority: medium Component: DRM/Radeon AssignedTo: dri-devel(a)lists.freedesktop.org ReportedBy: zboszor(a)pr.hu I got these errors on my AMD A4-3300 notebook (ASUS K53TA) after I upgraded to kernel 3.4.0 and xorg-x11-drv-ati-6.14.4-6.20120602git930760942 yesterday evening (CET): Jun 7 19:26:41 localhost kernel: [ 889.757979] radeon 0000:00:01.0: evergreen_cs_track_validate_cb:439 cb[0] bo too small (layer size 18874368, offset 0, max layer 1, bo size 4718592, slice 18431) Jun 7 19:26:41 localhost kernel: [ 889.757986] radeon 0000:00:01.0: evergreen_cs_track_validate_cb:443 problematic surf: (1536 768) (4 4 1 1 1 64 1) Jun 7 19:26:41 localhost kernel: [ 889.757989] radeon 0000:00:01.0: evergreen_packet3_check:2055 invalid cmd stream 2587 Jun 7 19:26:41 localhost kernel: [ 889.757993] [drm:radeon_cs_ib_chunk] *ERROR* Invalid command stream ! Jun 7 19:26:50 localhost systemd-tmpfiles[1176]: Successfully loaded SELinux database in 20ms 513us, size on heap is 532K. Jun 7 19:26:50 localhost systemd-tmpfiles[1176]: stat(/run/user/zozo/gvfs) failed: Permission denied Jun 7 19:27:04 localhost kernel: [ 913.093258] radeon 0000:00:01.0: evergreen_cs_track_validate_cb:439 cb[0] bo too small (layer size 10223616, offset 0, max layer 1, bo size 2555904, slice 9983) Jun 7 19:27:04 localhost kernel: [ 913.093272] radeon 0000:00:01.0: evergreen_cs_track_validate_cb:443 problematic surf: (1024 624) (4 4 1 1 1 64 1) Jun 7 19:27:04 localhost kernel: [ 913.093280] radeon 0000:00:01.0: evergreen_packet3_check:2055 invalid cmd stream 5344 Jun 7 19:27:04 localhost kernel: [ 913.093286] [drm:radeon_cs_ib_chunk] *ERROR* Invalid command stream ! Jun 7 19:27:05 localhost kernel: [ 914.074877] radeon 0000:00:01.0: evergreen_cs_track_validate_texture:796 texture bo too small (layer size 10223616, offset 0, max layer 1, depth 1, bo size 2555904) (1024 624) Jun 7 19:27:05 localhost kernel: [ 914.074883] [drm:radeon_cs_ib_chunk] *ERROR* Invalid command stream ! Jun 7 19:27:06 localhost kernel: [ 915.073121] radeon 0000:00:01.0: evergreen_cs_track_validate_texture:796 texture bo too small (layer size 10223616, offset 0, max layer 1, depth 1, bo size 2555904) (1024 624) Jun 7 19:27:06 localhost kernel: [ 915.073127] [drm:radeon_cs_ib_chunk] *ERROR* Invalid command stream ! Jun 7 19:27:06 localhost kernel: [ 915.166232] radeon 0000:00:01.0: evergreen_cs_track_validate_texture:796 texture bo too small (layer size 10223616, offset 0, max layer 1, depth 1, bo size 2555904) (1024 624) Jun 7 19:27:06 localhost kernel: [ 915.166237] [drm:radeon_cs_ib_chunk] *ERROR* Invalid command stream ! Jun 7 19:27:07 localhost kernel: [ 915.193506] radeon 0000:00:01.0: evergreen_cs_track_validate_texture:796 texture bo too small (layer size 10223616, offset 0, max layer 1, depth 1, bo size 2555904) (1024 624) Jun 7 19:27:07 localhost kernel: [ 915.193511] [drm:radeon_cs_ib_chunk] *ERROR* Invalid command stream ! Jun 7 19:27:07 localhost kernel: [ 915.291245] radeon 0000:00:01.0: evergreen_cs_track_validate_texture:796 texture bo too small (layer size 10223616, offset 0, max layer 1, depth 1, bo size 2555904) (1024 624) Jun 7 19:27:07 localhost kernel: [ 915.291251] [drm:radeon_cs_ib_chunk] *ERROR* Invalid command stream ! Jun 7 19:27:07 localhost kernel: [ 915.317023] radeon 0000:00:01.0: evergreen_cs_track_validate_texture:796 texture bo too small (layer size 10223616, offset 0, max layer 1, depth 1, bo size 2555904) (1024 624) Jun 7 19:27:07 localhost kernel: [ 915.317028] [drm:radeon_cs_ib_chunk] *ERROR* Invalid command stream ! Jun 7 19:27:07 localhost kernel: [ 915.327642] radeon 0000:00:01.0: evergreen_cs_track_validate_texture:796 texture bo too small (layer size 10223616, offset 0, max layer 1, depth 1, bo size 2555904) (1024 624) Jun 7 19:27:07 localhost kernel: [ 915.327649] [drm:radeon_cs_ib_chunk] *ERROR* Invalid command stream ! Jun 7 19:27:07 localhost kernel: [ 915.343749] radeon 0000:00:01.0: evergreen_cs_track_validate_texture:796 texture bo too small (layer size 10223616, offset 0, max layer 1, depth 1, bo size 2555904) (1024 624) Jun 7 19:27:07 localhost kernel: [ 915.343761] [drm:radeon_cs_ib_chunk] *ERROR* Invalid command stream ! Jun 7 19:27:07 localhost kernel: [ 915.360748] radeon 0000:00:01.0: evergreen_cs_track_validate_texture:796 texture bo too small (layer size 10223616, offset 0, max layer 1, depth 1, bo size 2555904) (1024 624) Jun 7 19:27:07 localhost kernel: [ 915.360760] [drm:radeon_cs_ib_chunk] *ERROR* Invalid command stream ! At first I thought I had to RMA the notebook because the display only showed a single horizontal line in the middle of the screen. Rebooting the machine showed various problems: missing icons (like the "faces" icon for users on the GDM screen) and after logging in various bluish - magentaish rectangles on the screen. Rebooting back to 3.3.7 at the time didn't fix the problem but after yum reinstall "*" at least 3.3.7-1.fc17 is usable. 3.4.0-1.fc17 reliably shows this problem. Today I accidentally reproduced this on my desktop machine with AMD Radeon HD6570 and kernel 3.4.0-1.fc17. I use Cinnamon on both machines. It turns out that the bad behaviour only shows up (but reliably) if I move the mouse pointer to the "magic spot" on the screen, i.e. the top-left corner so the workspace switcher kicks in. Killing X with Ctrl-Alt-BkSp cures it. The difference between my desktop machine and the notebook is that for some reason, when X starts, the cursor shows up in the top-left corner on my notebook but in the middle of the screen on my desktop machine. So, the error occurred on the notebook as soon login was attempted without moving the mouse. Currently installed relevant software versions: kernel-3.3.7-1.fc17.x86_64 kernel-3.4.0-1.fc17.x86_64 mesa-libGL-8.0.3-1.fc17.i686 mesa-libGL-8.0.3-1.fc17.x86_64 mesa-dri-drivers-8.0.3-1.fc17.x86_64 mesa-dri-drivers-8.0.3-1.fc17.i686 xorg-x11-server-Xorg-1.12.0-5.fc17.x86_64 xorg-x11-drv-ati-6.14.4-6.20120602git930760942.fc17.x86_64 cinnamon-1.4.0-5.UP1.fc17.x86_64 muffin-1.0.3-3.fc17.x86_64 Since I heard about the current state of ColorTiling2D is not yet usable, I thought it might somehow kick in and created this file on my notebook: # cat /etc/X11/xorg.conf.d/01-radeon.conf ########################### Section "Device" Identifier "Radeon" Driver "radeon" Option "ColorTiling2D" "off" EndSection ########################### Xorg.0.conf confirms setting ColorTiling2D to off explicitly but it didn't solve the problem on the notebook. The order of events on the notebook: yum upgrade installed these: Jun 7 15:56:23 localhost yum[876]: Updated: avahi-0.6.31-3.fc17.x86_64 Jun 7 15:56:23 localhost yum[876]: Updated: avahi-glib-0.6.31-3.fc17.x86_64 Jun 7 15:56:27 localhost yum[876]: Updated: xulrunner-13.0-1.fc17.x86_64 Jun 7 15:56:28 localhost yum[876]: Updated: xsane-common-0.998-10.fc17.x86_64 Jun 7 15:56:28 localhost yum[876]: Updated: xsane-gimp-0.998-10.fc17.x86_64 Jun 7 15:56:33 localhost yum[876]: Updated: firefox-13.0-1.fc17.x86_64 Jun 7 15:56:34 localhost yum[876]: Updated: avahi-ui-gtk3-0.6.31-3.fc17.x86_64 Jun 7 15:56:34 localhost yum[876]: Updated: avahi-gobject-0.6.31-3.fc17.x86_64 Jun 7 15:56:36 localhost yum[876]: Updated: fontconfig-devel-2.8.0-7.fc17.x86_64 Jun 7 15:56:39 localhost yum[876]: Updated: kernel-headers-3.4.0-1.fc17.x86_64 Jun 7 15:56:39 localhost yum[876]: Updated: xorg-x11-drv-synaptics-1.6.1-1.fc17.x86_64 Jun 7 15:56:40 localhost yum[876]: Updated: avahi-autoipd-0.6.31-3.fc17.x86_64 Jun 7 15:56:41 localhost yum[876]: Updated: kpartx-0.4.9-26.fc17.x86_64 Jun 7 15:56:45 localhost yum[876]: Updated: fontconfig-2.8.0-7.fc17.i686 Jun 7 15:56:55 localhost yum[876]: Installed: kernel-3.4.0-1.fc17.x86_64 yum --enablerepo=updates-testing upgrade libX11* xorg-x11-drv-ati installed these: Jun 7 15:59:23 localhost yum[10612]: Updated: libX11-common-1.5.0-1.fc17.noarch Jun 7 15:59:26 localhost yum[10612]: Updated: libX11-1.5.0-1.fc17.x86_64 Jun 7 15:59:31 localhost yum[10612]: Updated: libX11-devel-1.5.0-1.fc17.x86_64 Jun 7 15:59:33 localhost yum[10612]: Updated: xorg-x11-drv-ati-6.14.4-6.20120602git930760942.fc17.x86_64 Jun 7 15:59:34 localhost yum[10612]: Updated: libX11-1.5.0-1.fc17.i686 Then the error kicked in after a reboot. I flashed the BIOS from version 207 to 214 after that, didn't solve anything. Then yum distro-sync downgraded these: Jun 7 19:28:28 localhost yum[1392]: Installed: libX11-common-1.4.99.901-2.fc17.noarch Jun 7 19:28:29 localhost yum[1392]: Installed: libX11-1.4.99.901-2.fc17.x86_64 Jun 7 19:28:32 localhost yum[1392]: Installed: libX11-devel-1.4.99.901-2.fc17.x86_64 Jun 7 19:28:33 localhost yum[1392]: Installed: xorg-x11-drv-ati-6.14.4-5.20120417git0bda305f7.fc17.x86_64 Jun 7 19:28:34 localhost yum[1392]: Installed: libX11-1.4.99.901-2.fc17.i686 Jun 7 19:28:57 localhost yum[1403]: Updated: libX11-common-1.5.0-1.fc17.noarch Jun 7 19:28:57 localhost yum[1403]: Updated: libX11-1.5.0-1.fc17.x86_64 Jun 7 19:29:01 localhost yum[1403]: Updated: libX11-devel-1.5.0-1.fc17.x86_64 Jun 7 19:29:02 localhost yum[1403]: Updated: libX11-1.5.0-1.fc17.i686 Since yesterday the above libX11* and xorg-x11-drv-ati versions were moved to updated from updates-testing. Today I performed a yum reinstall "*" to ensure that every packages are ok. memtest86+ was ran on the machine after I bought it in January, it happily ran Fedora 16. Then it was upgraded to F17 during its RC series and only yum upgrade was performed since then, possibly missing some rebuilds which yum reinstall "*" finally included. Or it was simply a gremlin in the machine. After this yum reinstall "*", I rebooted several times switching between 3.4.0 and 3.3.7. 3.3.7 is usable, 3.4.0 triggers the "invalid command stream" messages in the syslog. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.

1 14

[Bug 45290] New: [bisected r200] fdo23670-drawpix_stencil fails and crashes
by bugzilla-daemon＠freedesktop.org 22 Jan '14

22 Jan '14

https://bugs.freedesktop.org/show_bug.cgi?id=45290 Bug #: 45290 Summary: [bisected r200] fdo23670-drawpix_stencil fails and crashes Classification: Unclassified Product: Mesa Version: git Platform: All OS/Version: All Status: NEW Severity: normal Priority: medium Component: Drivers/DRI/r200 AssignedTo: dri-devel(a)lists.freedesktop.org ReportedBy: idr(a)freedesktop.org There seem to be at least two problems with fdo23670-drawpix_stencil (and other stencil tests) on r200. There is incorrect rendering, which bisects to the first commit listed below, and a crash, which bisects to the second. The backtrace of the segfault is: (gdb) bt #0 0x00007ffff5a2fd5f in radeon_unmap_renderbuffer_s8z24 (ctx=0x6992d0, rb=0x85d2d0) at radeon_fbo.c:270 #1 0x00007ffff5a2fe31 in radeon_unmap_renderbuffer (ctx=0x6992d0, rb=0x85d2d0) at radeon_fbo.c:290 #2 0x00007ffff5a40726 in radeon_renderbuffer_unmap (ctx=0x6992d0, rb=0x85d2d0) at radeon_span.c:510 #3 0x00007ffff5a408a8 in radeon_unmap_framebuffer (ctx=0x6992d0, fb=0x85cc50) at radeon_span.c:545 #4 0x00007ffff5a40a67 in radeonSpanRenderFinish (ctx=0x6992d0) at radeon_span.c:579 #5 0x00007ffff5d0d249 in swrast_render_finish (ctx=0x6992d0) at swrast/s_context.h:335 #6 0x00007ffff5d0f5ae in _swrast_DrawPixels (ctx=0x6992d0, x=50, y=50, width=20, height=20, format=6401, type=5121, unpack=0x6a8bb0, pixels=0x7fffffffdf30) at swrast/s_drawpix.c:750 #7 0x00007ffff5c0c9a6 in _mesa_meta_DrawPixels (ctx=0x6992d0, x=50, y=50, width=20, height=20, format=6401, type=5121, unpack=0x6a8bb0, pixels=0x7fffffffdf30) at drivers/common/meta.c:2217 #8 0x00007ffff5ca6311 in _mesa_DrawPixels (width=20, height=20, format=6401, type=5121, pixels=0x7fffffffdf30) at main/drawpix.c:131 #9 0x0000000000429ba0 in piglit_display () at /home/idr/devel/graphics/piglit/tests/bugs/fdo23670-drawpix_stencil.c:68 #10 0x0000000000429c51 in display () at /home/idr/devel/graphics/piglit/tests/util/piglit-framework.c:56 #11 0x00007ffff7b0db07 in ?? () from /usr/lib64/libglut.so.3 #12 0x00007ffff7b11269 in fgEnumWindows () from /usr/lib64/libglut.so.3 #13 0x00007ffff7b0dfe2 in glutMainLoopEvent () from /usr/lib64/libglut.so.3 #14 0x00007ffff7b0e8d5 in glutMainLoop () from /usr/lib64/libglut.so.3 #15 0x000000000042a3c0 in main (argc=1, argv=0x7fffffffe4b8) at /home/idr/devel/graphics/piglit/tests/util/piglit-framework.c:304 (gdb) print tiled_s8z24_map $1 = (uint32_t *) 0x7ffff4d09000 (gdb) print dst_offset $2 = 53288 (gdb) print untiled_s8z24_map $3 = (uint32_t *) 0x868b10 (gdb) print src_offset $4 = 256 (gdb) print tiled_s8z24_map[dst_offset/4] Cannot access memory at address 0x7ffff4d16028 (gdb) commit 345fc4161967f15fb80848cd7dc6a63100f8c12d Author: Eric Anholt <eric(a)anholt.net> Date: Wed Oct 12 17:05:20 2011 -0700 swrast: Convert color glReadPixels slow path to using MapRenderbuffer. This may be a bit slower than before because we're switching from per-format compiled loops in GetRow to _mesa_unpack_rgba_block_unpack's loop around a callback to unpack a pixel. The solution there would be to make _mesa_unpack_rgba_block fold the span loop into the format handlers. (On the other hand, function call overhead will hardly matter if MapRenderbuffer means the driver gets the data into cacheable memory instead of uncached). The adjust_colors code should no longer be required, since the unpack function does the 565 to float conversion in a single pass instead of converting it (poorly) through 8888 as apparently happened in the past. Reviewed-by: Brian Paul <brianp(a)vmware.com> commit 7d91ecf7a3a08c01a704f2d427444f7a97991680 Author: Dave Airlie <airlied(a)redhat.com> Date: Mon Dec 5 19:15:04 2011 +0000 radeon/r200: add draw/stencil buffer detiling This moves the detiling to the fbo mapping, r200 depth is always tiled, and we can't detile it with the blitter. Signed-off-by: Dave Airlie <airlied(a)redhat.com> -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.

1 5

[Bug 43441] New: [RADEON:KMS:RV370:RESUME] garbage on screen (console or X) after suspend-resume with radeon (KMS only)
by bugzilla-daemon＠bugzilla.kernel.org 17 Jan '14

17 Jan '14

https://bugzilla.kernel.org/show_bug.cgi?id=43441 Summary: [RADEON:KMS:RV370:RESUME] garbage on screen (console or X) after suspend-resume with radeon (KMS only) Product: Drivers Version: 2.5 Kernel Version: 2.6.32-3.5rc2 Platform: All OS/Version: Linux Tree: Mainline Status: NEW Severity: high Priority: P1 Component: Video(DRI - non Intel) AssignedTo: drivers_video-dri(a)kernel-bugs.osdl.org ReportedBy: cyberbat(a)lavabit.com Regression: No Created an attachment (id=73681) --> (https://bugzilla.kernel.org/attachment.cgi?id=73681) full kernel 3.5rc2 log Screen on my Samsung R50 notebook with AMD Mobility Radeon X300 (RV370 chipset) become completely unusable after resume (watch screenshots). I've tested different kernels from 2.6.32 till 3.5rc2. Just the same thing. The thing happens only with KMS turned on. I have tried suspend from X (Xfce) and from console (using pm-suspend). I repeatedly get following errors in kernel log after resume: Jun 15 18:56:39 localhost kernel: radeon 0000:01:00.0: GPU lockup CP stall for more than 10000msec Jun 15 18:56:39 localhost kernel: radeon 0000:01:00.0: GPU lockup (waiting for 0x000000000000023d last fence id 0x000000000000023c) Jun 15 18:56:39 localhost kernel: Failed to wait GUI idle while programming pipes. Bad things might happen. Jun 15 18:56:39 localhost kernel: radeon 0000:01:00.0: (r300_asic_reset:392) RBBM_STATUS=0x80010140 Jun 15 18:56:39 localhost kernel: radeon 0000:01:00.0: (r300_asic_reset:411) RBBM_STATUS=0x80010140 Jun 15 18:56:39 localhost kernel: radeon 0000:01:00.0: (r300_asic_reset:423) RBBM_STATUS=0x00000140 Jun 15 18:56:39 localhost kernel: radeon 0000:01:00.0: GPU reset succeed Jun 15 18:56:39 localhost kernel: radeon 0000:01:00.0: GPU reset succeed Jun 15 18:56:39 localhost kernel: radeon 0000:01:00.0: f5eaf400 unpin not necessary Jun 15 18:56:39 localhost kernel: [drm] radeon: 1 quad pipes, 1 Z pipes initialized. Jun 15 18:56:39 localhost kernel: [drm] PCIE GART of 512M enabled (table at 0x00000000D0040000). Jun 15 18:56:39 localhost kernel: radeon 0000:01:00.0: WB enabled Jun 15 18:56:39 localhost kernel: radeon 0000:01:00.0: fence driver on ring 0 use gpu addr 0x00000000b0000000 and cpu addr 0xff8de000 Jun 15 18:56:39 localhost kernel: [drm] radeon: ring at 0x00000000B0001000 Jun 15 18:56:39 localhost kernel: [drm] ring test succeeded in 1 usecs Jun 15 18:56:39 localhost kernel: [drm] ib test succeeded in 0 usecs ... Jun 15 18:58:32 localhost kernel: radeon 0000:01:00.0: GPU lockup CP stall for more than 10000msec Jun 15 18:58:32 localhost kernel: radeon 0000:01:00.0: GPU lockup (waiting for 0x0000000000000490 last fence id 0x000000000000033b) Jun 15 18:58:32 localhost kernel: Failed to wait GUI idle while programming pipes. Bad things might happen. Jun 15 18:58:32 localhost kernel: radeon 0000:01:00.0: (r300_asic_reset:392) RBBM_STATUS=0x80010140 Jun 15 18:58:32 localhost kernel: radeon 0000:01:00.0: (r300_asic_reset:411) RBBM_STATUS=0x80010140 Jun 15 18:58:32 localhost kernel: radeon 0000:01:00.0: (r300_asic_reset:423) RBBM_STATUS=0x00000140 Jun 15 18:58:32 localhost kernel: radeon 0000:01:00.0: GPU reset succeed Jun 15 18:58:32 localhost kernel: radeon 0000:01:00.0: GPU reset succeed Jun 15 18:58:32 localhost kernel: radeon 0000:01:00.0: f5eaf400 unpin not necessary Jun 15 18:58:32 localhost kernel: [drm] radeon: 1 quad pipes, 1 Z pipes initialized. Jun 15 18:58:32 localhost kernel: [drm] PCIE GART of 512M enabled (table at 0x00000000D0040000). Jun 15 18:58:32 localhost kernel: radeon 0000:01:00.0: WB enabled Jun 15 18:58:32 localhost kernel: radeon 0000:01:00.0: fence driver on ring 0 use gpu addr 0x00000000b0000000 and cpu addr 0xff8de000 Jun 15 18:58:32 localhost kernel: [drm] radeon: ring at 0x00000000B0001000 Jun 15 18:58:32 localhost kernel: [drm] ring test succeeded in 1 usecs Jun 15 18:58:32 localhost kernel: [drm] ib test succeeded in 0 usecs Jun 15 19:00:46 localhost /usr/sbin/gpm[1110]: *** info [daemon/processrequest.c(42)]: Jun 15 19:00:46 localhost /usr/sbin/gpm[1110]: Request on 6 (console 1) Jun 15 19:01:42 localhost kernel: radeon 0000:01:00.0: GPU lockup CP stall for more than 200579msec Jun 15 19:01:42 localhost kernel: radeon 0000:01:00.0: GPU lockup (waiting for 0x000000000000058f) Jun 15 19:01:42 localhost kernel: radeon 0000:01:00.0: failed to get a new IB (-35) Jun 15 19:01:42 localhost kernel: [drm:radeon_cs_ib_chunk] *ERROR* Failed to get ib ! Jun 15 19:01:42 localhost kernel: Failed to wait GUI idle while programming pipes. Bad things might happen. Jun 15 19:01:42 localhost kernel: radeon 0000:01:00.0: (r300_asic_reset:392) RBBM_STATUS=0x80010140 Jun 15 19:01:42 localhost kernel: radeon 0000:01:00.0: (r300_asic_reset:411) RBBM_STATUS=0x80010140 Jun 15 19:01:42 localhost kernel: radeon 0000:01:00.0: (r300_asic_reset:423) RBBM_STATUS=0x00000140 Jun 15 19:01:42 localhost kernel: radeon 0000:01:00.0: GPU reset succeed Jun 15 19:01:42 localhost kernel: radeon 0000:01:00.0: GPU reset succeed I recognize that I have really old notebook, but It has enough power for my tasks so it will be good to use KMS on it cause I loose a lot of features of X without it. -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching the assignee of the bug.

1 8

[Bug 49747] New: dpms on only works on DP0 on a hd5700
by bugzilla-daemon＠freedesktop.org 17 Jan '14

17 Jan '14

https://bugs.freedesktop.org/show_bug.cgi?id=49747 Bug #: 49747 Summary: dpms on only works on DP0 on a hd5700 Classification: Unclassified Product: DRI Version: XOrg CVS Platform: Other OS/Version: All Status: NEW Severity: normal Priority: medium Component: DRM/Radeon AssignedTo: dri-devel(a)lists.freedesktop.org ReportedBy: daniel(a)ffwll.ch On my hd5700 with 5 dp outputs, dpms off works as expected, but dpms on only brings back the screen on output 0. 06:00.0 VGA compatible controller [0300]: Advanced Micro Devices [AMD] nee ATI Juniper [Radeon HD 5700 Series] [1002:68b8] 06:00.1 Audio device [0403]: Advanced Micro Devices [AMD] nee ATI Juniper HDMI Audio [Radeon HD 5700 Series] [1002:aa58] Kernel is drm-next as of a few days ago, precisely: commit 4f256e8aa3eda15c11c3cec3ec5336e1fc579cbd Merge: 4086b1e dc257cf Author: Dave Airlie <airlied(a)redhat.com> Date: Mon May 7 16:09:09 2012 +0100 Merge branch 'for-airlied' of git://people.freedesktop.org/~danvet/drm-intel Daniel prepared this branch with a back-merge as git was getting very confused about changes in intel_display.c plus a bunch of drm/i915 patches. I'll attach dmesg, Xorg.log and xrandr --verbose. If I should just retest with latest drm-next, please just holler. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.

1 22

[Bug 64810] New: EGL/Gles/Weston give segfault on RADEONSI
by bugzilla-daemon＠freedesktop.org 15 Jan '14

15 Jan '14

https://bugs.freedesktop.org/show_bug.cgi?id=64810 Priority: medium Bug ID: 64810 Assignee: dri-devel(a)lists.freedesktop.org Summary: EGL/Gles/Weston give segfault on RADEONSI Severity: enhancement Classification: Unclassified OS: Linux (All) Reporter: jrch2k10(a)gmail.com Hardware: x86-64 (AMD64) Status: NEW Version: git Component: Drivers/Gallium/radeonsi Product: Mesa Just informing since i can't see it in the TODO[i assume they aren't ready], so just for the info. glx and OpenGL works good enough Hardware 01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Cape Verde XT [Radeon HD 7770 GHz Edition] Linux localhost 3.10.0-rc1 #1 SMP PREEMPT Sun May 12 11:20:57 VET 2013 x86_64 AMD FX(tm)-6100 Six-Core Processor AuthenticAMD GNU/Linux Software mesa/libdrm/glamor/ddx/llvm/wayand/weston all daily git builded Issue Egl is not working beyond eglinfo, eglgears and eglscreen_XX segfault GLES is not working at all, any related command segfaults either es1_ or es2_ Wayland/Weston logically doesn't work either GDB throws Program received signal SIGSEGV, Segmentation fault. 0x00007ffff4346cde in r600_init_query_functions () from /usr/lib64/egl/egl_gallium.so -- You are receiving this mail because: You are the assignee for the bug.

1 38

← Newer
1
...
35
36
37
38
39
40
41
...
71
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel May 2013