dri-devel November 2012

dri-devel@lists.freedesktop.org

126 participants
797 discussions

[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

[Bug 48424] New: Fix warnings/errors reported by clang's scan-build tool
by bugzilla-daemon＠freedesktop.org 12 Apr '18

12 Apr '18

https://bugs.freedesktop.org/show_bug.cgi?id=48424 Bug #: 48424 Summary: Fix warnings/errors reported by clang's scan-build tool Classification: Unclassified Product: Mesa Version: git Platform: x86 (IA32) URL: https://gitorious.org/jobermayr/scan-build-mesa OS/Version: All Status: NEW Severity: normal Priority: medium Component: Mesa core AssignedTo: mesa-dev(a)lists.freedesktop.org ReportedBy: johannesobermayr(a)gmx.de CC: dri-devel(a)lists.freedesktop.org, nouveau(a)lists.freedesktop.org https://gitorious.org/jobermayr/scan-build-mesa ~ 8 MB to download, 680 MB on disk. Please report false positives here. I will forward them. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

1 6

[Bug 42941] New: Resume from suspend to memory leaves display blank on Lenovo Ideapad U455
by bugzilla-daemon＠bugzilla.kernel.org 07 Mar '18

07 Mar '18

https://bugzilla.kernel.org/show_bug.cgi?id=42941 Summary: Resume from suspend to memory leaves display blank on Lenovo Ideapad U455 Product: Power Management Version: 2.5 Kernel Version: 3.3.0-rc7+ Platform: All OS/Version: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: Hibernation/Suspend AssignedTo: power-management_other(a)kernel-bugs.osdl.org ReportedBy: e-mail(a)date.by CC: drivers_video-dri(a)kernel-bugs.osdl.org Regression: No Created an attachment (id=72610) --> (https://bugzilla.kernel.org/attachment.cgi?id=72610) dmesg output Hardware: Lenovo Ideapad U455 laptop with AMD Athlon Neo processor and two video cards: Radeon HD 3200 and Radeon HD 4500. Description: when system resumes from suspend to memory (`echo mem > /sys/power/state`) system resumes fine as i can log into it via ssh and display turns on, but the display stays black showing nothing. However it's possible to make display show a picture by switching video cards with vga_switcheroo. Steps to reproduce attached dmesg log (see my comments below): [1]# mount -t debugfs none /sys/kernel/debug [2]# cat /sys/kernel/debug/vgaswitcheroo/switch 0:IGD:+:Pwr:0000:01:05.0 1:DIS: :Pwr:0000:02:00.0 [3]# echo mem > /sys/power/state [4]# cat /sys/kernel/debug/vgaswitcheroo/switch 0:IGD:+:Pwr:0000:01:05.0 1:DIS: :Pwr:0000:02:00.0 [5]# echo DIS > /sys/kernel/debug/vgaswitcheroo/switch [6]# echo IGD > /sys/kernel/debug/vgaswitcheroo/switch [7]# cat /sys/kernel/debug/vgaswitcheroo/switch 0:IGD:+:Pwr:0000:01:05.0 1:DIS: :Off:0000:02:00.0 [8]# echo mem > /sys/power/state [9]# cat /sys/kernel/debug/vgaswitcheroo/switch 0:IGD:+:Pwr:0000:01:05.0 1:DIS: :Off:0000:02:00.0 [10]# echo DIS > /sys/kernel/debug/vgaswitcheroo/switch [11]# echo IGD > /sys/kernel/debug/vgaswitcheroo/switch Comments: [2] This shows the state of the video cards before suspend. [3] Suspend worked fine, but display was blank after resume. [4] This shows the state of the video cards after resume. [5] That command made display to show the picture. [7] This shows the state of the video cards before second suspend, when only IGD card was active. [8] Suspend worked fine, but resume took a lot of time: PM: resume devices took 82.256 seconds ------------[ cut here ]------------ WARNING: at kernel/power/suspend_test.c:53 suspend_test_finish+0x86/0x90() Hardware name: 20046 Component: resume devices, time: 82256 Modules linked in: btusb bluetooth snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device snd_pcm_oss snd_mixer_oss ipv6 ext2 mbcache cpufreq_ondemand powernow_k8 freq_table mperf lp parport_pc parport fuse radeon brcmsmac ttm mac80211 drm_kms_helper joydev snd_hda_codec_hdmi ohci_hcd snd_hda_codec_conexant brcmutil ssb snd_hda_intel drm mmc_core snd_hda_codec sp5100_tco cfg80211 sg ideapad_laptop agpgart psmouse atl1c thermal snd_hwdep processor video crc8 thermal_sys pcmcia snd_pcm snd_timer cordic rtc_cmos pcmcia_core shpchp sparse_keymap evdev ehci_hcd i2c_piix4 snd k8temp i2c_algo_bit bcma rfkill i2c_core serio_raw soundcore snd_page_alloc battery ac hwmon button loop btrfs [last unloaded: pcmcia_rsrc] Pid: 1834, comm: bash Not tainted 3.3.0-rc7+ #36 Call Trace: [<ffffffff8103fe3f>] warn_slowpath_common+0x7f/0xc0 [<ffffffff8103ff36>] warn_slowpath_fmt+0x46/0x50 [<ffffffff8107fc96>] suspend_test_finish+0x86/0x90 [<ffffffff8107f9a1>] suspend_devices_and_enter+0x101/0x1e0 [<ffffffff8107fb51>] enter_state+0xd1/0x110 [<ffffffff8107e4c7>] state_store+0xb7/0x130 [<ffffffff812623cf>] kobj_attr_store+0xf/0x30 [<ffffffff811b0d22>] sysfs_write_file+0xf2/0x180 [<ffffffff81149793>] vfs_write+0xb3/0x180 [<ffffffff81149aba>] sys_write+0x4a/0x90 [<ffffffff8153f829>] system_call_fastpath+0x16/0x1b ---[ end trace 6802c35567ce73fa ]--- PM: Finishing wakeup. [9] This shows the state of the video cards after second resume. [10] That command turned display off and that's what appeared in dmesg output: radeon: switched on radeon 0000:02:00.0: enabling device (0000 -> 0003) radeon 0000:02:00.0: Wait for MC idle timedout ! radeon 0000:02:00.0: Wait for MC idle timedout ! [drm] PCIE GART of 512M enabled (table at 0x0000000000040000). radeon 0000:02:00.0: WB enabled [drm] fence driver on ring 0 use gpu addr 0x20000c00 and cpu addr 0xffff8800a4523c00 [drm:r600_ring_test] *ERROR* radeon: ring 0 test failed (scratch(0x8500)=0xFFFFFFFF) [drm:rv770_resume] *ERROR* r600 startup failed on resume fbcon: Remapping primary device, fb1, to tty 1-63 radeon: switched off [11] That command made display to show the picture. Notes: * I have read Documentation/power/basic-pm-debugging.txt and made all described tests and all of them were successful. * I have tried different quirks with `pm-suspend --quirk-*`, but none of them helped. -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching someone on the CC list of the bug.

1 3

[Bug 50325] New: Glyphy bad render on r600g (software render is fine)
by bugzilla-daemon＠freedesktop.org 06 Mar '18

06 Mar '18

https://bugs.freedesktop.org/show_bug.cgi?id=50325 Bug #: 50325 Summary: Glyphy bad render on r600g (software render is fine) Classification: Unclassified Product: Mesa Version: 8.0 Platform: x86-64 (AMD64) OS/Version: Linux (All) Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/r600 AssignedTo: dri-devel(a)lists.freedesktop.org ReportedBy: edwin+mesa(a)etorok.net Created attachment 62078 --> https://bugs.freedesktop.org/attachment.cgi?id=62078 apitrace (cf. https://github.com/apitrace/apitrace/tree/1.0) I just tried Glyphy on r600g and the output is very bad. Don't know if its Glyphy bug or Mesa bug, but if I force software rendering in Mesa then I do see the output. Attached screenshots of bad (r600g) and good (software render). The bad render was obtained by: demo/glyphy-demo The good one: LIBGL_ALWAYS_SOFTWARE=1 demo/glyphy-demo I tested on: OpenGL vendor string: X.Org OpenGL renderer string: Gallium 0.4 on AMD RV730 OpenGL version string: 2.1 Mesa 8.0.2 OpenGL shading language version string: 1.20 I'll try to test on mesa git later to see if its still an issue there. Also attached is a an apitrace, and the bad render can be reproduced with: build/glretrace lt-glyphy-demo.trace The good render (initialization a bit slow, but works): LIBGL_ALWAYS_SOFTWARE=1 build/glretrace lt-glyphy-demo.trace The source code for Glyphy can be found here: https://code.google.com/p/glyphy/source/checkout -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.

1 10

[Bug 50338] New: r600g: EE r600_shader.c:140 r600_pipe_shader_create - translation from TGSI failed !
by bugzilla-daemon＠freedesktop.org 06 Mar '18

06 Mar '18

https://bugs.freedesktop.org/show_bug.cgi?id=50338 Bug #: 50338 Summary: r600g: EE r600_shader.c:140 r600_pipe_shader_create - translation from TGSI failed ! Classification: Unclassified Product: Mesa Version: git Platform: x86-64 (AMD64) OS/Version: Linux (All) Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/r600 AssignedTo: dri-devel(a)lists.freedesktop.org ReportedBy: edwin+mesa(a)etorok.net Created attachment 62087 --> https://bugs.freedesktop.org/attachment.cgi?id=62087 R600_DUMP_SHADERS=1 output Trying to reproduce bug #50325 on Mesa git caused this error: EE r600_shader.c:140 r600_pipe_shader_create - translation from TGSI failed ! Bug can be reproduced by one of these: build/glretrace lt-glyphy-demo.trace demo/glyphy-demo I get the translation failed error both with R600_LLVM=0, and R600_LLVM=1. I've attached the R600_DUMP_SHADERS=1 output. glretrace is from https://github.com/apitrace/apitrace/tree/1.0 and glyphy is from https://code.google.com/p/glyphy/source/checkout lt-glypy-demo.trace is here: https://bugs.freedesktop.org/attachment.cgi?id=62078 git version of Mesa: OpenGL vendor string: X.Org OpenGL renderer string: Gallium 0.4 on AMD RV730 OpenGL version string: 2.1 Mesa 8.1-devel (git-35f302d) OpenGL shading language version string: 1.30 OpenGL extensions: Built with (on Debian unstable): ./configure --with-dri-drivers= --with-gallium-drivers=r600,swrast --enable-glx-tls --enable-gallium-llvm LLVM_CONFIG=/usr/bin/llvm-config-3.1 -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.

1 4

[Bug 47201] New: TGSI source register with absolute negative modifier does not work correctly
by bugzilla-daemon＠freedesktop.org 06 Mar '18

06 Mar '18

https://bugs.freedesktop.org/show_bug.cgi?id=47201 Bug #: 47201 Summary: TGSI source register with absolute negative modifier does not work correctly Classification: Unclassified Product: Mesa Version: 8.0 Platform: Other OS/Version: Linux (All) Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/r600 AssignedTo: dri-devel(a)lists.freedesktop.org ReportedBy: llyzs(a)163.com Recently I found a TGSI fragment shader does not render correctly with r600 driver and I further identified the issue down to instructions in this form: CMP TEMP[0].yz, -|TEMP[1].xxxx|, TEMP[2].xxxx, CONST[0].xyxw If I covert all those instructions to the equivalents: ABS TEMP[5], TEMP[1].xxxx CMP TEMP[0].yz, -TEMP[5], TEMP[2].xxxx, CONST[0].xyxw It then works fine. However, the original instructions work just fine with nouveau and swrast driver, so it should be a r600 bug. Any clue on this issue? -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.

1 9

[Bug 36072] New: celestia causes kernel oops when allocation a lot of memory (for textures)
by bugzilla-daemon＠bugzilla.kernel.org 28 Feb '18

28 Feb '18

https://bugzilla.kernel.org/show_bug.cgi?id=36072 Summary: celestia causes kernel oops when allocation a lot of memory (for textures) Product: Drivers Version: 2.5 Kernel Version: 2.6.38 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: acelists(a)atlas.sk Regression: Yes The celestia program often allocates a lot of memory (like 1.5GB on my 2GB machine with 3GB swap) for its textures. I don't know where it stores them (probably not Video memory), but it seems in system RAM, because swap is used much. Sometimes when this happens the kernel crashes. After that I can only sync and reboot the machine with alt-sysrq commands. I have only noticed this with kernel 2.6.38.x, not before. I was using the OSS ati driver 6.14.1, with mesa 7.10.2. All including the kernel seft compiled (for AMD fam10h CPU). I do not understand the first line of the log. Where can I increase the vmalloc size. Is the on the kernel command line? But it should not crash the kernel in any case, just the program. Here is the kernel log: May 19 21:26:52 coolbox kernel: vmap allocation for size 178982912 failed: use vmalloc=<size> to increase size. May 19 21:26:52 coolbox kernel: BUG: unable to handle kernel paging request at b892a45d May 19 21:26:52 coolbox kernel: IP: [<f9696a50>] ttm_mem_io_lock+0x0/0x20 [ttm] May 19 21:26:52 coolbox kernel: *pde = 00000000 May 19 21:26:52 coolbox kernel: Oops: 0000 [#1] PREEMPT SMP May 19 21:26:52 coolbox kernel: last sysfs file: /sys/devices/LNXSYSTM:00/device:00/PNP0A03:00/device:01/ATK0110:00/hwmon/hwmon0/fan3_input May 19 21:26:52 coolbox kernel: Modules linked in: fbcon font bitblit softcursor radeon ttm drm_kms_helper drm agpgart fb fbdev autofs4 cfbcopyarea cfbimgblt cfbfillrect nf_conntrack_ftp xt_tcpudp xt_owner xt_multiport nf_conntrack_ipv4 nf_defrag_ipv4 xt_state nf_conntrack ipt_REJECT ipt_LOG iptable_filter ip_tables x_tables asus_atk0110 snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device snd_pcm_oss snd_mixer_oss cpufreq_conservative cpufreq_ondemand psmouse pcspkr cx88_blackbird firmware_class cx2341x cx8802 tuner_simple tuner_types tda9887 tda8290 tea5767 tuner cx8800 cx88xx rc_core i2c_algo_bit tveeprom v4l2_common videodev btcx_risc videobuf_dma_sg videobuf_core forcedeth snd_hda_codec_via snd_hda_intel snd_hda_codec snd_pcm snd_timer snd soundcore snd_page_alloc i2c_nforce2 i2c_core ext4 mbcache jbd2 crc16 usbhid powernow_k8 processor mperf ohci_hcd ehci_hcd usbcore fuse May 19 21:26:52 coolbox kernel: May 19 21:26:52 coolbox kernel: Pid: 25014, comm: celestia Not tainted 2.6.38.6 #57 System manufacturer System Product Name/M2N68 May 19 21:26:52 coolbox kernel: EIP: 0060:[<f9696a50>] EFLAGS: 00010246 CPU: 3 May 19 21:26:52 coolbox kernel: EIP is at ttm_mem_io_lock+0x0/0x20 [ttm] May 19 21:26:52 coolbox kernel: EAX: b892a420 EBX: d03cfc28 ECX: 00000000 EDX: 00000000 May 19 21:26:52 coolbox kernel: ESI: f519a40c EDI: b892a420 EBP: d03cfd48 ESP: d03cfbf0 May 19 21:26:52 coolbox kernel: DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068 May 19 21:26:52 coolbox kernel: Process celestia (pid: 25014, ti=d03ce000 task=f06fb830 task.ti=d03ce000) May 19 21:26:52 coolbox kernel: Stack: May 19 21:26:52 coolbox kernel: f9696f25 d03cfc28 d03cfd80 d03cfc98 f96970e2 f29e2c2c fffffff4 00040002 May 19 21:26:52 coolbox kernel: f519a40c f9695c16 f29e2c64 f50135c0 00040001 00000002 00000002 d03cfcd0 May 19 21:26:52 coolbox kernel: f519a45c f519a40c 00000000 af3e5000 d03cfc48 d03cfc9c f519a40c d03cfc98 May 19 21:26:52 coolbox kernel: Call Trace: May 19 21:26:52 coolbox kernel: [<f9696f25>] ? ttm_mem_reg_iounmap+0x35/0x70 [ttm] May 19 21:26:52 coolbox kernel: [<f96970e2>] ? ttm_bo_move_memcpy+0x182/0x310 [ttm] May 19 21:26:52 coolbox kernel: [<f9695c16>] ? ttm_bo_mem_space+0x306/0x3a0 [ttm] May 19 21:26:52 coolbox kernel: [<f97f4fb0>] ? radeon_bo_move+0xe0/0x330 [radeon] May 19 21:26:52 coolbox kernel: [<f96944d5>] ? ttm_bo_reserve_locked+0xa5/0x120 [ttm] May 19 21:26:52 coolbox kernel: [<f97f4ed0>] ? radeon_bo_move+0x0/0x330 [radeon] May 19 21:26:52 coolbox kernel: [<f9694e15>] ? ttm_bo_handle_move_mem+0x135/0x330 [ttm] May 19 21:26:52 coolbox kernel: [<f9695ddc>] ? ttm_bo_move_buffer+0x12c/0x140 [ttm] May 19 21:26:52 coolbox kernel: [<f9695e86>] ? ttm_bo_validate+0x96/0x120 [ttm] May 19 21:26:52 coolbox kernel: [<f97f5f5a>] ? radeon_bo_list_validate+0x5a/0xe0 [radeon] May 19 21:26:52 coolbox kernel: [<f980d14c>] ? radeon_cs_ioctl+0x7c/0x1a0 [radeon] May 19 21:26:52 coolbox kernel: [<c0206466>] ? prepare_for_delete_or_cut+0x3c6/0x650 May 19 21:26:52 coolbox kernel: [<f96b3b51>] ? drm_ioctl+0x191/0x380 [drm] May 19 21:26:52 coolbox kernel: [<c0206466>] ? prepare_for_delete_or_cut+0x3c6/0x650 May 19 21:26:52 coolbox kernel: [<f980d0d0>] ? radeon_cs_ioctl+0x0/0x1a0 [radeon] May 19 21:26:52 coolbox kernel: [<c018ccf8>] ? handle_pte_fault+0x88/0x630 May 19 21:26:52 coolbox kernel: [<c026006f>] ? prio_tree_insert+0x12f/0x250 May 19 21:26:52 coolbox kernel: [<f96b39c0>] ? drm_ioctl+0x0/0x380 [drm] May 19 21:26:52 coolbox kernel: [<c01b1edf>] ? do_vfs_ioctl+0x7f/0x590 May 19 21:26:52 coolbox kernel: [<c011df35>] ? do_page_fault+0x185/0x3a0 May 19 21:26:52 coolbox kernel: [<c0190bae>] ? mmap_region+0x16e/0x440 May 19 21:26:52 coolbox kernel: [<c01351d5>] ? irq_exit+0x35/0x70 May 19 21:26:52 coolbox kernel: [<c01b242d>] ? sys_ioctl+0x3d/0x70 May 19 21:26:52 coolbox kernel: [<c0206466>] ? prepare_for_delete_or_cut+0x3c6/0x650 May 19 21:26:52 coolbox kernel: [<c03979a1>] ? syscall_call+0x7/0xb May 19 21:26:52 coolbox kernel: [<c0206466>] ? prepare_for_delete_or_cut+0x3c6/0x650 May 19 21:26:52 coolbox kernel: [<c0206466>] ? prepare_for_delete_or_cut+0x3c6/0x650 May 19 21:26:52 coolbox kernel: Code: 00 00 00 66 31 c0 83 c8 01 89 47 50 eb 9f 90 8d 74 26 00 89 da 89 f0 e8 0f cb ff ff 85 c0 74 a4 89 c5 eb b2 8d b4 26 00 00 00 00 <80> 78 3d 00 74 03 31 c0 c3 84 d2 75 0a 83 c0 28 e8 db f5 cf c6 May 19 21:26:52 coolbox kernel: EIP: [<f9696a50>] ttm_mem_io_lock+0x0/0x20 [ttm] SS:ESP 0068:d03cfbf0 May 19 21:26:52 coolbox kernel: CR2: 00000000b892a45d May 19 21:26:52 coolbox kernel: ---[ end trace 70c887d309b00b2d ]--- May 19 21:27:18 coolbox kernel: Emergency Sync complete May 19 21:27:21 coolbox kernel: Emergency Sync complete -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching the assignee of the bug. ------------------------------------------------------------------------------ vRanger cuts backup time in half-while increasing security. With the market-leading solution for virtual backup and recovery, you get blazing-fast, flexible, and affordable data protection. Download your free trial now. http://p.sf.net/sfu/quest-d2dcopy1 -- _______________________________________________ Dri-devel mailing list Dri-devel(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel

1 12

[Bug 37474] New: Segmentation Fault in glCopyTexSubImage2D
by bugzilla-daemon＠freedesktop.org 30 Jan '18

30 Jan '18

https://bugs.freedesktop.org/show_bug.cgi?id=37474 Summary: Segmentation Fault in glCopyTexSubImage2D Product: Mesa Version: 7.10 Platform: PowerPC OS/Version: Linux (All) Status: NEW Severity: normal Priority: medium Component: Drivers/DRI/r128 AssignedTo: dri-devel(a)lists.freedesktop.org ReportedBy: asguthrie(a)gmail.com Created an attachment (id=47011) --> (https://bugs.freedesktop.org/attachment.cgi?id=47011) stracktrace projectM-pulseaudio seg faults whilst calling glCopyTextSubImage2D. stacktrace attached. patch inspired by bug #27652 also attached. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.

1 3

[Bug 42117] New: r200 driver performance, ums, all mesa versions from 7.6
by bugzilla-daemon＠freedesktop.org 03 Nov '17

03 Nov '17

https://bugs.freedesktop.org/show_bug.cgi?id=42117 Bug #: 42117 Summary: r200 driver performance, ums, all mesa versions from 7.6 Classification: Unclassified Product: Mesa Version: unspecified Platform: x86 (IA32) OS/Version: Linux (All) Status: NEW Severity: major Priority: medium Component: Drivers/DRI/r200 AssignedTo: dri-devel(a)lists.freedesktop.org ReportedBy: majkell10(a)interia.pl With disabled ModeSetting, performance in some 3d applications drop almost to zero. glxgears runs flawlessly, few maps in openarena is unplayable, extremetuxracer is unplayable. oprofile with tuxracer: CPU: Athlon, speed 1399.45 MHz (estimated) Counted CPU_CLK_UNHALTED events (Cycles outside of halt state) with a unit mask of 0x00 (No unit mask) count 100000 samples % symbol name 146220 16.6991 sample_lambda_2d 123695 14.1267 fetch_texel_2d_f_argb8888 102183 11.6699 sample_linear_2d 86150 9.8388 linear_texel_locations.clone.23 79573 9.0877 interpolate_texcoords 69939 7.9874 _swrast_fog_rgba_span 55210 6.3053 _swrast_texture_span 54151 6.1843 _swrast_compute_lambda 50989 5.8232 radeonReadDepthSpan_z24_s8 21567 2.4631 radeonReadRGBASpan_ARGB8888 11802 1.3479 radeonWriteRGBASpan_ARGB8888 I've tested almost all mesa versions from 7.6 to 7.11, unsuccessfully. With mesa 7.5 all works great. Mesa 7.6.1 compiled with folders radeon and r200 copied from 7.5.2, also works great. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.

1 19

← Newer
1
...
15
16
17
18
19
20
21
...
80
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel November 2012