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:
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
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.
>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
Bug #158109 appears to be a duplicate on i386 installs. Please review that bug also. TIA
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.
(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
> 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).
Also, this seems to be a recent bug. Older Xorg such as that in FC3 are not affected.
I can confirm the same thing seems to happen on i386.
(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.
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?
*** Bug 158109 has been marked as a duplicate of this bug. ***
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.
Created attachment 114779 [details] lspci -vvn for a Geforce 6200 system exhibiting the problem
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.
*** Bug 155515 has been marked as a duplicate of this bug. ***
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?
*** Bug 160289 has been marked as a duplicate of this bug. ***
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)?
*** Bug 161239 has been marked as a duplicate of this bug. ***
Confirmed now by another user on GeForce 6600 as well.
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.
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
xorg-x11-6.8.2-41 is now available for download via ftp at the following URL: ftp://people.redhat.com/mharris/testing/unstable
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.
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.
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
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.
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).
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?
(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"
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?
(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. ;)
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
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.
*** Bug 169317 has been marked as a duplicate of this bug. ***
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
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.
*** Bug 175252 has been marked as a duplicate of this bug. ***
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
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)
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.
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.
I booted FC5T2 and it seems to work now.
*** Bug 178849 has been marked as a duplicate of this bug. ***
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.
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.
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.
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.
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.