Created attachment 398582 [details] Xorg.0.log obtained after crash and before reboot. Description of problem: X server receives a SIGABRT some time after boot, ranging from a few minutes to several hours. It's an assertion failure (see back trace in folder linked below). One can stil SSH in afterward, so I've retrieved logs as they are after the crash and before reboot. Nomodeset doesn't fix this, nor EXA nor XAA options as described in http://fedoraproject.org/wiki/Xorg/Debugging (I've also checked that the xorg.conf generated by Xorg -configure does boot successfully without revisions). Version-Release number of selected component (if applicable): xorg-x11-drv-intel-2.9.1-1.fc12.i686 The xorg-x11-server version is 1.7.5-5.fc12.i686 How reproducible: Seems to happen always, at a seemingly random moment within 16 hours after boot. I typically use this computer as a console, using SSH-forwarded X11 from several other connected hosts. Steps to Reproduce: 1. Turn on system. 2. Wait. Actual results: Screen goes black some time after boot. One can still log in from a connected host via SSH (w/o X11 forwarding). Expected results: Computer doesn't crash unexpectedly. Additional info: Full back trace, Relevant logs &c are also posted in this folder: http://www.niftimal.com/computers/bugs/fedora/xorg/batchbuffer-io-err-sigabrt/100308-010902/ Back trace: http://www.niftimal.com/computers/bugs/fedora/xorg/batchbuffer-io-err-sigabrt/100308-010902/bt-full-100308-003106.lst lspci output: http://www.niftimal.com/computers/bugs/fedora/xorg/batchbuffer-io-err-sigabrt/100308-010902/lspci.lst Xorg.0.log: http://www.niftimal.com/computers/bugs/fedora/xorg/batchbuffer-io-err-sigabrt/100308-010902/Xorg.0.log Dmesg a few minutes after crash but before reboot: http://www.niftimal.com/computers/bugs/fedora/xorg/batchbuffer-io-err-sigabrt/100308-010902/dmesg-100308-003227.lst
I should have mentioned, regarding the EXA and XAA options: Each of them causes my system to hang with the completed Fedora "egg-f" logo displayed in the center of the light-blue splash field.
Created attachment 398602 [details] Back trace obtained by connected host
This may occur most often for me while running Thunderbird on a remote X client with X11 forwarded via SSH.
(In reply to comment #3) > This may occur most often for me while running Thunderbird on a remote X client > with X11 forwarded via SSH. Nope, that turns out to be false.
The end of Xorg.0.log is disquieting: (==) Depth 24 pixmap format is 32 bpp (II) intel(0): [DRI2] Setup complete (**) intel(0): Framebuffer compression disabled (**) intel(0): Tiling enabled (**) intel(0): SwapBuffers wait enabled (==) intel(0): VideoRam: 131072 KB (II) intel(0): Attempting memory allocation with tiled buffers. (II) intel(0): Tiled allocation successful. (II) UXA(0): Driver registered support for the following operations: (II) solid (II) copy (II) composite (RENDER acceleration) (==) intel(0): Backing store disabled (==) intel(0): Silken mouse enabled (II) intel(0): Initializing HW Cursor (II) intel(0): No memory allocations Fatal server error: Failed to submit batchbuffer: Input/output error Please consult the Fedora Project support at http://bodhi.fedoraproject.org/ for help. Please also check the log file at "/var/log/Xorg.0.log" for additional information. ================================================================== and this is very interesting #3 0x0095abe8 in __assert_fail (assertion=<value optimized out>, file=<value optimized out>, line=<value optimized out>, function=<value optimized out>) at assert.c:81 buf = 0x9406020 "Xorg: i830_batchbuffer.h:79: intel_batch_emit_dword: Assertion `pI830->batch_ptr != ((void *)0)' failed.\n" #4 0x0076d767 in intel_batch_emit_dword (pScrn=<value optimized out>) at i830_batchbuffer.h:79 No locals. #5 I830EmitFlush (pScrn=<value optimized out>) at i830_accel.c:159 pI830 = 0x8de7fe8 flags = 17 __func__ = "I830EmitFlush" #6 0x0076d86d in I830Sync (pScrn=<value optimized out>) at i830_accel.c:142
I should mention also that the remote X11 clients are all Fedora 10, not 12. Here's a listing of the xorg pkgs installed there apart from drivers: xorg-x11-filesystem-7.3-2.fc10.noarch xorg-x11-xtrans-devel-1.2.1-2.fc10.i386 xorg-x11-fonts-ISO8859-1-75dpi-7.2-6.fc9.noarch xorg-x11-font-utils-7.2-6.fc10.i386 xorg-x11-server-common-1.5.3-18.fc10.i386 xorg-x11-server-utils-7.4-3.fc10.i386 xorg-x11-utils-7.4-3.fc10.i386 xorg-x11-xauth-1.0.2-5.fc10.i386 xorg-x11-xkb-utils-7.2-7.fc10.i386 xorg-x11-drivers-7.3-9.fc10.i386 xorg-x11-proto-devel-7.4-5.fc10.noarch xorg-x11-server-Xorg-1.5.3-18.fc10.i386 xorg-x11-util-macros-1.1.6-2.fc10.i386 xorg-x11-xinit-1.0.9-4.fc10.i386 xorg-x11-fonts-misc-7.2-6.fc9.noarch
Happens to me on a fresh install and update of F12 on x86_64 too.
*** Bug 580907 has been marked as a duplicate of this bug. ***
Bug 580907 seems to be the same * abrt stack trace * Dell Latitude D410 * Intel Corporation Mobile 915GM/GMS/910GML Express Graphics Controller * Only seen with ViewSonic PJ562 attached Can anyone recommend a workaround? Or recommend a version that works?
It seems to happen here when the console is logged out and you: a) wake up video with right shift b) press down arrow to select another login This may be because the screen is actually locked, and pressing the down arrow attempts to run another X server. When it happens, the screen disappears too fast for me to check. This assertion error appears in the gdm log for :0 Xorg: i830_batchbuffer.h:79: intel_batch_emit_dword: Assertion `pI830->batch_ptr != ((void *)0)' failed.
I get this on my Dell Latitude D430 [Intel Corporation Mobile 945GM/GMS/GME, 943/940GML Express Integrated Graphics Controller (rev 03)] when I have an external LCD display connected. It always seems to happen when I am in Thunderbird for some reason. My system is fully up to date and it still happens. The "nomodeset" kernel option doesn't change anything for me.
I had the error Xorg: i830_batchbuffer.h:79: intel_batch_emit_dword: Assertion `pI830->batch_ptr != ((void *)0)' failed. on three occasions; each time, once X failed, gdm would try to restart the X server, but the X server would die with the same error immediately until gdm gave up trying to restart the X server. The condition cleared when I rebooted the system until the next instance, usually ten minutes or so into a login session, mostly using Firefox. That was with grub booted kernel title Fedora (2.6.32.11-99.fc12.x86_64) root (hd0,0) kernel /vmlinuz-2.6.32.11-99.fc12.x86_64 ro root=/dev/mapper/vg_stephens-LogVol00 LANG=en_US.UTF-8 SYSFONT=latarcyrheb-sun16 KEYBOARDTYPE=pc KEYTABLE=us initrd /initramfs-2.6.32.11-99.fc12.x86_64.img I have since booted with the previously available kernel on this system title Fedora (2.6.32.10-90.fc12.x86_64) root (hd0,0) kernel /vmlinuz-2.6.32.10-90.fc12.x86_64 ro root=/dev/mapper/vg_stephens-LogVol00 LANG=en_US.UTF-8 SYSFONT=latarcyrheb-sun16 KEYBOARDTYPE=pc KEYTABLE=us initrd /initramfs-2.6.32.10-90.fc12.x86_64.img ...and have not experienced a problem for several days. I'm happy to have this (for me) workaround; it's a data point I thought it might be useful to share, but it could just be an accidental misdirection.
Never mind. It just crashed again with the same symptoms.
This may or may not be relevant. We have two desktops at the office with Fedora 12 and 845G (the 3rd I overwrote with CentOS5 and shipped off as a VPN print server). One has the X server crashing much more often (daily) than the other (monthly). Both have the same software, and the same motherboard (which has a Celeron or P4 option). The one that crashes the most is a Celeron, and the other is a Pentium 4. It may be coincidence, but it sounds like a timing problem to me.
(In reply to comment #14) > Fedora 12 and 845G (the 3rd I overwrote with CentOS5 and shipped off as a VPN > print server). One has the X server crashing much more often (daily) than the > other (monthly). I have a laptop here which just started to see a heavier use (with Fedora 12 it was used before only occasionally) and today it is crashing X quite regularly, multiple times in short hours, although in unpredictable moments. Sometimes I am getting a black desktop even if gdm did start up. 845G chipset. More precisely - 82845G/GL[Brookdale-G]/GE. These are cascading crashes so most of log files /var/log/Xorg.?.log and what one can find /var/log/gdm/ are destroyed with majority coming of a zero size. In what remains after multiple attempts to restart X on various displays I can consistently see: i830_batchbuffer.h:79: intel_batch_emit_dword: Assertion `pI830->batch_ptr != ((void *)0)' failed. and Fatal server error: Failed to submit batchbuffer: Input/output error Various attempts to boot without xorg.conf and with a skeleton one and adding or not adddig "nomodeset" so far failed to put a dent in this problem. If somebody has any ideas I would be grateful as this becomes unusable. The current kernel is 2.6.32.11-99.fc12.i686 and xorg-x11-server-Xorg-1.7.6-4.fc12.i686, xorg-x11-drv-intel-2.9.1-1.fc12.i686 Maybe related or maybe not but after suspend or when power management will turn a screen off it remains black with no reaction to a keyboard although a machine is not crashed. A restore after hibernation still works. This is a marked regression from a situation in Fedora 10 (running on this laptop before it was replaced by Fedora 12) where screen waking and suspension, and hibernation, worked without a hitch. Note: I am running at this moment with "intel_iommu=off" and so far I was able to type that comment without crashing. It may be a pure luck but before that X went away twice in a span of 20 minutes (although it did work for few hours before that).
*** Bug 577035 has been marked as a duplicate of this bug. ***
(In reply to comment #15) > > Note: I am running at this moment with "intel_iommu=off" and so far I was able > to type that comment without crashing. It may be a pure luck This was bogus and "pure luck". After a while I run out of it and server started crashing again. The only thing I can predict is that it will bomb out and rather sooner that later. So far no apparent correlations with anything I can see.
Created attachment 416113 [details] Xorg log after X server crash 2.6.32.12-115.fc12.i686
Comment on attachment 416113 [details] Xorg log after X server crash 2.6.32.12-115.fc12.i686 Typically crash occurs using firefox after a couple of hours of browsing.
*** Bug 579123 has been marked as a duplicate of this bug. ***
(In reply to comment #19) > Typically crash occurs using firefox after a couple of hours of browsing. Apparently these are very short hours in my case. Not predictable but they can be reduced to some ...teen minutes. This is on an old laptop with 512 M of memory. Maybe this has something to do with it? I cannot exclude also BIOS problems (and there is no newer BIOS for this machine so I can try to replace). OTOH at times of f10 this laptop could be configured to operate a display very reliably (i810 driver, though). In particular suspending and screesaver were NOT killing video completely (cf. bug 546994). Usually I can hear then fans going up to maximal revs while X is freezing up. An attempt to attach strace to a process of X locked up everything right away.
I encountered this almost at once when starting an upgrade to F13 when anaconda starts building it's package list (actually it's as soon as it tries to update the progress bar the second time, never the first always the second). That is a somewhat smaller set of interactions to debug, so if there are any particular logs/traces that would be useful to resolving this let me know and I can obtain them at any time.
VGA compatible controller: Intel Corporation 82845G/GL[Brookdale-G]/GE Chipset Integrated Graphics Device (rev 03) Since I "upgraded" to Fedora 12, this error is currently happening about once an hour, usually but not exclusively when selecting mail folders in Thunderbird. X gets into an continuous cycle of crashing and restarting, leaving a trail of core dumps in /var/gdm until I next reboot. This is more frustrating than Fedora 11, where X would occasionally crash on startup but not after that. Is there any evidence that this has been fixed in F13?
I've also ran into this bug. But for some reason it only happens with HP w22XX/w24XX series monitors attached.
Seeing it here, too. Dell Optiplex GX260. Intel Corporation 82845G/GL[Brookdale-G]/GE Chipset Integrated Graphics Device. Kernel: 2.6.32.19-163.fc12.i686. X dies with the batchbuffer error message, e.g., several Xorg.N.log files which end with a message similar to: (==) intel(0): Backing store disabled (==) intel(0): Silken mouse enabled (II) intel(0): Initializing HW Cursor (II) intel(0): No memory allocations Fatal server error: Failed to submit batchbuffer: Input/output error Please consult the Fedora Project support at http://bodhi.fedoraproject.org/ for help. Please also check the log file at "/var/log/Xorg.0.log" for additional informat.
And I'm also getting the Xorg: i830_batchbuffer.h:79: intel_batch_emit_dword: Assertion `pI830->batch_ptr != ((void *)0)' failed. message in /var/log/gdm/:0.log and multiple other files in /var/log/gdm. Any word on whether this also happens in Fedora Core 13?
I found a workaround. It works for me. I do not know if it will work for you. Like most workarounds, it is not perfect. Save a copy of your /etc/X11/xorg.conf file, if you have one. Change the Device stanza to read: Section "Device" Identifier "Videocard0" Driver "vesa" EndSection You can do this with a gui interface with system-config-display. You may have to install the system-config-display rpm. Log out and log in again. How is this not perfect? The alternative virtual termianls, normally accessable with control-alt-fN, for a small positive integer N, stop working. All I see is a blank screen. And, I cannot get back to the X window display. Control-alt-F7 nor control-alt-f1 do anything. I still see a blank screen. My system does not crash, but it's not very usable either. If I forget, and press control-alt-fN anyway, I have to go go another system, ssh to my system, and reboot my system. Not having the virtual terminals is undesireable. Having X crash altogether at unpredictable intervals is even less desireable.
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.