dri-devel June 2015

dri-devel@lists.freedesktop.org

188 participants
1140 discussions

[Bug 80673] New: XCOM: Enemy Unknown - Wrong read access when starting the game
by bugzilla-daemon＠freedesktop.org 12 Apr '16

12 Apr '16

https://bugs.freedesktop.org/show_bug.cgi?id=80673 Priority: medium Bug ID: 80673 Assignee: dri-devel(a)lists.freedesktop.org Summary: XCOM: Enemy Unknown - Wrong read access when starting the game Severity: normal Classification: Unclassified OS: Linux (All) Reporter: freedesktop(a)psydk.org Hardware: x86-64 (AMD64) Status: NEW Version: 10.1 Component: Drivers/Gallium/r600 Product: Mesa Created attachment 101971 --> https://bugs.freedesktop.org/attachment.cgi?id=101971&action=edit callstack of the wrong read access Some background: I am trying to understand why "XCOM: Enemy Uknown" (a game that was released for Linux x64 last week on Steam), leads to crashes when running with the open source Radeon driver. The people who did the port do not officialy support the open source driver but seems to be open to the idea of making it run on it. My system: Ubuntu 14.04 x64 Readon HD 4870 Mesa 10.1.3 Unfortunately that Radeon model is not supported by AMD's closed source driver. However, the game runs very well with the open source driver, with the exception of several random crashes. This bug report is one of the problem I have found and for which I have some information. The main crash I was experimenting was corrupting the heap, so I used a tool to detect illegal read and write accesses. The first problem it found is an illegal read access at the start of the game, after the different logos, when the main menu is about to appear. What is happening is that a memcpy with a size of 1360 bytes is made with a source buffer of only 1280 bytes in u_upload_data(). I will attach the callstack to this ticket. In that context, the entry point in the driver is: vbo_exec_DrawRangeElementsBaseVertex(GLenum mode, GLuint start, GLuint end, GLsizei count, GLenum type, const GLvoid *indices, GLint basevertex) Here are the values of the parameters: --------------------------------------------------------------- mode: 4 (GL_TRIANGLES) start: 0 end: 16 count: 24 type: 5123 (GL_UNSIGNED_SHORT) indices: 72 bytes: 00 00 02 00 03 00 00 00 01 00 02 00 04 00 06 00 07 00 04 00 05 00 06 00 08 00 0a 00 0b 00 08 00 09 00 0a 00 0c 00 0e 00 0f 00 0c 00 0d 00 0e 00 00 00 04 00 06 00 00 00 06 00 02 00 01 00 03 00 07 00 01 00 07 00 05 00 reordered as 36 u16: 0000 0002 0003 0000 0001 0002 0004 0006 0007 0004 0005 0006 0008 000a 000b 0008 0009 000a 000c 000e 000f 000c 000d 000e 0000 0004 0006 0000 0006 0002 0001 0003 0007 0001 0007 0005 basevertex: 0 --------------------------------------------------------------- Now I'm no expert in OpenGL and it is the first time I look at Mesa code, so I can't identify the main reason for the error. Hopefully you will have a clue. A tip to debug the game: if you have Steam and the game, I renamed the main exectuable in ".../Steam/SteamApps/common/XCom-Enemy-Unknown/binaries/linux/" named "game.x86_64" as "game.x86_64_real" and created a shell script named "game.x86_64" that performs necessary settings for debugging and then launch "game.x86_64_real". In my case I am setting LD_PRELOAD with a library that catches malloc() calls and fences the buffer before returning it. -- You are receiving this mail because: You are the assignee for the bug.

1 12

[Bug 78717] New: radeon: Failed to allocate a buffer
by bugzilla-daemon＠freedesktop.org 05 Apr '16

05 Apr '16

https://bugs.freedesktop.org/show_bug.cgi?id=78717 Priority: medium Bug ID: 78717 Assignee: dri-devel(a)lists.freedesktop.org Summary: radeon: Failed to allocate a buffer Severity: normal Classification: Unclassified OS: Linux (All) Reporter: mmstickman(a)gmail.com Hardware: x86-64 (AMD64) Status: NEW Version: 10.1 Component: Drivers/Gallium/radeonsi Product: Mesa When you set shadows to Ultra in the recently released open source game, Tesseract, the game will segfault with the following: radeon: Failed to allocate a buffer: radeon: size : 536870912 bytes radeon: alignment : 32768 bytes radeon: domains : 4 radeon: Failed to allocate a buffer: radeon: size : 536870912 bytes radeon: alignment : 32768 bytes radeon: domains : 4 radeon: Failed to allocate a buffer: radeon: size : 536870912 bytes radeon: alignment : 32768 bytes radeon: domains : 4 radeon: Failed to allocate a buffer: radeon: size : 536870912 bytes radeon: alignment : 32768 bytes radeon: domains : 4 radeon: Failed to allocate a buffer: radeon: size : 536870912 bytes radeon: alignment : 32768 bytes radeon: domains : 4 radeon: Failed to allocate a buffer: radeon: size : 536870912 bytes radeon: alignment : 32768 bytes radeon: domains : 4 failed allocating shadow atlas! MSAA also seems to hang the entire machine -- You are receiving this mail because: You are the assignee for the bug.

1 9

[Bug 72701] New: Screen freeze when using radeon driver
by bugzilla-daemon＠bugzilla.kernel.org 27 Mar '16

27 Mar '16

https://bugzilla.kernel.org/show_bug.cgi?id=72701 Bug ID: 72701 Summary: Screen freeze when using radeon driver Product: Drivers Version: 2.5 Kernel Version: 3.13 and 3.14 Hardware: All OS: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: Video(DRI - non Intel) Assignee: drivers_video-dri(a)kernel-bugs.osdl.org Reporter: banjacnikola(a)openmailbox.org Regression: No I got this problem with all distributions using new kernels, that I tried to boot from live CD, as well as the ones I have on the hard drive. Faster booting ones manage to boot before they freeze, while slower ones freeze in the middle of booting process. [klod@klod ~]$ lspci | grep VGA 00:01.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] BeaverCreek [Radeon HD 6520G] 01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Whistler [Radeon HD 6630M/6650M/6750M/7670M/7690M] When I turn off discrete GPU in my laptop's BIOS, it works well. -- You are receiving this mail because: You are watching the assignee of the bug.

1 24

[Bug 34643] New: ut2004/doom3 looping in submenu on r300g/PageFlip
by bugzilla-daemon＠freedesktop.org 19 Mar '16

19 Mar '16

https://bugs.freedesktop.org/show_bug.cgi?id=34643 Summary: ut2004/doom3 looping in submenu on r300g/PageFlip Product: Mesa Version: git Platform: Other OS/Version: Linux (All) Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/r300 AssignedTo: dri-devel(a)lists.freedesktop.org ReportedBy: krzysztof.krakowiak(a)gmail.com Created an attachment (id=43736) --> (https://bugs.freedesktop.org/attachment.cgi?id=43736) gdb/ut2k4 output and backraces. ut2004(32/64bit) and doom3(32bit) are looping everytime in submenu on r300g/PageFlip. I believe that bug occured during last two weeks, but bisecting would be hard, because I was bisecting for: https://bugs.freedesktop.org/show_bug.cgi?id=34418 And everytime supertuxkart wasnt working, ut2k4 also and vice versa, altough bugs were definitely different. Now previous bug is fixed(which affected only 64bit apps), but ut2004/doom3 got very similar behaviour(like looped video tape or something, moving forward and back), similar spam in console, but a bit different at output. Disabling PageFLip fixes this problem definitely, but I was happpy pflip user from a long time. Kernel is fresh D-R-T, DDX/DRM/Mesa from master. --- UT2004 dmesg --- [...] [drm:radeon_cs_parser_relocs] *ERROR* gem object lookup failed 0xe [drm:radeon_cs_ioctl] *ERROR* Failed to parse relocation -2! [drm:radeon_cs_parser_relocs] *ERROR* gem object lookup failed 0x1f [drm:radeon_cs_ioctl] *ERROR* Failed to parse relocation -2! [drm:radeon_cs_parser_relocs] *ERROR* gem object lookup failed 0xe [drm:radeon_cs_ioctl] *ERROR* Failed to parse relocation -2! [drm:radeon_cs_parser_relocs] *ERROR* gem object lookup failed 0x1f [drm:radeon_cs_ioctl] *ERROR* Failed to parse relocation -2! [...] --- EOF UT2004 dmesg --- --- UT2004 gdb output/backtrace --- [...] [Thread 0x7fffe50cd700 (LWP 5934) exited] [New Thread 0x7fffe50cd700 (LWP 5935)] [Thread 0x7fffe50cd700 (LWP 5935) exited] [New Thread 0x7fffe50cd700 (LWP 5936)] [...] [Thread 0x7fffe50cd700 (LWP 6540) exited] [New Thread 0x7fffe50cd700 (LWP 6541)] radeon: The kernel rejected CS, see dmesg for more information. [Thread 0x7fffe50cd700 (LWP 6541) exited] [...] Program received signal SIGINT, Interrupt. 0x00007ffff6e0a1f3 in poll () from /lib64/libc.so.6 (gdb) bt #0 0x00007ffff6e0a1f3 in poll () from /lib64/libc.so.6 #1 0x00007ffff65eac6a in ?? () from /usr/lib64/libxcb.so.1 #2 0x00007ffff65ec2ff in xcb_wait_for_reply () from /usr/lib64/libxcb.so.1 #3 0x00007ffff684392d in _XReply () from /usr/lib64/libX11.so.6 #4 0x00007fffe6c1748c in DRI2GetBuffersWithFormat () from /opt/xorg/lib64/libGL.so.1 #5 0x00007fffe6c14bf9 in dri2GetBuffersWithFormat () from /opt/xorg/lib64/libGL.so.1 #6 0x00007fffe56de4d8 in dri2_allocate_textures () from /opt/xorg/lib64/dri/gallium/r300_dri.so #7 0x00007fffe56dfb77 in dri_st_framebuffer_validate () from /opt/xorg/lib64/dri/gallium/r300_dri.so #8 0x00007fffe573f132 in st_framebuffer_validate () from /opt/xorg/lib64/dri/gallium/r300_dri.so #9 0x00007fffe5740916 in st_manager_validate_framebuffers () from /opt/xorg/lib64/dri/gallium/r300_dri.so #10 0x00007fffe58e3c1e in st_validate_state () from /opt/xorg/lib64/dri/gallium/r300_dri.so #11 0x00007fffe58ebb3a in st_Clear () from /opt/xorg/lib64/dri/gallium/r300_dri.so #12 0x0000000000d291d9 in FOpenGLRenderInterface::Clear(int, FColor, int, float, int, unsigned int) () #13 0x000000000069d234 in UGameEngine::Draw(UViewport*, int, unsigned char*, int*) () #14 0x0000000000d1d106 in USDLViewport::Repaint(int) () #15 0x0000000000d1ab09 in USDLClient::Tick() () #16 0x00000000006a0f54 in UGameEngine::Tick(float) () #17 0x000000000053d2a3 in CMainLoop::RunLoop() () #18 0x000000000053344f in ?? () #19 0x000000000052f1a0 in main () --- UT2004 gdb output/backtrace --- --- Doom3 output --- [...] radeon: The kernel rejected CS, see dmesg for more information. radeon: The kernel rejected CS, see dmesg for more information [...] --- EOF Doom3 output --- TIP: For full logs, look into attachements (but nothing special in xorg.log) -- 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 94171] New: ati multihead black on one output
by bugzilla-daemon＠bugzilla.kernel.org 19 Mar '16

19 Mar '16

https://bugzilla.kernel.org/show_bug.cgi?id=94171 Bug ID: 94171 Summary: ati multihead black on one output Product: Drivers Version: 2.5 Kernel Version: 3.16, 3.19, 4.0rc1 Hardware: x86-64 OS: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: Video(DRI - non Intel) Assignee: drivers_video-dri(a)kernel-bugs.osdl.org Reporter: mrmazda(a)earthlink.net Regression: Yes Created attachment 168641 --> https://bugzilla.kernel.org/attachment.cgi?id=168641&action=edit dmesg using cedar and 3.19.0 with drm.debug=0x0E on cmdline ATI mailing list http://lists.x.org/archives/xorg-driver-ati/2015-February/027079.html response suggested I file this and that bug 91861 might be related, so I used that bug as a guide to choosing input fields here. I'm just a user/tester who does not build. http://marc.info/?l=linux-ide&m=142517892627960&w=2 explains that booting test machine to openSUSE 13.2 3.16.7, openSUSE Tumbleweed 3.19.0 and Rawhide 4.0.0.rc1 is currently somewhat painful due to long boot delay. Cut and paste from mailing list: [paste] Whether starting X including this: xrandr --dpi 144 --output DVI-0 --mode 1920x1080 --above VGA-0 --output VGA-0 --primary --mode 1920x1440 # ati dual works or not depends on which Radeon gfxcard used, and how new the software. The cards' info: http://fm.no-ip.com/Tmp/Linux/Xorg/ATIdual/hwinfo-gfx-rv380fan.txt X600 http://fm.no-ip.com/Tmp/Linux/Xorg/ATIdual/hwinfo-gfx-rv516.txt X1300 http://fm.no-ip.com/Tmp/Linux/Xorg/ATIdual/hwinfo-gfx-cedarPC-big41.txt rv380 works as expected regardless at least as far back as openSUSE 13.1 k3.12. openSUSE Tumbleweed 3.19.0: http://fm.no-ip.com/Tmp/Linux/Xorg/ATIdual/xorg.0.log-under1440xover1080-rv… cedar works as expected as recently as Mageia 4 k3.12 and openSUSE 13.1 k3.12: http://fm.no-ip.com/Tmp/Linux/Xorg/ATIdual/xorg.0.log-under1440over1080-os1… http://fm.no-ip.com/Tmp/Linux/Xorg/ATIdual/xorg.0.log-under1440-over1080-ma… Failures in the form of black screen on only one output using rv516 and cedar in the following: Fedora 20 k3.17.7 cedar (black VGA): http://fm.no-ip.com/Tmp/Linux/Xorg/ATIdual/xorg.0.log-under1440bad-over1080… openSUSE 13.2 k3.16.7 cedar (black VGA): http://fm.no-ip.com/Tmp/Linux/Xorg/ATIdual/xorg.0.log-under1440bad-over1080… Fedora 21 cedar (black VGA): http://fm.no-ip.com/Tmp/Linux/Xorg/ATIdual/xorg.0.log-under1440bad-over1080… http://fm.no-ip.com/Tmp/Linux/Xorg/ATIdual/xorg.0.log-under1440bad-over1080… openSUSE Tumbleweed k3.19.0 rv516 (black DVI): http://fm.no-ip.com/Tmp/Linux/Xorg/ATIdual/xorg.0.log-under1440OKxover1080b… openSUSE Tumbleweed k3.19.0 cedar (black VGA): http://fm.no-ip.com/Tmp/Linux/Xorg/ATIdual/xorg.0.log-under1440bad-over1080… All of above pertains to same system, with only changes made being: 1-which OS booted 2-which ATI gfxcard installed With necessary xrandr output descriptors for Intel, results are as expected using onboard Intel gfx instead of ATI PCIe cards. On cedar in Tumbleweed at least, dropping analog output mode from 1920x1440 to 1600x1200 produces expected output. [/paste] Dropping analog output mode from 1920x1440 to 1600x1200 on rv516 in Tumbleweed 3.19.0 does not help. With rv516, Rawhide 4.0.0rc1.gt2.1 produces boot tty1 oopses instead of booting if both video cables are connected, boots normally with only VGA cable connected, and locks up after 32 seconds with only DVI cable connected. -- You are receiving this mail because: You are watching the assignee of the bug.

1 5

[PATCH v15 0/3] Add drm driver for Rockchip Socs
by Mark Yao 17 Mar '16

17 Mar '16

This a series of patches is a DRM Driver for Rockchip Socs, add support for vop devices. Future patches will add additional encoders/connectors, such as eDP, HDMI. The basic "crtc" for rockchip is a "VOP" - Video Output Processor. the vop devices found on Rockchip rk3288 Soc, rk3288 soc have two similar Vop devices. Vop devices support iommu mapping, we use dma-mapping API with ARM_DMA_USE_IOMMU. Changes in v2: - add DRM master device node to list all display nodes that comprise the graphics subsystem. - use the component framework to defer main drm driver probe until all VOP devices have been probed. - use dma-mapping API with ARM_DMA_USE_IOMMU, create dma mapping by master device and each vop device can shared the drm dma mapping. - use drm_crtc_init_with_planes and drm_universal_plane_init. - remove unnecessary middle layers. - add cursor set, move funcs to rockchip drm crtc. - add vop reset. Changes in v3: - change "crtc->fb" to "crtc->primary-fb" Adviced by Daniel Vetter - init cursor plane with universal api, remove unnecessary cursor set,move Changes in v4: Adviced by David Herrmann - remove drm_platform_*() usage, use register drm device directly. Adviced by Rob Clark - remove special mmap ioctl, do userspace mmap with normal mmap() or mmap offset Changes in v5: Adviced by Arnd Bergmann - doing DMA start with a 32-bit masks with dma_mask and dma_coherent_mark - fix some incorrect dependencies. Adviced by Boris BREZILLON - fix some mistake and bugs. Adviced by Daniel Vetter - drop all special ioctl and use generic kms ioctl instead. Adviced by Rob Clark - use unlocked api for drm_fb_helper_restore_fbdev_mode. - remove unused rockchip_gem_prime_import_sg_table. Changes in v6: - set gem buffer pitch 64 bytes align, needed by mali gpu. Adviced by Daniel Kurtz - fix some mistake, bugs, remove unused define, more better code style etc. - use clk_prepare()/unprepare() at probe()/remove() and clk_enable()/disable() at runtime instead of clk_prepare_enable(). - provide a help function from vop for encoder to do mode config, instead of using drm_diaplay_mode private method. - change vop mode_set timing to make it more safely. Changes in v7: - fix memory leakage problem. Changes in v8: - fix iommu crash when use dual crtc. - use frame start interrupt for vsync instead of line flag interrupt, because the win config take affect at frame start time, if we use ling flag interrupt, the address check often failed. Adviced by Daniel Kurtz - fix some bugs, mistake, remove unused function - keep clock and vop disabled when probe end - use drm_plane_helper_check_update to check update_plane if vaild Changes in v9: - fix suspend and resume bug, make iommu attach and detach safely. - fix mail info style. Changes in v10: Adviced by Andrzej Hajda - check drm_dev if it's NULL at PM suspend/resume Adviced by Sean Paul - use drm_fb_helper_prepare to init fb_helper funcs - Optimized code structure and remove some unnecessary Variables. Changes in v11: - fix mistake that use wrong variable at rockchip sys_resume/sys_suspend Changes in v12: - fix compile problem with drm-next - Optimization framebuffer reference/unreference - Optimization Code structure - fix pm suspend/resume problem - fix vblank irq can't close problem Changes in v13: - fix vop compile warning. Adviced by Daniel Vetter - directly call rockchip_drm_load before register instead of call ->load at the middle of drm register. Changes in v14: - revert v13 directly call rockchip_drm_load at bind, connector, crtc _init should before dev-node kms object lookup idr and conector sysfs need below minor node register, I don't like split the connector init and register, so just call ->load at the midile of drm register. Changes in v15: - remove depends on ARM_DMA_USE_IOMMU & IOMMU_API which cause recursive dependency problem - fix compile problems when build as a module. Mark yao (3): drm: rockchip: Add basic drm driver dt-bindings: video: Add for rockchip display subsytem dt-bindings: video: Add documentation for rockchip vop .../devicetree/bindings/video/rockchip-drm.txt | 19 + .../devicetree/bindings/video/rockchip-vop.txt | 58 + drivers/gpu/drm/Kconfig | 2 + drivers/gpu/drm/Makefile | 1 + drivers/gpu/drm/rockchip/Kconfig | 17 + drivers/gpu/drm/rockchip/Makefile | 8 + drivers/gpu/drm/rockchip/rockchip_drm_drv.c | 551 ++++++++ drivers/gpu/drm/rockchip/rockchip_drm_drv.h | 68 + drivers/gpu/drm/rockchip/rockchip_drm_fb.c | 201 +++ drivers/gpu/drm/rockchip/rockchip_drm_fb.h | 28 + drivers/gpu/drm/rockchip/rockchip_drm_fbdev.c | 210 +++ drivers/gpu/drm/rockchip/rockchip_drm_fbdev.h | 21 + drivers/gpu/drm/rockchip/rockchip_drm_gem.c | 294 ++++ drivers/gpu/drm/rockchip/rockchip_drm_gem.h | 54 + drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 1455 ++++++++++++++++++++ drivers/gpu/drm/rockchip/rockchip_drm_vop.h | 201 +++ 16 files changed, 3188 insertions(+) -- 1.7.9.5

6 12

[Bug 60523] New: Lockup with radeon DPM on Radeon HD5770 (Juniper)
by bugzilla-daemon＠bugzilla.kernel.org 13 Mar '16

13 Mar '16

https://bugzilla.kernel.org/show_bug.cgi?id=60523 Bug ID: 60523 Summary: Lockup with radeon DPM on Radeon HD5770 (Juniper) Product: Drivers Version: 2.5 Kernel Version: 3.10-drm-next-3.11 Hardware: x86-64 OS: Linux Tree: Mainline Status: NEW Severity: high Priority: P1 Component: Video(DRI - non Intel) Assignee: drivers_video-dri(a)kernel-bugs.osdl.org Reporter: tdroste(a)gmx.de Regression: No Created attachment 106814 --> https://bugzilla.kernel.org/attachment.cgi?id=106814&action=edit dmesg | grep -iE "drm|radeon|power|uvd" after starting a video with mplayer I have some not always reproducible lockup with the latest DPM code. There are 2 scenarios: 1. PC boots, DPM is active and reports different power states and levels in dmesg, but does not change the power level (it's always at power level 2) 2. mplayer is started and plays a video with UVD. DPM switches the power state to UVD and switches between powerlevel 0 and 2 while playing the video 3. When closing mplayer there are 2 possible outcomes: a) DPM switches the power state back to performance and stays in power level 0 or 1. This will stay until something triggers it to switch to power level 2 again. As soon as it's in power level 2 again it's never changing back. b) PC locks up, display is black and VT switch doesn't work until I SysRq+REISUB to reboot the machine Scenario b is harder to trigger but it happened at least 2 times today. dmesg | grep -iE "drm|radeon|power|uvd" -- You are receiving this mail because: You are watching the assignee of the bug.

1 78

[RFC 0/2] drm/dsi: DSI for devices with different control bus
by Archit Taneja 02 Mar '16

02 Mar '16

We are currently restricted when it comes to supporting DSI on devices that have a non-DSI control bus. For example, DSI encoder chips are available in the market that are configured via i2c. Configuring their registers via DSI bus is either optional or not available at all. These devices still need to pass DSI parameters (data lanes, mode flags etc) to the DSI host they are connected to. We don't have a way to do that at the moment. The method presented in these patches is to provide an API to create a 'dummy' mipi_dsi_device. This device is populated with the desired DSI params, which are passed on to the host via mipi_dsi_attach(). This method will require the device driver to get a phandle to the DSI host since there is no parent-child relation between the two. Is there a better way to do this? Please let me know! Archit Taneja (2): drm/dsi: Create dummy DSI devices drm/dsi: Get DSI host by DT device node drivers/gpu/drm/drm_mipi_dsi.c | 108 ++++++++++++++++++++++++++++++++++++++++- include/drm/drm_mipi_dsi.h | 4 ++ 2 files changed, 110 insertions(+), 2 deletions(-) -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, hosted by The Linux Foundation

8 83

[Bug 87316] [radeonsi][bonaire][drm-next-3.19] unable to handle kernel NULL pointer dereference: radeon_fence_signaled
by bugzilla-daemon＠freedesktop.org 26 Feb '16

26 Feb '16

https://bugs.freedesktop.org/show_bug.cgi?id=87316 Bug ID: 87316 Summary: [radeonsi][bonaire][drm-next-3.19] unable to handle kernel NULL pointer dereference: radeon_fence_signaled Product: DRI Version: XOrg git Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component: DRM/Radeon Assignee: dri-devel(a)lists.freedesktop.org Reporter: shawn.starr(a)rogers.com hardware: Dell Precision M6800 (GPU: FirePro M6100) kernel: drm-next-3.19 from agdf5's linux git repo mesa: master from 20141213 (10.5-dev) I was using DRI_PRIME prior, the kernel oops happened while the GPU was powered down awhile later, see full kernel log from boot to failure. kernel oops dump: [22485.963089] BUG: unable to handle kernel NULL pointer dereference at 0000000000000d48 [22485.967333] IP: [<ffffffffa015668e>] radeon_fence_signaled+0x3e/0x90 [radeon] [22485.971403] PGD 0 [22485.973433] Oops: 0000 [#1] SMP [22485.975511] Modules linked in: cpufreq_stats rfcomm xt_CHECKSUM iptable_mangle ipt_MASQUERADE nf_nat_masquerade_ipv4 iptable_nat nf_nat_ipv4 nf_nat nf_conntrack_ipv4 nf_defrag_ipv4 xt_conntrack nf_conntrack tun bridge stp llc bnep snd_hda_codec_realtek snd_hda_codec_hdmi snd_hda_codec_generic snd_hda_intel snd_hda_controller x86_pkg_temp_thermal coretemp snd_hda_codec kvm_intel kvm arc4 iwlmvm snd_hwdep mac80211 snd_seq i915 uvcvideo iwlwifi snd_seq_device videobuf2_vmalloc videobuf2_core videobuf2_memops v4l2_common crct10dif_pclmul videodev cfg80211 btusb media crc32_pclmul snd_pcm bluetooth vfat fat snd_timer joydev dell_wmi sparse_keymap iTCO_wdt iTCO_vendor_support dell_laptop snd dcdbas ppdev sdhci_pci mei_me crc32c_intel cdc_acm wmi serio_raw pcspkr ie31200_edac mei ghash_clmulni_intel lpc_ich [22486.010804] mfd_core rfkill soundcore edac_core i2c_hid i2c_i801 shpchp i2c_designware_platform video i2c_designware_core parport_pc parport dw_dmac dw_dmac_core dell_smo8800 radeon i2c_algo_bit drm_kms_helper ttm drm e1000e sdhci_acpi sdhci mmc_core ptp pps_core [22486.022517] CPU: 7 PID: 717 Comm: systemd-logind Not tainted 3.18.0+ #1 [22486.026765] Hardware name: Dell Inc. Precision M6800/05NG6V, BIOS A11 11/20/2014 [22486.030890] task: ffff8800c588cb00 ti: ffff880804028000 task.ti: ffff880804028000 [22486.035282] RIP: 0010:[<ffffffffa015668e>] [<ffffffffa015668e>] radeon_fence_signaled+0x3e/0x90 [radeon] [22486.041831] RSP: 0018:ffff88080402b878 EFLAGS: 00010246 [22486.045102] RAX: 0000000000000000 RBX: ffff880803e46600 RCX: 000000010040000e [22486.048791] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 [22486.053330] RBP: ffff88080402b898 R08: 0000000063e8df01 R09: 000000010040000e [22486.057116] R10: ffffffffa01cc22d R11: ffff880763e8df00 R12: 0000000000000000 [22486.061664] R13: 0000000000000d40 R14: 0000000000000000 R15: ffff88080402ba38 [22486.066733] FS: 00007f294be348c0(0000) GS:ffff88082ebc0000(0000) knlGS:0000000000000000 [22486.069989] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [22486.074192] CR2: 0000000000000d48 CR3: 0000000807fa9000 CR4: 00000000001407e0 [22486.077843] Stack: [22486.080235] ffff88080402b898 ffff880763e8d580 ffff88079424e880 ffff880802949a20 [22486.084016] ffff88080402b8c8 ffffffffa01cc2b4 ffff88080402bb18 ffff880802949978 [22486.088606] ffff88080402bb18 ffff8807a3887f40 ffff88080402b9e8 ffffffffa01cc8a8 [22486.093200] Call Trace: [22486.094945] [<ffffffffa01cc2b4>] radeon_sa_bo_try_free+0x64/0x80 [radeon] [22486.099356] [<ffffffffa01cc8a8>] radeon_sa_bo_new+0x118/0x490 [radeon] [22486.102843] [<ffffffffa01559ab>] ? radeon_fence_activity+0x10b/0x1c0 [radeon] [22486.107423] [<ffffffffa0227567>] radeon_ib_get+0x37/0xe0 [radeon] [22486.110871] [<ffffffffa02337f3>] radeon_vce_get_destroy_msg+0x43/0x240 [radeon] [22486.115516] [<ffffffffa0234833>] radeon_vce_ib_test+0x63/0x100 [radeon] [22486.119946] [<ffffffffa02279fa>] radeon_ib_ring_tests+0x5a/0xc0 [radeon] [22486.123477] [<ffffffffa013a91d>] radeon_resume_kms+0x9d/0x260 [radeon] [22486.127830] [<ffffffffa0138143>] radeon_pmops_runtime_resume+0x73/0xb0 [radeon] [22486.131779] [<ffffffff813cef9f>] pci_pm_runtime_resume+0x7f/0xc0 [22486.136004] [<ffffffff8149d2f9>] vga_switcheroo_runtime_resume+0x39/0x40 [22486.139411] [<ffffffff8128e200>] ? kernfs_fop_release+0x60/0x60 [22486.142766] [<ffffffff814ae194>] __rpm_callback+0x34/0x90 [22486.146340] [<ffffffff814ae216>] rpm_callback+0x26/0xa0 [22486.149156] [<ffffffff814ae6f4>] rpm_resume+0x464/0x640 [22486.152313] [<ffffffff8175a836>] ? mutex_lock+0x16/0x40 [22486.154513] [<ffffffff814af76f>] __pm_runtime_resume+0x4f/0x80 [22486.157761] [<ffffffffa01622e3>] radeon_dp_detect+0x43/0x290 [radeon] [22486.161421] [<ffffffffa00a2171>] status_show+0x41/0x90 [drm] [22486.164584] [<ffffffff814a0a00>] dev_attr_show+0x20/0x60 [22486.167656] [<ffffffff8175a836>] ? mutex_lock+0x16/0x40 [22486.169910] [<ffffffff8128eec6>] sysfs_kf_seq_show+0xb6/0x150 [22486.172287] [<ffffffff8128d673>] kernfs_seq_show+0x23/0x30 [22486.175550] [<ffffffff81237185>] seq_read+0xf5/0x3d0 [22486.178653] [<ffffffff8128e0a5>] kernfs_fop_read+0xf5/0x160 [22486.181877] [<ffffffff81211e88>] vfs_read+0x98/0x180 [22486.184017] [<ffffffff81212a75>] SyS_read+0x55/0xd0 [22486.186276] [<ffffffff8175cae9>] system_call_fastpath+0x12/0x17 [22486.189533] Code: 48 89 fb 48 83 ec 08 8b 47 68 4c 8b 67 60 48 8b 7f 58 48 89 c2 48 89 c6 48 c1 e0 08 48 c1 e2 04 48 29 d0 4c 8d ac 07 40 0d 00 00 <49> 8b 45 08 49 39 c4 77 19 48 89 df e8 11 e6 36 e1 48 83 c4 08 [22486.198672] RIP [<ffffffffa015668e>] radeon_fence_signaled+0x3e/0x90 [radeon] [22486.202344] RSP <ffff88080402b878> [22486.204115] CR2: 0000000000000d48 [22486.211204] ---[ end trace 0f3b8a81fa241e74 ]--- -- You are receiving this mail because: You are the assignee for the bug.

1 2

[Bug 91061] [4.1-rc8][radeonsi] GPU lockup from chrome - radeon_ttm_bo_destroy
by bugzilla-daemon＠freedesktop.org 26 Feb '16

26 Feb '16

https://bugs.freedesktop.org/show_bug.cgi?id=91061 Bug ID: 91061 Summary: [4.1-rc8][radeonsi] GPU lockup from chrome - radeon_ttm_bo_destroy Product: DRI Version: XOrg git Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component: DRM/Radeon Assignee: dri-devel(a)lists.freedesktop.org Reporter: shawn.starr(a)rogers.com Created attachment 116660 --> https://bugs.freedesktop.org/attachment.cgi?id=116660&action=edit Kernel stack dump Somehow triggered GPU lockup with Chrome Attachment contains crash stack from kernel DDX: xorg-x11-drv-ati-7.5.0-3.fc22.x86_64 Kernel: 4.1.0-0.rc8.git0.2.fc23.x86_64 Mesa: mesa-dri-drivers-10.7.0-0.devel.60.20150606.fc22.x86_64 (git master build, from specified date) -- You are receiving this mail because: You are the assignee for the bug.

1 3

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel June 2015