dri-devel January 2016

dri-devel@lists.freedesktop.org

194 participants
1200 discussions

[Bug 82455] New: Failed to allocate virtual address for buffer
by bugzilla-daemon＠freedesktop.org 31 Aug '18

31 Aug '18

https://bugs.freedesktop.org/show_bug.cgi?id=82455 Priority: medium Bug ID: 82455 Assignee: dri-devel(a)lists.freedesktop.org Summary: Failed to allocate virtual address for buffer Severity: normal Classification: Unclassified OS: Linux (All) Reporter: 407883775(a)qq.com Hardware: SPARC Status: NEW Version: 9.2 Component: Drivers/Gallium/radeonsi Product: Mesa I am update kernel to 3.10.0 , and the mesa version is 9.2.5; Our video card is AMD HD7750 . The system is running very well in text mode. But when I am used startx command start graphic desktop. The X can't work. Our team analysis the problem and read the mesa code. Due to Mesa , I think. our computer arch is "sparc" I sought you commit the bug in the freedesktoporg : http://cgit.freedesktop.org/mesa/mesa/commit/?id=a37835c8eda017f0c955e0927e… but the mesa (version 9.2.5) have this bug. how could i do . pls give me some message . thk . The attachment is system dmesg . The debug message is follow: [dmesg] [ 355.852288] radeon 0000:01:00.0: soffset:0x00100000, eoffset: 0x00200000 [ 355.853024] radeon 0000:01:00.0: tmp->soffset:0x00000000, tmp->eoffset: 0x00000000, size:0x00100000 [ 359.114368] radeon 0000:01:00.0: soffset:0x00100000, eoffset: 0x00200000 [ 359.114399] radeon 0000:01:00.0: tmp->soffset:0x00000000, tmp->eoffset: 0x00000000, size:0x00100000 [ 359.433678] radeon 0000:01:00.0: soffset:0x00100000, eoffset: 0x00200000 [ 359.433711] radeon 0000:01:00.0: tmp->soffset:0x00000000, tmp->eoffset: 0x00000000, size:0x00100000 [ 359.433891] radeon 0000:01:00.0: soffset:0x00100000, eoffset: 0x00200000 [ 359.433915] radeon 0000:01:00.0: tmp->soffset:0x00000000, tmp->eoffset: 0x00000000, size:0x00100000 [ 519.314418] radeon 0000:01:00.0: soffset:0x00100000, eoffset: 0x00200000 [ 519.314453] radeon 0000:01:00.0: tmp->soffset:0x00000000, tmp->eoffset: 0x00000000, size:0x00100000 [ 521.768715] radeon 0000:01:00.0: soffset:0x00100000, eoffset: 0x00200000 [ 521.768746] radeon 0000:01:00.0: tmp->soffset:0x00000000, tmp->eoffset: 0x00000000, size:0x00100000 [ 522.077890] radeon 0000:01:00.0: soffset:0x00100000, eoffset: 0x00200000 [ 522.077924] radeon 0000:01:00.0: tmp->soffset:0x00000000, tmp->eoffset: 0x00000000, size:0x00100000 [ 522.078105] radeon 0000:01:00.0: soffset:0x00100000, eoffset: 0x00200000 [ 522.078129] radeon 0000:01:00.0: tmp->soffset:0x00000000, tmp->eoffset: 0x00000000, size:0x00100000 [ 565.368145] radeon 0000:01:00.0: [radeon_gem_va_ioctl, 525]:args->offset: 0x00800000, argx->flags:22 [ 565.368180] radeon 0000:01:00.0: soffset:0x00800000, eoffset: 0x00802000 [ 565.368201] radeon 0000:01:00.0: tmp->soffset:0x00000000, tmp->eoffset: 0x00000000, size:0x00002000 [ 565.368221] radeon 0000:01:00.0: tmp->soffset:0x00100000, tmp->eoffset: 0x00200000, size:0x00002000 [ 763.251113] radeon 0000:01:00.0: [radeon_gem_va_ioctl, 525]:args->offset: 0x00801000, argx->flags:22 [ 763.251148] radeon 0000:01:00.0: soffset:0x00801000, eoffset: 0x00803000 [ 763.251169] radeon 0000:01:00.0: tmp->soffset:0x00000000, tmp->eoffset: 0x00000000, size:0x00002000 [ 763.251189] radeon 0000:01:00.0: tmp->soffset:0x00100000, tmp->eoffset: 0x00200000, size:0x00002000 [ 763.251210] radeon 0000:01:00.0: tmp->soffset:0x00800000, tmp->eoffset: 0x00802000, size:0x00002000 [ 763.251234] radeon 0000:01:00.0: bo fffff801f3ee2c00 va 0x00000000 conflict with (bo fffff801f3ee3000 0x00800000 0x00802000) [ 763.251855] radeon 0000:01:00.0: [radeon_gem_va_ioctl, 525]:args->offset: 0x00801000, argx->flags:22 [ 763.251878] radeon 0000:01:00.0: soffset:0x00801000, eoffset: 0x00803000 [ 763.251899] radeon 0000:01:00.0: tmp->soffset:0x00000000, tmp->eoffset: 0x00000000, size:0x00002000 [ 763.251919] radeon 0000:01:00.0: tmp->soffset:0x00100000, tmp->eoffset: 0x00200000, size:0x00002000 [ 763.251939] radeon 0000:01:00.0: tmp->soffset:0x00800000, tmp->eoffset: 0x00802000, size:0x00002000 [ 763.251962] radeon 0000:01:00.0: bo fffff801f3ee2c00 va 0x00000000 conflict with (bo fffff801f3ee3000 0x00800000 0x00802000) [ 884.626830] radeon 0000:01:00.0: soffset:0x00100000, eoffset: 0x00200000 [ 884.626864] radeon 0000:01:00.0: tmp->soffset:0x00000000, tmp->eoffset: 0x00000000, size:0x00100000 [ 887.207173] radeon 0000:01:00.0: soffset:0x00100000, eoffset: 0x00200000 [ 887.207204] radeon 0000:01:00.0: tmp->soffset:0x00000000, tmp->eoffset: 0x00000000, size:0x00100000 [ 887.564451] radeon 0000:01:00.0: soffset:0x00100000, eoffset: 0x00200000 [ 887.564488] radeon 0000:01:00.0: tmp->soffset:0x00000000, tmp->eoffset: 0x00000000, size:0x00100000 [ 887.564672] radeon 0000:01:00.0: soffset:0x00100000, eoffset: 0x00200000 [ 887.564696] radeon 0000:01:00.0: tmp->soffset:0x00000000, tmp->eoffset: 0x00000000, size:0x00100000 [ 985.395298] radeon 0000:01:00.0: soffset:0x00100000, eoffset: 0x00200000 [ 985.395332] radeon 0000:01:00.0: tmp->soffset:0x00000000, tmp->eoffset: 0x00000000, size:0x00100000 [ 987.861353] radeon 0000:01:00.0: soffset:0x00100000, eoffset: 0x00200000 [ 987.861387] radeon 0000:01:00.0: tmp->soffset:0x00000000, tmp->eoffset: 0x00000000, size:0x00100000 [ 988.175840] radeon 0000:01:00.0: soffset:0x00100000, eoffset: 0x00200000 [ 988.175873] radeon 0000:01:00.0: tmp->soffset:0x00000000, tmp->eoffset: 0x00000000, size:0x00100000 [ 988.176054] radeon 0000:01:00.0: soffset:0x00100000, eoffset: 0x00200000 [ 988.176078] radeon 0000:01:00.0: tmp->soffset:0x00000000, tmp->eoffset: 0x00000000, size:0x00100000 -- You are receiving this mail because: You are the assignee for the bug.

1 37

[Bug 80690] New: Suddenly X halts
by bugzilla-daemon＠freedesktop.org 31 Aug '18

31 Aug '18

https://bugs.freedesktop.org/show_bug.cgi?id=80690 Priority: medium Bug ID: 80690 Assignee: dri-devel(a)lists.freedesktop.org Summary: Suddenly X halts Severity: normal Classification: Unclassified OS: All Reporter: omegatype(a)gmail.com Hardware: Other Status: NEW Version: 10.2 Component: Drivers/Gallium/radeonsi Product: Mesa Created attachment 101986 --> https://bugs.freedesktop.org/attachment.cgi?id=101986&action=edit XOrg log Hello! After some time of work screen goes dark, than blinks and than hangs (picture stands still with no changes and no reaction on keyboard or mouse, numlock isn't working). # uname -a Linux 3.15.2-1-ARCH #1 SMP PREEMPT Fri Jun 27 07:41:19 CEST 2014 x86_64 GNU/Linux Mesa: 10.2.2-1 I have no specific options for radeon in /etc/X11/xorg.conf.d/*. XOrg.log end with messages like: (EE) [mi] EQ overflowing. Additional events will be discarded until existing events are processed. (EE) (EE) Backtrace: (EE) 0: /usr/bin/X (xorg_backtrace+0x48) [0x584b08] (EE) 1: /usr/bin/X (mieqEnqueue+0x22b) [0x566b7b] (EE) 2: /usr/bin/X (QueuePointerEvents+0x52) [0x44cc72] (EE) 3: /usr/lib/xorg/modules/input/evdev_drv.so (0x7fdd74bb3000+0x60ba) [0x7fdd74bb90ba] (EE) 4: /usr/lib/xorg/modules/input/evdev_drv.so (0x7fdd74bb3000+0x657d) [0x7fdd74bb957d] (EE) 5: /usr/bin/X (0x400000+0x72f08) [0x472f08] (EE) 6: /usr/bin/X (0x400000+0x9b4b0) [0x49b4b0] (EE) 7: /usr/lib/libpthread.so.0 (0x7fdd7ba3b000+0xf4b0) [0x7fdd7ba4a4b0] (EE) 8: /usr/lib/libc.so.6 (ioctl+0x7) [0x7fdd7a769e47] (EE) 9: /usr/lib/libdrm.so.2 (drmIoctl+0x28) [0x7fdd7b8329b8] (EE) 10: /usr/lib/libdrm.so.2 (drmCommandWrite+0x1b) [0x7fdd7b834c2b] (EE) 11: /usr/lib/libdrm_radeon.so.1 (0x7fdd74fc2000+0x2189) [0x7fdd74fc4189] (EE) 12: /usr/lib/xorg/modules/drivers/radeon_drv.so (0x7fdd751d0000+0x41b3a) [0x7fdd75211b3a] (EE) 13: /usr/lib/xorg/modules/drivers/radeon_drv.so (0x7fdd751d0000+0x42e00) [0x7fdd75212e00] (EE) 14: /usr/lib/libdrm.so.2 (drmHandleEvent+0x7e) [0x7fdd7b836e6e] (EE) 15: /usr/bin/X (WakeupHandler+0x6d) [0x43a59d] (EE) 16: /usr/bin/X (WaitForSomething+0x1bf) [0x5820bf] (EE) 17: /usr/bin/X (0x400000+0x359e1) [0x4359e1] (EE) 18: /usr/bin/X (0x400000+0x39aaa) [0x439aaa] (EE) 19: /usr/lib/libc.so.6 (__libc_start_main+0xf0) [0x7fdd7a6a8000] (EE) 20: /usr/bin/X (0x400000+0x2507e) [0x42507e] -- You are receiving this mail because: You are the assignee for the bug.

1 5

[Bug 56666] New: AMD SUMO GPU lockup when launching any heavy 3D application
by bugzilla-daemon＠freedesktop.org 25 Aug '18

25 Aug '18

https://bugs.freedesktop.org/show_bug.cgi?id=56666 Priority: medium Bug ID: 56666 Assignee: dri-devel(a)lists.freedesktop.org Summary: AMD SUMO GPU lockup when launching any heavy 3D application Severity: critical Classification: Unclassified OS: Linux (All) Reporter: runetmember(a)gmail.com Hardware: x86-64 (AMD64) Status: NEW Version: XOrg CVS Component: DRM/Radeon Product: DRI Created attachment 69423 --> https://bugs.freedesktop.org/attachment.cgi?id=69423&action=edit AMD SUMO GPU lockup when I launch Unigine Heaven 3 GPU lockup happen for me while launching any heavy 3D application on Radeon HD 6620G. For example GPU lockup 100% reproducible when I launch Unigine Heaven 3 (dmesg attached). It also may happen in web-browser, if browser use rendering hardware acceleration (for example Firefox with enabled "layers.acceleration.force-enabled" option). Lockup is not reproducible when I launch same applications on discrete Radeon HD 6650M GPU using DRI_PRIME feature, so I guess my issue related to AMD SUMO GPU's (or maybe to more APU's). Software: Kubuntu 12.10 x86_64 updated from Xorg Edgers PPA. Linux 3.7rc3. With Linux 3.5 and 3.6 is also reproducible, Mesa: 9.1~git20121029.00e6819e libdrm-radeon1: git20121025.bc494b31 xserver-xorg-video-radeon: git20120928.e8cb0b72 xserver-xorg-core: 1.13.0+git20120920.70e57668 KDE 4.9.2, desktop effects enabled. Hardware: Acer Aspire 7560G laptop, BIOS 2.04, AMD APU A8-3500M with integrated Radeon HD 6620G (SUMO) Discrete AMD Radeon HD 6650M (TURKS) -- You are receiving this mail because: You are the assignee for the bug.

1 5

[Bug 87059] Graphical glitches r9290
by bugzilla-daemon＠freedesktop.org 02 Aug '18

02 Aug '18

https://bugs.freedesktop.org/show_bug.cgi?id=87059 Bug ID: 87059 Summary: Graphical glitches r9290 Product: Mesa Version: git Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/radeonsi Assignee: dri-devel(a)lists.freedesktop.org Reporter: jarkko_korpi(a)hotmail.com Created attachment 110519 --> https://bugs.freedesktop.org/attachment.cgi?id=110519&action=edit glitches I just bought This war of mine and there is some animation at start and it has weird black boxes. -- You are receiving this mail because: You are the assignee for the bug.

1 14

[Bug 89327] Loss of HDMI audio on auto screen off (energy saving)
by bugzilla-daemon＠freedesktop.org 20 Jul '18

20 Jul '18

https://bugs.freedesktop.org/show_bug.cgi?id=89327 Bug ID: 89327 Summary: Loss of HDMI audio on auto screen off (energy saving) Product: Mesa Version: git Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/radeonsi Assignee: dri-devel(a)lists.freedesktop.org Reporter: john.ettedgui(a)gmail.com QA Contact: dri-devel(a)lists.freedesktop.org Since moving to 4.0-rc1 when my screen goes off (energy saving), I lose the hdmi audio, standard stuff. When I move the mouse I get the screen back but not the audio anymore. Switching it back on with xrandr works. Thanks -- You are receiving this mail because: You are the assignee for the bug.

1 25

[Bug 83748] New: Only black content on screen, in the Tokyo flashback of the game "The Secret World"
by bugzilla-daemon＠freedesktop.org 20 Jul '18

20 Jul '18

https://bugs.freedesktop.org/show_bug.cgi?id=83748 Priority: medium Bug ID: 83748 Assignee: dri-devel(a)lists.freedesktop.org Summary: Only black content on screen, in the Tokyo flashback of the game "The Secret World" Severity: normal Classification: Unclassified OS: Linux (All) Reporter: john.ettedgui(a)gmail.com Hardware: x86-64 (AMD64) Status: NEW Version: git Component: Drivers/Gallium/radeonsi Product: Mesa Hey, I am trying to play the game "The Secret World" on my system. It is a Windows game so I am using Wine to run it. Initially the game runs, and I can see everything (cinematics and in-game stuff), but for some reason once I enter the Tokyo flashback, I cannot see the cinematic or anything in that dungeon. In the cinematic my screen seems to be completely black. Once back in-game, all content is dark/black, but I can kind of see where walls are or the overall shape of my character. Maybe that's what it would be with a null contrast and 0 brightness? Also the game is still running, I can interact with the npcs (if I manage to find them) etc... I tried using stable mesa 10.2.7 instead of daily git but it was the same. I then tried running the game on the same machine using the Catalyst drivers and all the visuals were there, both in the cinematic and in-game, so as far as I can see the issue shouldn't be in Wine. I don't understand why I'm getting that problem only in that part of the game, I've passed it using Catalyst, and now I'm able to continue the game normally with the gallium driver after this strange part... I am not sure what logs to add to this, since it is a visual issue and I don't see any kind of error message about it (although it could be hidden in the wine verbose logs I suppose). My system: Radeon 7970 running with Mesa, daily git or 10.2.7. llvm either daily git or 3.5.0 Arch Linux 64b with Linux kernel 3.16.2 I've tried both wine and wine-csmt, both have the same issue. Thanks! -- You are receiving this mail because: You are the assignee for the bug.

1 17

[Bug 69120] New: With dpm=1 vdpau is not usable
by bugzilla-daemon＠freedesktop.org 20 Jul '18

20 Jul '18

https://bugs.freedesktop.org/show_bug.cgi?id=69120 Priority: medium Bug ID: 69120 Assignee: dri-devel(a)lists.freedesktop.org Summary: With dpm=1 vdpau is not usable Severity: normal Classification: Unclassified OS: Linux (All) Reporter: john.ettedgui(a)gmail.com Hardware: x86-64 (AMD64) Status: NEW Version: 9.2 Component: Drivers/Gallium/r600 Product: Mesa Hello, with radeon.dpm=0 (or not set), vdpau output works very fine. But if I switch to radeon.dpm=1 it becomes unusable. mplayer tells me that my computer is too slow, video stutters to a crazy extent, same in xbmc. With dpm set to 1, I am still able to watch videos "normally" if not using vdpau. I have a Radeon 4670, Linux 3.11, Mesa 9.2 and Radeon 1:7.2.0. I tried to change power_dpm_state and power_dpm_force_performance_level to see if it would help. power_dpm_state stays at performance but even if I set power_dpm_force_performance_level to high, but it always reverts to auto... This doesn't help at all... I am not sure what else to attach. Thank you -- You are receiving this mail because: You are the assignee for the bug.

1 29

[Bug 90481] Radeon R9 270X gpu lockup in game spec ops: the line.
by bugzilla-daemon＠freedesktop.org 04 Jul '18

04 Jul '18

https://bugs.freedesktop.org/show_bug.cgi?id=90481 Bug ID: 90481 Summary: Radeon R9 270X gpu lockup in game spec ops: the line. Product: DRI Version: unspecified Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: DRM/Radeon Assignee: dri-devel(a)lists.freedesktop.org Reporter: vim(a)xmail.net Created attachment 115834 --> https://bugs.freedesktop.org/attachment.cgi?id=115834&action=edit kernel log with drm.debug=1 Playing in spec ops: the line from steam causes gpu lockup. Behaviour differs. Firstly system freeze, after a few seconds screen becomes black. Sometimes works only sysrq, sometimes i can switch to VT and log in (screen still is black, but sudo reboot works). Sometimes it unfreeze and everything works again. System: Fedora 22 x86_64 kernel: 4.0.2-300.fc22.x86_64 mesa: 10.5.4-1.20150505.fc22 xorg-server: 1.17.1-11.fc22 libdrm: 2.4.61-3.fc22 xorg-x11-drv-ati.x86_64: 7.5.0-3.fc22 window manager: kwin-5.3.0-2.fc22 video card Radeon R9 270X OpenGL vendor string: X.Org OpenGL renderer string: Gallium 0.4 on AMD PITCAIRN OpenGL core profile version string: 3.3 (Core Profile) Mesa 10.5.4 OpenGL core profile shading language version string: 3.30 OpenGL core profile context flags: (none) OpenGL core profile profile mask: core profile OpenGL core profile extensions: OpenGL version string: 3.0 Mesa 10.5.4 OpenGL shading language version string: 1.30 OpenGL context flags: (none) OpenGL extensions: OpenGL ES profile version string: OpenGL ES 3.0 Mesa 10.5.4 OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.00 OpenGL ES profile extensions: reproduce always. After 15-40 minutes of playing. -- You are receiving this mail because: You are the assignee for the bug.

1 28

[PATCH wq#for-linus] drm: fix a fallout from slow-work -> wq conversion
by Tejun Heo 19 Jun '18

19 Jun '18

Commit 991ea75c (drm: use workqueue instead of slow-work), which made drm to use wq instead of slow-work, didn't account for the return value difference between delayed_slow_work_enqueue() and queue_delayed_work(). The former returns 0 on success and -errno on failures while the latter never fails and only uses the return value to indicate whether the work was already pending or not. This misconversion triggered spurious error messages. Remove the now unnecessary return value check and error message. Signed-off-by: Tejun Heo <tj(a)kernel.org> Reported-by: Markus Trippelsdorf <markus(a)trippelsdorf.de> Cc: David Airlie <airlied(a)linux.ie> Cc: dri-devel(a)lists.freedesktop.org --- Markus, it's almost trivial but it would be great if you can test this one too. David, may I route this wq#for-linus? Thanks. drivers/gpu/drm/drm_crtc_helper.c | 8 ++------ 1 file changed, 2 insertions(+), 6 deletions(-) diff --git a/drivers/gpu/drm/drm_crtc_helper.c b/drivers/gpu/drm/drm_crtc_helper.c index 4598130..211ed7e 100644 --- a/drivers/gpu/drm/drm_crtc_helper.c +++ b/drivers/gpu/drm/drm_crtc_helper.c @@ -839,7 +839,6 @@ static void output_poll_execute(struct work_struct *work) struct drm_connector *connector; enum drm_connector_status old_status, status; bool repoll = false, changed = false; - int ret; mutex_lock(&dev->mode_config.mutex); list_for_each_entry(connector, &dev->mode_config.connector_list, head) { @@ -874,11 +873,8 @@ static void output_poll_execute(struct work_struct *work) dev->mode_config.funcs->output_poll_changed(dev); } - if (repoll) { - ret = queue_delayed_work(system_nrt_wq, delayed_work, DRM_OUTPUT_POLL_PERIOD); - if (ret) - DRM_ERROR("delayed enqueue failed %d\n", ret); - } + if (repoll) + queue_delayed_work(system_nrt_wq, delayed_work, DRM_OUTPUT_POLL_PERIOD); } void drm_kms_helper_poll_disable(struct drm_device *dev)

4 4

[Bug 28771] New: Vsync always on
by bugzilla-daemon＠freedesktop.org 12 Jun '18

12 Jun '18

https://bugs.freedesktop.org/show_bug.cgi?id=28771 Summary: Vsync always on Product: Mesa Version: git Platform: Other OS/Version: All Status: NEW Severity: normal Priority: medium Component: Drivers/DRI/r300 AssignedTo: dri-devel(a)lists.freedesktop.org ReportedBy: sa(a)whiz.se With kernel 2.6.35, there doesn't seem to be a way to turn off vsync/vblank. E.g. "vblank_mode=0 glxgears" has no effect. This seems to be the same for both r300c and r300g. System environment: -- system architecture: 32-bit -- Linux distribution: Debian unstable -- GPU: RV570 -- Model: Asus EAX1950Pro 256MB -- Display connector: DVI -- xf86-video-ati: 801e83227a59a29eea425ea612083bbf2b536c30 -- xserver: 1.8.1.901 -- mesa: a5c44986a3f19936df448fe4ae47ca77ece9b0ce -- drm: 6ea2bda5f5ec8f27359760ce580fdad3df0464df -- kernel: 2.6.35-rc3 -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.

1 38

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel January 2016