Black screen with GeForce 7900 GT

[luroh]

Revision 32630, gcc2.

The card is a PCI-e 7900 GT with 512 MB RAM, two DVI outputs and one S-Video, listdev says:

device Display controller (VGA compatible controller, VGA controller) [3|0|0]
  vendor 10de: nVidia Corporation
  device 0291: G71 [GeForce 7900 GT/GTO]

The card works with vesa but makes Haiku freeze when using the nvidia driver, showing a black screen after the bootsplash. I say that it's frozen because holding down Ctrl-Alt-Del does not reboot the system. The only thing I can do is press <F12> and typing 'reboot.

Attaching syslog from booting with vesa and nvidia log from booting with nvidia.settings file (logmask 0xffffffff).

[rudolfc]

Hi,

Please modify nvidia.settings this line: switchhead false

to read switchhead true,

and reboot. Does it work now?

Also: please set it back to: switchhead false

and connect your screen to the other connector using a VGA cable and a VGA-DVI converter. Does it work then?

I'd like to know the answer to both questions please..

Thanks!

Rudolf.

[luroh]

Hi Rudolf,

Sorry, tried all four possible combinations (false/true, output1/output2) but none of them made any difference. Yes, I'm using a DVI->VGA adapter and a VGA cable. My CRT monitor is VGA only, it has no DVI input.

[luroh]

Hi again,

It turns out that fiddling with the memory setting in nvidia.settings actually brings the card to life and prevents freezing, albeit with a distorted picture. 'memory 256', 'memory 128' and 'memory 64' all produce output. 'memory 512' produces the same black screen and freeze as before.
Picture of the distorted output attached (memory_256.jpg).

[luroh]

For what it's worth, setting 'block_acc true' produces the same distorted picture as in the 'memory 64/128/256' case above.

[rudolfc]

Hi,

Since today the memory setting is nolonger needed. That part of this problem is fixed now.

Bye!

Rudolf.

[luroh]

Revision 32862, gcc2, trunk.

Ah, progress, sweet progress. With 32862 and a default nvidia.settings file, the card doesn't freeze the machine any more. The picture is heavily distorted - perhaps more so than with the tweaked memory settings above - but it's a picture. :o)

Attaching picture and log file.

[rudolfc]

Hmm,

Can you use the Screen pref panel or otherwise create a vesa settings file holding your native resolution, and then do a reboot?

We might have a dup ticket: missing init in driver, vesa settings file needed to make it work....

Thanks for your quick response BTW!

Rudolf.

[luroh]

Hi,

A vesa settings file definitely made a difference, the picture now looks just like memory_256.jpg - the top is distorted but I can read most parts of the drop-down menu when clicking the deskbar.

[luroh]

Attaching log from booting with vesa settings file.

[luroh]

with vesa settings file

[rudolfc]

Nice! Could you also post a picture if possible?

Thanks!

Rudolf.

[luroh]

Certainly. Picture attached where I have done two things; inserted a USB stick and clicked the deskbar, just to illustrate a little bit more what it looks like - and it does look close! :o) (The text you see in the picture is actually sharp and fully readable, it's just my mobile phone camera that has difficulties focusing properly on the glass screen.)

[rudolfc]

Hi,

Well, that looks fully OK apart from a modeline issue. I'll look in the last log you uploaded to see if the app_server actually issues the native modeline or not..

I'll be back. Thanks for your help tonight!

Rudolf.

[luroh]

Ok, thanks a lot!

[rudolfc]

Hi again,

The app_server correctly sets the mode according to the 'native' modeline being 1280x1024@85Hz according to the driver.

Can you confirm your monitor's resfreshrate from the onscreen menu inside the monitor?

Can you also post the exact typenumber info of your screen? EDID only tells the brand and serial number. I'd like to have a look at it's manual/specs if I can find it.

A question: if you connect your monitor to another nvidia gfx cards on that system: would the native mode be OK? (in other words: do we have a modesetting problem with your screen or with your card?) Would you be able to do such a test?

Thanks for any additional info you might have..

Bye!

Rudolf.

[luroh]

Hi Rudolf,

Under Haiku, the monitor reports "64.1 kHz, 60 Hz, NN", it doesn't mention the resolution at all. Under Windows 2000, it reports "91.1kHz, 85 Hz, 1280x1024, PP".

Manufacturer: Samsung Model name: SyncMaster 957MB S Model code: PU19ISBBCQ/EDC

I have a server box with a fanless GeForce 6200 LE card, I'll see if I can get it running Haiku from a USB stick and revert with the results.

[luroh]

Sorry, didn't notice that the wiki format messed up the specs, so again, for clarity:

Manufacturer: Samsung
Model name: SyncMaster 957MB S
Model code: PU19ISBBCQ/EDC

In Haiku, I can actually read the screen prefs by moving some windows around and it reports 1280x1024, 85.4 Hz. Selecting any other refreshrate does not seem to affect the picture at all.

I'll get back to you with the GF6200LE results as soon as possible.

[luroh]

Ok, here we go. Interestingly, the GF6200LE booted straight into 1280x1024/85Hz on the first boot (nice job!), I didn't even have to create a vesa settings file. Attaching a screenshot (GF6200LE.png) of its screen prefs. The only thing that strikes me as slightly odd is the 17.3" size, as I believe it should be 19".

[luroh]

I think I found the correct manual, excerpt attached.

[rudolfc]

Hi again,

On the GF6200, is the display completely correct? Or do you still have the symptomps as on the other system? If you, on the GF6200, ask the monitor for it's settings via the onscreen display, what does it say? If you modify the refreshrate to for instance 60Hz with Screenprefs, does the display report 60Hz via the onscreen menu as well?

Thanks for the info so far!!

Rudolf.

[axeld]

The 17.3" is computed from the size the monitor reports - if it really is 36x27 cm, that is more or less correct (though I get 17.7" if I compute it manually).

[luroh]

Rudolf: the picture looks perfect from the server with the GF6200 card. I'll boot it up again to what the monitor reports when I get home from work and get back to you on that.

Axel: Ah, right, I can spot two sets of size values being reported in the nvidia log file, screen prefs seems to be displaying the diagonal size calculated from the smaller one. Anyway, no biggie.

[axeld]

The (in this case) smaller one is supposed to be the more accurate one. Just measure it yourself, this may either prove their EDID data wrong, or this screen just isn't 19" after all :-)

[rudolfc]

Hi there,

luroh, please also report the PP / NN information from the screen at the 6200 (this is the Hsync and Vsync polarity I expect, which might turn out to be of importance somehow.

Axel, there's a second size indication in the EDID which is a bit smaller, I take it Screen uses that one. The smaller one will be the diagonal visible part of the screen (outer pixels), while the bigger one might be the glass size visible. 19inch might be the total glass size (which is bigger than one can see as otherwise the crt would fall out of the housing).

Bye!

Rudolf.

[rudolfc]

BTW:

Personally I like to see the smallest diagonal size as it now probably is, as that should be the real picture size. a '19 inch' screen name is mostly (in the CRT days) a sales argument only and reflects the total glass size AFAIK.

Bye!

Rudolf.

[luroh]

Hi Rudolf,

With the GF6200LE computer running Haiku, monitor reports: "91.1 kHz, 85 Hz, 1280x1024, PP". In other words, same as when running Windows 2000.

My guess is that the GF7900GT is to blame here, partly because the monitor seems to work fine with the GF6200LE, and partly because changing the resolution or refresh rate with the GF7900GT does not influence the picture at all - the monitor goes black for a second and then comes back looking exactly the same as with the previous settings.

[luroh]

Correction: changing the resolution does affect the GF7900GT picture, objects on the screen get multiplied, the picture is unreadable and I have to wait a couple of seconds for the auto fallback to kick in. Changing the refresh rate does not seem to have any effect however.

[rudolfc]

Hmm, thanks!

From what you tell me now, I am getting an idea what's really wrong here. The CRTC and/or PLL programming fails on that card. In other words: a modeline issue, but inside the driver itself because programming fails. With the VESA settings file the modeline already in the card more resembles the modeline the driver tries to program, than is the case without the vesa settings file. That's why with VESA file the screen becomes more readable.

I am going to dig a bit into the xfree86 driver asap to see what I can find that I don't have in the driver yet.

Another possibility is that the CRTC and PLL are switched with the other head by the BIOS (via a new switch register I don't know about yet): so programming succeeds but affects the disabled head. Can you try to bootup with the setting: switchhead true (or something: see the nvidia.settings file) to see what happens then?

---

If you are wanting to test some more (just a sort of test I'd try to get a bit more info): you could try to remove the vesa settings file again: you can see you have the picture four times on your screen on a screenshot you uploaded. Try this: bootup and select your native mode with Screen, but in 8 bit color (takes 4 times less memory than 32bit color). Hit apply and exit screenprefs. wait a few seconds so we are sure the vesa file gets written to disk. Now delete the vesa file, but keep the app_server_settings in place.

Reboot. How does the resulting picture look? Can you upload a photo from this test?

Bye!

Rudolf.

[luroh]

Great news, you've nailed it, thanks! All I had to do was to connect to head #1. The monitor confirms ""91.1kHz, 85 Hz, 1280x1024, PP". I'll do a fresh build to confirm and will revert with a sum-up of any necessary steps for attaining a proper picture.

*bows to the master*

[luroh]

Revision 32909, gcc2, trunk.

Ok, with a fresh build with *no* vesa file and *no* nvidia.settings file, it turns out there is only a single requirement: connect to head number 1. Head number 2 is the one producing the distorted picture.

Rudolf, I suspect you fixed it already back in hrev32845, I should just have tried the other head, sorry for not thinking of that - any BG beer is on me!

[rudolfc]

Hi there,

I did locate something inside the linux driver though, that may be worth testing. I'll come up with a testversion of the driver maybe later on. After all, it should also work if you connect your screen to head2.

For now: can you please upload a new log from the correctly working driver where you have connected your screen to head 1? I'd like to know as much as I can about this..

Thanks!

Rudolf.

[luroh]

Full log attached from correctly working head 1.

[rudolfc]

Hi again,

I've just committed a modification to the driver, hrev32933. Can you test that driver for me, trying your screen for a boot on head1 and for a boot on head2?

I'd like to know if now both outputs do their jobs...

Thanks in advance!

Rudolf.

[luroh]

Revision 32933, gcc2, trunk.

Booted with head 1 - worked just as well as before, no problem as far as I can see. Shut the computer down, shifted to head 2, booted and got the distorted, multiplied picture I've mentioned before. Screenshot attached, please let me know if you need any logs.

Perhaps I should also mention another observed difference between the two heads - head 1 presents the boot splash in 1280x1024, while head 2 presents it in a lower resolution.

[rudolfc]

Hmm :-/

Please try this: bootup using head1. Now select the lower resolution used during boot on head2 (1024x768?). Hit apply.

Do you still have a correct image on head1?

OK, whatever the answer on the above question (please tell me though), leave it as it is, now shutdown, turn computer off, connect screen to head2, and bootup.

Do you now have a correct picture on head2?

OK, now use screen prefs to set 1280x1024. Picture the same error as always?

Thanks!!!

(suspecting PLL selection trouble, programming and CRTC programming probably OK. I'm testing over here while we speak..)

Rudolf.

[luroh]

Booted head1, lowered the resolution 1024x768/60Hz/32, pressed Apply, picture looked correct. Shut computer down, switched to head2 and booted - distorted picture appeared.

Built fresh and repeated the above test with 1024x768/60Hz/16. Distorted picture appeared for a second, then the monitor went black and so did its LED indicator which is normally lit (or flashing when no signal). System not hung, I could still reboot with Ctrl-Alt-Del, but switching back to head1 and rebooting did not bring the picture back.

[rudolfc]

Hi again,

Hmm, so that didn't go well either.

Anyhow, I think I got it fixed for good this time. Please checkout hrev32946. Can you now boot correctly on both heads, and set modes as you want to?

Man, I'm curious.. I have worked for hours and hours... (since I could reproduce the suspected PLL selection trouble and got a fix for that now!)

Bye!

Rudolf.

[luroh]

Revision 32946, gcc2, trunk.

I'm sorry, I can only guess at the huge amount of work that has gone into solving this issue, but I unfortunately have to tell you that it still doesn't work. I notice no difference compared to 32933 when trying the tip in comment:34

Still, I'm a very happy and grateful camper with a working head1. :o)

[rudolfc]

Hi again,

How about now (hrev32958)? Apparantly the previous commit was a fix for DVI only, but introduced analog problems over here (I found that out later on). Now that is fixed too and since you're on an analog connection this might help!

Please test both heads again..

Thanks for your time and efforts!

Rudolf.

[luroh]

Nope, just getting a black screen now after the bootsplash, no matter if I try to boot 1280x1024/32/85.4 or 1024x768/32/60.

[rudolfc]

The other head is still OK I hope?

Rudolf.

[luroh]

Clarification: by black screen, I mean no picture and monitor is indicating no signal (blinking LED). The system is not hung however, I can still Ctrl-Alt-Del.

Yes, head1 still works fine.

[rudolfc]

Hi again,

Thanks for sending over the card to me! I am now using it. All tests I did are 100% OK, apart from just one: the second connector doesn't get an analog signal if it's the only one connected. (dual DVI OK, single DVI on both outputs OK, single VGA on 1 OK, 2 turns screen off.)

A workaround is setting: "switchhead true" in nvidia settings. Results perfect picture via analog VGA on the second connector.

This is the same bug as #2948. I'll start working on it soon. Bug is: missing hardware register location of new second analog output switch. Resolution will probably be a workaround, I have an idea how to identify this situation and automatically switch to the other head then.

Bye!

Rudolf.

BTW: Those heatpipes work perfectly! The temperature is evenly distributed on both heatsinks. (first time I have such a card in my system :-)

[luroh]

Ah that's good news, thanks for the update and good luck!

[rudolfc]

Hi,

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.

I tested your card Luroh and it's working perfectly over here now.

Will you be on Begeistert indeed?

Bye!

Rudolf.

[luroh]

Awsome work Rudolf, thanks a lot! Yes, I'll be at Begeistert.