Bug 132267 (fc3-i810-refresh)

Created attachment 103685 [details]
xorg.conf with option "NoAccel" added

*** Bug 131934 has been marked as a duplicate of this bug. ***

As discussions regarding this bug relate to several pecularities. I
have decided to test some of the resolution and DRI options. With the
1280 x 1024 at 24 depth, my system works fine and does not have a
refresh problem. With the same resolution and at depth 16, things are
horrible regarding the refresh problem encountered. This refresh
problem needs processes related to X to have to be restarted, in order
to rid one from this refresh problem. Changes to the driver used,
resolution settings etc have no effect until a restarting of the system.
At 1024 x 768 at 16 depth, X basically and DRI is enabled. This works
fine until you decide to ctl-alt-Fn to a terminal, then X departs and
needs to be restarted. The same result seems to happen when using
runlevel 5 as with runlevel 3. I'm at runlevel 3 as my choice now for
tests.
Soon to be attached is the Xorg.0.log @ 1024 x 768 and 16 depth. This
kills X totally.

Created attachment 104160 [details]
total kill of server DRI - 1024 x768 @ 16 depth

start X, change to terminal ... no X on screen 7 or 8.

Created attachment 104161 [details]
Things work well at 1280 x 1024 and 24 depth - no refresh problem

This resolution works well and the ability to change to a terminal w/o crashing
X exists. Changing to 16 depth will cause problems related to the screen not
refreshing.
I get no DRI when I set to 16 depth but do get the bonus refresh problem. (1280
x 1024)

The version presently installed on the system is xorg-x11-6.8.1-3

Also, several users (me and two others minimum) had a problem with the
installer, which started producing vertical lines on the monitor and
the install needed to be exited w/ alt-sysreq-b in order to escape the
failed GUI installation. Someone posted to the bug that setting the
resolution to 800 x 600 for the installation would allow a sucessful
GUI install. How to start the installer at 640 x 480 from anaconda is
something that was never needed before the CVS releases, where this
problem regarding the 815 Graphics controller started to appear, post
patch to get X to even start again w/ the driver.

correction to above statement. for a successful install. 800 x 600 is
the desired resolution. No mention of 640 x 480 intended.
After I figure out how to specify 800 x 600 to the installer, I'll try
this pecularity additional item out to sucessfully install via GUI. 

Created attachment 104165 [details]
jumping up to 1400 x 1050 seems better - no refresh problem

Being interested in resolution possibilities, I decided to go one step further
up into a better resolution. The 1400 x 1050 resolution at 24 depth is even
better than the lower display rate that caused the refresh problem.
What it has to do with the refresh rate not effecting higher resolutions and
depths is what confuses me.
L

There's a bug in bugzilla, which sometimes randomly removes the
"QA Contact" field.  I've added dkl back to the QA contact
field.

The bug removing the QA contact is mej

Anyway, Alan passed on that work regarding the i810 driver is underway
for the 810/5 Graphics controller. Hopefully this problem can be overcome.

finished with additions to the report for now.

Not sure what you mean in comment #11.  Bugzilla has a known bug
that causes it to sometimes remove the QA contact when someone
makes a change to a bug, such as adding themselves to CC.  It's
kind of random, and doesn't happen all that often, but it does
happen still.  Nobody has tracked the problem down, so it still
occurs.

I got this message from bugzilla that was dated 9/24/2004. I still
have the message if this is of interest.

It looks like mej-- was removing dlk from the QA contact
field. The message was generated via bugzilla.com

Sorry if I'm incorrect here in understanding the message from
bugzilla. This is not intended to generate false accusations. Sorry if
I'm wrong here.

Jim

mej changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
          QAContact|dkl              |

Yep, that is the bugzilla bug I referred to above.  I noticed it
happen to a bug once, and fixed it and commented to the person
who removed the QA contact.  They responded that they didn't change
the QA contact.  We noticed this happen in several other bugs
also over time, and at some point our bugzilla maintainer,
(who coincidentally is dkl, the address that gets
removed <grin>) mentioned that this was a bugzilla bug, but one
that was not immediately reproduceable to track down.

If anyone can figure out the exact magic that causes this problem
to manifest, it would be greatly appreciated if they could file
a bug against bugzilla itself in our bugzilla, and dkl might
be able to fix it perhaps.  ;o)

I've added mej to the CC field for him/her to
comment, but I'm pretty sure they did not remove th QA contact
intentionally, and quite possibly never even viewed this bug.
It seems it happens to random bugs, which would point to 
SQL database problems or misplaced pointers or data references
in the bugzilla code I guess.

Anyhow..  I guess that's enough background on an otherwise
boring bugzilla glitch.  ;o)  hehe.

Take care Jim,
TTYL

As another data point on the original bug, not the Bugzilla QA bug, I
am using NoAccel on my xorg-x11 server as well due to the same problem
:-(. I'm glad that the i810 code was rewritten/revisited as FC2 forced
me to use NoAccel due to a rare xorg-x11 crash event when downloading
a file in Mozilla while xorg-x11 acceleration was enabled, so I hope
that the i810 refresh problem in the current version can be fixed
easily before FC3 reaches production.

Similar refresh problem for me but also at 1280 x 1024 and 24 depth.
"NoAccel" fixes problem

Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug report.

https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=132267


jnm11.ac.uk changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
          QAContact|dkl              |

As a new discovery regarding this bug. I can run decent at high
resolutions and depths with kernel-2.6.8-1.541. If I boot with
kernel-2.6.8-1.603 with the same settings, the refresh problem strikes
out. I have not booted with kernels between the two listed kernels
because or reports regarding failures.

I assume that this means that the AGP is causing this refresh problem.
But IANAD.

Jim

Does the problem go away if you disable rhgb graphical boot, and
then reboot the system?

I don't believe I'm using rhgb graphical boot, so I conclude not.

My grub entry reads:

title Fedora Core (2.6.8-1.610)
        root (hd0,1)
        kernel /boot/vmlinuz-2.6.8-1.610 ro root=/dev/hda2
        initrd /boot/initrd-2.6.8-1.610.img

I just checked that the problem still exists with kernel-2.6.8-1.610
and the rest of today's fedora-development rpms, and that the
work-around of Option "NoAccell" still works.

It's important for us that you know you're not using rhgb for sure.
rhgb starts after the kernel initializes, and presents a graphical
init using the X server, instead of the older traditional text based
init which displays "Starting foo:    [OK]" style messages in text
mode.  If you are getting the old style text based init, then you
are not using rhgb.  If you are getting a graphical display with
eye candy init, it's rhgb.

To ensure you do not get rhgb, you can do:

rpm -e rhgb

Please confirm.


The next thing we can do to narrow the problem down without totally
killing acceleration for you, is to get you to re-enable accel by
commenting out the Noaccel line in the config file, and then
experimenting with the various "XaaNo...." options described in
the xorg.conf manpage.  This may take a while to test as you have
to edit the config file many times and then test the server, but
if you can narrow the problem down to a single XaaNo option, or
a couple of options which seem to solve the problem, this may
point us directly at the problematic code in the video driver.
At that point it might be an easy fix, or worst case we can just
disable that single accel primative and still have a mostly
accelerated driver until a better fix can be found.

Please update us once you have a chance to play with XaaNo options.

Thanks in advance.

I don't boot with rhgb on the system mostly. As a test later, I'll
confirm that adding rhgb would work without a refresh problem. Also
the kernels after -603 seem to be back to working at high color and
higher resolutions w/o the refresh problem.
This is using the same xorg.conf file submitted as attachments above.
Currently, I'm on the laptop w/ the working radeon.

I applied the "rpm -e rhgb" fix, and now my system boots. 
Unfortunately the max screen resolution is now 800x600, whereas
before, I was able to get 1024x768.

I have not made the "NoAccel" change.

I have been following this bug's conversation and will also try out
the XaaNo* options tomorrow morning when I arrive at work.

One thing that I may need to know, however, and forgive me for asking
in the bug conversation, is that when I try to boot up with either
kernel-2.6.8-1.603 or kernel-2.6.8.607, fsck.ext3 fails and then init
asks for the root password. It looks like something in the initrd of
those two kernels remounts / as rw before running fsck.ext3, and I'm
wondering if I'm doing something wrong. If you let me know, I can test
out the XaaNo* options on my i810 system. I currently run on
kernel-2.6.8-1.541 and have the redraw problems when I run xorg-x11
without the NoAccel option.

Are you ready for a series of files? 

test 1: boot w/ kernel-2.6.8-1.610 and rhgb - runlevel 5
the rhgb loader worked fair. There was a problem with the program
changing back to briefness when I selected details. This happened more
than three times.
Next, gdm was slow to respond or not refreshing. I entered username -
password. X loaded and had a refresh problem.

test 2: no rhgb and runlevel 3 using kernel-2.6.8-1.610
refresh problem present. very bad refresh problem. kernel-2.6.8-1.607
does not seem to exhibit this problem. kernel-2.6.8-1.603 did the only
time that I booted into it.

test 3: rhgb - runlevel 5 - kernel-2.6.8-1.541
I have no problem refreshing the screen. gdm is alright and I was not
present to observe rhgb.

I have gdm logs for test 1 w/ xorg logs. I have xorg logs for test 2.
test 3 I have gdm log and xorg log.

I'll submit them if these would be of some value. They are saved in my
user directory.

No file onslaught just yet.

Jim

Responding to NEEDINFO comment #23

Did "rpm -e rhgb" and verified that the problem still exists as
descibed with today's updates, incl: kernel-2.6.8-1.624 and
xorg-x11-6.8.1-6

Removed "Option NoAccel" and did a pseudo-binary search on the 19
XaaNo options described in man xorg.conf

Problem can be suppressed with:
  Option "XaaNoSolidFillRect"
  Option "XaaNoScreenToScreenCopy"

Without XaaNoSolidFillRect there is random-noise garbage on the screen
during startx which clears up when the desktop initialization completes.

Without XaaNoScreenToScreenCopy damaged areas are not repaired. 
Damage was created by moving one gnome-terminal over another.

One more.  I found a libXaw application (dotty from graphviz)
that worked OK with NoAccel, but which needed:
   Option "XaaNoScanlineCPUToScreenColorExpandFill"
in addition to the other two.

Without this option it would fail to render text on its canvas or in
its menus.

Created attachment 105295 [details]
xorg.conf with XaaNo options instead of NoAccel

Just to add a correction for the kernels that effect the refresh
problems. All the kernels except for kernel-2.6.8-1.541
Cause the refresh problem (up to kernel-2.6.8-1.610). I have not
tested the latest X and newer kernel combo effects. 

I am currently running kernel-2.6.8-1.541, booting with rhgb and
booting into runlevel 5 without any special options to the Xorg.conf file.

I'll copy the XaaNo options from the attachment in comment 30 and see
if any of them would cause an X problem using the 541, 610 or later
kernels.

Jim 

After finally completing todays upgraded, X works quicker with the 541
kernel. I just finished rebooting the system after the upgrades to
start afresh.
glxgears reports about the same results as running without DRI showed
previously.

Since this is a new version of X, I am including the Xorg.conf w/
comment 30 changes, but commented out and the latest Xorg.0.log for
the currently running system.

I removed some of the many kernel versions except for the working,
last known bomb and the latest version.

kernel-2.6.8-1.541 - works 24bpp 1400x1050
kernel-2.6.8-1.610 - refresh problem w/ same xorg.conf settings
kernel-2.6.8-1.624 - not tested yet.

Created attachment 105316 [details]
xorg.conf w/ added test settings

Ready for testing but commented out

Created attachment 105317 [details]
With xorg-x11-6.8.1-6 installed, system restarted.

This seems to work quicker. Lower 16bpp settings not tested yet.

dropping down to 1280x1024 works fine also. This is maximum for my
monitor, though it works at the higher resolution.

Just to add that as in comment 28 - adding (uncommenting)
  Option "XaaNoSolidFillRect"
  Option "XaaNoScreenToScreenCopy"
allows operation in X w/0 the refresh problem.

This is with kernel-2.6.8-1.624 installed and with the same basic
xorg.conf option above.
Still, booting with kernel-2.6.8-1.541 and no special options entered
in xorg.conf works fine at 24bpp.

Ok, this issue seems to be accel related, and specific to this
particular Intel chip, which is either i810 DDX driver specific
or kernel DRM related.  I'm not convinced it's a kernel issue
however, but nothing can be ruled out at this stage.

i810 again same problem 
kernel-2.6.9-1.640
xorg-x11-6.8.1-12
Driver i810 

I try to use anacoda the devel version to new install.  The screen
would not refresh.

Just wanted to add that the problem is here too. I have an Intel 82815
(i815) graphics controller. When I try to install FC3 Test3, and
graphical install commences, the screen is just garbage, and I can't
use the installer. 
But hey, you already knew all this, right?

On more item is look like my screen update work and do not work base
on the change CPU speed.  PIII 1G laptop processor.

Hope this might help.

kernel 2.6.9-1.643 fixed my problem with my i810 driver with screen
refresh

kernel 2.6.9-1.643 did not fix my problem (as original reported).
In fact if anything it is worse since now (with acelleration enabled)
X11 locks up completely with a black screen requiring the system to be
rebooted.

The sytem is still usable with the 3 XaaNo... workarounds.

Created attachment 105831 [details]
Xorg.0.log showing new lockup with kernel-2.6.9-1.643

I am very sad to report that this is still severely broken in Core 3
Release. I find hard to believe it made the release in this state.
Maybe there aren't enough i815 users out there anymore.
For me, it broke my system. I can't get in. It hangs every time. The
few times it made it through the hang, it was just to freeze the
screen and corrupt the desktop.
I was happy with FC1 but I had to upgrade. Oh,well. Live and learn.
Have not tried the noaccel option but not sure I want to.

Adding "fc3-i810-refresh" as an alias for this bug, to facilitate
easier bug referencing.

*** Bug 133010 has been marked as a duplicate of this bug. ***

*** Bug 138489 has been marked as a duplicate of this bug. ***

Adding a "me too" on this problem (and adding myself to Cc list).

I have not tried FC3 on the computer with the 815 chipset yet. I do
not think the chipset is becoming that rare. Regarding the NoAccel or
adding at least the two lines below seem to work alright until a
solution can be determined.
 Option "XaaNoSolidFillRect"
  Option "XaaNoScreenToScreenCopy"

I hope that you do not get too discouraged with this breakage. The
driver tries to cover too many chipsets and should at least be split
as is the practice according to the below link. (split into i810 and
i830 drivers)

http://tlug.up.ac.za/guides/lkcg/drivers_char_drm.html

Splitting the driver into two seperate generations would allow
improvements for intel chipsets such as 865G and also allow the
810/815 chipsets to function and not be subjected to improvements to
later chipsets breaking existing, stagnated in new features chipsets.

Jim

I agree with you. I am not discouraged yet though. I waited a long
time for FC3 (skipped FC2).
I got it working with the "noaccel" option. I can hardly tell the
difference in speed.
Mine is an i815 which is not even in that list but I guess it is
covered by the i810 one.
FC1 did not have this problem so it is my guess that something
happened with the switch over to Xorg. I may be wrong though.
I sure wish some one finds a fix quick. I hear it has been busted
since FC3 was in testing and was never addressed. I fear because there
is a workaround, it will wind up in the back burner and never taken
care of. :(

I have the i815 chipset on an Intel motherboard.

Originally, when the problem first showed up in the beta cycle, I
removes the rhgb module via rpm, and that seemed to take care of my
problem.  I updated regularly, and had no problems, even during the
rc1-rc5 snapshots.  After I installed the release version on a newly
formatted hard drive, every thing went to pieces.  Editing the
xorg.conf file to add the following lines took care of most, but not
all, of the problems:

  Option "XaaNoScanlineCPUToScreenColorExpandFill"
  Option "XaaNoSolidFillRect"
  Option "XaaNoScreenToScreenCopy"

I have not used the "NoAccel" option.

I still get a screen full of random colors with a mouse hourglass
cursor when X is first launched, but the screen soon settles down, and
I can use it.  These random colors show up again when I log out to the
GDM screen.

FWIW, I'm not seeing these problems on an i815 I have here, with FC3.
However, the refresh problems *do* happen when I boot a Knoppix CD (I
don't remember the exact XFree86 version number there, but it's some
kind of Debian-patched XFree86 4.3).

>Splitting the driver into two seperate generations would allow
>improvements for intel chipsets such as 865G and also allow the
>810/815 chipsets to function and not be subjected to improvements to
>later chipsets breaking existing, stagnated in new features chipsets.

Hi Jim,

Once the cause of this bug is known, X.Org may be able to determine
wether or not it is related to new features or support having been
added to the driver, or wether it is the result of some other
changes in the X server, etc.  The problem could also be a kernel
DRM or AGP issue and may not be the video driver itself.

Intel maintains the i8xx driver officially (financially) by funding
the development of it.  The people who do the work ultimately
decide wether it will be one single unified driver or a split up
driver, but Red Hat is not involved in the driver's development
or decisions of this nature upstream.  Whatever the driver structure
is that X.Org supplies, is what we will ultimately ship in Fedora
Core.

I strongly recommend discussion of this on X.Org mailing lists,
and also filing bug reports in X.Org bugzilla to ensure the
official i810 driver maintainers and people working on i8xx DRM
and AGP support are aware of the issues and have a chance to
assess the problems and come up with a solution.

If patches become available for the X server or kernel to resolve
these issues, we will review them for consideration in future
updates to Fedora Core.  If the issue isn't resolved upstream
in the near future, then we can institute a workaround by disabling
acceleration for the affected chipsets until the upstream
maintainers are able to fix the issue or to divide the driver into
multiple drivers if they decide that is a better way to handle
the problem for the future.

Thanks for the feedback.

I have a Sony Vaio with the i815 chipset and had this same problem. I
added the NoAccel option and the problem goes away, no noticable
slowdown really. I also tried several of the suggested resolutions and
16-bit depth, but only the NoAccel option worked. FC2 was fine on this
machine, this only occurred after FC3 installed.

I installed in text mode so I don't know f anaconda would have worked
or not.

Re: Comment #55

I have to concur.  It is obvious that the problem is actually a X.org
issue, since the problem now has been reported here on a non-Fedora
system.  (See Comment #54).

Since that time, I have attempted to install a different distribution
(Novell Linux Desktop) on this hardware with similar results.  Unlike
the Fedora install (which, with some install screen corruption, did
work), the Novell install could not be completed.

Someone has reported this problem to freedesktop.org.  See:

http://freedesktop.org/bugzilla/show_bug.cgi?id=1817

*** Bug 138921 has been marked as a duplicate of this bug. ***

*** Bug 138948 has been marked as a duplicate of this bug. ***

*** Bug 138948 has been marked as a duplicate of this bug. ***

*** Bug 138055 has been marked as a duplicate of this bug. ***

*** Bug 138247 has been marked as a duplicate of this bug. ***

Another fedora user with the i810 refresh issue.

(I am on final FC3 and up-to-date official updates.)

I have a video card which is:
VGA compatible controller: Intel Corp. 82815 CGC [Chipset
Graphics Controller] (rev 02) (prog-if 00 [VGA])

And having "NoAccel" "yes" for the i810 driver fixes the problem.

(I know it is not going to do hardware accelerated 2D or 3D, but
having a good display is better than having none.)

Hari.

Same problem here with
(--) PCI:*(0:2:0) Intel Corp. 82815 CGC [Chipset Graphics Controller]
rev 2, Mem @ 0x44000000/26, 0x40400000/19

*** Bug 139064 has been marked as a duplicate of this bug. ***

*** Bug 139387 has been marked as a duplicate of this bug. ***

OK, I finally got my hands on a i810 system, and was able to reproduce
the problem.  The latest Xorg CVS has quite a few fixes for the i810
and it makes the redraw problem go away for me.

I've uploaded the new i810 driver to

  http://people.redhat.com/krh/i810_drv.o

Please give this a try by downloading it and copying it to
/usr/X11R6/lib/modules/drivers (replacing the old i810_drv.o there).

Thanks!

Well, I can post some prelim results:

FC3 with the new driver seem to be OK. I see no refresh problem
without the need for the "noaccel" option:
Having said that, I am also using these screen settings that I believe
also had some bearing on the problem.

Section "Screen"
        Identifier "Screen0"
        Device     "Videocard0"
        Monitor    "Monitor0"
        DefaultDepth     24
        SubSection "Display"
                Viewport   0 0
                Depth     16
                Modes    "800x600" "640x480"
        EndSubSection
        SubSection "Display"
                Viewport   0 0
                Depth     24
                Modes    "1024x768" "800x600" "640x480"
        EndSubSection
EndSection

These settings seemed to also clear the problem just as well as the
forementioned option.

I still have no acceleration comming on though as reported by glxinfo:

name of display: :0.0
display: :0  screen: 0
direct rendering: No
server glx vendor string: SGI
server glx version string: 1.2
server glx extensions:

Other than that is all well.

I have installed and have working fine the driver at
http://people.redhat.com/krh/i810_drv.o by Kristian Høgsberg
(krh)

Thanks

Hardware Dell Inspiron 2500
VGA compatible controller: Intel Corp. 82815 CGC [Chipset Graphics
Controller] (rev 11)

Forgot to add version number sorry FC3 fully update as today.

kernel-2.6.9-1.667
xorg-x11-6.8.1-12

How this helps

On a stock FC3 machine, updated to latest modules by RHN, the new
i810_drv.o driver has fixed my problems.

I had edited the xorg.conf file to add the "Xaa" options, but now I
have removed them and all is well.

The driver at: http://people.redhat.com/krh/i810_drv.o fixed my problem.

Thank you very much. 

So there is no need for me to disable the hardware acceleration. (Not
that the new driver gives more FPS, but at least it works!)

Well done!

Hari.

Likewise, I can work without the "NoAccel" option.  For kicks, I tried
"Noaccel" "no" in this config.  Of course it did not work.

I posted this to show that it was definitely working in 16 bit depth
even beyond the 1024x768 res.  The 24 bit worked with the old driver
on mine.  I haven't tried higher resolutions yet. I don't think I
could see the screen!

glxgears show 144 FPS on mine.  That's not enough to run any GL or
fancy screensavers.  That's all I'm really after with accel - I'm
pretty much a newbie at linux and don't know what else I'd do with
accel yet.  It'd be nice to watch the screensavers though!  :^)

Thanks for the great work on this!

Wendell

Section "Device"
        Identifier  "Videocard0"
        Driver      "i810"
        VendorName  "Videocard vendor"
        BoardName   "Intel 810"
        Option      "NoAccel" "no"
EndSection

Section "Screen"
        Identifier "Screen0"
        Device     "Videocard0"
        Monitor    "Monitor0"
        DefaultDepth     16
        SubSection "Display"
                Viewport   0 0
                Depth     16
                Modes    "1152x864" "1024x768" "800x600" "640x480"
        EndSubSection
EndSection

Just to reiterate tests results:
I switched back to depth 16 and got all the resolutions back. DRI is
kicking in just fine though no noticeable difference in FPS. No
refresh problems what so ever either.
Looks to me the new driver is a winner! 
+1 to have it included in the next roll out.

Thanks for taking care if this.

Kristian:

Does xorg-x11-6.8.1-12.FC3.1 include a fix for this problem, or was it
too late for it to be included?

Winston:  The option you put in your config file in comment #77 is
incorrect.  The correct option is:

    Option "noaccel"

Do not put "no" after that.  The option is "accel", which defaults
to on in the driver, thus giving acceleration.  "noaccel" means
disable acceleration, which is what we want.  While there are
various ways of indicating you do not want acceleration using
X config file syntax, "noaccel" is the most common and least
confusing one, and I recommend you use that.  There are other
synonyms such as:

   Option "accel" "no"
   Option "accel" "false"

and others, but they all do one of two things, which is to
set a single flag to enable or disable acceleration.  The recommended
way is "noaccel".  Your syntax performs a double negation, saying
"I do not want no acceleration", which means "I want acceleration"
which is the default if you don't put any setting in the file.

Please try again using:

    Option "noaccel"

For what it's worth, todays update of xorg killed my 16 bit setting. 
I copied the driver listed above back to the drivers directory and it
works fine again.   I hope the xorg update wasn't supposed to be the
"fix" for this issue.  Did it break anyone elses?

Re:  noaccel - I took that out after I tested with it, but thanks.

Any idea if we'll ever get accelleration with this driver?

Thanks.

Woah!  Sorry for the second post, but while today's xorg update killed
the stable 16 bit configuration, after copying the driver back, I seem
to have acceleration!  I was getting only 144 FPS on glxgears
previously.  Now I'm getting 433!  Cool!  Even the GL screensavers
work now! Any info on what fixed that?  Thanks to whomever it's due!

*** Bug 139329 has been marked as a duplicate of this bug. ***

Re comment #69: 
 
I'm a "me too" that has been lurking.  It resolves the issue on my 
system (Intel i815) 
 
But my up2date icon is throbbing and I see there are xorg updates.  
I'll bet they make this whole issue go away, eh? 

Once we have adequately isolated the fix for this issue and
developed a patch for xorg 6.8.1, we will include the fix in a
future update for Fedora Core, and a status update will be added
to the bug report to indicate new packages are available which
fix this issue.

The new xorg-x11 erratum being released is a security fix release
which mainly contains fixes for security issues found in libXpm.
It does not yet contain fixes for this issue, however we should
have a fix sometime in the near future.  We'll post status
changes here when there's an update containing the fixes.

*** Bug 139223 has been marked as a duplicate of this bug. ***

Thanks for the feedback, it's good to hear that it's working. 
Unfortunatly, it seems that VT-switching doesn't work with the new
driver--switching to text mode and back seems to crash the X server. 
I'm currently inverstigating this and hope to have an updated driver
available soon.

As Mike says in comment 85, the xorg-x11-6.8.1-12.FC3.1 update is only
a security update to fix a number of issues with the Xpm library.
Thanks,
Kristian

Hmm, acceleration is working for me again, I can only guess it must be
due to either the xorg-x11-6.8.1-12.FC3.1 or the
kernel-2.6.9-1.678_FC3 updates, which I just applied and rebooted with.

My hardware is 

[root@hesse gavin]# /sbin/lspci | grep VGA
00:01.0 VGA compatible controller: Intel Corp. 82810 CGC [Chipset
Graphics Controller] (rev 03)

When I saw the xorg-x11 and kernel updates on yum, I hoped they would
fix my acceleration problems (which match those described here, X
unusuable with settion Option "noaccel"), removed the noaccel option
and rebooted.

Just decided to check back here to see what part of the updates had
fixed the problem and thought I would post this since no one else
seems to have reported it working again...

comment 5 has an attachment with the vt-switching problem when DRI is
enabled. This problem happened after the driver was patched, following
the complete killing of the driver, when the first CVS version of
xorg-x11 was released.
If memory serves me correctly, there was work on getting the 830
performance/functionality up and something in the 810 portion of the
code was overlooked.
DRI enabled vt-switching crash.
https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=104160&action=view

With reference to Gavin ("no one else seems to have reported it
working again..."): 

X worked fine for me after I:

1) Added the Option NoAccel line from xorg.conf
2) Rebooted and finished installation
3) Removed the Option NoAccel line from xorg.conf

That box is at home and is not online - no details here at work.

Barry, I meant to say that prior to today I could only use X with
Option NoAccel.  Now it is working *without* Option NoAccel.  My
experience has been:

Install -- Could not perform graphical install.  As soon as X started
the screen was covered with random colors.  Performed a text
installation (i.e. typing in "linux text" at the cdrom boot prompt).

Post-install -- X "worked", but with windows not refreshing properly,
a la John Ellson's original bug at the top of this page.  Adding
Option NoAccel got things working properly.

Today -- After the recent round of yum updates (kernel, xorg...) I was
able to remove Option NoAccel and I no longer have window refresh
problems.

As a side note, I haven't seen any problems switching to VT terminals.
 I've been using 1400x1050 24-bit the whole time though.

You can probably ignore my comments -- I reverted back to the older
xorg  / kernel rpms to test and even with those I was able to run X
without refresh problems and without Option NoAccel.  So I'm not sure
when or why that went away for me.

I can confirm that either new xorg and/or kernel fixed the problem,
without any need to put the "NoAccel" option in xorg.conf anymore:

[root@home ~]# uname -a
Linux home.imoqland.com 2.6.9-1.678_FC3 #1 Mon Nov 15 18:28:07 EST
2004 i686 i686 i386 GNU/Linux
[root@home ~]# rpm -q xorg-x11
xorg-x11-6.8.1-12.FC3.1
[root@home ~]# glxgears
531 frames in 5.0 seconds = 106.200 FPS
480 frames in 6.0 seconds = 80.000 FPS
480 frames in 5.0 seconds = 96.000 FPS
X connection to :0.0 broken (explicit kill or server shutdown).
[root@home ~]# cat /etc/X11/xorg.conf | grep -i "noaccel"
#       Option "NoAccel"
[root@home ~]# lspci | grep -i intel
00:00.0 Host bridge: Intel Corp. 82810E DC-133 GMCH [Graphics Memory
Controller Hub] (rev 03)
00:01.0 VGA compatible controller: Intel Corp. 82810E DC-133 CGC
[Chipset Graphics Controller] (rev 03)
00:1e.0 PCI bridge: Intel Corp. 82801AA PCI Bridge (rev 02)
00:1f.0 ISA bridge: Intel Corp. 82801AA ISA Bridge (LPC) (rev 02)
00:1f.1 IDE interface: Intel Corp. 82801AA IDE (rev 02)
00:1f.2 USB Controller: Intel Corp. 82801AA USB (rev 02)
[root@home ~]#

I used the computer all the weekend without any glitches anymore.

*** Bug 140365 has been marked as a duplicate of this bug. ***

*** Bug 138426 has been marked as a duplicate of this bug. ***

There is a fix available in rawhide (xorg-x11-6.8.1-17or later).  We
will probably issue an FC3 udpate shortly, which will also provide a
fix for Fedora users.

*** Bug 140828 has been marked as a duplicate of this bug. ***

*** Bug 137779 has been marked as a duplicate of this bug. ***

*** Bug 141618 has been marked as a duplicate of this bug. ***

*** Bug 141619 has been marked as a duplicate of this bug. ***

*** Bug 141710 has been marked as a duplicate of this bug. ***

Positive results have happened with the new version for i810. The
first positiveresult is with being able to run with DRI at 1280x1024
at 16 "depth". This works now and previously did not run with DRI.
The second thing is that I can run at 1280x1024 using the default 16
without the refresh problem. I have other issues regarding dula-head,
but this is positive news with fixing and making the card
functionality better.
My xorg.conf (with some manual editing), Xorg.0.log and glxinfo output.
*Thanks!*

Jim

Created attachment 107883 [details]
slghtly edited xorg.conf - dual-head

Created attachment 107884 [details]
successful log - DRI present - 1280x1024 @ 16

Created attachment 107885 [details]
This shows DRI active - A first for this resolution.

The bad news is that changing to a console with ctl-alt-Fn kills the
server as described in earlier postings.

We are now testing release candidate 1 for X.org 6.8.2 in rawide.  The
fix for this issue is slightly different in 6.8.2 so I would very much
appreciate if you guys could try it out and make sure it won't break
i810 again.  Once 6.8.2 is released we will issue a FC3 update with
the release.

Thanks!

It appears that the newer version is holding ground with previous
versions. I did lose DRI functionality for 1280x1024 @ 16 resolution
that I was able to get with the previous version. The ctl-alt-F1 to a
terminal does not seem to be a problem.
Using resolution 1024x768 @ 16 does enable DRI functionality. No
refresh problems were observed by me at several different resolutions
and color depths.
I'd like to have 1280x1024 @ 16 still enable DRI, but this is not a
major distraction for me.

Created attachment 109144 [details]
A consideration with keeping the path for higher DRI resolution

Just to make sure that I was not mistaken with losing DRI at a higher
resolution with xorg-x11-6.8.1-12.FC3.21, I tried this out on an installation
that was not upgraded to the latest rawhide version. DRI is active at 1280x1024
and the speed is 3 times better with the above mentioned xorg-x11 version.
I only get DRI at 1024x768 with the rawhide version and with historical
versions of X from as long back as I owned this computer.
I assume that the fact that I am losing DRI at higher resolutions indicates
that taking the alternative path is a bit of a loss in functionality for the
815 type cards.

I'm going to go ahead and close this bug.  Jim, if you have problems
with DRI not working, could you please open a new bug for this issue -
thanks.

The change is more of a regression to some factor that was pretty much
characteristic for my Intel 815. I'll file a bou specific to the DRI
issue later. The refresh problem seems to be resolved.
Thanks!
Jim

i815, same issue, vertical lines. my software requires me to use 24
bits, 1600x1200 on a 21 inch monitor.

unfortunately 16 bits doesn't work for this software ( 8 or 24, i know
it is silly...)

Can Fedora 3 do it ? (with the proper settings)

I read elsewhere the chipset can do it with a decent refresh rate.
do I need to specify somewhere to reserve memory for the video card ?
as there is no separate memory for video, it is using the main memory.

Which version of xorg-x11 are you running? I used to be only able to
use X without the refresh problem at 1280x1024 @ 24. With the test
version submitted, I could run @ 16bits without the refresh problem.
This is with an Intel 815, using a 17" monitor capable of the above
resolution.
xorg-x11-6.8.1.901-1 is the version that I have tested.

*** Bug 146720 has been marked as a duplicate of this bug. ***

*** Bug 144670 has been marked as a duplicate of this bug. ***

To answer my post above, I'm using the stock public release of FC3. 
I'm not sure which version or xorg it is. I don't manage to find it 
either.
it says 6.8.1 in the man page I have, but I haven't been testing 
anything else than the public release of FC3.

so is there a "fixed" i810/i815 driver out yet, or is it still in the 
works ?

xorg-x11-6.8.1-12.FC3.21 or later should work without the refresh
problem. By stock, I'm guessing you are having problems with the
original version on the FC3 distribution discs. The driver was
horrible when FC3 was released.
Running FC3 updates should correct the problem. You might need to add
Option "NoAccel" to your /etc/X11/xorg.conf file (in the section where
the driver information is located) to get X working good enough to
apply the updates.

Stock seems to mean "Snapshot" for Fedora. The "picture" turned out
badly. Updates applied is the touched up version.

6.8.2 is in rawhide and has been for a while now.  It resolves
this issue.  It will be released soon for FC3 also, with no specific
definition for "soon", but if you frequently run "yum update" you
will automatically get it when it is released.  It shouldn't be long,
but then I have no specific definition of "long" either.  ;o)

One thing is certain though, if you try to update, and it is not
yet released for FC3, it is because we have decided there are one
or more additional (unrelated) bug fixes we need to resolve before
releasing it.  ;o)

HTH

Just a note to users of FC4T1 test, there is a new bug introduction that effects
this driver again. Adding the Option "NoAccel" option is needed again for
xorg-x11-6.8.2-10

Yikes!

xorg-x11-6.8.2-1.FC3.13.i386.rpm is officially out.

I can't wait to go home and try it to see if it finally resolves the problem.

Thanks, Mike :)

Hi,

I have been trying to find an updated driver for my onboard intel graphics card 
(i810). I am using fedora core 3, my kernel version is 2.6.11-1.27_FC3. I've 
already tried to go the intel website and download that driver but when I try 
to install it, it tells me that I have to update my kernel. Since this is the 
latest kernel for fc3 I doubt thats the problem. The way things are now I can 
only use an 800x600 resolution with color depth thousands of colors.
I've also tryed the vesa driver but that doesn't work either, infact it gives 
me a black screen. 
Does anybody know of a workable driver?

Thanks a lot.

Whirl

Dependng on which card you have, the stock driver works fine. There are some
problems related to BIOS settings and buggy BIOS.
I had a Dell GX270 w/ an Intel 865G that needed the legacy video set to 8MB
instead of the default 1MB. Additionally, the BIOS was that the computer sold
with was buggy. It was at version A03. After upgrading the BIOS to version A04
the color resolution went up to at least 1280 x 1024.

I have experience with both the Intel 815 and the 865G cards. I do not know
about the other card types.
Try enabling the testing repo and checking out the the xorg-x11 version from
there and updating. The next version for FC4 has problems that cover several
video cards, but this version works well with the 865G and the 815 card.

I hope this leads you in the right direction to solve your video problem.