Description of problem: When browsing to the URL http://upload.wikimedia.org/wikipedia/commons/2/2a/Eta_Carinae_Nebula_1.jpg with firefox and xorg-x11-drv-intel 2.12.0 X will no longer crash as with 2.11 (as described in bug #608259 ) but will remain in an unstable state with text colour corruption (see attached screenshots) and finally crashed when I fired up blender and refused to start (only a reboot fixed things again). Version-Release number of selected component (if applicable): 2.12.0, installed from http://www.scrye.com/~kevin/fedora/xorg-intel/ How reproducible: , browse to URL http://upload.wikimedia.org/wikipedia/commons/2/2a/Eta_Carinae_Nebula_1.jpg while having the Konversation client (or probably other Qt/KDE apps?) open and see how, after closing firefox down, text colours start to go weird. Steps to Reproduce: 1. Install intel 2.12.0, konversation, firefox on Fedora 13 2. Run Firefox, Konversation (IRC client) 3. Browse to URL http://upload.wikimedia.org/wikipedia/commons/2/2a/Eta_Carinae_Nebula_1.jpg 4. Kill the hanging firefox (which it always will with such a large image) 5. See how text colours in Konversation (and possibly other complex Qt apps?) go weird (6. Possibly see subsequent X crashes or other faulty behaviour following this corruption) Actual results: X corrupts text colours and finally crashes Expected results: X continues to work normally Additional info: bash-4.1$ glxinfo | grep Mesa client glx vendor string: Mesa Project and SGI OpenGL renderer string: Mesa DRI Intel(R) 945GME GEM 20100328 2010Q1 OpenGL version string: 1.4 Mesa 7.8.1 bash-4.1$ Intel 2.12.0 installed from http://www.scrye.com/~kevin/fedora/xorg-intel/
I actually forgot to wipe out that piece of text from the "How reproducible" section, also because I didn't test reproducibility yet. As it turns out, this seems to have been some rare condition I hit and I cannot really reproduce it myself. Blender still works, no text colour weirdness. Sorry for not checking that (since the whole computer I also work at is hanging up for some minutes due to the excessive load testing this is quite expensive and time consuming which is why I didn't do that immediately)
Created attachment 431893 [details] text colour weirdness in Konversation Attaching some screenshots anyway... maybe it helps someone in getting an idea what went wrong in this situation
Created attachment 431894 [details] text colour weirdness in konversation, 2 The text colours changed approximately every 30 seconds
Can you confirm that this is really a duplicate of bug 608259 and it has been fixed in xorg-x11-drv-intel 2.12.0 (see on http://koji.fedoraproject.org/koji/packageinfo?packageID=7794 for the packages)? If not, feel free to reopen, add drm.debug=0x04 to the kernel command line, restart computer, and attach * your X server config file (/etc/X11/xorg.conf, if available), * X server log file (/var/log/Xorg.*.log) * output of the dmesg command, and * system log (/var/log/messages) to the bug report as individual uncompressed file attachments using the bugzilla file attachment link above. We will review this issue again once you've had a chance to attach this information. Thanks in advance.
*** This bug has been marked as a duplicate of bug 608259 ***
> Can you confirm that this is really a duplicate of bug 608259 and it has been fixed in xorg-x11-drv-intel 2.12.0 I mean, I wrote it above. This one is not a duplicate since I experienced this with intel 2.12.0 (see the technical info I posted). Dunno what else I should do to point out that this is something else. Still I have been completely unable to reproduce as I wrote above (in case you read that) although I tried a lot, so not sure this is helpful. This was definitely 2.12.0 though (again, read what I wrote for intel version on the top). If nobody can reproduce this you might close it again with WORKSFORME or something like that.
OK, if anybody can reproduce this with the latest updates to F-13 let us know.
Ok, I now kinda reproduced this myself again. The problem is, it just happens sometimes after long system use and I have found no way to reproduce it willingly. Here are a few things that seem connected to it: - Using a large external screen with a higher resolution seems to accelerate it - High memory usage or maybe many open programs seem to accelerate it aswell - When running a game that uses lots of uncompressed textures (Jedi Academy in wine), I get similarly looking corruption in OpenGL (which is fixed by using compressed textures that use up less texture space) [which didn't result in the kernel oopses described below though] Also I seem to get kernel oopses everytime the problem starts, always three times the same thing: WARNING: at mm/highmem.c:453 debug_kmap_atomic+0xad/0x12a() Hardware name: 1000H Modules linked in: fuse sunrpc cpufreq_ondemand acpi_cpufreq xt_physdev nf_conntrack_netbios_ns ip6t_REJECT nf_conntrack_ipv6 ip6table_filter ip6_tables ipv6 vboxnetadp vboxnetflt vboxdrv uinput snd_hda_codec_realtek snd_hda_intel snd_hda_codec snd_hwdep snd_seq snd_seq_device snd_pcm snd_timer snd iTCO_wdt eeepc_laptop iTCO_vendor_support soundcore rt2860sta snd_page_alloc uvcvideo sparse_keymap rfkill atl1e videodev v4l1_compat joydev microcode aes_i586 aes_generic xts gf128mul dm_crypt i915 drm_kms_helper drm i2c_algo_bit i2c_core video output [last unloaded: scsi_wait_scan] Pid: 0, comm: swapper Not tainted 2.6.33.6-147.fc13.i686.PAE #1 Call Trace: [<c043d69d>] warn_slowpath_common+0x65/0x7c [<c04b12e1>] ? debug_kmap_atomic+0xad/0x12a [<c043d6c1>] warn_slowpath_null+0xd/0x10 [<c04b12e1>] debug_kmap_atomic+0xad/0x12a [<c042a91b>] kmap_atomic_prot+0x5c/0x10c [<c04c9162>] ? __kmalloc+0x103/0x10f [<c042a9df>] kmap_atomic+0x14/0x16 [<f8008083>] i915_error_object_create+0x9f/0xfa [i915] [<f80083f2>] i915_handle_error+0x314/0x813 [i915] [<f8008990>] i915_hangcheck_elapsed+0x9f/0xdf [i915] [<c0448749>] run_timer_softirq+0x163/0x1e6 [<f80088f1>] ? i915_hangcheck_elapsed+0x0/0xdf [i915] [<c0442a79>] __do_softirq+0xac/0x152 [<c0442b50>] do_softirq+0x31/0x3c [<c0442c64>] irq_exit+0x29/0x5c [<c041d6d7>] smp_apic_timer_interrupt+0x6f/0x7d [<c078358d>] apic_timer_interrupt+0x31/0x38 [<c045007b>] ? __cancel_work_timer+0x12a/0x15d [<c05ffe10>] ? acpi_idle_enter_simple+0x10a/0x13d [<c06d886b>] cpuidle_idle_call+0x6e/0xc3 [<c0407ab8>] cpu_idle+0x91/0xad [<c077e7a7>] start_secondary+0x1f5/0x233 As soon as they get shot out (so far always three times in instant succession), the corruption starts (some pixmaps start to turn black or strange colours, and mainly text colours in all sorts of applications wildly change as seen in the attached screenshots). glxinfo and intel 2.12.0 version is still the same as mentioned in the first post. * /etc/X11/xorg.conf not present * Xorg.0.log contains four very interesting almost similar lines at the end: [ 9898.021] (WW) intel(0): i830_uxa_prepare_access: gtt bo map failed: Input/output error [ 9898.021] (WW) intel(0): i830_uxa_prepare_access: gtt bo map failed: Input/output error [ 9898.022] (WW) intel(0): i830_uxa_prepare_access: gtt bo map failed: Input/output error [ 9898.022] (WW) intel(0): i830_uxa_prepare_access: gtt bo map failed: Input/output error (will attach full log in a second) * /var/log/messages: just contains "Aug 6 18:34:49 localhost kernel: ===>rt_ioctl_giwscan. 3(3) BSS returned, data->length = 444" with different times repeated over the last hours * dmesg: just the line "===>rt_ioctl_giwscan. 3(3) BSS returned, data->length = 444" repeated Similar to the first time this happened to me, X is still running (I am just writing those lines while the bug is happening), but I guess if I tried to open up blender or some other more demanding up it might again lock up completely. I'll try that in a second after attaching the full Xorg.0.log
Created attachment 437203 [details] Full Xorg.0.log Interesting observation: - Newly started up applications seem to have proper text and pixmaps again, only those that were already running when the kernel oops happened are starting to corrupt more or less heavily (including plasma's task bars or the window manager's title bars) * uname -a (I forgot to post that, probably changed since the first post): Linux jth 2.6.33.6-147.fc13.i686.PAE #1 SMP Tue Jul 6 22:24:44 UTC 2010 i686 i686 i386 GNU/Linux Will now try whether starting up some 3d applications can again finally hang up X.
Ok, I am a bit excited now since it seems to be the same issue. As I started up blender again, it would, similarly to the first time I encountered and reported this, kill X completely (starting up blender after a reboot works just fine). Note: I haven't been using firefox this time, but Opera was opened with some tabs (no abnormally large image though as far as I've been aware of that).
This seems the same bug or strongly related to https://bugs.freedesktop.org/show_bug.cgi?id=28204 on bugs.freedesktop.org (where I also added some info now)
This message is a reminder that Fedora 13 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 13. 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 '13'. 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 13'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 13 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 13 changed to end-of-life (EOL) status on 2011-06-25. Fedora 13 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.