No nVidia accelerated video on 7600GS analog output

[tigerdog]

A few months back, I reported a bug about accelerated video failing on a 7600GS card. Bug was closed as a modeline issue, but I've done further work and have now isolated it to either the nvidia driver or accelerant. Video is OK in VESA mode at all resolutions except 1920x1200 due to a known modeline issue. Video does not work at all when the nvidia driver is invoked.

If there is no /boot/home/config/settings/kernel/drivers/nvidia.settings file, the display does not correctly initialize. Instead, the video output from the analog port toggles on and off. If I copy an nvidia.settings file from an older version, garbage is displayed and the display freezes.

To test further, I built the driver and accelerant with "--target=hrev5" and tested under Zeta. The driver does exactly the same thing under Zeta as under Haiku, so I don't think this is Haiku-specific.

I enabled full logging Haiku with the current driver and under Zeta with an older version that works correctly; I've attached the two log files. I hope this helps.

[tigerdog]

nvidia driver log taken under Haiku

[tigerdog]

log under Zeta with older version of driver Feb 2007

[anevilyak]

This sounds a lot like ticket #2643 ... duplicate maybe?

[tigerdog]

could be duplicate of 2643, but here the trouble happens on analog output, not DVI. Also, trouble happens under Haiku and also Zeta with hrev5 version of driver. My apologies if this is a duplicate.

[anevilyak]

I'll let Rudolf make that call, don't know at this point.

[tigerdog]

Console Output of Accelerant build failure

[tigerdog]

Just for fun, I tried to build the driver after updating from SVN. jam nvidia worked, but "jam nvidia.accelerant" failed. ProposeDisplayMode.o was not built - console output of the error is attached to the bug.

Build environment is haiku pre-alpha rev 28641.

[tigerdog]

oops -please ignore the above. had bogus version of source in tree and so was not updated properly. current version builds OK.

[tigerdog]

Better comparison: diff of Zeta (rev .81) and Haiku (rev. .85) with screen resolution set to 1920x1200 on both.

[tigerdog]

I've heard from others who say they see a similar problem on digital outputs. I did some testing a while back and discovered the current rev .85 driver fails under Zeta (when built for target=BONE) in the same way it fails under Haiku, so we're back to looking at either the driver itself or maybe the rewritten AGP/GART manager? I first noticed this problem with rev 24669 but had not been testing nightly builds on a regular basis prior to that.

I'd really love to be able to use the nVidia driver, as the VESA driver does not do well at my screen's native 1920x1200 resolution (presumably because of card BIOS/timing issues, not the driver itself).

Is there anything I can do to help isolate this trouble?

[rudolfc]

Hi,

I've just looked at the nvidia accelerant log under haiku and it seems there are ram access errors (you can see that in the log around, at the end of a setmode command).

I expect driver needs updating for extra init stuff: I have to sync the driver to current linux x.org I expect. Before I can do that I need a stable working environment being haiku itself: I'm working on it. (nearly there it seems).

I have a 7600 card here that I'll test with. BTW if there are DVI specific problems you might take a look at: ​http://www.haiku-os.org/community/forum/dvi_support#comment-10219

I've written some extra related info there.

back soon I hope :)

Bye!

[tigerdog]

Rudolph, thanks for looking at this. One of the logs show RAM init errors because "dma_acc false" was in nvidia.settings. As long as "dma_acc true" is set, RAM initializes OK.

Also, I just downloaded the oldest image on haiku-files.org and installed the nvidia driver and accelerant (rev 0.84 from January 1, 2008). This version does the same thing, so rewritten AGP is not resposible.

I hope this helps!

[tigerdog]

Very odd! Another bit of info. I have assumed, because the system only boots with a VESA settings config file, that the system is using the VESA driver. I also left my nvidia settings file in place, with logging enabled.

I just noticed, the nvidia log file is getting an entry added every time the screen goes into or out of power-save mode by the screensaver. If the nvidia driver is not being used, is this still logged?

[tigerdog]

Now, some good news: The nVidia driver is working!

My system's display only initializes when a VESA config file is present, so I assumed I was running in VESA mode. I also assumed my display issues at 1920x1200 were due -to VESA driver and/or card BIOS issues. Both assumptions were wrong.

After I noticed nvidia log entries being written when I thought VESA was in use, I tested a new 1920x1200 modeline in the nvidia accelerant. The change solved my display issue! Therefore, I conclude a few things:

-the 1920x1200 modeline in ProposeDisplayMode.c needs to be changed (ticket #2791)
-the nVidia accelerated driver works
-the nVidia accelerated driver does not intialize correctly. To work, both a vesa and nvidia config file must be manually placed in /boot/home/config/settings/kernel/drivers

There is still a problem, because for new installs or system restarts, nvidia displays won't init properly unless VESA is selected and a VESA config file is present.

[rudolfc]

Hi tigerdog,

Thanks for all the extra stuff you added here. I'll try to find the missing init stuff later on. Meanwhile, I expect that you can remove the vesa settings file because Haiku makes a VESA BIOS call these days to show the splash screen. This VESA BIOS call just might do the extra init you need. Can you confirm or deny this for me please?

Thanks!

(If Haiku now works without vesa settings file it will be hard for me to test missing init since I can only run Haiku on my system, not BeOS. Hmm Zeta maybe though.. I'll test that meanwhile.)

Rudolf.

[rudolfc]

Hi tigerdog,

Can you post a full update on the status here? Also let me know if you are testing with GCC4 or GCC2 just to be sure.. Can you upload a new logfile as well?

Thanks!

Rudolf.

[rudolfc]

Please upgrade to hrev32946. Please remove the vesa file and the app_server_settings file.

All OK now?

Thanks!

Rudolf.

[rudolfc]

Hi there,

Please disregard the previous message and upgrade to hrev32958. Now the fix seems complete. Please test and let me know!

Thanks!

Rudolf.

[tigerdog]

log file under R32645

[tigerdog]

nvida.settings file used to trigger logging

[tigerdog]

Rudolf, unfortunately, I still get no video. Monitor displays "no input" when switch occurs. I created a very minimal "nvidia.settings" file to trigger logging and have attached the resulting log file.

I also tried R32662 GCC4 build but had no video there either.

I double-checked to make sure no vesa configuration file was present and there's no app_server_settings file, either.

[tigerdog]

could it be, the driver is confused because it thinks the monitor is not wide-screen capable yet it still tries to set a wide-screen mode? I think that's what I see in the log file.

[luroh]

Excuse me for interfering, but 32662 is about a month old, Rudolf has been doing much work on the driver since then. Since the nightly builds have apparently stopped appearing (perhaps until alpha1 is out), please grab one of the alpha images instead to test with, here: ​http://haiku-files.org/releases/R1Alpha1/

My own GF7900GT card has gone from exhibiting the same symptom as yours, to a fully working head1 (head2 isn't working yet, but we haven't given up hope). Hope it works for you too.

[rudolfc]

Hi guys!

Thanks Luroh for the update. Unfortunately the alpha1 branch isn't upto date. The only option is to checkout the full driversources from trunk and compile from there.

If that isn't possible for you let me know, I'll upload the latest version here then.

Bye!

Rudolf.

[tigerdog]

Unfortunately, I don't have the ability to build Haiku at the moment. If you are able to upload the latest, I'll be happy to test. I tried R33000 but (obviously) had the same problem.

[rudolfc]

Hi again,

The driver is now upto date in the alpha branch. If all is right you can download the latest version and have the newest nvidia driver that way.

Please let me know how it goes, and can you upload a logfile?

Thanks!

Rudolf.

[tigerdog]

I've updated to rev 33054 but still have the problem. Very stubborn! I'll upload a new log.

[tigerdog]

log from rev 33054

[tigerdog]

MYSTERY SOLVED! after looking through the attached log, it occurred to me there was a lot of information about CRTC2. I changed "switchhead true" and now have video on my monitor! So the question remains, why does the driver not automatically recognize the DVI interface is not connected and analog is the only one active?

[tigerdog]

Please note, I had to copy and rename an old "nv.settings" file into /boot/home/config/settings/kernel/drivers, then modify the switchhead setting. Please also note, I used to need force_ws true but now I can leave this false and the correct modes are made available.

[rudolfc]

Thanks tigerdog. Good news indeed! :-)

Can you try this: disable switchhead again, and connect your screen using a DVI<>VGA adapter to the other port. Reboot. Do you have a picture now as well? If so, please upload a log from that.

If not, upload a log from the trick you are using now.

I suspect you ran into the problem I call 'unknown new analog output switch'. Phillippe Houdoin (if I spell this correcty) suffers from exaxt the same problem.

I can reproduce it here as well on a card. I have an idea on how to workaround this problem, but that won't be in alpha1.

Let's first make sure you have the same problem by doing the test I just requested.

Thanks!

Rudolf.

[tigerdog]

log with DVI->VGA adapter and switchhead false

[tigerdog]

Hi Rudolf,

Tested with DVI->VGA adapter and "switchhead false". It works! I've attached the log as requested.

Regards, Doug

[tigerdog]

one other minor note: if I run on secondary (analog) output connector, I have to add the line "dma_acc true" to nvidia.settings or the screen image is corrupted. does this need a new bug?

[rudolfc]

You should leave it at the default setting being "dma_acc true". I'll remove PIO mode I think to prevent people from still trying the old method since there are no known problems with DMA acceleration anymore.

BTW: app_server does not use acceleration atm.

Oh, and PIO mode is only working on pre-NV40 cards, so not on yours. Since DMA acc is the default setting (also without nvidia.settings in place) I don't see non-working PIO mode as a bug.

Bye!

Rudolf.

[rudolfc]

BTW It's not Philippe who reported the same problem but Jerome (hope I remember correctly this time!)

And: you are having the same problem which I can reproduce here. I'll look at it soon.

Bye! (Thanks for testing!)

Rudolf.

[rudolfc]

Update:

This bug is also the same one as #4321.

Bye!

Rudolf.

[tigerdog]

To be a little more clear: when I install Haiku from the live CD, then boot from HD, nvidia.settings is never written to /boot/home/config/settings/kernel/drivers . And with no file there, everything works fine with DVI port->DVI/VGA adapter->VGA cable to monitor. If I move vga cable to vga connector with nothing on the DVI, then I get no video. When I create nvidia.settings and add only the line "switchhead true", video is present but corrupted. When I add the line "dma_acc true" then it works. So maybe "dma_acc true" is NOT the default under certain conditions? Seems like that's the case here.

[rudolfc]

Hmm, OK. I never created such a file myself (just copied the original with all the entries searched for by the driver in place). The default is as I said if the file isn't present. Apparantly if the entry isn't found in an existing file then the wrong assumtion is made.

I'll have a look and will fix that I expect.

Thanks for the clarification!

Rudolf.

[rudolfc]

Hi there tigerdog,

I just modified the kernel driver to behave as expected concerning driversettings. If you upgrade to hrev33206 then you should find that for instance 'dma_acc true' is now the really always default setup.

Thanks again!

Rudolf.

[tigerdog]

Thanks Rudolf. Once I get to the point where I am once again building Haiku, I'll try this version. Alternately, if you want to send me a zipped copy of the latest one, I'll try it now.

[rudolfc]

Hi again,

Since hrev33255 the driver should behave normally: it should nolonger matter if you use the first or the secondary connector for VGA. This means 'switchhead true' is nolonger needed.

Tigerdog, can you test the current revision using the DVI<>VGA adapter and also try a boot with the monitor connected to the other VGA(only) output? Should be OK now.

If you don't have access to the driver I'll upload the current version here tomorrow. Please let me know..

Thanks!

Rudolf.

[tigerdog]

Yes, please upload the current version here. I am not able to build Haiku at the moment. BTW, I can now test on two machines. My "garage" computer uses Haiku on with a 7200GS card. It worked from first boot off the live, but the refresh rate was not correct (59.7Hz). I booted in "safe mode" and saved the VESA config. The nvidia driver set the correct 60Hz refresh rate on the next boot. Does this need its own bug?

[rudolfc]

nvidia driver 1.05 compiled with gcc2 (hrev33255)

[rudolfc]

Hi tigerdog,

I just uploaded the driver here. Please test it and let me know the results!

About that refreshrate: if that .3 error (0,5%) is the worst case scenario then I think we don't need a bug report for that currently.

The refreshrate programming inside the driver is a bit coarse since exact enough specs are not really known. I think you should test again with the new driver, and try other resolutions with different refreshrates. If you find more serious errors the bug report might be handy. Especially if the screen becomes instable. refreshrate errors above say 2-3% make me suspicious. :-)

Bye!

Rudolf.

[tigerdog]

Excellent work, Rudolf! I removed the vesa and nvidia configuration files, installed the new driver and came up with full 1920x1200 video on the first try, with flat panel on analog/vga connector. Perfect!

[tigerdog]

Tested in garage machine also, same process. deleted nvidia.settings and vesa settings, rebooted with new driver. Correct display and refresh were there immediately (is this info stored somewhere else? Desktop prefs?)

BTW, card in garage machine is FX5200, not 7200GS.

[rudolfc]

Hi there Tigerdog,

Thanks for testing. I am closing this bug then. :-)

The settings are only stored if you run the Screen prefs app and hit apply, then exit. app_server_settings will get created and a vesa file. If you don't run Screen prefs then app_server just asks the driver on every boot, and the driver will relay the info from the monitor attached. So we always have native mode this way.

Bye!

Rudolf.