Bug 571525 - 82845G/GL: Failed to submit batchbuffer: Input/output error
82845G/GL: Failed to submit batchbuffer: Input/output error
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: xorg-x11-drv-intel (Show other bugs)
12
i686 Linux
low Severity high
: ---
: ---
Assigned To: Adam Jackson
Fedora Extras Quality Assurance
http://www.niftimal.com/computers/bug...
card_845G
: Triaged
: 577035 579123 580907 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2010-03-08 13:47 EST by Ted Bagg
Modified: 2010-12-03 12:42 EST (History)
20 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-12-03 12:42:35 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Xorg.0.log obtained after crash and before reboot. (15.91 KB, text/plain)
2010-03-08 13:47 EST, Ted Bagg
no flags Details
Back trace obtained by connected host (12.92 KB, text/plain)
2010-03-08 14:43 EST, Ted Bagg
no flags Details
Xorg log after X server crash 2.6.32.12-115.fc12.i686 (13.89 KB, text/plain)
2010-05-24 09:05 EDT, Charles Buenzli
no flags Details

  None (edit)
Description Ted Bagg 2010-03-08 13:47:57 EST
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
Comment 1 Ted Bagg 2010-03-08 14:28:53 EST
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.
Comment 2 Ted Bagg 2010-03-08 14:43:42 EST
Created attachment 398602 [details]
Back trace obtained by connected host
Comment 3 Ted Bagg 2010-03-10 11:22:49 EST
This may occur most often for me while running Thunderbird on a remote X client with X11 forwarded via SSH.
Comment 4 Ted Bagg 2010-03-10 11:33:42 EST
(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.
Comment 5 Matěj Cepl 2010-03-11 19:32:37 EST
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
Comment 6 Ted Bagg 2010-03-17 19:01:58 EDT
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
Comment 7 Henrique Martins 2010-03-31 07:41:58 EDT
Happens to me on a fresh install and update of F12 on x86_64 too.
Comment 8 Mads Kiilerich 2010-04-09 08:48:06 EDT
*** Bug 580907 has been marked as a duplicate of this bug. ***
Comment 9 Mads Kiilerich 2010-04-09 08:53:12 EDT
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?
Comment 10 Stuart D Gathman 2010-04-14 16:38:32 EDT
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.
Comment 11 Marc Heckmann 2010-04-17 19:04:09 EDT
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.
Comment 12 Stephen P. Schaefer 2010-05-02 01:15:26 EDT
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.
Comment 13 Stephen P. Schaefer 2010-05-02 03:59:51 EDT
Never mind.  It just crashed again with the same symptoms.
Comment 14 Stuart D Gathman 2010-05-04 14:53:01 EDT
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.
Comment 15 Michal Jaegermann 2010-05-18 13:41:52 EDT
(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).
Comment 16 Matěj Cepl 2010-05-21 10:16:25 EDT
*** Bug 577035 has been marked as a duplicate of this bug. ***
Comment 17 Michal Jaegermann 2010-05-21 19:54:32 EDT
(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.
Comment 18 Charles Buenzli 2010-05-24 09:05:16 EDT
Created attachment 416113 [details]
Xorg log after X server crash 2.6.32.12-115.fc12.i686
Comment 19 Charles Buenzli 2010-05-24 09:07:38 EDT
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.
Comment 20 Matěj Cepl 2010-05-24 10:02:19 EDT
*** Bug 579123 has been marked as a duplicate of this bug. ***
Comment 21 Michal Jaegermann 2010-05-24 16:21:19 EDT
(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.
Comment 22 Bob Rentschler 2010-05-26 18:54:35 EDT
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.
Comment 23 Martin Burchell 2010-07-19 18:55:42 EDT
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?
Comment 24 Jasper Siepkes 2010-07-30 12:38:49 EDT
I've also ran into this bug. But for some reason it only happens with HP w22XX/w24XX series monitors attached.
Comment 25 setha45 2010-08-31 13:32:41 EDT
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.
Comment 26 setha45 2010-08-31 15:35:28 EDT
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?
Comment 27 setha45 2010-09-14 12:55:26 EDT
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.
Comment 28 Bug Zapper 2010-11-03 16:26:10 EDT
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
Comment 29 Bug Zapper 2010-12-03 12:42:35 EST
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.

Note You need to log in before you can comment on or make changes to this bug.