180.06 report (some improvements)

[zBeeble42]

First... I'll say that a rather large improvement --- that the adapter now detects the AC line --- is very appreciated. However, there are some rather debilitating regressions.

The most noticable problem is that it can't detect that both my desktop display and my integrated display (in my laptop) are 1920x1200. If there is no configuration in the xorg.conf regarding resolution, it will choose 1024x768. If I use nvidia-settings, it wants to add a "metamodes" line consisting of "DFP1: 1920x1200 +0+0" ... in which case the display comes up in 1280x1024 mode.

I've tried several different configurations --- including using the internal display. The note in the log file is similar to:

(--) NVIDIA(0): Connected display device(s) on GeForce 8700M GT at PCI:3:0:0:
(--) NVIDIA(0): Seiko (DFP-0)
(--) NVIDIA(0): DELL 2405FPW (DFP-1)
(--) NVIDIA(0): Seiko (DFP-0): 330.0 MHz maximum pixel clock
(--) NVIDIA(0): Seiko (DFP-0): Internal Dual Link LVDS
(--) NVIDIA(0): DELL 2405FPW (DFP-1): 330.0 MHz maximum pixel clock
(--) NVIDIA(0): DELL 2405FPW (DFP-1): Internal Dual Link TMDS
(II) NVIDIA(0): Display Device found referenced in MetaMode: DFP-0
(II) NVIDIA(0): Assigned Display Device: DFP-0
(WW) NVIDIA(0): No valid modes for "DFP-0:1920x1200"; removing.
(WW) NVIDIA(0):
(WW) NVIDIA(0): Unable to validate any modes; falling back to the default mode
(WW) NVIDIA(0): "nvidia-auto-select".
(WW) NVIDIA(0):
(II) NVIDIA(0): Validated modes:
(II) NVIDIA(0): "nvidia-auto-select"
(II) NVIDIA(0): Virtual screen size determined to be 1024 x 768
(--) NVIDIA(0): DPI set to (70, 84); computed from "UseEdidDpi" X config
(--) NVIDIA(0): option
(==) NVIDIA(0): Enabling 32-bit ARGB GLX visuals.

each time.

I've attached an nvidia-bug-report.log file to help with debugging this --- although I don't see it saying much about the EDID read from the flat panels.

Additionally, if the metamodes line is in the xorg.conf, then nvidia-settings will not even offer 1920x1200 as an option.

Interestingly, the external flat panel sees the video signal as 1920x1200 the whole time (ie: the panel is not doing the scaling).

It's worth noting that we still have 100% interrupts on one of the two CPUs. I'm also forced to use -vo gl or -vo gl2 on mplayer (meaning many other movie players don't work).

But on the plus side, it would appear that solid window moving is now good (no noticeable lag).

[zander]

To better understand the mode validation problem, please start X with -logverbose 6 and generate/attach another nvidia-bug-report.log file.

[BSDMare]

Massive improvements here for me. Firefox 3 had appalling scrolling under FreeBSD on <div> heavy websites or websites with floating relational <div>'s such as http://www.freebsdnews.net/ when you scroll down past the title. Or Slashdot's new comment system that caused the whole desktop to judder to a halt until the page finished scrolling.

On these drivers it scrolls as smooth as Firefox 2, very happy about this as I am currently spending all day working on our companies new website which suffered the same scrolling problems :D

Thanks very much!

Looking forward to see what happens with VDPAU.

[ZOleg]

What about computers with >=4Gb RAM?
Computers hangs on start X or not with 180.06 drivers?

[rnejdl]

NVidia still does not support 64 Bit FreeBSD.

Rusty Nejdl

[zBeeble42]

zander... willdo that tomorrow sometime.

[zBeeble42]

As for 4G (or more), the nvidia driver doesn't seem to support PAE. My mistake. It was my windows boot that was successfully using PAE, not my FreeBSD install.

But on to Zander's request. I've create two nvidia-bug-report.log's --- one with DFP0 as the metamode hint and one with DFP1. They seem to behave slightly differently --- so you might want to have a look at them.

They are, however, too big for the forum upload facility, so I'm leaving you two links here --- you can fetch them yourself from my website:

http://daveg.ca/~dgilbert/nvidia-bug-report-DFP0.log
http://daveg.ca/~dgilbert/nvidia-bug-report-DFP1.log

Good hunting.

[zander]

@zBeeble42: thank you for the detailed log files, I took a look. It looks like the extended GPU capabilities check is throwing out 1920x1200 for the internal panel:
(II) NVIDIA(0): --- Building ModePool for Seiko (DFP-0) ---
(II) NVIDIA(0): Validating Mode "1920x1200":
(II) NVIDIA(0): 1920 x 1200 @ 60 Hz
(II) NVIDIA(0): For use as DFP backend.
(II) NVIDIA(0): Mode Source: EDID
(II) NVIDIA(0): Pixel Clock : 166.44 MHz
(II) NVIDIA(0): HRes, HSyncStart : 1920, 1968
(II) NVIDIA(0): HSyncEnd, HTotal : 2000, 2228
(II) NVIDIA(0): VRes, VSyncStart : 1200, 1203
(II) NVIDIA(0): VSyncEnd, VTotal : 1209, 1245
(II) NVIDIA(0): H/V Polarity : -/-
(II) NVIDIA(0): Mode is valid.
(II) NVIDIA(0): Native backend timings for Seiko (DFP-0):
(II) NVIDIA(0): 1920 x 1200 @ 60 Hz
(II) NVIDIA(0): Pixel Clock : 166.440 MHz
(II) NVIDIA(0): HRes, HSyncStart : 1920, 1968
(II) NVIDIA(0): HSyncEnd, HTotal : 2000, 2228
(II) NVIDIA(0): VRes, VSyncStart : 1200, 1203
(II) NVIDIA(0): VSyncEnd, VTotal : 1209, 1245
(II) NVIDIA(0): H/V Polarity : -/-
(II) NVIDIA(0):
(II) NVIDIA(0): Validating Mode "1920x1200":
(II) NVIDIA(0): 1920 x 1200 @ 60 Hz
(II) NVIDIA(0): Mode Source: EDID
(II) NVIDIA(0): Pixel Clock : 166.44 MHz
(II) NVIDIA(0): HRes, HSyncStart : 1920, 1968
(II) NVIDIA(0): HSyncEnd, HTotal : 2000, 2228
(II) NVIDIA(0): VRes, VSyncStart : 1200, 1203
(II) NVIDIA(0): VSyncEnd, VTotal : 1209, 1245
(II) NVIDIA(0): H/V Polarity : -/-
(II) NVIDIA(GPU-0): BestFit Scaled and BestFit AspectScaled are identical;
(II) NVIDIA(GPU-0): collapsing BestFit AspectScaled.
(II) NVIDIA(GPU-0): BestFit Centered and BestFit Scaled are identical;
(II) NVIDIA(GPU-0): collapsing BestFit Scaled.
(II) NVIDIA(GPU-0): Native Scaled and Native AspectScaled are identical;
(II) NVIDIA(GPU-0): collapsing Native AspectScaled.
(II) NVIDIA(GPU-0): Native Centered and Native Scaled are identical;
(II) NVIDIA(GPU-0): collapsing Native Scaled.
(II) NVIDIA(GPU-0): BestFit and Native are identical; collapsing Native.
(WW) NVIDIA(GPU-0): BestFit Centered ViewPort 1920x1200 exceeds hardware
(WW) NVIDIA(GPU-0): capabilities.
(WW) NVIDIA(0): Mode is rejected: Unable to construct hardware-specific
(WW) NVIDIA(0): mode timings.
Ditto for the external Dell DFP. You should be able to work around this by specifying one of these two X driver option lines:
Option "ModeValidation" "DFP-0: NoExtendedGpuCapabilitiesCheck; DFP-1: NoExtendedGpuCapabilitiesCheck"
Option "ModeValidation" "NoExtendedGpuCapabilitiesCheck"

However, I'd really liked to root cause this problem. Which notebook (make/model) are you using? If I can get a hold of one, I might be able to reproduce and investigate the interrupt storm problem, as well.

As to PAE, the NVIDIA FreeBSD graphics driver has never supported it due to limitations of the mmap(2) interface; the workaround needed for the same limitations can break down on large memory configurations even with non-PAE kernels.

[zBeeble42]

OooOh... master spiffy!

Ok. It's a Dell XPS-1730 with the dual 8700M (they also now come with a dual 8800M last I checked) and the intel extreme x7900 (currently @2.8 Ghz). It also has that physics co-processor board, if that matters.

On a fairly regular but somewhat limited basis, I can make my laptop available for login, too.

[zander]

OK, thanks. I checked and we do have one of these notebooks in the office. It's currently being used for higher-priority work, but I've added myself to the queue.

[zBeeble42]

Just to help firm things up, with that line ...

Option "ModeValidation" "NoExtendedGpuCapabilitiesCheck"

... The display comes up at the correct resolution.

[edhunterbg]

What about computers with >=4Gb RAM?
Computers hangs on start X or not with 180.06 drivers?

I would like to ask it too...

Yes ... I am aware that i386 does not support 4+ GB without PAE.
I have freebsd7.1-pre-i386 with 4G without PAE. Yes I am aware that I dont use all of my RAM (loosing about half gig) but that is ok for me. The problem is that when I load X with nvidia-driver the pc hangs at black screen. When I physicaly remove 2G (my dimms are 2x2gigs), the there is no problem with X+nvidiadriver.
No i dont have memory remap option in bios.

I am tired to install every release of nvidia driver just to see that my pc still hangs when i try to run X...

[zander]

@zBeeble42: I tracked down the mode validation regression, future 180.xx releases should no longer exhibit this problem. I couldn't reproduce the interrupt storm on this XPS 1730 notebook, though. I was using a variant of FreeBSD 6.3-RELEASE, FreeBSD 7.0-RELEASE wouldn't install; have you seen the problem with older FreeBSD releases?

@edhunterbg: please see my post #8 to this thread.

[HenryHu]

I'm seeing blocks of colored dots on the screen, after upgrading to 180.06.
Sometimes they disappear when I switch to another window, sometimes I need to switch to desktop and click the right mouse button... I'm using compiz + KDE4.

I think the scrolling is better, although I've not done any test.
Sometimes the screen flashes several times and then the system hang or crash. If I try to switch to console, sometimes this would help me out of crash.
There are NVRM messages if I successfully switched to console.
Nov 20 16:36:30 laptop kernel: NVRM: Xid (0001:00): 13, 0001 00000000 00005039 00000328 00000000 00000023
Nov 20 16:36:30 laptop kernel: NVRM: Xid (0001:00): 13, 0001 00000000 00005039 00000328 00000000 00000023
Nov 20 16:36:31 laptop kernel: NVRM: Xid (0001:00): 13, 0003 00000000 00008297 00000f04 3f7ae1fb 00000040

and another time:

Nov 17 19:59:41 laptop kernel: NVRM: Xid (0001:00): 13, 0001 00000000 00005097 00000680 0009000f 00000080
Nov 17 20:00:11 laptop kernel: NVRM: Xid (0001:00): 13, 0005 00000000 00008297 00000f04 00000000 00000040
Nov 17 20:00:11 laptop kernel: NVRM: Xid (0001:00): 13, 0005 00000000 00008297 00000f04 3f70a5f1 00000040
Nov 17 20:01:11 laptop kernel: NVRM: Xid (0001:00): 13, 0005 00000000 00008297 00000f04 3f70a5f1 00000040

[edhunterbg]

@edhunterbg: please see my post #8 to this thread.
yes .. sorry i havent readed the entier post ..
now i see it.

is there any hope in near future to have some workaround ...
or the situation is comparable with status of nvidia driver for freebsd/amd64 = waiting for freebsd devs
?

[BSDMare]

Ok, I've been running these drivers over the last week without a reboot and things are really starting to grind down. Even just opening a new terminal window seems to lag the system so the point where xorg is completely unresponsive to the mouse for a few seconds.

Doesn't appear to be any noticeable increase in memory usage but during these slowdowns xorg cpu usage can get upto 90% WCPU usage in top. I'm not running any fancy compositing settings, just plain xfce4.

Also nvidia doesn't seem to appear in vmstat -i any more so I can't see if the interrupts are going crazy, just that top says 0.9% interrupt.

I've attached a bug report. Just going to reboot and see if that helps. :headexplode:

---edit

Rebooted and now its all back to full speed again, very smooth.

[rnejdl]

I am seeing this in both of the 180.x drivers. Simply logging out and logging back into X solves the issue for me, no reboot required. I am running KDE4. I think I'll be reverting soon as this just doesn't work.

Rusty Nejdl

[BSDMare]

Ah yes, that works too. Cheers for that.

Still a bit of a pain as I have a lot of work open on here. On one hand I love the smooth scrolling in FireFox 3 but having everything slowly grind down to a halt every few days isn't fun. :(

[zander]

Are you seeing this problem with the 180.11 driver release? It addressed a memory leak in the glyph cache that would've caused the symptoms you described.

[zander]

It looks like we never posted a release announcement for 180.08, nor for 180.11; I apologize for that, it's fixed now for the latter release.

[rnejdl]

I just updated to 180.11 so I will let you know. It definitely felt like a memory leak in the glyph cache though.

Thanks!
Rusty