Opened 10 years ago

Closed 10 years ago

#2948 closed bug (fixed)

No nVidia accelerated video on 7600GS analog output

Reported by: tigerdog Owned by: rudolfc
Priority: normal Milestone: R1
Component: Drivers/Graphics/nVidia Version: R1/pre-alpha1
Keywords: Cc: doug@…
Blocked By: Blocking:
Has a Patch: no Platform: x86

Description

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.

Attachments (9)

NV_Haiku_nv.10de_0392_050000.0.log (123.5 KB) - added by tigerdog 10 years ago.
nvidia driver log taken under Haiku
NV_Zeta_nv.10de_0392_050000.0.log (106.6 KB) - added by tigerdog 10 years ago.
log under Zeta with older version of driver Feb 2007
nvidiaProposeDisplayModeBuildFailure (3.2 KB) - added by tigerdog 10 years ago.
Console Output of Accelerant build failure
NV_log_diff (95.1 KB) - added by tigerdog 10 years ago.
Better comparison: diff of Zeta (rev .81) and Haiku (rev. .85) with screen resolution set to 1920x1200 on both.
nvidia.10de_0392_050000.0.log (90.5 KB) - added by tigerdog 10 years ago.
log file under R32645
nvidia.settings (196 bytes) - added by tigerdog 10 years ago.
nvida.settings file used to trigger logging
nvidia.10de_0392_050000.0.2.log (90.8 KB) - added by tigerdog 10 years ago.
log from rev 33054
nvidia.10de_0392_050000.0.3.log (90.7 KB) - added by tigerdog 10 years ago.
log with DVI->VGA adapter and switchhead false
nvidia_1.05_gcc2.zip (89.4 KB) - added by rudolfc 10 years ago.
nvidia driver 1.05 compiled with gcc2 (hrev33255)

Download all attachments as: .zip

Change History (48)

Changed 10 years ago by tigerdog

nvidia driver log taken under Haiku

Changed 10 years ago by tigerdog

log under Zeta with older version of driver Feb 2007

comment:1 Changed 10 years ago by anevilyak

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

comment:2 Changed 10 years ago by 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.

comment:3 Changed 10 years ago by anevilyak

Owner: changed from axeld to rudolfc

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

Changed 10 years ago by tigerdog

Console Output of Accelerant build failure

comment:4 Changed 10 years ago by tigerdog

Cc: doug@… added

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.

comment:5 Changed 10 years ago by tigerdog

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

Changed 10 years ago by tigerdog

Attachment: NV_log_diff added

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

comment:6 Changed 10 years ago by 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?

comment:7 Changed 10 years ago by 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!

comment:8 Changed 10 years ago by 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!

comment:9 Changed 10 years ago by 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?

comment:10 Changed 10 years ago by 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.

comment:11 Changed 10 years ago by 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.

comment:12 Changed 10 years ago by 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.

comment:13 Changed 10 years ago by rudolfc

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

All OK now?

Thanks!

Rudolf.

comment:14 Changed 10 years ago by 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.

Changed 10 years ago by tigerdog

log file under R32645

Changed 10 years ago by tigerdog

Attachment: nvidia.settings added

nvida.settings file used to trigger logging

comment:15 Changed 10 years ago by 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.

comment:16 Changed 10 years ago by 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.

comment:17 Changed 10 years ago by 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.

comment:18 Changed 10 years ago by 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.

comment:19 Changed 10 years ago by 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.

comment:20 Changed 10 years ago by 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.

comment:21 Changed 10 years ago by tigerdog

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

Changed 10 years ago by tigerdog

log from rev 33054

comment:22 Changed 10 years ago by 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?

comment:23 Changed 10 years ago by 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.

comment:24 Changed 10 years ago by 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.

Changed 10 years ago by tigerdog

log with DVI->VGA adapter and switchhead false

comment:25 Changed 10 years ago by tigerdog

Hi Rudolf,

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

Regards, Doug

comment:26 Changed 10 years ago by 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?

comment:27 Changed 10 years ago by 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.

comment:28 Changed 10 years ago by 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.

comment:29 Changed 10 years ago by rudolfc

Update:

This bug is also the same one as #4321.

Bye!

Rudolf.

comment:30 Changed 10 years ago by 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.

comment:31 Changed 10 years ago by 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.

comment:32 Changed 10 years ago by 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.

comment:33 Changed 10 years ago by 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.

comment:34 Changed 10 years ago by 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.

comment:35 Changed 10 years ago by 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?

Changed 10 years ago by rudolfc

Attachment: nvidia_1.05_gcc2.zip added

nvidia driver 1.05 compiled with gcc2 (hrev33255)

comment:36 Changed 10 years ago by 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.

comment:37 Changed 10 years ago by 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!

comment:38 Changed 10 years ago by 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.

comment:39 Changed 10 years ago by rudolfc

Resolution: fixed
Status: newclosed

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.

Note: See TracTickets for help on using tickets.