Bug 584823
Summary: | Infinite loop lockup | ||||||
---|---|---|---|---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Trever Adams <trever> | ||||
Component: | xorg-x11-drv-ati | Assignee: | X/OpenGL Maintenance List <xgl-maint> | ||||
Status: | CLOSED CURRENTRELEASE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||
Severity: | medium | Docs Contact: | |||||
Priority: | low | ||||||
Version: | 13 | CC: | pjsanon, xgl-maint | ||||
Target Milestone: | --- | ||||||
Target Release: | --- | ||||||
Hardware: | All | ||||||
OS: | Linux | ||||||
Whiteboard: | |||||||
Fixed In Version: | Doc Type: | Bug Fix | |||||
Doc Text: | Story Points: | --- | |||||
Clone Of: | Environment: | ||||||
Last Closed: | 2010-05-03 18:43:14 UTC | Type: | --- | ||||
Regression: | --- | Mount Type: | --- | ||||
Documentation: | --- | CRM: | |||||
Verified Versions: | Category: | --- | |||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
Cloudforms Team: | --- | Target Upstream Version: | |||||
Embargoed: | |||||||
Attachments: |
|
The mesa update released today (version just newer than those listed above) did not fix the problem. Exact same situation here, was able to get the system working by using the vesa driver. The system freezes and i can access it only from remote (ssh). Nothing unusal in Xorg.0.log but the /var/log/messages shows the following Apr 23 12:32:43 localhost kernel: INFO: task Xorg:1575 blocked for more than 120 seconds. Apr 23 12:32:43 localhost kernel: "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. Apr 23 12:32:43 localhost kernel: Xorg D 0000000000000001 3824 1575 1571 0x00400084 Apr 23 12:32:43 localhost kernel: ffff8800b65cdbc8 0000000000000046 ffff880005bd68c0 ffff8800b73487e8 Apr 23 12:32:43 localhost kernel: ffff8800b65cdb38 ffffffff8107220a ffff8800b65cdb68 ffff8800b65cdfd8 Apr 23 12:32:43 localhost kernel: ffff8800b65cdfd8 000000000000fb80 00000000001d5e80 ffff8800b73483f8 Apr 23 12:32:43 localhost kernel: Call Trace: Apr 23 12:32:43 localhost kernel: [<ffffffff8107220a>] ? sched_clock_cpu+0xc3/0xce Apr 23 12:32:43 localhost kernel: [<ffffffff81479140>] ? __mutex_lock_common+0x23e/0x392 Apr 23 12:32:43 localhost kernel: [<ffffffffa00ac3ef>] ? radeon_cs_ioctl+0x37/0x1a0 [radeon] Apr 23 12:32:43 localhost kernel: [<ffffffffa00ac3ef>] ? radeon_cs_ioctl+0x37/0x1a0 [radeon] Apr 23 12:32:43 localhost kernel: [<ffffffff81479150>] __mutex_lock_common+0x24e/0x392 Apr 23 12:32:43 localhost kernel: [<ffffffffa00ac3ef>] ? radeon_cs_ioctl+0x37/0x1a0 [radeon] Apr 23 12:32:43 localhost kernel: [<ffffffff8107caae>] ? lock_release_holdtime+0x34/0xe3 Apr 23 12:32:43 localhost kernel: [<ffffffff81479358>] mutex_lock_nested+0x3e/0x43 Apr 23 12:32:43 localhost kernel: [<ffffffffa00ac3ef>] radeon_cs_ioctl+0x37/0x1a0 [radeon] Apr 23 12:32:43 localhost kernel: [<ffffffff810f2e20>] ? might_fault+0x5c/0xac Apr 23 12:32:43 localhost kernel: [<ffffffff8147ae20>] ? _lock_kernel+0x7d/0x95 Apr 23 12:32:43 localhost kernel: [<ffffffffa0019418>] drm_ioctl+0x28f/0x373 [drm] Apr 23 12:32:43 localhost kernel: [<ffffffffa00ac3b8>] ? radeon_cs_ioctl+0x0/0x1a0 [radeon] Apr 23 12:32:43 localhost kernel: [<ffffffff810720e1>] ? sched_clock_local+0x1c/0x82 Apr 23 12:32:43 localhost kernel: [<ffffffff81055925>] ? do_setitimer+0x1b1/0x1e2 Apr 23 12:32:43 localhost kernel: [<ffffffff8107220a>] ? sched_clock_cpu+0xc3/0xce Apr 23 12:32:43 localhost kernel: [<ffffffff8107ca78>] ? trace_hardirqs_off+0xd/0xf Apr 23 12:32:43 localhost kernel: [<ffffffff8112d108>] vfs_ioctl+0x32/0xa6 Apr 23 12:32:43 localhost kernel: [<ffffffff8112d688>] do_vfs_ioctl+0x490/0x4d6 Apr 23 12:32:43 localhost kernel: [<ffffffff8112d724>] sys_ioctl+0x56/0x79 Apr 23 12:32:43 localhost kernel: [<ffffffff81009c72>] system_call_fastpath+0x16/0x1b Apr 23 12:32:43 localhost kernel: 1 lock held by Xorg/1575: Apr 23 12:32:43 localhost kernel: #0: (&rdev->cs_mutex){+.+.+.}, at: [<ffffffffa00ac3ef>] radeon_cs_ioctl+0x37/0x1a0 [radeon] this block is repeated numerous times exactly 120 seconds apart. For now, my work around is simply "rpm -e --nodeps compiz" It leaves my config in tact, as I use few other OpenGL apps, I am good to go. I can reinstall to test fixes. The problem seems to be fixed with the installation of the latest xorg-x11-server-Xorg-1.8.0-8.fc13. Thanks to those involved. I agree. This bug appears to have been fixed. Thank you. (Sorry for the delay in response, I was just able to reboot since the fix for the first time.) |
Created attachment 408333 [details] Xorg log Description of problem: I use compiz-fusion. The system locks up as soon as the 3d initialization starts happening. (I just rebooted for the first time in about a month.) Version-Release number of selected component (if applicable): kernel-2.6.33.2-57.fc13.x86_64 xorg-x11-drv-ati-6.13.0-1.fc13.x86_64 mesa-libGL-7.8.1-1.fc13.i686 mesa-dri-drivers-7.8.1-1.fc13.x86_64 mesa-dri-drivers-experimental-7.8.1-1.fc13.x86_64 mesa-libOSMesa-7.8.1-1.fc13.x86_64 mesa-libGLw-6.5.1-8.fc12.x86_64 mesa-libGLU-7.8.1-1.fc13.i686 mesa-libGL-7.8.1-1.fc13.x86_64 mesa-dri-drivers-7.8.1-1.fc13.i686 How reproducible: Everytime, login, gnome panel and nautilus starts. I get the flicker of 3d switch over... FREEZE I have attached the log from Xorg.