dri-devel January 2016

dri-devel@lists.freedesktop.org

194 participants
1200 discussions

[Bug 91982] [radeonsi] fs leak in get_radeon_bo()
by bugzilla-daemon＠freedesktop.org 31 Aug '16

31 Aug '16

https://bugs.freedesktop.org/show_bug.cgi?id=91982 Bug ID: 91982 Summary: [radeonsi] fs leak in get_radeon_bo() 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: shawn.starr(a)rogers.com QA Contact: dri-devel(a)lists.freedesktop.org While debugging something for Borderlands 2, I broke the DRI driver, tripped a file descriptor leak Mesa git master (Sept 10th build), kernel 4.3.0-0.rc0.git9.2.fc24.x86_64m libdrm-2.4.64 aug 18th Steps to reproduce fd leak ========================== Take my trace for Borderlands 2 from here: https://drive.google.com/open?id=0Bze7CJKD12nORWQ4RTdIbk4zT1k 1) apitrace trim --frames=0-2469 --exact -o bl2469.trace Borderlands2-menu.trace 2) apitrace replay --loop -b bl2469.trace Wait... it will crash... see attachment Kernel: [129925.490377] VFS: file-max limit 100000 reached [129925.651137] [drm:radeon_gem_object_create [radeon]] *ERROR* Failed to allocate GEM object (135168, 2, 4096, -23) [129925.651717] [drm:radeon_gem_object_create [radeon]] *ERROR* Failed to allocate GEM object (135168, 2, 4096, -23) [129925.652239] [drm:radeon_gem_object_create [radeon]] *ERROR* Failed to allocate GEM object (135168, 2, 4096, -23) [129925.652754] [drm:radeon_gem_object_create [radeon]] *ERROR* Failed to allocate GEM object (135168, 2, 4096, -23) [129925.653278] [drm:radeon_gem_object_create [radeon]] *ERROR* Failed to allocate GEM object (1216512, 2, 4096, -23) [129925.653813] [drm:radeon_gem_object_create [radeon]] *ERROR* Failed to allocate GEM object (1216512, 2, 4096, -23) [129925.764233] [drm:radeon_gem_object_create [radeon]] *ERROR* Failed to allocate GEM object (8847360, 6, 16384, -23) [129925.764829] [drm:radeon_gem_object_create [radeon]] *ERROR* Failed to allocate GEM object (8847360, 6, 16384, -23) [131671.087659] [drm:radeon_gem_object_create [radeon]] *ERROR* Failed to allocate GEM object (4096, 6, 4096, -23) [131671.207257] [drm:radeon_gem_object_create [radeon]] *ERROR* Failed to allocate GEM object (4096, 6, 4096, -23) [131671.241259] [drm:radeon_gem_object_create [radeon]] *ERROR* Failed to allocate GEM object (4096, 6, 4096, -23) [131671.311307] [drm:radeon_gem_object_create [radeon]] *ERROR* Failed to allocate GEM object (4096, 2, 4096, -23) [131671.312227] [drm:radeon_gem_object_create [radeon]] *ERROR* Failed to allocate GEM object (4096, 2, 4096, -23) [131671.331355] [drm:radeon_gem_object_create [radeon]] *ERROR* Failed to allocate GEM object (3244032, 2, 4096, -23) See attachment for stack dump from DRI -- You are receiving this mail because: You are the assignee for the bug.

1 8

[Bug 92912] Full GPU lockups in TF2 - R600
by bugzilla-daemon＠freedesktop.org 29 Aug '16

29 Aug '16

https://bugs.freedesktop.org/show_bug.cgi?id=92912 Bug ID: 92912 Summary: Full GPU lockups in TF2 - R600 Product: Mesa Version: 11.0 Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/r600 Assignee: dri-devel(a)lists.freedesktop.org Reporter: hofmann.zachary(a)gmail.com QA Contact: dri-devel(a)lists.freedesktop.org Created attachment 119583 --> https://bugs.freedesktop.org/attachment.cgi?id=119583&action=edit Partial dmesg log where the GPU tries to reset itself and fails I'm experiencing some random lockups whilst playing TF2. There doesn't seem to be any particular cause, and they happen after a random period of time (but still fairly often). There don't seem to be any accompanying symptoms. I've attached a relevant log, and the versions of relevant packages and other info are listed below. Please let me know if I've missed anything, or if any additional logs or dumps would be useful. GPU - Radeon HD 4670 Mesa 11.0.4 LLVM 3.7.0-r2 libdrm 2.4.65 Linux kernel 4.3.0-gentoo -- You are receiving this mail because: You are the assignee for the bug.

1 10

[Bug 92923] SGPR spilling
by bugzilla-daemon＠freedesktop.org 24 Aug '16

24 Aug '16

https://bugs.freedesktop.org/show_bug.cgi?id=92923 Bug ID: 92923 Summary: SGPR spilling Product: Mesa Version: 11.0 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: freedesktop.org(a)psycho3d.de QA Contact: dri-devel(a)lists.freedesktop.org Created attachment 119606 --> https://bugs.freedesktop.org/attachment.cgi?id=119606&action=edit stacktrace from game log file "LLVM triggered Diagnostic Handler: Ran out of VGPRs for spilling SGPR" The game Planet Explorers crashes after a few minutes, the log file is flooded with this error message. Additional error messages: radeon_llvm_compile: Processing Diag Flag LLVM failed to compile shader EE si_state_shaders.c:647 si_shader_select - Failed to build shader variant (type=1) 1 The problem may have started with mesa 11.0 but I'm not sure, I don't play it very often. The game runs on unity 5. Attaching backtrace and stacktrace from the log file. There is also a memory map I could attach. OpenGL info from the log file: Version: OpenGL 3.0 [3.0 Mesa 11.0.5] Renderer: Gallium 0.4 on AMD PITCAIRN (DRM 2.43.0, LLVM 3.7.0) Vendor: X.Org VRAM: 2048 MB Hardware is a Radeon HD 7870 -- You are receiving this mail because: You are the assignee for the bug.

1 15

[Bug 91342] Very dark textures on some objects in indoors environments in Postal 2
by bugzilla-daemon＠freedesktop.org 20 Aug '16

20 Aug '16

https://bugs.freedesktop.org/show_bug.cgi?id=91342 Bug ID: 91342 Summary: Very dark textures on some objects in indoors environments in Postal 2 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: acutiator(a)outlook.com QA Contact: dri-devel(a)lists.freedesktop.org Blocks: 77449 I'd like to take a screenshot, but Postal 2 likes to take over my desktop and I'm not certain how to rectify this. I can't alt-tab out of Postal 2 to take a screenshot and using Steam's screenshot utility, I only get garbled output. but on radeonsi on Cape Verde hardware (git-8787141) some models (mostly NPCs and doors) have VERY dark lighting, almost black. For the doors it is always the entire door that is dark, but it then sometimes is properly lit when I walk close enough to the door. For NPCs, they are sometimes properly lit below the waist and very dark above. I have an extra game in my Steam inventory and will be happy to send it to someone to help debug this. -- You are receiving this mail because: You are the assignee for the bug.

1 25

[Bug 61941] New: Random GPU lockups/resets on Mobility Radeon HD 3650 with radeon.dpm=1
by bugzilla-daemon＠bugzilla.kernel.org 19 Aug '16

19 Aug '16

https://bugzilla.kernel.org/show_bug.cgi?id=61941 Bug ID: 61941 Summary: Random GPU lockups/resets on Mobility Radeon HD 3650 with radeon.dpm=1 Product: Drivers Version: 2.5 Kernel Version: >=3.11.0 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: itumaykin(a)gmail.com Regression: No Created attachment 109311 --> https://bugzilla.kernel.org/attachment.cgi?id=109311&action=edit lspci -vvv Hello. I have 3.11 kernel with radeon.dpm enabled via kernel boot option. Sometimes under unknown circumstances my GPU resets. It happens seldom and randomly during a common desktop workflow: web browsing, document typing, video playback. No games or video benchmarks or any other GPU-eating stuff. During such lockup my screen turns black, but backlight is still on. After a while image reappears, though it is blurry and after 10-15 seconds my screen is back to normal state completely. Also sometimes after such reset I am able to continue working, but sometimes screen is stuck with one image that appeared after screen restoration and I have to reboot machine to fix this. Everything else seems to work fine during lockups, for example music is playing without any problems. I can't say for sure, but it looks like this bug happens more often when some video is played in Firefox. (JIC: I don't have Adobe Flash installed.) My OS is Gentoo amd64 with vanilla kernel 3.11.{0,1}. And this happens with power_dpm_state set to "balanced". I've attached two dmesg outputs after such lockups. I do understand that it is probably too vague description to fix this and I am ready to provide any other additional info. -- You are receiving this mail because: You are watching the assignee of the bug.

1 25

[Bug 93288] dpm malfunction on radeon hawaii r9 390X
by bugzilla-daemon＠freedesktop.org 18 Aug '16

18 Aug '16

https://bugs.freedesktop.org/show_bug.cgi?id=93288 Bug ID: 93288 Summary: dpm malfunction on radeon hawaii r9 390X 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: dev(a)illwieckz.net QA Contact: dri-devel(a)lists.freedesktop.org Hi, I encounter many problems with radeonsi and dpm (I never got it working, even with previous radeon cards I owned). While running linux 4.2 two months ago I got a a graphical hang with a "[drm:radeon_pm_resume [radeon]] *ERROR* radeon: dpm resume failed" message. To get this bug I just had to boot my system and wait less than 10min before it hangs. The system was still usable by ssh, but the "reboot" never complete. I was running 4.2 kernel on Ubuntu Wily with mesa git (I'm using some nightly build packages). I have a radeon R9 390X (Hawaii), lspci says that: 01:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. [AMD/ATI] Hawaii XT [Radeon R9 290X] [1002:67b0] (rev 80) (prog-if 00 [VGA controller]) dmesg says that: [drm:radeon_pm_resume [radeon]] *ERROR* radeon: dpm resume failed I 'll join a detailed lspci entry, a complete dmesg log and a screen photo. The only way to run the radeon R9 390X is to run radeon.dpm=0 and it was needed too for a radeon HD 7970 I had in the past. Right now, I tried to reboot with radeon.dpm=1 and I got a graphical hang then some weird stuff printed on screen. I rebooted my computer to not burn my CPU (see https://bugs.freedesktop.org/show_bug.cgi?id=93101 ), so currently the only information I have is the ones was syslogged. It printed things like that: Dec 8 01:32:07 gollum kernel: [ 82.262780] radeon 0000:01:00.0: ring 3 stalled for more than 10368msec Dec 8 01:32:07 gollum kernel: [ 82.262790] radeon 0000:01:00.0: GPU lockup (current fence id 0x000000000000155c last fence id 0x0000000000001655 on ring 3) Dec 8 01:32:08 gollum kernel: [ 82.366721] radeon 0000:01:00.0: ring 4 stalled for more than 10472msec Dec 8 01:32:08 gollum kernel: [ 82.366729] radeon 0000:01:00.0: ring 0 stalled for more than 10472msec Dec 8 01:32:08 gollum kernel: [ 82.366737] radeon 0000:01:00.0: GPU lockup (current fence id 0x000000000000089a last fence id 0x000000000000089b on ring 4) Dec 8 01:32:08 gollum kernel: [ 82.366744] radeon 0000:01:00.0: GPU lockup (current fence id 0x0000000000000ce4 last fence id 0x0000000000000d0e on ring 0) Dec 8 01:32:27 gollum kernel: [ 101.898853] radeon 0000:01:00.0: Saved 3901 dwords of commands on ring 0. Dec 8 01:32:27 gollum kernel: [ 101.898870] radeon 0000:01:00.0: GPU softreset: 0x00000009 Right now I'm running: - Ubuntu Wily 15.10 + Oibaf PPA - Linux 4.3 - libdrm-radeon1 2.4.65+git1512011830.42f2f9~gd~w - xserver-xorg-video-radeon 7.6.99+git1512040732.78fbca~gd~w - xserver-xorg 7.7+7ubuntu4 - libgl1-mesa-dri 11.2~git1512061930.d108b6~gd~w And dmesg | grep radeon says: [ 0.000000] Command line: BOOT_IMAGE=/boot/vmlinuz-4.3.0-040300-generic root=/dev/mapper/gollum--vg-gollum--disk ro quiet splash nomdmonddf nomdmonisw libata.atapi_passthru16=0 radeon.dpm=0 vt.handoff=7 [ 0.000000] Kernel command line: BOOT_IMAGE=/boot/vmlinuz-4.3.0-040300-generic root=/dev/mapper/gollum--vg-gollum--disk ro quiet splash nomdmonddf nomdmonisw libata.atapi_passthru16=0 radeon.dpm=0 vt.handoff=7 [ 1.958053] [drm] radeon kernel modesetting enabled. [ 1.962224] fb: switching to radeondrmfb from VESA VGA [ 1.962529] radeon 0000:01:00.0: Invalid ROM contents [ 1.962629] radeon 0000:01:00.0: VRAM: 8192M 0x0000000000000000 - 0x00000001FFFFFFFF (8192M used) [ 1.962631] radeon 0000:01:00.0: GTT: 2048M 0x0000000200000000 - 0x000000027FFFFFFF [ 1.962710] [drm] radeon: 8192M of VRAM memory ready [ 1.962711] [drm] radeon: 2048M of GTT memory ready. [ 1.962888] [drm] radeon: power management initialized [ 1.968997] radeon 0000:01:00.0: WB enabled [ 1.969003] radeon 0000:01:00.0: fence driver on ring 0 use gpu addr 0x0000000200000c00 and cpu addr 0xffff8808126b5c00 [ 1.969005] radeon 0000:01:00.0: fence driver on ring 1 use gpu addr 0x0000000200000c04 and cpu addr 0xffff8808126b5c04 [ 1.969007] radeon 0000:01:00.0: fence driver on ring 2 use gpu addr 0x0000000200000c08 and cpu addr 0xffff8808126b5c08 [ 1.969009] radeon 0000:01:00.0: fence driver on ring 3 use gpu addr 0x0000000200000c0c and cpu addr 0xffff8808126b5c0c [ 1.969011] radeon 0000:01:00.0: fence driver on ring 4 use gpu addr 0x0000000200000c10 and cpu addr 0xffff8808126b5c10 [ 1.969410] radeon 0000:01:00.0: fence driver on ring 5 use gpu addr 0x0000000000076c98 and cpu addr 0xffffc90004036c98 [ 1.969558] radeon 0000:01:00.0: fence driver on ring 6 use gpu addr 0x0000000200000c18 and cpu addr 0xffff8808126b5c18 [ 1.969560] radeon 0000:01:00.0: fence driver on ring 7 use gpu addr 0x0000000200000c1c and cpu addr 0xffff8808126b5c1c [ 1.969631] radeon 0000:01:00.0: radeon: using MSI. [ 1.969660] [drm] radeon: irq initialized. [ 3.762178] fbcon: radeondrmfb (fb0) is primary device [ 3.780407] radeon 0000:01:00.0: fb0: radeondrmfb frame buffer device [ 3.791974] [drm] Initialized radeon 2.43.0 20080528 for 0000:01:00.0 on minor 0 -- You are receiving this mail because: You are the assignee for the bug.

1 15

[Bug 81382] New: Text console blanking does not go away
by bugzilla-daemon＠freedesktop.org 15 Aug '16

15 Aug '16

https://bugs.freedesktop.org/show_bug.cgi?id=81382 Priority: medium Bug ID: 81382 Assignee: dri-devel(a)lists.freedesktop.org Summary: Text console blanking does not go away Severity: normal Classification: Unclassified OS: All Reporter: vda.linux(a)googlemail.com Hardware: Other Status: NEW Version: XOrg CVS Component: DRM/Radeon Product: DRI Created attachment 102847 --> https://bugs.freedesktop.org/attachment.cgi?id=102847&action=edit dmesg I log in as root on a text virtual console. After about 10 minutes screen blanks. Surprisingly, pressing a key does *not* unblank the screen! Machine is still alive (I can ssh into it), and typed keys even reach the console: I can type e.g. "ls -lR /usr" and I see disk indicator blinking, ls process is visible in the ps in ssh session, etc. This does not happen in X. This is observed on Lenovo T60, on RHEL7 kernel and also on recent upstream kernel 3.15.5. Investigation had revealed that VT unblanking code, after all the hard work it done to turn display back on, calls ATOM_LCD_BLOFF (backlight off, numeric value 2) function. Digging further, I discovered that fb_blank(blank=0) almost at its end calls fb_notifier_call_chain(FB_EVENT_BLANK). Which calls backlight.c::fb_notifier_callback(), which tries to set brightness via radeon_atom_backlight_update_status(), which does atombios_set_backlight_level(radeon_atom_bl_level()), but radeon_atom_bl_level() is zero (it's an uint8_t, brightness level). So it's essentially atombios_set_backlight_level(0) and it switches backlight off. In drivers/gpu/drm/radeon/*, bd->props.brightness, surprisingly, is only set in radeon_atom_backlight_init() and radeon_legacy_backlight_init(), all other locations are only reading it. So, if this init code sets it to 0, then VT unblanking code will use this zero value as brightness to restore, causing this bug. And indeed, that's what happens on the machine exhibiting this bug: [ 2.301563] radeon_atom_get_backlight_level_from_reg: RADEON_BIOS_2_SCRATCH [ 2.301633] radeon_atom_get_backlight_level_from_reg: bios_2_scratch:00000000 [ 2.301704] radeon_atom_backlight_init: bd->props.brightness=0 [ 2.301780] radeon_atom_backlight_update_status: atombios_set_back The full dmesg of the RHEL7 boot with many debug printks added is attached. (Sorry, I started debugging it on RHEL7, I believe mainline does not differ significantly). It shows the following: After "setterm -blank 1 && sleep 60", VT blanking triggers at ~362 seconds, and at ~370 seconds VT is trying to unblank because of keyboard activity. The bug is evident here: [ 370.852058] fb_blank: fb_notifier_call_chain(FB_EVENT_BLANK)... [ 370.852061] fbcon_event_notify: case FB_EVENT_BLANK: fbcon_fb_blanked(blank:0) [ 370.852063] fbcon_fb_blanked: do_unblank_screen(0) [ 370.852064] do_unblank_screen: entered on cpu 0 [ 370.852066] do_unblank_screen: !console_blanked on cpu 0 [ 370.852068] backlight: drivers/video/backlight/backlight.c:fb_notifier_callback: backlight_update_status() [ 370.852071] radeon_atom_backlight_update_status: atombios_set_backlight_level() [ 370.852072] radeon_atom_bl_level: level = bd->props.brightness:0 [ 370.852074] atombios_set_backlight_level(level:0) [ 370.852077] atombios_set_backlight_level: atom_execute_table(ATOM_LCD_BLOFF) ^^^^^^^^^^^^^^^^^^^^ THIS TURNS OFF DISPLAY ^^^^^^^^^^^^^^^^^ [ 370.852083] atom_execute_table_locked(index:23,*params:ffff8802) returns 0 [ 370.852085] backlight: drivers/video/backlight/backlight.c:fb_notifier_callback: backlight_update_status() [ 370.852940] fb_blank returns 0 [ 370.852942] fbcon_blank: update_screen()... [ 370.862313] do_unblank_screen: done on cpu 0 Note: PCI error seen during blanking is not causing this bug. It happens on first blanking (including Xserver screen blankings, which do not exhibit this bug), and never repeats. Google says it's a known issue on Radeon, comes from PCIe lanes reconfiguration. I am unsure how to proceed from here. Maybe init code needs fixing to properly read backlight brightness on this hardware? I think radeon people are more qualified to take it from here. I'm willing to test patches. -- You are receiving this mail because: You are the assignee for the bug.

1 45

[Bug 85241] New: audio over HDMI on AMD E-350 with radeon driver
by bugzilla-daemon＠bugzilla.kernel.org 15 Aug '16

15 Aug '16

https://bugzilla.kernel.org/show_bug.cgi?id=85241 Bug ID: 85241 Summary: audio over HDMI on AMD E-350 with radeon driver Product: Drivers Version: 2.5 Kernel Version: 3.14 and higher 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: wmyrda(a)auticon.pl Regression: No I have problem with HDMI and audio on my Asus AMD E-350 platform which started around kernel 3.14 with sigle error message "[drm:dce4_afmt_write_speaker_allocation] *ERROR* Couldn't read Speaker Allocation Data Block: 0" which become even more severe with kernels 3.15 & 3.16 as now logs are flooded with "sound hdaudioC0D0: HDMI ATI/AMD: no speaker allocation for ELD" My setup is PC with Asus E-350 connected directly to the TV with HDMI cable (it has been in the past to the 5.1 analog system hence the entry of "options snd-hda-intel model=3stack-6ch-dig" in /etc/modprobe.d/alsa.conf) on software side it is Gentoo with libdrm & mesa & xf86-video-ati --- git versions updated on the regular basis about every 1-2 weeks pulseaudio 5.0 xorg 1.16.1 here are some logs. If more info is needed please let me know dmesg 3.14.19 http://pastebin.com/AHyV1nRk Xorg.0.log http://pastebin.com/J66tUcU5 audio 3.16.3 http://www.alsa-project.org/db/?f=7e2075...92b0b5c23e audio 3.15.10 http://www.alsa-project.org/db/?f=bbb92a...14bd0bc831 audio 3.14.19 http://www.alsa-project.org/db/?f=5d2f93...2a7a6697a6 -- You are receiving this mail because: You are watching the assignee of the bug.

1 6

[Bug 93516] "Gods Will Be Watching" hangs at chapter load
by bugzilla-daemon＠freedesktop.org 14 Aug '16

14 Aug '16

https://bugs.freedesktop.org/show_bug.cgi?id=93516 Bug ID: 93516 Summary: "Gods Will Be Watching" hangs at chapter load Product: Mesa Version: 11.0 Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/r600 Assignee: dri-devel(a)lists.freedesktop.org Reporter: andreaskem(a)web.de QA Contact: dri-devel(a)lists.freedesktop.org Created attachment 120709 --> https://bugs.freedesktop.org/attachment.cgi?id=120709&action=edit strace output Hi, I am using the radeon r600 driver on an integrated AMD GPU listed by lspci as [AMD/ATI] Wrestler [Radeon HD 7340]. It is the GPU part of the AMD E2-2000 APU. I am on an up-to-date x86-64 Arch Linux [testing] system: *** mesa 11.1.0 xf86-video-ati 7.6.1 xorg-server 1.18.0 libdrm 2.4.65 llvm 3.7.0 linux 4.3.3 (corresponding 32 bit versions are installed where applicable) *** While trying to play the Steam game "Gods Will Be Watching", I encounter a hang at the start of chapter 1 with no progress being made at the black screen showing "One Year Ago". This happens whenever I try to load the saved game at that point. Enabling LIBGL_ALWAYS_SOFTWARE allows the game to progress (but at an extremely low frame rate, of course). It does not matter whether I am using DRI2 or DRI3. Attached is the strace output with me killing the process at the end. I currently do not have debug versions of the libraries installed, so the gdb backtrace is pretty useless, and I am not sure if I captured the right moment: *** #0 0xf7fd9be5 in __kernel_vsyscall () #1 0xf77eda2b in pthread_cond_wait@@GLIBC_2.3.2 () from /usr/lib32/libpthread.so.0 #2 0xf78f6d8d in pthread_cond_wait@@GLIBC_2.3.2 () from /usr/lib32/libc.so.6 #3 0xe0a10592 in ?? () from /usr/lib32/xorg/modules/dri/r600_dri.so #4 0xe0a115b0 in ?? () from /usr/lib32/xorg/modules/dri/r600_dri.so #5 0xe094a317 in ?? () from /usr/lib32/xorg/modules/dri/r600_dri.so #6 0xe0a2eb69 in ?? () from /usr/lib32/xorg/modules/dri/r600_dri.so #7 0xe05bce81 in ?? () from /usr/lib32/xorg/modules/dri/r600_dri.so #8 0xe060709b in ?? () from /usr/lib32/xorg/modules/dri/r600_dri.so #9 0xe06d9f18 in ?? () from /usr/lib32/xorg/modules/dri/r600_dri.so #10 0xf7d9ac25 in ?? () from /usr/lib32/libGL.so.1 #11 0xf7d9b00a in ?? () from /usr/lib32/libGL.so.1 #12 0xf7d711a3 in glXSwapBuffers () from /usr/lib32/libGL.so.1 #13 0x08260e61 in ?? () #14 0xf7818497 in __libc_start_main () from /usr/lib32/libc.so.6 #15 0x08050c75 in ?? () *** Excerpt from glxinfo: *** Extended renderer info (GLX_MESA_query_renderer): Vendor: X.Org (0x1002) Device: AMD PALM (DRM 2.43.0, LLVM 3.7.0) (0x9808) Version: 11.1.0 Accelerated: yes Video memory: 384MB Unified memory: no Preferred profile: core (0x1) Max core profile version: 3.3 Max compat profile version: 3.0 Max GLES1 profile version: 1.1 Max GLES[23] profile version: 3.0 *** Thank you for your work on the open source Linux graphics stack. It is very much appreciated. Andreas Kempf -- You are receiving this mail because: You are the assignee for the bug.

1 2

[Bug 85087] New: [NVD9] Thinkpad T420 - freezes under load
by bugzilla-daemon＠freedesktop.org 10 Aug '16

10 Aug '16

https://bugs.freedesktop.org/show_bug.cgi?id=85087 Bug ID: 85087 Summary: [NVD9] Thinkpad T420 - freezes under load Product: DRI Version: XOrg CVS Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: major Priority: medium Component: DRM/other Assignee: dri-devel(a)lists.freedesktop.org Reporter: david.heidelberger(a)ixit.cz Dist: Ubuntu 14.04 Kernel: 3.13 - 3.17.1 Mesa/DDX: Ubuntu default - oibaf git generated Setting: to discrete GPU (PRIME disabled). When loading Nouveau or in third icon of KDE loading (probably kwin load compositing) it froze. No SYSRQ, no ssh working. It's completly frozen. It's not my laptop, so i'll try proviede debug information, but it will take time. [ 0.767676] [drm] Initialized drm 1.1.0 20060810 [ 0.797073] nouveau [ DEVICE][0000:01:00.0] BOOT0 : 0x0d9170a1 [ 0.797158] nouveau [ DEVICE][0000:01:00.0] Chipset: GF119 (NVD9) [ 0.797244] nouveau [ DEVICE][0000:01:00.0] Family : NVC0 [ 0.797346] nouveau [ VBIOS][0000:01:00.0] checking PRAMIN for image... [ 0.866415] nouveau [ VBIOS][0000:01:00.0] ... appears to be valid [ 0.866503] nouveau [ VBIOS][0000:01:00.0] using image from PRAMIN [ 0.866698] nouveau [ VBIOS][0000:01:00.0] BIT signature found [ 0.866784] nouveau [ VBIOS][0000:01:00.0] version 75.19.53.00.00 [ 0.867372] nouveau 0000:01:00.0: irq 27 for MSI/MSI-X [ 0.867381] nouveau [ PMC][0000:01:00.0] MSI interrupts enabled [ 0.867509] nouveau W[ PFB][0000:01:00.0][0x00000000][ffff88003600a800] reclocking of this ram type unsupported [ 0.867654] nouveau [ PFB][0000:01:00.0] RAM type: DDR3 [ 0.867766] nouveau [ PFB][0000:01:00.0] RAM size: 1024 MiB [ 0.867878] nouveau [ PFB][0000:01:00.0] ZCOMP: 0 tags [ 0.869561] nouveau [ VOLT][0000:01:00.0] GPU voltage: 850000uv [ 0.900042] nouveau [ PTHERM][0000:01:00.0] FAN control: none / external [ 0.900163] nouveau [ PTHERM][0000:01:00.0] fan management: automatic [ 0.900285] nouveau [ PTHERM][0000:01:00.0] internal sensor: yes [ 0.900423] nouveau [ CLK][0000:01:00.0] 07: core 270 MHz memory 405 MHz [ 0.900561] nouveau [ CLK][0000:01:00.0] 0f: core 810 MHz memory 800 MHz [ 0.900851] nouveau [ CLK][0000:01:00.0] --: core 270 MHz memory 405 MHz [ 0.905408] nouveau [ DRM] VRAM: 1024 MiB [ 0.905516] nouveau [ DRM] GART: 1048576 MiB [ 0.905626] nouveau [ DRM] TMDS table version 2.0 [ 0.905736] nouveau [ DRM] DCB version 4.0 [ 0.905844] nouveau [ DRM] DCB outp 00: 01800323 00010034 [ 0.905956] nouveau [ DRM] DCB outp 01: 02811300 00000000 [ 0.906068] nouveau [ DRM] DCB outp 02: 028223a6 0f220010 [ 0.906180] nouveau [ DRM] DCB outp 03: 02822362 00020010 [ 0.906291] nouveau [ DRM] DCB outp 04: 048333b6 0f220010 [ 0.906402] nouveau [ DRM] DCB outp 05: 04833372 00020010 [ 0.906513] nouveau [ DRM] DCB outp 06: 088443c6 0f220010 [ 0.906632] nouveau [ DRM] DCB outp 07: 08844382 00020010 [ 0.906745] nouveau [ DRM] DCB conn 00: 00000040 [ 0.906937] nouveau [ DRM] DCB conn 01: 00000100 [ 0.907122] nouveau [ DRM] DCB conn 02: 00101246 [ 0.907323] nouveau [ DRM] DCB conn 03: 00202346 [ 0.907507] nouveau [ DRM] DCB conn 04: 00410446 [ 0.908716] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013). [ 0.908836] [drm] Driver supports precise vblank timestamp query. [ 0.914353] nouveau [ DRM] MM: using COPY0 for buffer copies [ 1.232769] nouveau [ DRM] allocated 1920x1080 fb: 0x60000, bo ffff88020ee67400 [ 1.232978] fbcon: nouveaufb (fb0) is primary device [ 1.309034] nouveau 0000:01:00.0: fb0: nouveaufb frame buffer device [ 1.309054] nouveau 0000:01:00.0: registered panic notifier [ 1.311511] [drm] Initialized nouveau 1.2.0 20120801 for 0000:01:00.0 on minor 0 -- You are receiving this mail because: You are the assignee for the bug.

1 2

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel January 2016