With the nv driver, and the onboard video on an ASUS M2N-MX motherboard, the monitor is driven using a clock rate approximately 8% slower than what should be used. We saw the problem first when an Samsung LCD monitor failed to properly display what was supposed to be a VESA-standard 1280x1024@60Hz mode; the monitor was actually getting only a 56Hz refresh rate. (We worked around the problem by artificially raising the clock value in the mode line from 108 to 116). I then reverified it on a different machine (same type of motherboard) using a different (CRT) monitor and totally different mode (1400x1050@85Hz). Again, the monitor was getting refresh rates about 8% slower than expected: only 79Hz. I updated to version 1.3 of the server and version 2.1.2 of the nv driver. There was no change; the problem persisted. To ensure there was no confusion about modes, I added the following modeline to the Monitor section of xorg.conf: Modeline "testmode" 184.00 1400 1464 1656 1960 1050 1051 1054 1100 +hsync +vsync I then forced the server to use only that mode by putting Modes "testmode" into the Display subsection. However, the monitor was still only getting 86.6 kHz horiz, 79 Hz vertical refresh rates instead of the 93.5 kHz / 85 Hz rates which that mode line is supposed to generate. If I change the clock value in the mode line from 184.00 to 198.00, then the monitor gets the correct 93.5 kHz / 85 Hz refresh rates (or closer to them). When I switch to the proprietary nvidia driver and again use the same "testmode" mode (with clock=184.00) in the xorg.conf file, the monitor also gets the correct 93.5 kHz / 85 Hz refresh rates. There may be some firmware / BIOS problem happening here but, whatever it is, the proprietary nvidia module is able to work around it properly. I will attach the server log file.
Created attachment 11135 [details] Log file
This seems to be a reason for bug #247271 even I did not tested it.
Sorry. Seems to be a reason for bug #8538.
I experienced the same behaviour on my MSI K9N6GM (GeForce 6100 nForce 405) and I have seen reports of nVidia using the PCIE clock / 4 = 25000 kHz to drive some of their cards instead of a crystal with a frequency of 27000 kHz. I noticed that 27000 / 25000 = 1.08. Applying the following patch resolved my problem and now the nv driver works fine for me: diff -ur xf86-video-nv-2.1.6/src/nv_setup.c xf86-video-nv-2.1.6.mihai/src/nv_setup.c --- xf86-video-nv-2.1.6/src/nv_setup.c 2007-09-17 22:17:51.000000000 +0100 +++ xf86-video-nv-2.1.6.mihai/src/nv_setup.c 2008-05-31 21:21:36.000000000 +0100 @@ -335,7 +335,11 @@ if(pNv->twoHeads && (implementation != 0x0110)) { if(pNv->PEXTDEV[0x0000/4] & (1 << 22)) - pNv->CrystalFreqKHz = 27000; + if(implementation == 0x03d0) /* GeForce 6100 nForce 405 */ + /* Quick and dirty: works for MSI K9N6GM */ + pNv->CrystalFreqKHz = 25000; + else + pNv->CrystalFreqKHz = 27000; } pNv->CURSOR = NULL; /* can't set this here */
The patch provided by Mihai resolved the issue for me as well. I have a video card with the same PCI ID (03d0). In support of getting a patch committed for this problem, is the PCIE clock guaranteed to always be 100000 kHz or does it need to be detected somehow? Also, are there other PCI ID's that this patch should apply to?
My card functions (slightly) better with this patch as well - modified to reflect my PCI ID of 10de:0242: diff -ur xf86-video-nv-2.1.6/src/nv_setup.c xf86-video-nv-2.1.6.mihai/src/nv_setup.c --- xf86-video-nv-2.1.6/src/nv_setup.c 2007-09-17 22:17:51.000000000 +0100 +++ xf86-video-nv-2.1.6.mihai/src/nv_setup.c 2008-05-31 21:21:36.000000000 +0100 @@ -335,7 +335,11 @@ if(pNv->twoHeads && (implementation != 0x0110)) { if(pNv->PEXTDEV[0x0000/4] & (1 << 22)) - pNv->CrystalFreqKHz = 27000; + if(implementation == 0x0240) + + pNv->CrystalFreqKHz = 25000; + else + pNv->CrystalFreqKHz = 27000; } pNv->CURSOR = NULL; /* can't set this here */ I also have an Ubuntu bug open at <https://bugs.launchpad.net/bugs/311976>
Created attachment 24584 [details] Diagnostics
xf86-video-nv has been officially unmaintained for a bit now, and we are closing all -nv bugs. If your problem was not addressed, and -nv is still broken, please try xf86-video-nouveau. Thank you.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.