Bug 157715 - (geforce-6x00) GeForce 6200/6600/6800 hangs during and after install
GeForce 6200/6600/6800 hangs during and after install
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: xorg-x11 (Show other bugs)
4
All Linux
medium Severity high
: ---
: ---
Assigned To: X/OpenGL Maintenance List
David Lawrence
:
: 155515 158109 160289 161239 169317 175252 178849 (view as bug list)
Depends On:
Blocks: FC6Target FC4Update
  Show dependency treegraph
 
Reported: 2005-05-13 20:15 EDT by Ben
Modified: 2008-08-02 19:40 EDT (History)
13 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-07-26 06:50:43 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
lspci -vvn for a Geforce 6200 system exhibiting the problem (11.81 KB, text/plain)
2005-05-24 12:17 EDT, Ben
no flags Details
lspci -vvn on a GeForce 6600 (10.56 KB, text/plain)
2005-05-24 20:30 EDT, Kyle R Maxwell
no flags Details
lspci -vvn output for 6800 card at PCI address 01:00.0 (AGP) (12.89 KB, text/plain)
2005-06-28 15:52 EDT, David Kewley
no flags Details


External Trackers
Tracker ID Priority Status Summary Last Updated
FreeDesktop.org 4523 None None None Never

  None (edit)
Description Ben 2005-05-13 20:15:32 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.7) Gecko/20050419 Galeon/1.3.20

Description of problem:
The nv driver is completely broken for the new GeForce 6200 and 6600. Loading any GTK program hangs the machine (can't even switch to another VT or control-alt-backspace). This means the installer crashes, too, as soon as it enters X!

SUSE 9.3 resorted to making XaaNoScreenToScreenCopy the default for these cards. I can confirm that this works, but is obviously not ideal. According to Owen Taylor, just XaaNoOffscreenPixmaps may fix a similar bug; I will try this and report back.

Something should at least be done to allow the graphical installer to run.

Version-Release number of selected component (if applicable):


How reproducible:
Always

Steps to Reproduce:
1. Start X.
2. Start (for example) GNOME.
3. Hang.
  

Additional info:
Comment 1 Markus Lanz 2005-05-14 03:30:17 EDT
I just can confirm this!
I got the problem with any actually Linux distribution!

It boots nice but when tux would start a GTK application it will not really
hang. It just stops loading you can still move your mouse, but OS will not
accept any keypress or mousepress.

As i mentioned got this problem with following distis:
Fedora Core 4 Test 3; Ubuntu; Suse LiveCD; Gnoppix

Following distis boots well:
KDE demonstration CD, Knoppix, xfce demonstration CD

I hope you guys find the solution for this problem.

greets
Markus Lanz

Specs:
- Athlon64 3200+ (running x86 of FedoraCore4 Test 3)
- 1028 DDR G.E.I.L (checked the hole night with memtest - no errors)
- Asus µatx mainboard (Via Chipset - Deactivated VGA and Modem - Activated Sound)
- Asus V9999 Geforce 6800 LE 128MB
- Logitec USB Desktop
- 19" Xerox TFT (Connected with DVI)
- Logitec USB Headset
- Nostromo Speedpad N51 Connected with USB
Comment 2 Mike A. Harris 2005-05-16 12:44:33 EDT
Are (either of) you seeing this just on x86_64, or does it happen on i386
installation of OS also?

Please attach X server log and config file individually using link below.

Once you can narrow down the specific primitives that prevent the problem
from occuring, we can investigate disabling them in the driver source
as a temporary workaround.  Since this is an "nv" video driver bug however,
it will require the driver maintainer at Nvidia to investigate the problem,
as they're the only ones with the hardware specs, so you'll also need to
file a bug report in X.Org bugzilla located at http://bugs.freedesktop.org
in the "xorg" component.

Once you've filed your bug report to X.Org and pasted 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 NEEDINFO, awaiting bug URL, file attachments, and
feedback.
Comment 3 Mike A. Harris 2005-05-18 20:33:11 EDT
>I can confirm that this works, but is obviously not ideal. According to Owen
>Taylor, just XaaNoOffscreenPixmaps may fix a similar bug; I will try this and
>report back.

Any test results yet?  Fedora Core 4 is almost complete.  If we're going
to make any changes for this issue, we need to know ASAP.

TIA
Comment 4 Mike A. Harris 2005-05-18 20:40:47 EDT
Bug #158109 appears to be a duplicate on i386 installs.  Please review
that bug also.  TIA
Comment 5 Ben 2005-05-18 22:06:42 EDT
I filed Xorg bug 3333 (https://bugs.freedesktop.org/show_bug.cgi?id=3333).

XaaNoOffscreenPixmaps did not fix it. The earliest I can test i386 is tomorrow
or the day after.

Thanks for looking into this.
Comment 6 Markus Lanz 2005-05-19 08:22:17 EDT
(In reply to comment #4)
> Bug #158109 appears to be a duplicate on i386 installs.  Please review
> that bug also.  TIA

Seems to be the same bug! Something goes wrong with the nv driver!


(In reply to comment #5)
> I filed Xorg bug 3333 (https://bugs.freedesktop.org/show_bug.cgi?id=3333).

Please notice that it also happens with 6800 Cards!

Maybe you can include a boot option to use an other driver then nv? I mean all
people will install the original nvidia driver (after Fedora installation).
I want to use Fedora Core 4, so i hope you guys find a workaround

Got no option to post any logs because i have no idea how i should do it without
a second pc

Markus Lanz
Comment 7 Ben 2005-05-19 14:04:05 EDT
> Got no option to post any logs because i have no idea how i should do it
> without a second pc

If you have an existing installation you can boot "linux single". Otherwise, you
can install in text mode. Any /var/log/Xorg.*.log will should still be there
after you trigger the crash and reboot (in text mode again, of course).
Comment 8 Ben 2005-05-19 14:06:16 EDT
Also, this seems to be a recent bug. Older Xorg such as that in FC3 are not
affected.
Comment 9 Ben 2005-05-22 15:50:14 EDT
I can confirm the same thing seems to happen on i386.
Comment 10 Markus Lanz 2005-05-23 08:37:35 EDT
(In reply to comment #8)
> Also, this seems to be a recent bug. Older Xorg such as that in FC3 are not
> affected.

I can Install Fedora Core 3 without any Problems... must have to do something
with the newer xorg or nv-driver maybe.
Comment 11 Markus Lanz 2005-05-23 08:51:24 EDT
Found something interesting in the ubuntu bugzilla.

Link: https://bugzilla.ubuntu.com/show_bug.cgi?id=8438

{Quote}  ------- Additional Comment #9 From Rich Jennings  2005-04-13 17:13 UTC
 [reply] -------

Just wanted to add an independent confirmation on this one.  I have a similar
configuration (AGP rather than PCIe) and had the same problem.  I have yet to
see any Linux distribution configure the NV43 6600 cards properly unless they
use vesa or fbdev driver.  BTW, I also used i386 rather than amd64 on AMD64
platform for stability (beaten path) issues. {/Quote}

sounds similiar to our issue, doesn´t it?
Comment 12 Mike A. Harris 2005-05-24 09:39:35 EDT
*** Bug 158109 has been marked as a duplicate of this bug. ***
Comment 13 Mike A. Harris 2005-05-24 09:45:03 EDT
Changing arch to "All" as this is reported on i386 and x86_64 now for
multiple Nvidia cards.

In older OS releases these cards were not supported at all, so the "vesa"
driver was used, which is why the problem never manifests in those releases,
as it isn't the same driver.

We've had multiple reports now of people confirming that the option
"XaaNoScreenToScreenCopy" works around the problem successfully for
them for these cards.  For now, we are going to enable this option
by default on Nvidia chips which people have attached their X server
log file for or the output of "lspci -vvn".  So, if you're experiencing
this issue, and have not already attached your X server log file or
lspci -vvn to this report, please do so right away as FC4 is frozen
right now, so once the changes are made, there probably wont be
further updates until FC4 is released.

Thanks in advance.
Comment 15 Ben 2005-05-24 12:17:47 EDT
Created attachment 114779 [details]
lspci -vvn for a Geforce 6200 system exhibiting the problem
Comment 16 Kyle R Maxwell 2005-05-24 20:30:22 EDT
Created attachment 114808 [details]
lspci -vvn on a GeForce 6600

I have the same issue; additionally, screen redraws occasionally present a
problem: I see "static" in areas that are being redrawn and I have to switch to
a virtual terminal and back (e.g. Ctrl-Alt-F1, Ctrl-Alt-F7) for the screen to
be useful again.
Comment 17 Mike A. Harris 2005-05-29 04:39:38 EDT
*** Bug 155515 has been marked as a duplicate of this bug. ***
Comment 19 Kyle R Maxwell 2005-06-09 15:30:31 EDT
Will there be a comment in the release notes stating that some nVidia cards
won't work with the installer and that the text-based installer should be used
instead?
Comment 20 Mike A. Harris 2005-06-21 12:52:41 EDT
*** Bug 160289 has been marked as a duplicate of this bug. ***
Comment 21 Kyle R Maxwell 2005-06-21 14:25:19 EDT
Hmm, upgraded to FC4-release this morning (from Rawhide, last updated a few days
before the fork for FC5) and the installer worked after all. Not sure what the
difference was; were there any changes in the kernel on the DVD (x86-64)?
Comment 22 Mike A. Harris 2005-06-23 13:33:42 EDT
*** Bug 161239 has been marked as a duplicate of this bug. ***
Comment 23 Mike A. Harris 2005-06-23 14:45:07 EDT
Confirmed now by another user on GeForce 6600 as well.
Comment 24 David Kewley 2005-06-28 15:52:46 EDT
Created attachment 116083 [details]
lspci -vvn output for 6800 card at PCI address 01:00.0 (AGP)

I see this on my 6800 using 'nv'.  I have just started using 'nvidia', and will
report if I see this problem with that driver as well.	I have not tried the
xorg.conf workarounds with 'nv'; let me know if that would be useful to you.
Comment 25 Mike A. Harris 2005-07-05 11:47:36 EDT
I've synchronized the "nv" driver to the one in CVS head, as there were
a few fixes present there not yet in 6.8, and very minimal changes.

This will be present in 6.8.2-41 which will be present in rawhide in the
next rawhide sync.  Once it's available for download, I'd like everyone
who has experienced any "nv" driver problems including all people CC'd
on this bug to do the following:

BEFORE UPGRADING to new X build:
- Uninstall any nvidia proprietary driver rpm packages or manually
  installed via nvidia's installer completely.

- Reconfigure X to use the "nv" driver if you haven't already.

UPGRADE to new X build:
- Upgrade to the new X build via yum, etc.

AFTER UPGRADING:
- *MANDATORY* - Do a complete system reboot to force a full hardware
  reset and cause the video board to completely repost to factory
  power-on settings.  Also, to ensure the kernel is untainted and
  "clean" in case the proprietary kernel module had been previously
  loaded.

- Edit your xorg.conf and comment out any options you might have been
  using that disable acceleration such as "noaccel" or "XaaNo...."
  options.


Then test start the X server and try to reproduce this bug.  Update this
report with your results, and if you can still reproduce it with the new
driver, please test with "noaccel" and "XaaNoScreenToScreenCopy" again.

If the problem is still present, then it's also present in Xorg CVS head
still, and we'll have to patch the driver to disable the primitive by
default for these cards until the 'nv' driver maintainer has a chance
to investigate and fix the real issue.

Thanks in advance.

Setting to "NEEDINFO", awaiting testing results of -41
Comment 26 Mike A. Harris 2005-07-05 13:41:31 EDT
xorg-x11-6.8.2-41 is now available for download via ftp at the following URL: 
ftp://people.redhat.com/mharris/testing/unstable
Comment 27 Marco 2005-07-07 07:31:02 EDT
Tested the new -41 package and I can reproduce the corruption of my screen just
like always:

1. open KDE
2. open control center
3. go to system administrator
4. go to login manager
5. click on administrator mode
6. insert root password 
7. corruption starts.
Comment 28 Mike A. Harris 2005-07-08 03:13:30 EDT
Marco:  Thanks for the response.

Nobody else has responded with their results of testing the new driver
since I posted it 3 days ago, so I'm assuming that the new driver does
not solve the problem for anyone.

For our next update, I'll be patching the driver to disable
ScreenToScreenCopy on these chips by default for driver stability
as we know this works around the problem.  Unfortunately, this will
likely cause quite a performance hit for these cards, but a slow but
working driver is better than a fast but non-working one.

When there are bug fix patches for the "nv" driver available upstream,
or in upstream CVS, we will review them for consideration to replace
this workaround in a future update.

I'll provide a status update when the new driver build with s2scopy
disabled is ready.

Thanks again.
Comment 29 Mike A. Harris 2005-07-08 05:46:35 EDT
Here are the PCI IDs that I've gotten from attached lspci output and
logs from people who are experiencing this problem.  This is the list
of PCI IDs I will be disabling ScreenToScreenCopy on to allow the
driver to work.

If anyone has an Nvidia card with a PCI ID not on this list, that
experiences this problem in Fedora Core 4, you will need to provide
me with the output of "lspci -vvn" for ALL cards that you experience
the problem on, so I can add them to the blacklist as well.

10de:0140
10de:014f
10de:00f1
10de:0041

Comment 30 Mike A. Harris 2005-07-12 06:44:38 EDT
I've disabled ScreenToScreenCopy on the PCI IDs indicated in comment #29
above, and built xorg-x11-6.8.2-42 in rawhide.  Please test this
new release and indicate if it works around the problem or not.

Thanks in advance.
Comment 31 David Dillow 2005-07-22 15:34:06 EDT
Tested xorg-x11-6.8.2-42 on a x86_64 FC4 and GeForce 6600 GT (10de:0140 rev a2),
but I still get corruption using Firefox to visit web sites with lots of images,
www.cnn.com, sportsillustrated.cnn.com galleries, and such.

I'm not sure this is the same bug, as this problem doesn't show up for quite
some time. When it does occur, the windows go white or occaisonally
multicolored, (browser, gnome-terminal, etc.). Moving the mouse over the browser
will restore the link text on mouseover, and typing still displays text in
gnome-terminal. Usually closing the browser window will leave a large white
rectangle onscreen at this point. Normal operation can be restored by switching
to a text console and back (per comment #16).
Comment 32 Rock Gordon 2005-08-06 03:35:58 EDT
Hi,

Recently purchased a Dell Dimension 8400C, which comes with an nVidia GeForce
6800 GTO PCI-Express board. I also burned all four FC4 ISOs to disk, started the
installed, picked "Custom" install method, and selected "Everything".

After the install was finished, I booted it only to find it trying to start X by
default - at which time the monitor starts displaying fancy colors, and the
console hangs completely.

Well, so I popped in Disk1 and tried the "rescue" mode, changed
/mnt/sysimage/etc/inittab to state 3 by default so it doesn't try to start X by
default and reboot - but it still tries to start X anyways with the same result.

Any suggestions?
Comment 33 Mike A. Harris 2005-08-27 05:25:50 EDT
(In reply to comment #31)
> Tested xorg-x11-6.8.2-42 on a x86_64 FC4 and GeForce 6600 GT (10de:0140 rev a2),
> but I still get corruption using Firefox to visit web sites with lots of images,
> www.cnn.com, sportsillustrated.cnn.com galleries, and such.
> 
> I'm not sure this is the same bug, as this problem doesn't show up for quite
> some time. When it does occur, the windows go white or occaisonally
> multicolored, (browser, gnome-terminal, etc.). Moving the mouse over the browser
> will restore the link text on mouseover, and typing still displays text in
> gnome-terminal. Usually closing the browser window will leave a large white
> rectangle onscreen at this point. Normal operation can be restored by switching
> to a text console and back (per comment #16).

Please experiment with the various "XaaNo" options described on the
xorg.conf manpage, and see which if any of them make the problem go
away for you while using the 'nv' driver with the latest xorg-x11
build.  If none of them work, try "noaccel" and let us know if that
works.

Once we know which options to disable to get it working, we can update
the driver again to handle those cases as well.

Thanks in advance.

Setting status to "NEEDINFO_REPORTER"
Comment 34 David Dillow 2005-09-06 19:41:00 EDT
I've been running xorg-x11-6.8.2-42 for ~10 days now with no corruption using
XaaNoImageWriteRect, XaaNoOffscreenPixmaps, and XaaNoPixmapCache. It feels
slower, but I've not been able to cause the problem. Unfortunately, it doesn't
always happen, so take it with a grain of salt.

I'm going to disable one of those options at a time and see if I can narrow down
which option seems to make the problem go away. Given that it seems to occur
when viewing image laden web pages more often, any suggestions on order or
perhaps a new RPM to test with?
Comment 35 Mike A. Harris 2005-09-14 01:20:42 EDT
(In reply to comment #34)
> I've been running xorg-x11-6.8.2-42 for ~10 days now with no corruption using
> XaaNoImageWriteRect, XaaNoOffscreenPixmaps, and XaaNoPixmapCache. It feels
> slower, but I've not been able to cause the problem. Unfortunately, it doesn't
> always happen, so take it with a grain of salt.
> 
> I'm going to disable one of those options at a time and see if I can narrow down
> which option seems to make the problem go away. Given that it seems to occur
> when viewing image laden web pages more often, any suggestions on order or
> perhaps a new RPM to test with?

There probably wont be any new nv driver to test.  Only Nvidia has knowledge
of how their hardware works, and the open source driver is obfuscated so that
it's not really easy to figure out how the hardware works.  As such, the
only bug fixes that will ever happen with the open source nv driver are
bugs that nvidia fixes and submits patches to X.Org.

All we can do is get users to disable acceleration primitives one at a
time or in combination to narrow down which ones make their problem go
away by using "XaaNo...", and then update the driver to automatically
disable that combination of options for the specified PCI ID.

Unfortunately, there does not appear to be any more work happening on
the open source 'nv' driver other than occasional new PCI ID updates
from the author of the driver to make it autodetect new Nvidia chips.
It appears no new feature work is being done on this driver, and
unfortunately, few if any bug fixing.

We might end up having to switch newer nvidia hardware to the 'vesa'
driver by default in the future.

Going to leave this issue open still however, in case the problem is
caused outside of the driver or something, or a magic fix comes from
nvidia. ;)
Comment 36 David Juran 2005-09-22 09:33:57 EDT
Here is yet another card that on which I see this problem. Do note that this is
on RHEL4 running xorg-x11-6.8.2-1.EL.13.6

01:00.0 Class 0300: 10de:0165 (rev a1)
        Subsystem: 10de:029d
        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, Cache Line Size 10
        Interrupt: pin A routed to IRQ 169
        Region 0: Memory at ed000000 (32-bit, non-prefetchable) [size=16M]
        Region 1: Memory at d0000000 (64-bit, prefetchable) [size=256M]
        Region 3: Memory at ee000000 (64-bit, non-prefetchable) [size=16M]
        Expansion ROM at efe00000 [disabled] [size=128K]
        Capabilities: [60] 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-
        Capabilities: [68] Message Signalled Interrupts: 64bit+ Queue=0/0 Enable-
                Address: 0000000000000000  Data: 0000
        Capabilities: [78] Express Endpoint IRQ 0
                Device: Supported: MaxPayload 128 bytes, PhantFunc 0, ExtTag-
                Device: Latency L0s <512ns, L1 <4us
                Device: AtnBtn- AtnInd- PwrInd-
                Device: Errors: Correctable- Non-Fatal+ Fatal+ Unsupported-
                Device: RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop+
                Device: MaxPayload 128 bytes, MaxReadReq 512 bytes
                Link: Supported Speed 2.5Gb/s, Width x16, ASPM L0s L1, Port 0
                Link: Latency L0s <256ns, L1 <4us
                Link: ASPM Disabled RCB 128 bytes CommClk+ ExtSynch-
                Link: Speed 2.5Gb/s, Width x16
        Capabilities: [100] Virtual Channel
        Capabilities: [128] Power Budgeting
Comment 37 Mike A. Harris 2005-09-26 22:03:36 EDT
At this point I think it's probably best for us to just switch Nvidia
GeForce 6x00 hardware to the 'vesa' driver, and track this upstream in
X.Org bugzilla.

Comment 38 Mike A. Harris 2005-09-26 22:05:26 EDT
*** Bug 169317 has been marked as a duplicate of this bug. ***
Comment 39 David Juran 2005-09-27 04:02:15 EDT
Problem with running the VESA driver was that other image distortions occurred.
It's a bit hard to describe, and it may be that this problem only occurs in
conjunction with a flat screen. However, when I tried using the VESA driver
there was a very annoying effect where primarily thin lines seemed 'wavy' and
kind of creeped across the screen.

However setting the options  "XaaNoImageWriteRect",  "XaaNoOffscreenPixmaps" and
 "XaaNoPixmapCach" to "yes" seems to work fine.
All of this on RHEL 4 using xorg-x11-6.8.2-1.EL.13.6
Comment 40 Mike A. Harris 2005-09-28 02:54:03 EDT
Another option has presented itself to us...

A couple of recent nv driver updates to X.Org CVS have occured, merged from
fixes from Mark V look promising.  They refer to issues that sound very
much like the problem being experienced by everyone here.

We'll likely update to the newer 'nv' driver in the future to test this.
Comment 41 Mike A. Harris 2005-12-21 11:50:33 EST
*** Bug 175252 has been marked as a duplicate of this bug. ***
Comment 42 Mark Evers 2005-12-22 15:21:41 EST
I'm having problems with a 6600 too, but in a multimonitor setup.
With the nv driver i wasn't able to get multimonitor working at all, but using
the nvidia driver i was... Untill i rebooted, after the reboot X comes up asking
me for my login and freezes, not responding to mouse or keyboard (caps lock
light won't even light up when i hit the caps lock)
If i recompile the kernel driver for nvidia all works ok again, untill i reboot
then i have to start all over.

Running FC4 x86_64 with kernel 2.6.14-1.1653_FC4smp here

error in my Xorg.log
(**) NVIDIA(0): ConnectedMonitor string: "crt,crt"
(**) NVIDIA(0): TwinView enabled
(EE) NVIDIA(0): Failed to load the NVIDIA kernel module!
(EE) NVIDIA(0):  *** Aborting ***
(II) UnloadModule: "nvidia"
(EE) Screen(s) found, but none have a usable configuration.

Fatal server error:
no screens found
Comment 43 Mark Evers 2005-12-22 18:22:09 EST
EDIT:
It's really a nvidia and nv bug, i changed the 6600 with a radeon 8900xt and
everything works like a charm now (same config, only changed nv to radeon)
Comment 44 Mike A. Harris 2006-01-20 12:43:12 EST
Have any of you guys had a chance to give Fedora Core 5 test2 a whirl?  I'm
curious if the problem is still present in the current X11R7 nv driver or not.

If someone who has hardware which exhibits this problem could test FC5t2 and
respond, that would be helpful.  If it turns out that the nv driver in FC5t2
no longer has this problem, we might be able to update the nv driver to the
new one in the next FC4 xorg update.

Unfortunately, I don't have the hardware to test it personally.  If anyone
else can give it a shot though, please update the report with your findings.
Comment 45 Ian Burrell 2006-01-21 16:17:07 EST
The nv driver in X11R7 has been working fine with my GeForce 6600 since I
installed FC5T1 on x86_64.  I haven't had the problems with the screen getting
messed up which I had with FC4.  On FC4, I had to disable XaaNoOffscreenPixmaps
acceleration.
Comment 46 Ben 2006-01-23 23:50:45 EST
I booted FC5T2 and it seems to work now.
Comment 47 Mike A. Harris 2006-01-24 21:10:07 EST
*** Bug 178849 has been marked as a duplicate of this bug. ***
Comment 48 matt zelda 2006-01-25 01:11:52 EST
I can confirm comment 46 as I have been running FC5test2 for a couple of days
now.  i posted that last duplicate bug(sry) and though i am gonna stay with test
2 untill the final release of fc5, i would like to find out what the problems. 

PS if anyone could tell me what kind of feedback is needed about fc5 i would be
willing to contribute although i am pretty new at this. 
Comment 50 Dan Book 2006-02-22 01:57:06 EST
I had a 6600 (pci-express) and had no issues with the nv driver, though I
installed the nvidia driver right away. Upon accidental reversion to nv though,
no problems, with FC4 and FC5 test 2. However, I recently upgraded to a 6800GS
pci-express, and then attempted to install FC5 test 3 (I haven't tested with
test 2 because it wouldn't boot after installing, but that's a different issue).
X just comes up with a bunch of crosshatch-ish colors, frozen. I ran a linux
text installation to install but still couldn't boot (the other issue again),
though the text was screwed up (shifted one character whenever highlighted, it
made it somewhat confusing). Anyway, I restored my FC4 install and didn't have
the problem at first...I'm not sure why...but it was using the nv driver I
believe. But as soon as I edited my xorg.conf a little, same problem. I
installed the nvidia driver and haven't had any problems since.
So this definitely is not fixed in FC5t3.
Comment 51 Dan Book 2006-02-22 02:00:45 EST
Actually, I'm not sure if this is the same as the original issue, because I
could switch to another tty or ctrl+alt+backspace, though the latter results in
just killing X for a second then going back into the madness.
Comment 52 Adam Jackson 2006-07-24 11:02:13 EDT
xorg-x11-drv-nv-1.2.0-1.fc5 has been submitted to the release team for
fc5-updates.  Please test once it's been pushed.
Comment 53 Mike A. Harris 2006-07-26 06:50:43 EDT
Assuming problem is fixed in new update referred to in previous comment and
closing as ERRATA for FC5.  If the problem still occurs for anyone, please
reopen the report and/or indicate it in a bug comment.

Thanks in advance.

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