Created attachment 348862 [details] Screenshot of the problem Description of problem: Blender ui components which are redrawn on mouse hover are drawn relative to the display screen instead of being drawn relative to the blender window position. Thus the blender menus are drawn over the gnome menu and buttons are drawn at wrong places. However the mouse click events take place in the proper place. Version-Release number of selected component (if applicable): blender-2.48a-21.fc11.x86_64 Intel 965M laptop integrated graphics How reproducible: On my machine, always Steps to Reproduce: 1. Open blender 2. Hover mouse over any component 3. Look at components redrawn over all wrong places Additional info: Seems like it may be problem with intel graphics. The blender render window's graphics are also rendered at wrong place, not inside the render window This also happens in KDE. However in KDE one silly workaround is to maximize the blender window and disable window borders so that the window and screen origins coincide.
This problem has been reproduced with radeon on F-11 with any blender up to 2.49a. So changes are hight that this is a Xorg driver problem instead of blender. (I miss one testcase to be sure, then to re-assign).
I have reassign this bug to the intel graphics driver.
Thanks for the bug report. We have reviewed the information you have provided above, and there is some additional information we require that will be helpful in our diagnosis of this issue. Please attach your X server config file (/etc/X11/xorg.conf, if available), /var/log/dmesg, and X server log file (/var/log/Xorg.*.log) to the bug report as individual uncompressed file attachments using the bugzilla file attachment link below. Does any of the steps described here https://fedoraproject.org/wiki/Common_F11_bugs#Miscellaneous_problems_with_Intel_graphics_adapters help you? We will review this issue again once you've had a chance to attach this information. Thanks in advance.
Created attachment 349212 [details] xorg log file xorg log file with drm.debug=1 kernel parameter set
Created attachment 349215 [details] /var/log/dmesg file the /var/log/dmesg file as requested (with drm.debug=1 kernel parameter set). I dont have the xorg.conf file. Note : setting nomodeset in the kernel parameters fixes the problem. However i feel it should also work with KMS and so the bug still needs to be fixed. Thanks
Kristian, isn't this weird (binary stuff in EDID): (WW) intel(0): Unknown vendor-specific block f (II) intel(0): W656G (II) intel(0): &6@Gj��� (II) intel(0): EDID (in hex): (II) intel(0): 00ffffffffffff004ca3583300000000 (II) intel(0): 00120103802115780a87f594574f8c27 (II) intel(0): 27505400000001010101010101010101 (II) intel(0): 010101010101d61b0090502022301030 (II) intel(0): 13004bcf100000190000000f00000000 (II) intel(0): 00000000002387026400000000fe0057 (II) intel(0): 363536470031353458330a20000000fe (II) intel(0): 00263640476a8fc6ff01010a2020008b
New update. With my fully updated system now, (F11 x86_64 as mentioned in bug report) blender no longer works. Here's the description. Steps: 1. open terminal 2. Type "blender" Observation: 1. some information about something like line 61 less number of arguments or something like that shows up 2. Blender window tries to open 3. Before anything is displayed in blender xserver hangs 4. With mode setting enabled: mouse cursor also stops Without kernel modesetting (nomodeset kernel parameter set): xserver still hangs but cursor still moves (not that it is of any use) 5. The symptoms in 4. are similar to what used to happen occasionally with compiz in F10 ("EQ overflowing. The server is probably stuck in an infinite loop." #464866). I could not check if the computer is still running (ssh) as i do not have access to another networked computer nearby. Note that the blender lockup problem occurs irrespective of whether compiz is enabled or not. Hard reboot is necessary to use the computer again
In my computer with Intel GMA 4500 MHD, the is top menu is very corrupted. It have strange overlay on the top of window and behave very strange. I press a menu button but the reaction is shifted upwards.
Its a kernel bug! After the blender lockup problem, i'm getting the lockups in another program (which i'm developing in python) which is based on mayavi (python) on top of vtk. So it is also related to drm. After enabling drm_debug=1 in the kernel parameters and running blender.bin (comp hangs as usual) and after a few much such lockups i came upon this thing in the /var/log/messages. Hope this is of some use in fixing the problem. It is really bad (I've done almost 20 hard reboots in the last 2 hours). Jul 6 12:07:41 localhost kernel: ------------[ cut here ]------------ Jul 6 12:07:41 localhost kernel: kernel BUG at drivers/gpu/drm/i915/i915_gem.c:2136! Jul 6 12:07:41 localhost kernel: invalid opcode: 0000 [#1] SMP Jul 6 12:07:41 localhost kernel: last sysfs file: /sys/devices/pci0000:00/0000:00:1f.2/host0/target0:0:0/0:0:0:0/block/sda/sda2/stat Jul 6 12:07:41 localhost kernel: CPU 0 Jul 6 12:07:41 localhost kernel: Modules linked in: fuse sunrpc ipv6 nf_conntrack_ftp nf_conntrack_netbios_ns cpufreq_ondemand acpi_cpufreq freq_table reiserfs dm_multipath kvm_intel kvm uinput snd_hda_codec_idt snd_hda_codec_intelhdmi lib80211_crypt_tkip snd_hda_intel snd_hda_codec wl(P) snd_hwdep snd_pcm uvcvideo snd_timer videodev snd lib80211 v4l1_compat iTCO_wdt sdhci_pci sdhci iTCO_vendor_support soundcore ricoh_mmc mmc_core sky2 v4l2_compat_ioctl32 snd_page_alloc firewire_ohci firewire_core wmi dell_laptop dcdbas crc_itu_t serio_raw pcspkr joydev i2c_i801 i915 drm i2c_algo_bit i2c_core video output [last unloaded: microcode] Jul 6 12:07:41 localhost kernel: Pid: 3087, comm: blender.bin Tainted: P 2.6.29.5-191.fc11.x86_64 #1 Inspiron 1525 Jul 6 12:07:41 localhost kernel: RIP: 0010:[<ffffffffa005f3d2>] [<ffffffffa005f3d2>] i915_gem_object_get_fence_reg+0x221/0x61e [i915] Jul 6 12:07:41 localhost kernel: RSP: 0000:ffff88005d825be8 EFLAGS: 00010202 Jul 6 12:07:41 localhost kernel: RAX: 0000000000002697 RBX: ffff88005f4e8780 RCX: 0000000000000010 Jul 6 12:07:41 localhost kernel: RDX: 0000000000002a02 RSI: 0000000000002697 RDI: ffff88005f4e8540 Jul 6 12:07:41 localhost kernel: RBP: ffff88005d825c28 R08: 0000000000000003 R09: ffff88007d5b61e8 Jul 6 12:07:41 localhost kernel: R10: 0000000000000200 R11: 0000000000000040 R12: ffff88005f4e86c0 Jul 6 12:07:41 localhost kernel: R13: ffff88007d5b6000 R14: ffff88005f4e8900 R15: ffff88007d5b5000 Jul 6 12:07:41 localhost kernel: FS: 00007fdbbaa55710(0000) GS:ffffffff817b7000(0000) knlGS:0000000000000000 Jul 6 12:07:41 localhost kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 Jul 6 12:07:41 localhost kernel: CR2: 00007fdbb4917000 CR3: 000000005d82b000 CR4: 00000000000026e0 Jul 6 12:07:41 localhost kernel: DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 Jul 6 12:07:41 localhost kernel: DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 Jul 6 12:07:41 localhost kernel: Process blender.bin (pid: 3087, threadinfo ffff88005d824000, task ffff880068100000) Jul 6 12:07:41 localhost kernel: Stack: Jul 6 12:07:41 localhost kernel: ffff880068100000 ffff88007d5b61e8 ffff88007d5b5020 ffff88005f4e8900 Jul 6 12:07:41 localhost kernel: ffff88007d5b5020 ffff88005f4e8780 ffff88005f435000 ffff88005d825ce8 Jul 6 12:07:41 localhost kernel: ffff88005d825c98 ffffffffa00610d3 ffff88000000c208 00007fdbb4917000 Jul 6 12:07:41 localhost kernel: Call Trace: Jul 6 12:07:41 localhost kernel: [<ffffffffa00610d3>] i915_gem_fault+0xc1/0x136 [i915] Jul 6 12:07:41 localhost kernel: [<ffffffff810b213f>] __do_fault+0x55/0x3d5 Jul 6 12:07:41 localhost kernel: [<ffffffff812429bb>] ? agp_flush_chipset+0x1b/0x1d Jul 6 12:07:41 localhost kernel: [<ffffffffa005d523>] ? i915_gem_object_flush_cpu_write_domain+0x26/0x32 [i915] Jul 6 12:07:41 localhost kernel: [<ffffffff810b4475>] handle_mm_fault+0x349/0x7c5 Jul 6 12:07:41 localhost kernel: [<ffffffff813ae615>] do_page_fault+0x5b5/0x9e9 Jul 6 12:07:41 localhost kernel: [<ffffffff813ac01a>] ? unlock_kernel+0x2f/0x32 Jul 6 12:07:41 localhost kernel: [<ffffffff810e0e27>] ? vfs_ioctl+0x76/0x87 Jul 6 12:07:41 localhost kernel: [<ffffffff810e12bb>] ? do_vfs_ioctl+0x462/0x4a3 Jul 6 12:07:41 localhost kernel: [<ffffffff813abab5>] ? trace_hardirqs_off_thunk+0x3a/0x6c Jul 6 12:07:41 localhost kernel: [<ffffffff813ac175>] page_fault+0x25/0x30 Jul 6 12:07:41 localhost kernel: Code: ff e8 35 e9 ff ff 85 c0 0f 84 b3 fe ff ff e9 06 04 00 00 41 83 7c 24 20 00 75 10 48 8b 55 c8 48 8b 02 f7 40 70 be ff ff ff 74 04 <0f> 0b eb fe 49 8b bf 38 01 00 00 48 8b 70 38 48 85 ff 74 1a 48 Jul 6 12:07:41 localhost kernel: RIP [<ffffffffa005f3d2>] i915_gem_object_get_fence_reg+0x221/0x61e [i915] Jul 6 12:07:41 localhost kernel: RSP <ffff88005d825be8> Jul 6 12:07:41 localhost kernel: ---[ end trace 48746cbe5fbb12dd ]---
It is the KMS problem. By adding nomodeset to the kernel, everything will be fine.
Thanks for the quick reply. However as i mentioned before (comment #7) it hangs despite disabling kms. The previous trace was with kms disabled, this is with kms disabled. Here's the kernel commandline params: Jul 6 12:46:46 localhost kernel: Command line: ro root=UUID=8526ad91-994f-46be-ab66-baa8b7d2abe6 rhgb quiet nomodeset drm_debug=1 As you can see after booting i ran blender and came up with this info in /var/log/messages on the next hard reboot. This seems slightly different from previous trace. There is no kernel: ---[ end trace 48746cbe5fbb12dd ]--- kind of line, so i've posted the messages till the next reboot message. Now i feel that this issue is somewhat different from the original bug report, So i think the original summary should be changed. I obviously cant get display artifacts in the original report message when blender doesn't start at all. Here's the kernel messages when it lockups with kms off. Jul 6 12:48:30 localhost kernel: ------------[ cut here ]------------ Jul 6 12:48:30 localhost kernel: kernel BUG at drivers/gpu/drm/i915/i915_gem.c:2136! Jul 6 12:48:30 localhost kernel: invalid opcode: 0000 [#1] SMP Jul 6 12:48:30 localhost kernel: last sysfs file: /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq Jul 6 12:48:30 localhost kernel: CPU 1 Jul 6 12:48:30 localhost kernel: Modules linked in: fuse sunrpc ipv6 nf_conntrack_ftp nf_conntrack_netbios_ns cpufreq_ondemand acpi_cpufreq freq_table reiserfs dm_multipath kvm_intel kvm uinput lib80211_crypt_tkip snd_hda_codec_idt snd_hda_codec_intelhdmi wl(P) snd_hda_intel snd_hda_codec uvcvideo iTCO_wdt snd_hwdep snd_pcm iTCO_vendor_support sdhci_pci videodev sdhci snd_timer snd soundcore lib80211 v4l1_compat v4l2_compat_ioctl32 serio_raw pcspkr firewire_ohci i2c_i801 snd_page_alloc sky2 mmc_core firewire_core wmi dell_laptop joydev dcdbas crc_itu_t i915 drm i2c_algo_bit i2c_core video output [last unloaded: microcode] Jul 6 12:48:30 localhost kernel: Pid: 2575, comm: blender.bin Tainted: P 2.6.29.5-191.fc11.x86_64 #1 Inspiron 1525 Jul 6 12:48:30 localhost kernel: RIP: 0010:[<ffffffffa005f3d2>] [<ffffffffa005f3d2>] i915_gem_object_get_fence_reg+0x221/0x61e [i915] Jul 6 12:48:30 localhost kernel: RSP: 0000:ffff88005d197be8 EFLAGS: 00010202 Jul 6 12:48:30 localhost kernel: RAX: 0000000000002bed RBX: ffff88005d1a9cc0 RCX: 0000000000000010 Jul 6 12:48:30 localhost kernel: RDX: 0000000000002a02 RSI: 0000000000002bed RDI: ffff88005d1a9a80 Jul 6 12:48:30 localhost kernel: RBP: ffff88005d197c28 R08: 0000000000000003 R09: ffff88007d5ae1e8 Jul 6 12:48:30 localhost kernel: R10: 0000000000000200 R11: 0000000000000040 R12: ffff88005d1a9c00 Jul 6 12:48:30 localhost kernel: R13: ffff88007d5ae000 R14: ffff88005d1a9e40 R15: ffff88007d5ac000 Jul 6 12:48:30 localhost kernel: FS: 00007f7324c6e710(0000) GS:ffff88007f001f00(0000) knlGS:0000000000000000 Jul 6 12:48:30 localhost kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 Jul 6 12:48:30 localhost kernel: CR2: 00007f731eb30000 CR3: 000000005d463000 CR4: 00000000000026e0 Jul 6 12:48:30 localhost kernel: DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 Jul 6 12:48:30 localhost kernel: DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 Jul 6 12:48:30 localhost kernel: Process blender.bin (pid: 2575, threadinfo ffff88005d196000, task ffff880056945c00) Jul 6 12:48:30 localhost kernel: Stack: Jul 6 12:48:30 localhost kernel: ffff88005d197c38 ffff88007d5ae1e8 ffff88007d5ac020 ffff88005d1a9e40 Jul 6 12:48:30 localhost kernel: ffff88007d5ac020 ffff88005d1a9cc0 ffff8800569f0c60 ffff88005d197ce8 Jul 6 12:48:30 localhost kernel: ffff88005d197c98 ffffffffa00610d3 ffff88005d197c68 00007f731eb30000 Jul 6 12:48:30 localhost kernel: Call Trace: Jul 6 12:48:30 localhost kernel: [<ffffffffa00610d3>] i915_gem_fault+0xc1/0x136 [i915] Jul 6 12:48:30 localhost kernel: [<ffffffff810b213f>] __do_fault+0x55/0x3d5 Jul 6 12:48:30 localhost kernel: [<ffffffff812429bb>] ? agp_flush_chipset+0x1b/0x1d Jul 6 12:48:30 localhost kernel: [<ffffffffa005d523>] ? i915_gem_object_flush_cpu_write_domain+0x26/0x32 [i915] Jul 6 12:48:30 localhost kernel: [<ffffffff810b4475>] handle_mm_fault+0x349/0x7c5 Jul 6 12:48:30 localhost kernel: [<ffffJul 6 12:49:17 localhost kernel: imklog 3.21.11, log source = /proc/kmsg started. Jul 6 12:49:17 localhost kernel: Initializing cgroup subsys cpuset The last line seems to be of the next reboot so i've pasted the message till here only Thanks
I have this backtrace too.
Do you mean it doesn't hang for you when you disable kms. Thats amazing. Why does it hang in my case then.
As the the issues mentioned in comment #7 are different from the original issue i'm creating a new bug report #509805. I have found a workaroung around this lockup problem. Ignore comments from #7, are they are not related to display artifacts. The display problems still remain though
I've just seen that this problem also exists for scilab. Though scilab is not yet packaged for fedora, using their binaries i get the same sort of display problems in their plotting routines. Mentioned here just for the record.
Since this bugzilla report was filed, there have been several major updates in various components of the Xorg system, which may have resolved this issue. Users who have experienced this problem are encouraged to upgrade their system to the latest version of their packages. For packages from updates-testing repository you can use command yum upgrade --enablerepo='*-updates-testing' Alternatively, you can also try to test whether this bug is reproducible with the upcoming Fedora 12 distribution by downloading LiveMedia of F12 Beta available at http://alt.fedoraproject.org/pub/alt/nightly-composes/ . By using that you get all the latest packages without need to install anything on your computer. For more information on using LiveMedia take a look at https://fedoraproject.org/wiki/FedoraLiveCD . Please, if you experience this problem on the up-to-date system, let us now in the comment for this bug, or whether the upgraded system works for you. If you won't be able to reply in one month, I will have to close this bug as INSUFFICIENT_DATA. Thank you. [This is a bulk message for all open Fedora Rawhide Xorg-related bugs. I'm adding myself to the CC list for each bug, so I'll see any comments you make after this and do my best to make sure every issue gets proper attention.]
Thanks for the reminder. I just check it out in updated Fedora 12 and the problem seems to have disappeared. Though in Fedora 11 it still seemed to occur. I could not check after applying todays updates, will check soon. Also i'm using the gnome-shell in F12, if thats relevant (compositing)
The problem is still there in updated Fedora 11. It is fixed in Fedora 12 probably due to the new kernel. You may do as you wish to the bug report.
This message is a reminder that Fedora 11 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 11. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '11'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 11's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 11 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Fedora 11 changed to end-of-life (EOL) status on 2010-06-25. Fedora 11 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.