Bug 168764

Please indicate the last exact version-release of xorg-x11 for FC4 that did
not have this problem for you.  If there are multiple previous builds that
worked, indicate as many known-working ones as you can.  This will help
narrow down when things changed.

Thanks in advance.

(In reply to comment #1)
> Please indicate the last exact version-release of xorg-x11 for FC4 that did
> not have this problem for you.  If there are multiple previous builds that
> worked, indicate as many known-working ones as you can.  This will help
> narrow down when things changed.
> 
> Thanks in advance.

Every version of xorg from FC2 to FC4 has worked correctly until this update:
https://www.redhat.com/archives/fedora-announce-list/2005-September/msg00063.html
(which, of course, also caused the crash).

Further information:

I reverted back to xorg-6.8.2-FC4-45.

The screen now fills to the edges correctly. I dont know how dynamic these
things are but the monitor now reports:
68.6kHz / 84hz

whereas with FC4-49 it reported:
70.2Khz / 87hz. 

And to test I went back to FC4-49. 

I can confidently say this is a genuine bug as the problem reappears! Once again
the monitor reports:
70.2KHz / 87Hz

Please *attach* (don't paste) /var/log/Xorg.0.log corresponding to both 
correctly and incorrectly started versions to compare and pinpoint the bug. 
The files actually indicate how the default refresh rate is selected. 

Created attachment 119147 [details]
FC4-49.2

Here is the incorrectly refreshing display as outlined in the bugreport.

Created attachment 119148 [details]
FC4-45

Here is the log which correctly sets the refresh rate.

Two big differences in log files stick out:    
    
1) 49.2 detects twice as much memory for free. Wow! I wonder if that's   
correct. You may try to enforce the correct amount with    
VideoRAM 32768 (or 65536 whichever is correct) in Section "Device" of   
xorg.conf   
   
than later,  
2) 49.2 doesn't echo what your monitor reports back via DDC, but refresh  
limits seems to be detected correctly. Despite 49.2 is very verbose in 
rejecting bad available rates, the final choice seems identical at the end. 
 
than later, 
3) A couple of failures on 49.2: 
+(WW) I810(0): Extended BIOS function 0x5f05 failed. 
+(II) I810(0): Setting refresh with VBE 3 method. 
 
Well... Try enforcing VideoRAM in xorg.conf.... Report back, even if it fails. 

Created attachment 119172 [details]
log with VideoRAM set to 64 (fails)

when xorg.conf has a section that looks like this:

Section "Device"
	Identifier  "Videocard0"
	Driver	    "i810"
	VendorName  "Videocard vendor"
	BoardName   "Intel 865"
	VideoRAM    65536

It still fails. To my knowledge, this video card has 64mb onboard RAM, or at
least, thats what the *marketing* specs say. I'm quite prepared for the fact
the reality is different. In any case, Ill halve the number above and report
back again. Cheers all :)

Created attachment 119173 [details]
VideoRAM enforced to 32mb (fails)

For completeness sake, here is the log genereated with an xorg.conf that has
VideoRAM 32768. Still no workaround.

Cheers again
Niko

Just an untested hypothesis...  This sounds to me like it may be a
regression in the updated i810 driver.  It might be worthwhile disabling
the new i915/945 support patch and rebuilding and seeing if that removes
the regression.

xorg-x11-6.8.2-add-i945-support.patch is the patch in question.

Can you try that?  If not, let me know and I'll do a rebuild of it
later this week and put it on people.redhat.com somewhere.

Sorry, Im a bit clueless when it comes to that.

Ill dig around google and try it out but I might need you to do it for me if
you're not too busy.

Its not a huge issue, Im happy to live with FC4-45 for now. 

Please edit your xorg.conf, and add the following option to the "ServerFlags"
section.  If there is no ServerFlags section, create a new one as such:

Section "ServerFlags"
        Option "PciOsConfig" "1"
EndSection

Then save and exit, and reboot the system, then start the X server up again.
Indicate wether the video problem is resolved or not.  If the problem
is still present, remove the above option, and replace it with the following
option instead, and try again:

        Option "PCIProbe1" "1"

Does this option resolve the issue?  If not, please try the following:

        Option "PCIProbe2" "1"

If any of these 3 options work around the problem, please update the bug
report to let us know which ones.  Be sure to reboot the machine before
each try, to ensure a full hardware reset.

This will help us to narrow down wether the problem is related to the PCI
configuration changes, or elsewhere.  Thanks in advance for testing.

Setting status to "NEEDINFO_REPORTER" and awaiting feedback.

(In reply to comment #13)
> Please edit your xorg.conf, and add the following option to the "ServerFlags"
> section.  If there is no ServerFlags section, create a new one as such:
> 
> Section "ServerFlags"
>         Option "PciOsConfig" "1"
> EndSection
> 
> Then save and exit, and reboot the system, then start the X server up again.
> Indicate wether the video problem is resolved or not.  If the problem
> is still present, remove the above option, and replace it with the following
> option instead, and try again:
> 
>         Option "PCIProbe1" "1"
> 
> Does this option resolve the issue?  If not, please try the following:
> 
>         Option "PCIProbe2" "1"
> 
> If any of these 3 options work around the problem, please update the bug
> report to let us know which ones.  Be sure to reboot the machine before
> each try, to ensure a full hardware reset.
> 
> This will help us to narrow down wether the problem is related to the PCI
> configuration changes, or elsewhere.  Thanks in advance for testing.
> 
> Setting status to "NEEDINFO_REPORTER" and awaiting feedback.


Unfortunately, none of these options creates a workaround.

Mike created a build with the i945 patch disabled. 
ftp://people.redhat.com/mharris/testing/fc4/xorg-x11/6.8.2-37.FC4.49.3.test_no_i945.0 
You can try it. Others report good results with it in bug 169093. 

Alexei:

Thanks, I forgot to put the URL here.  ;)

Indeed, the latest testing labs RPMs with i945 patch disabled solve this problem. 

Thanks Mike! Looking forward to seeing this in yum :)

I can confirm this version works on my Dell Latitude D400.

I had a different problem than above, though: xinerama stopped working after
xorg-x11-6.8.2-37.FC4.45. Newer versions just resulted in blank screens,
sometimes the external screen would be filled with some random colour patterns,
but I always ended up having to reboot to reset the display.

Log files showed no errors, it just stopped logging after recognising the V_BIOS.

It _did_ always disable DisplayInfo due to "Bad V_BIOS checksum". In older
versions I had to disable it by hand, newer versions always disabled it
automatically. However, specifying the sync/refresh manually always worked up to
and including 6.8.2-37.FC4.45. After that, no go.

This version fixes it, so I can now enjoy my extended desktop again :-)

If anyone is interested in the log files, let me know. I still have it on my
disk, but it seems to be related to the i945 patch breaking the sync/refresh
(quite badly in my case).

Thanks,
Steven

This bug is not resolved, please don't close it.

The rpms I built are *test* rpms for diagnostic purposes only.  They are
not an official ERRATA release, and they wont be released as an official
update.

Just to clarify things, the latest official xorg-x11 update we released
has an updated i810 driver which adds support for Intel i945 chipsets, and
updates other support.  Changes in this new driver have the unfortunate
side effect of regressing support for some users.  The test build I've
had you guys test, removes the i945 support patch only for diagnostic
purposes to help determine if it is this new support patch that has caused
the regression you are experiencing.  This is only a temporary diagnostic
test.  We are not removing the i945 support patch in an official update.

The current state, is that we need to determine what if any driver options
help people to work around the problems in the new driver, so we can try
to find a real solution.  The preference of course will be to find a solution
that "just works" for people and does not require manual intervention or
manual configuration, however that may or may not be easily possible.

One thing is certain, is that we are tracking the official X.Org driver
whatever direction it goes, as maintaining a diverging driver fork is
definitely not an option.  ;o)


Setting status back to "REOPENED", to continue diagnosis.

Using the current FC4 xorg-x11 update rpm (not the test release I
provided above), if you use the following option in the device
section of xorg.conf, does it change the problem or make it go
away at all?

    Option "NoDDC"

If this option doesn't change anything, what about the following:

    Option "VBERestore"

Please update with your testing results.

Thanks in advance.

(In reply to comment #13)
> Please edit your xorg.conf, and add the following option to the "ServerFlags"
> section.  If there is no ServerFlags section, create a new one as such:
> 
> Section "ServerFlags"
>         Option "PciOsConfig" "1"
> EndSection
> 
> Then save and exit, and reboot the system, then start the X server up again.
> Indicate wether the video problem is resolved or not.  If the problem
> is still present, remove the above option, and replace it with the following
> option instead, and try again:
> 
>         Option "PCIProbe1" "1"
> 
> Does this option resolve the issue?  If not, please try the following:
> 
>         Option "PCIProbe2" "1"
> 
> If any of these 3 options work around the problem, please update the bug
> report to let us know which ones.  Be sure to reboot the machine before
> each try, to ensure a full hardware reset.
> 
> This will help us to narrow down wether the problem is related to the PCI
> configuration changes, or elsewhere.  Thanks in advance for testing.
> 
> Setting status to "NEEDINFO_REPORTER" and awaiting feedback.


After performing the following:

rpm -e --allmatches --nodeps --noscripts xorg-x11-Mesa-libGLU
yum install xorg-x11-Mesa-libGLU

The second suggested configuration change worked:

Section "ServerFlags"
        Option "PCIProbe1" "1"
EndSection

This was successful for a HP Compaq dc7100 with the following lspci output:

00:02.0 VGA compatible controller: Intel Corporation 82915G/GV/910GL Express
Chipset Family Graphics Controller (rev 04) (prog-if 00 [VGA])
        Subsystem: Hewlett-Packard Company: Unknown device 3006
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B-
        Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort-
<MAbort- >SERR- <PERR-
        Latency: 0
        Interrupt: pin A routed to IRQ 209
        Region 0: Memory at cfe00000 (32-bit, non-prefetchable) [size=512K]
        Region 1: I/O ports at 3800 [size=8]
        Region 2: Memory at e0000000 (32-bit, prefetchable) [size=256M]
        Region 3: Memory at cff00000 (32-bit, non-prefetchable) [size=256K]
        Capabilities: [d0] Power Management version 2
                Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA
PME(D0-,D1-,D2-,D3hot-,D3cold-)
                Status: D0 PME-Enable- DSel=0 DScale=0 PME-

00:02.1 Display controller: Intel Corporation 82915G Express Chipset Family
Graphics Controller (rev 04)
        Subsystem: Hewlett-Packard Company: Unknown device 3006
        Control: I/O- Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B-
        Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort-
<MAbort- >SERR- <PERR-
        Latency: 0
        Region 0: Memory at cfe80000 (32-bit, non-prefetchable) [disabled]
[size=512K]
        Capabilities: [d0] Power Management version 2
                Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA
PME(D0-,D1-,D2-,D3hot-,D3cold-)
                Status: D0 PME-Enable- DSel=0 DScale=0 PME-

(In reply to comment #19)
> This bug is not resolved, please don't close it.
> 
> The rpms I built are *test* rpms for diagnostic purposes only.  They are
> not an official ERRATA release, and they wont be released as an official
> update.
> 
> Just to clarify things, the latest official xorg-x11 update we released
> has an updated i810 driver which adds support for Intel i945 chipsets, and
> updates other support.  Changes in this new driver have the unfortunate
> side effect of regressing support for some users.  The test build I've
> had you guys test, removes the i945 support patch only for diagnostic
> purposes to help determine if it is this new support patch that has caused
> the regression you are experiencing.  This is only a temporary diagnostic
> test.  We are not removing the i945 support patch in an official update.
> 
> The current state, is that we need to determine what if any driver options
> help people to work around the problems in the new driver, so we can try
> to find a real solution.  The preference of course will be to find a solution
> that "just works" for people and does not require manual intervention or
> manual configuration, however that may or may not be easily possible.
> 
> One thing is certain, is that we are tracking the official X.Org driver
> whatever direction it goes, as maintaining a diverging driver fork is
> definitely not an option.  ;o)
> 
> 
> Setting status back to "REOPENED", to continue diagnosis.

Apologies for closing the bug. I thought you would open a new bug 'i915 breaks
i810' or something. 

Option "NoDDC"
Option "VBERestore"

in Section Device both fail to fix the problem. Workaround detailed in comment
21 also does not fix the problem here.

Hi the update caused this problem for me. Setting PciOsConfig to 1 fixed it. Tnx.

Hi the update caused this problem for me on my Intel D845GERG2 board. Setting
PciOsConfig to 1 fixed it. Tnx.

Update to xorg-x11-6.8.2-1.FC3.45.2 (on FC3) caused similar problem for me with
HP D530, Dell GX260 and Dell GX270 (at least) with a variety of TFT panels.

So far, I've only tried the above options on an HP D530 with Nec 1760 TFT and
neither fixed the problem.

Hi, sorry it took a while to try again with xorg-x11-6.8.2-37.FC4.49.2. Tried
the suggestions in Comment #13 (Pci0sConfig, PCIProbe1, PCIProbe2) and #20
(NoDDC, VBERestore), all failed to get a working desktop in Xinerama.

Cheers,
Steven

A success report.

hardware:
Rosewill R910E lcd monitor
Shuttle SB61G2v3 with onboard Intel 82865G graphics

software: all latest FC4 according to yum

Current Xorg is at 49.2 (latest). All previous xorg pkgs failed to show anything
on LCD. Last good pkgs were 45. VT's worked all along though. While
experimenting with FC5t1 had the same problem (do I report this to FC5 related
bugzilla?). Read through bugs #168764 and #169093 and the following suggested
fixes did not help: Pci0sConfig, PCIProbe1, PCIProbe2. The 'NoDDC' worked in
FC5t1. So I tried it on FC4 after upgrading to 49.2. Worked.

I can attach log files if you like. I can go back to 45 (got practice) or remove
the NoDDC option and send you the logs.

Hi folks

Not sure if the problem that I'm experiencing is this bug or another one.

I just upgraded a fairly vanilla FC4 install, and my resolution fell back from a
custom 1280x800 mode which is the top res for my laptop back to 1024x768.

I had previously gotten that resolution to work by following the instrauctions
at http://www.cs.cornell.edu/~scs49/install_linux.html#destHeader107 . That had
been working up until the update that I did today.

I note that in my /var/log/Xorg.0.log, I see the line:
(II) I810(0): Not using built-in mode "1280x800_60.00" (width too large for
virtual size)

I'm pretty sure that that was the mode that I was using before the update, since
it's the one that I manually added when following the instructions linked to above.

I have tried all 5 options listed above (NoDDC etc), rebooting for each, without
luck. I'm appy to post my Xorg.0.log if that'll help. If you think this isn't
related to this bug, I'll post a new one.

Cheers, Tom

Oh, btw: Dell Inspiron 700m, Intel 855GME 

Since this bugzilla report was filed, there have been several major
updates to the X Window System, which may resolve this issue.  Users
who have experienced this problem are encouraged to upgrade to the
latest version of Fedora Core, which can be obtained from:

        http://fedora.redhat.com/download

If this issue turns out to still be reproduceable in the latest
version of Fedora Core, please file a bug report in the X.Org
bugzilla located at http://bugs.freedesktop.org in the "xorg"
component.

Once you've filed your bug report to X.Org, if you paste the new
bug URL here, Red Hat will continue to track the issue in the
centralized X.Org bug tracker, and will review any bug fixes that
become available for consideration in future updates.

Setting status to "CURRENTRELEASE".