Created attachment 372469 [details] Smolt profile Description of problem: Fresh install of Fedora 12 [KDE and XFCE] used to freeze the system at irregular intervals.The keyboard used to stop working, clicking using mouse was also not possible though the free mouse movement was possible. Enabling KMS just solved the issue to an extent that the freeze used to happen after a little longer interval. Finally the system have to be hard-rebooted to get the desktop back. Note : The issue was also seen while working on the machine with Live USB plugged in. Version-Release number of selected component (if applicable): Fedora 12 [XFCE] How reproducible: Not reproducible,used to happen at irregular intervals. Steps to Reproduce: 1. 2. 3. Actual results: The keyboard used to stop working, clicking using mouse was also not possible though the free mouse movement was possible. Expected results: The desktop should not hang and I/O devices should function as normal. Additional info: F11 used to work properly.Just faced 2 issues which were fixed per direction under. - https://fedoraproject.org/wiki/Common_F11_bugs#Miscellaneous_problems_with_Intel_graphics_adapters - https://fedoraproject.org/wiki/Common_F11_bugs#Garbage_displayed_in_several_applications_on_systems_with_Intel_i845_.2F_i855_graphics_adapters
The whole story : - System running fine with F11 XFCE. - Downloaded F12 KDE on 17th,running the LIVE system saw instances of freezing, considered it to be something transient. - Installed from LIVE iso.The issues was still there.thought the small amount of RAM [1 Gigs] as the cause of it since the KDE interface was looking very glassy,with high effects. - Installed XFCE and switched to it, no freezing over there for 2 days, but was having issues like screen locking not working, evolution not remembering the pop password. So thought of getting a fresh install of XFCE. - Downloaded the iso and tried the LIVE environment, the freezing was again there after around 15 min of use. - Installed the system, the system froze a couple of times and had to hard reboot. At IRC enabling KMS was recommended.The system remained fine for around 2 hours and again it froze. - Re-booted the system and again it froze after about 5 mins. A point to note, don't know that if its linked. After KMS, the freezing took place when i was away from my work station. Finally have to come back leaving the system down, fearing all my mails will be bouncing off as they will not be downloaded from pop server having limited space.
[root@nextag ~]# lspci 00:00.0 Host bridge: Intel Corporation 82845G/GL[Brookdale-G]/GE/PE DRAM Controller/Host-Hub Interface (rev 01) 00:02.0 VGA compatible controller: Intel Corporation 82845G/GL[Brookdale-G]/GE Chipset Integrated Graphics Device (rev 01) 00:1d.0 USB Controller: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #1 (rev 01) 00:1d.1 USB Controller: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #2 (rev 01) 00:1d.2 USB Controller: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #3 (rev 01) 00:1d.7 USB Controller: Intel Corporation 82801DB/DBM (ICH4/ICH4-M) USB2 EHCI Controller (rev 01) 00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev 81) 00:1f.0 ISA bridge: Intel Corporation 82801DB/DBL (ICH4/ICH4-L) LPC Interface Bridge (rev 01) 00:1f.1 IDE interface: Intel Corporation 82801DB (ICH4) IDE Controller (rev 01) 00:1f.3 SMBus: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) SMBus Controller (rev 01) 00:1f.5 Multimedia audio controller: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) AC'97 Audio Controller (rev 01) 01:09.0 Ethernet controller: Broadcom Corporation BCM4401 100Base-T (rev 01) [root@nextag ~]#
[root@nextag ~]# startx xauth: creating new authority file /root/.serverauth.5510 Fatal server error: Server is already active for display 0 If this server is no longer running, remove /tmp/.X0-lock and start again. Please consult the The X.Org Foundation support at http://bodhi.fedoraproject.org/ for help. xinit: Server error.
No gain from enabling KMS so switched it off, in the morning and the system is working great till time approx 5 hours. [root@nextag ~]# uptime 14:45:58 up 4:44, 4 users, load average: 0.16, 0.11, 0.09 [root@nextag ~]#
(In reply to comment #4) > No gain from enabling KMS so switched it off, in the morning and the system is > working great till time approx 5 hours. > > [root@nextag ~]# uptime > 14:45:58 up 4:44, 4 users, load average: 0.16, 0.11, 0.09 > [root@nextag ~]# Correction needed : 'disbling' KMS by adding 'nomodeset' was of no help.
I can confirm it's happening on i686/x86_64 with Gnome Desktop, if I boot with KMS it freezes even before showing the GDM screen, the only way I get an usable system is with nomodeset, and even with that, if I enable "Desktop Effects" I get a compiz crash (https://bugzilla.redhat.com/show_bug.cgi?id=532218) $ lspci 00:00.0 Host bridge: Intel Corporation Mobile 4 Series Chipset Memory Controller Hub (rev 07) 00:02.0 VGA compatible controller: Intel Corporation Mobile 4 Series Chipset Integrated Graphics Controller (rev 07) 00:02.1 Display controller: Intel Corporation Mobile 4 Series Chipset Integrated Graphics Controller (rev 07) 00:1a.0 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #4 (rev 03) 00:1a.1 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #5 (rev 03) 00:1a.2 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #6 (rev 03) 00:1a.7 USB Controller: Intel Corporation 82801I (ICH9 Family) USB2 EHCI Controller #2 (rev 03) 00:1b.0 Audio device: Intel Corporation 82801I (ICH9 Family) HD Audio Controller (rev 03) 00:1c.0 PCI bridge: Intel Corporation 82801I (ICH9 Family) PCI Express Port 1 (rev 03) 00:1c.1 PCI bridge: Intel Corporation 82801I (ICH9 Family) PCI Express Port 2 (rev 03) 00:1c.2 PCI bridge: Intel Corporation 82801I (ICH9 Family) PCI Express Port 3 (rev 03) 00:1c.4 PCI bridge: Intel Corporation 82801I (ICH9 Family) PCI Express Port 5 (rev 03) 00:1c.5 PCI bridge: Intel Corporation 82801I (ICH9 Family) PCI Express Port 6 (rev 03) 00:1d.0 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #1 (rev 03) 00:1d.1 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #2 (rev 03) 00:1d.2 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #3 (rev 03) 00:1d.7 USB Controller: Intel Corporation 82801I (ICH9 Family) USB2 EHCI Controller #1 (rev 03) 00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev 93) 00:1f.0 ISA bridge: Intel Corporation ICH9M LPC Interface Controller (rev 03) 00:1f.2 SATA controller: Intel Corporation ICH9M/M-E SATA AHCI Controller (rev 03) 02:00.0 Network controller: Intel Corporation PRO/Wireless 5100 AGN [Shiloh] Network Connection 85:00.0 Ethernet controller: Broadcom Corporation NetLink BCM5787M Gigabit Ethernet PCI Express (rev 02) 86:02.0 FireWire (IEEE 1394): Agere Systems FW322/323 (rev 70) $ cat /proc/cmdline ro root=/dev/mapper/vg_nbrmaureira-lv_root nomodeset LANG=en_US.UTF-8 SYSFONT=latarcyrheb-sun16 KEYBOARDTYPE=pc KEYTABLE=la-latin1 rhgb quiet My SMOLT profile (http://www.smolts.org/client/show/pub_484873bb-2045-4025-9f87-c221de679098)
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), output of the dmesg command, 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. We will review this issue again once you've had a chance to attach this information. Thanks in advance.
Hi, I guess my problem is related to BZ#540218 and BZ#539789 nevertheless, do you want those files? I've attached those on the mentioned BZ.
(In reply to comment #7) > Please attach your X server config file (/etc/X11/xorg.conf, if available), xorg.conf was not present in the mentioned dir.I t was not there on F11 [previous install] also, though i forced created it to resolve some issues as mentioned earlier in comment 0. > output of the dmesg command, 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. Attached dmesg ,Xorg.0.log, Xorg.9.log > > We will review this issue again once you've had a chance to attach this > information. > > Thanks in advance.
Created attachment 373928 [details] dmesg.txt
Created attachment 373929 [details] Xorg.0.log
Created attachment 373930 [details] Xorg.9.log
Xorg.*.log files present were as follows [root@nextag ~]# ll /var/log/Xorg* -rw-r--r--. 1 root root 44575 2009-11-26 11:03 /var/log/Xorg.0.log -rw-r--r--. 1 root root 37256 2009-11-25 17:33 /var/log/Xorg.0.log.old -rw-r--r--. 1 root root 18184 2009-11-20 11:25 /var/log/Xorg.9.log [root@nextag ~]#
just an update : the system frequency of getting hung have reduced a lot over the time.This week it just hung 3 times.
The Xorg.0.log.old from a boot immediately after a crash may be the most useful log, as that should be the log from the actual crash. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
Created attachment 374671 [details] Xorg.0.log.old attached
don't see any crash info in there :/ is that file from a boot immediately after seeing this crash? If you have two successful boots in a row, even .old will probably be a success log. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
oops, i didn't knew that, will make sure to get the good one logged next time.
Created attachment 375342 [details] Xorg.0.log.old after crash
This one do have something meaningful. "EQ overflowing. The server is probably stuck in an infinite loop."
Thanks for the correct log. Can we also get your /var/log/messages file? Thanks. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
Do the /var/log/messages also be the one from the boot just after the crash.?
No, /var/log/messages is just appended to across reboots, so it's fine, just attach it. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
I have same problem in F12 [but with Gnome] with same 845G card, same "EQ overflowing. The server is probably stuck in an infinite loop." message in Xorg.0.log.old. Also saw in F12-beta live cd Can attach log files etc if would be helpful
the following (in /var/log/messages) gets repeated every 2 or 4 minutes when display freezes. can ssh into machine but only a reboot seems to get display back. this bug seems to have been reported for many distros and video cards (not just intel) Dec 4 18:22:40 localhost kernel: INFO: task i915/0:108 blocked for more than 120 seconds. Dec 4 18:22:40 localhost kernel: "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. Dec 4 18:22:40 localhost kernel: i915/0 D f65bb598 0 108 2 0x00000000 Dec 4 18:22:40 localhost kernel: f65dbf14 00000046 fecf6973 f65bb598 c09ef6ec c09f4120 f65bb598 f65dbee0 Dec 4 18:22:40 localhost kernel: c09f4120 c09f4120 c09f4120 000d2fb2 f65dbf0c 00000000 d2cfff97 0000010e Dec 4 18:22:40 localhost kernel: c1d8f120 f65bb300 00000000 f65dbf18 c0430cc4 00000000 f649f014 f65bb300 Dec 4 18:22:40 localhost kernel: Call Trace: Dec 4 18:22:40 localhost kernel: [<c0430cc4>] ? finish_task_switch+0xa4/0xbf Dec 4 18:22:40 localhost kernel: [<c07655f8>] __mutex_lock_common+0xde/0x12d Dec 4 18:22:40 localhost kernel: [<c076565e>] __mutex_lock_slowpath+0x17/0x1a Dec 4 18:22:40 localhost kernel: [<c0765747>] ? mutex_lock+0x2e/0x3c Dec 4 18:22:40 localhost kernel: [<c0765747>] mutex_lock+0x2e/0x3c Dec 4 18:22:40 localhost kernel: [<f7d91c35>] i915_gem_retire_work_handler+0x29/0x66 [i915] Dec 4 18:22:40 localhost kernel: [<c0446238>] worker_thread+0x13c/0x1bc Dec 4 18:22:40 localhost kernel: [<f7d91c0c>] ? i915_gem_retire_work_handler+0x0/0x66 [i915] Dec 4 18:22:40 localhost kernel: [<c0449be1>] ? autoremove_wake_function+0x0/0x34 Dec 4 18:22:40 localhost kernel: [<c04460fc>] ? worker_thread+0x0/0x1bc Dec 4 18:22:40 localhost kernel: [<c0449937>] kthread+0x70/0x75 Dec 4 18:22:40 localhost kernel: [<c04498c7>] ? kthread+0x0/0x75 Dec 4 18:22:40 localhost kernel: [<c04041a7>] kernel_thread_helper+0x7/0x10 Dec 4 18:24:40 localhost kernel: INFO: task i915/0:108 blocked for more than 120 seconds. Dec 4 18:24:40 localhost kernel: "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. Dec 4 18:24:40 localhost kernel: i915/0 D f65bb598 0 108 2 0x00000000 Dec 4 18:24:40 localhost kernel: f65dbf14 00000046 fecf6973 f65bb598 c09ef6ec c09f4120 f65bb598 f65dbee0 Dec 4 18:24:40 localhost kernel: c09f4120 c09f4120 c09f4120 000d2fb2 f65dbf0c 00000000 d2cfff97 0000010e Dec 4 18:24:40 localhost kernel: c1d8f120 f65bb300 00000000 f65dbf18 c0430cc4 00000000 f649f014 f65bb300 Dec 4 18:24:40 localhost kernel: Call Trace: Dec 4 18:24:40 localhost kernel: [<c0430cc4>] ? finish_task_switch+0xa4/0xbf Dec 4 18:24:40 localhost kernel: [<c07655f8>] __mutex_lock_common+0xde/0x12d Dec 4 18:24:40 localhost kernel: [<c076565e>] __mutex_lock_slowpath+0x17/0x1a Dec 4 18:24:40 localhost kernel: [<c0765747>] ? mutex_lock+0x2e/0x3c Dec 4 18:24:40 localhost kernel: [<c0765747>] mutex_lock+0x2e/0x3c Dec 4 18:24:40 localhost kernel: [<f7d91c35>] i915_gem_retire_work_handler+0x29/0x66 [i915] Dec 4 18:24:40 localhost kernel: [<c0446238>] worker_thread+0x13c/0x1bc Dec 4 18:24:40 localhost kernel: [<f7d91c0c>] ? i915_gem_retire_work_handler+0x0/0x66 [i915] Dec 4 18:24:40 localhost kernel: [<c0449be1>] ? autoremove_wake_function+0x0/0x34 Dec 4 18:24:40 localhost kernel: [<c04460fc>] ? worker_thread+0x0/0x1bc Dec 4 18:24:40 localhost kernel: [<c0449937>] kthread+0x70/0x75 Dec 4 18:24:40 localhost kernel: [<c04498c7>] ? kthread+0x0/0x75 Dec 4 18:24:40 localhost kernel: [<c04041a7>] kernel_thread_helper+0x7/0x10
Please note this might be a duplicate of this Bug #538563 Let's keep these all together so the developers can see that this is an acutal issue with the i915 driver.
Sorry to say, but the system with which I was facing this issue is no more with me as it was my official machine and today was my last day there.
Created attachment 376552 [details] /var/log/messages after freeze this is messages file from p.johns not sawrub but is the same problem
Since this bug is already be worked by a dev, I'm going to just set it to keyword=triaged and status=assigned (Fedora 12) per policy. These aren't the droids you're looking for. This bug has been triaged -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
Is this a duplicate of bug 464866?
(In reply to comment #30) > Is this a duplicate of bug 464866? Anything is duplicate of bug 464866 -- it is a bad bug, which should be probably killed soon, because it serves only as a red herring.
matej: i've gone ahead and killed that bug. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
This bug seems to have become quite confused. I can't see any confirmation that the issue described in comment #25 is actually the same bug the original reporter suffers from. p.johns, can you explain exactly why you think this is the same bug? ajax, can you tell for sure if the two are the same (and if 538563 is also the same)? Thanks. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
The reasons i said they were the same are: - he describes the exact same symptoms as i saw in his bug description - the same 845G card - same messages in Xorg.0.log he didn't supply a messages file so i don't know if he saw the same messages there. I have since applied updates, i still see the freezes, but maybe less often and the last time didn't have the same messages in /var/log/messages as comment 25, before updates. Will be applying latest updates later on today. if you want i can supply output from intel_gpu_dump messages log Xorg.0.log anything else helpful the next time it freezes (assuming latest updates don't fix it)
and bug 538563 does sound the same (same symptoms in Description of problem and same messages in /var/log/messages, i.e. INFO: task i915/0:108 blocked for more than 120 seconds. etc).
(In reply to comment #32) > matej: i've gone ahead and killed that bug. It's probably better so, I didn't have to courage :(
Thanks, p.johns. The 'infinite loop' error is a very generic one and means very little - it can occur in all sorts of different cases, and doesn't actually indicate any one is the same bug as any other. But given the chipset and symptoms these two may well be the same. It would be good to see your X and kernel logs the next time the freeze happens, if it does. thanks! -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
Still getting the freezes. Have been using EXA the last few days, so attached files are from freeze with EXA. Attached bzipped archive with dmesg output, /var/log/messages, /var/log/Xorg.0.log and intel_gpu_dump output all from during the freeze by ssh'ing into machine with frozen display (except for mouse cursor). Also looked at content of files in /sys/kernel/debug/dri/0/ and when i tried "cat /sys/kernel/debug/dri/0/bufs" it got stuck every time so that i could not kill cat process and had to log in from another terminal.
Created attachment 379184 [details] dmesg output, /var/log/messages, /var/log/Xorg.0.log and intel_gpu_dump output during freeze
I can confirm the initial reported bug, and that it also affects Gnome. I reportet a reproducible freeze in bug #538563 - which seems to be related to this bug. It all worked fine in F11.
This message is a reminder that Fedora 12 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 12. 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 '12'. 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 12'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 12 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 12 changed to end-of-life (EOL) status on 2010-12-02. Fedora 12 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.