Bug 220197

So, what's happening?  Is it still hanging?

Do you have the yast log files for us and the output of dmesg?  We need some more debugging information.

Created attachment 104796 [details]
dmesg output from chroot

I'm not sure if it hangs or it's just incorrectly detected settings (which my monitor shouldn't be having). Screen is black. 

Yast logs: http://www.youmortals.com/suse/logs/yast2logs.tar

Not sure how to properly get the dmesg output, but I tried chrooting and running dmesg there (not sure if that's right). Attached, anyhow.

could you reproduce this by calling

   init 3
   sax2 -r

your report doesn't tell me if you were able to use the newly installed
system. With this question I assume you are running the current beta2
and you could login to the system calling the commands listed above

Thanks

Hi, 

Nope, I'm not running beta2 at the moment because of the above problem. Can't progress any further, even though I'm near the end of the installation. 

<Ctrl><Alt><Backspace> doesn't help, and I can't get to a console session with ctrl+alt+f1 either. 

I had a similar thing happen last night installing Beta2 on 32-bit Athlon XP 2400+

AsRock K7S8X r3.0 m/b + nVidia Geforce 6200 (rev a1) + Philips 107MB CRT

At the installation's hardware detection stage:

Hardware detection process started.

Graphical screen vanished, briefly revealing the text screen that has the YaST Starting message at the bottom (terminal 1?).

Screen went black, but no loss of video signal as the monitor stayed on.

Could not access any terminals with Ctrl-Alt-F1/F2/F3 etc. to log in, BUT when flipping to where the graphical screen should be (Ctrl-Alt-F7) the colour of the screen changed slightly to very dark grey (so it seemed flipping was working, just the screens were obscured).

After some time (20-30 secs) the floppy and hard disks chugged so the hardware detection was working but I could not see the display. I waited maybe two minutes.

Did a hard reset and the installer picked up from where it left off. At the hardware detection stage the graphical screen disappeared briefly as before but reappeared so I could continue the install (I had to enter a different normal user as the previous one was still existing but the install worked).

http://www.bouncingayatollah.co.uk/suse/SaX.log
http://www.bouncingayatollah.co.uk/suse/Xorg.0.log
http://www.bouncingayatollah.co.uk/suse/Xorg.0.log.old
http://www.bouncingayatollah.co.uk/suse/Xorg.99.log
http://www.bouncingayatollah.co.uk/suse/Xorg.99.log.old
http://www.bouncingayatollah.co.uk/suse/xorg.conf
http://www.bouncingayatollah.co.uk/suse/xorg.conf.install
http://www.bouncingayatollah.co.uk/suse/xorg.conf.saxsave
http://www.bouncingayatollah.co.uk/suse/y2logs.tgz

I figured I'd try specifying a completely new user, too (instead of specifying one already in my /home) and I noticed this time round that there is certainly some monitor output, as the gentleman above noted. If I raise my screen's brightness to near-max I can very faintly make out some of the graphics (very hard to make out, but just about can). Enough to just about complete the installation, and verify that even if X is killed, things remain precisely the same. 

I'm pretty sure this is not a configuration issue

I don't understand this. As long as you don't have a dualcard system, SaX2 does not do any graphics hardware probing automatically, so no second Xserver with native driver is started. Do you press the test button for the graphics configuration?

Nope, I don't get to. As soon as it shows a flash of the whole hardware configuration window loading up, things go out. 

Isn't this not an X (even sax?) issue though since even after killing the X-server (with rcxdm stop, which I eventually could do -- brightness adjusting, which helped very little) things stay just as blacked out as they are. 

Ok. I'll try to reproduce this issue with one of our 6200 cards.

Matthias will test.

Just tested an installation with SL10.2 Beta2+. The nv driver works out-of-the-box for my 6200:

VGA compatible controller: nVidia Corporation NV43 [GeForce 6200] (rev a2)
PCIId: 10de:014f
VideoBIOS: 05.43.02.27.ad


You might have to consider that your card is actually broken, but only exhibits this behavior with the newest X.org. The change from beta 1 to beta 2 was pretty large with respect to X. The card I have e.g. behaves completely normal, until you use OpenGL, when its display goes completely berserk. We finally came to the conclusion that this is broken hardware.

You should probably test the binary only driver from NVidia, though not being able to complete the installation in graphical mode is surly bad.


OTOH - the reporters all seem to have a (rev a1) card, while I only have a (rev a2) - maybe this is a hint?

Stefan, close as WORKSFORME, or add someone from NVidia?

Trying WORKSFORME.

Created attachment 105851 [details]
dark screen with full brightness, from a camera

> You might have to consider that your card is actually broken, but only exhibits
this behavior with the newest X.org.

Ok, I just tested a clean 10.1 install which I upgraded to 10.2. beta2 and the problem is not there. In which case it seems to deal fine with the card both (i) with the default free driver, and (ii) with the nvidia driver.

> The card I have e.g. behaves completely normal,
until you use OpenGL, when its display goes completely berserk. We finally came
to the conclusion that this is broken hardware.

Ok, but I use OpenGL on this card daily. 

So I did *another* fresh install to check this. This time with no extra configuration, not saving my old /home and I'm sorry but this problem is *definitely* there. I've attached a picture showing what it's like. As you can see, if I put my brightness to near-max, then some text does indeed become viewable. 

Since I can navigate around a bit now I hit "Test Configuration" and voila. Everything is detected just fine, and from here on everything works perfectly. Suffice it to say that's a pretty bad/tough workaround. 

Since I'm in I can now also provide any info you'd require.

In case it's any help I did notice the following oddities in the X org logs:

My monitor refresh rates are (from the PDF manual I just found):

 30-86  kHz horizontal
 50-160 Hz vertical

I notice in either Xorg.99 log (.log or .log.old) @ lines 412-413

 (II) NV(0): Monitor[0]: Using hsync range of 30.00-33.00 kHz
 (II) NV(0): Monitor[0]: Using vrefresh range of 43.00-72.00 Hz   <--- 43 ?

and from either Xorg.0 log @ lines 499-500

 (II) NV(0): Monitor[0]: Using hsync range of 30.00-86.00 kHz
 (II) NV(0): Monitor[0]: Using vrefresh range of 50.00-160.00 Hz  (OK)

but @ line 566

 (**) NV(0):  Default mode "928x696": 109.2 MHz, 86.4 kHz, 60.1 Hz (D)

So is it possible that with an unlucky/rare selection of mode the monitor  is being pushed JUST outside its range?

Problem still here in RC1. James, will you be testing it as well by any chance?

Well, yes, the problem still happens here in RC1.

As Francis suggested, if I max the brightness on my monitor after hardware detection and Test Configuration, sax2 chooses Screen[0] 1280x1024 @ 80KHz : 75Hz and the display comes back fine. Before that, the monitor reports 1280x1024, 64kHz, 60Hz, even when the display has darkened.

I also installed in 1024x768 with F3 from the initial CD menu (monitor reports 1024x768, 48kHZ, 60Hz) but the display still goes dark at hardware detection. Test Configuration fixes it as above.

Thankfully, after logging in everything is fine. Maybe this will disappear with Xorg7.2 if 10.2 ships with that?

>My monitor refresh rates are (from the PDF manual I just found):
>
> 30-86  kHz horizontal
> 50-160 Hz vertical
>
>I notice in either Xorg.99 log (.log or .log.old) @ lines 412-413
>
> (II) NV(0): Monitor[0]: Using hsync range of 30.00-33.00 kHz
> (II) NV(0): Monitor[0]: Using vrefresh range of 43.00-72.00 Hz   <--- 43 ?
These are default values, because the monitor could not be detected. I cannot see any mode selected with vrefresh < 50 Hz in the logfile. This is the default mode, which should be ok.

(--) NV(0): Virtual size is 640x480 (pitch 640)
(**) NV(0): *Driver mode "640x480": 25.2 MHz, 31.5 kHz, 60.0 Hz

> and from either Xorg.0 log @ lines 499-500
>
> (II) NV(0): Monitor[0]: Using hsync range of 30.00-86.00 kHz
> (II) NV(0): Monitor[0]: Using vrefresh range of 50.00-160.00 Hz  (OK)
>
> but @ line 566
>
> (**) NV(0):  Default mode "928x696": 109.2 MHz, 86.4 kHz, 60.1 Hz (D)
>
> So is it possible that with an unlucky/rare selection of mode the monitor 
> is being pushed JUST outside its range?

The default mode is the following, which is inside the monitor ranges.

(**) NV(0): *Driver mode "1280x1024": 135.0 MHz, 80.0 kHz, 75.0 Hz
(II) NV(0): Modeline "1280x1024"  135.00  1280 1296 1440 1688  1024 1025 1028 1066 +hsync +vsync

Marcus, what kind of graphics hardware/monitor probing is done, when YaST2 reaches the hardware configuration dialog? Does SaX2 start an Xserver for probing any values required for configuration. I wonder because it's a single head setup.

BTW, the problem can probably workaround by specifying

  acceleratedx=1

as boot option during installation. Then the nv driver is already used during installation instead of fbdev driver.

Marcus, see my comment #19.

Using acceleratedx=1 during initial install and more importantly after first reboot works. Thanks.

Using this option animated splash screens are 1280x1024 64kHz 60Hz, installation GUIs are 800x600 38kHz 60Hz. At hardware detection, the GUI disappears, the "Starting YAST" screen is revealed, there's a brief black screen then the 800x600 GUI reappears with everything correctly detected so I can continue.

Another small detail: if the dark screen issue occurs and Test Configuration is used - upon returning from Test a copy of the original (?) mouse pointer is left on screen as well as the active mouse pointer. The copy looks as if its number of colours has been reduced and it is frozen on the backdrop.

I can test the acceleratedx=1 during install as well, but only possibly tomorrow I'm afraid (out now). 

With regard to the mouse pointer being left on the screen in the corner -- I did experience that as well, but it disappeared as soon as KDE started up. 

I can confirm this behavior on my GeForce 7800GT.

beta1 - OK
beta2 - broken
RC1   - broken

During hardware detection, screen switches to vconsole 1, then switches back and the screen is very dark so I can barely see anything.
However, I managed to press the "Next" buttons and finally starting up the configured X Server somehow resets the graphics card and everything is ok.


haven't tried the acceleratedx=1 workaround

some hw info:

linux:~ # lspci
00:00.0 Memory controller: nVidia Corporation CK804 Memory Controller (rev a3)
00:01.0 ISA bridge: nVidia Corporation CK804 ISA Bridge (rev a3)
00:01.1 SMBus: nVidia Corporation CK804 SMBus (rev a2)
00:02.0 USB Controller: nVidia Corporation CK804 USB Controller (rev a2)
00:02.1 USB Controller: nVidia Corporation CK804 USB Controller (rev a3)
00:04.0 Multimedia audio controller: nVidia Corporation CK804 AC'97 Audio Controller (rev a2)
00:06.0 IDE interface: nVidia Corporation CK804 IDE (rev a2)
00:07.0 IDE interface: nVidia Corporation CK804 Serial ATA Controller (rev a3)
00:08.0 IDE interface: nVidia Corporation CK804 Serial ATA Controller (rev a3)
00:09.0 PCI bridge: nVidia Corporation CK804 PCI Bridge (rev a2)
00:0a.0 Bridge: nVidia Corporation CK804 Ethernet Controller (rev a3)
00:0b.0 PCI bridge: nVidia Corporation CK804 PCIE Bridge (rev a3)
00:0c.0 PCI bridge: nVidia Corporation CK804 PCIE Bridge (rev a3)
00:0d.0 PCI bridge: nVidia Corporation CK804 PCIE Bridge (rev a3)
00:0e.0 PCI bridge: nVidia Corporation CK804 PCIE Bridge (rev a3)
00:18.0 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] HyperTransport Technology Configuration
00:18.1 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Address Map
00:18.2 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] DRAM Controller
00:18.3 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Miscellaneous Control
01:00.0 VGA compatible controller: nVidia Corporation G70 [GeForce 7800 GT] (rev a1)
05:07.0 FireWire (IEEE 1394): Texas Instruments TSB43AB22/A IEEE-1394a-2000 Controller (PHY/Link)
05:08.0 Network controller: AVM Audiovisuelles MKTG & Computer System GmbH Fritz!PCI v2.0 ISDN (rev 02)
linux:~ # hwinfo --monitor
33: None 00.0: 10000 Monitor
  [Created at monitor.93]
  Unique ID: rdCR.uQVMa4Kpga2
  Hardware Class: monitor
  Model: "S/T 97P/96P"
  Vendor: STN
  Device: eisa 0x000c "S/T 97P/96P"
  Serial ID: "HVAT301299"
  Resolution: 720x400@70Hz
  Resolution: 720x400@88Hz
  Resolution: 640x480@60Hz
  Resolution: 640x480@67Hz
  Resolution: 640x480@72Hz
  Resolution: 640x480@75Hz
  Resolution: 800x600@56Hz
  Resolution: 800x600@60Hz
  Resolution: 800x600@72Hz
  Resolution: 800x600@75Hz
  Resolution: 832x624@75Hz
  Resolution: 1024x768@87Hz (interlaced)
  Resolution: 1024x768@60Hz
  Resolution: 1024x768@70Hz
  Resolution: 1024x768@75Hz
  Resolution: 1280x1024@75Hz
  Resolution: 640x480@60Hz
  Resolution: 640x480@85Hz
  Resolution: 800x600@85Hz
  Resolution: 1024x768@85Hz
  Size: 352x264 mm
  Detailed Timings:
     Resolution: 1280x1024
     Horizontal: 1280 1344 1504 1728 (+64 +224 +448) +hsync
       Vertical: 1024 1025 1028 1072 (+1 +4 +48) +vsync
    Frequencies: 157.50 MHz, 91.15 kHz, 85.02 Hz
  Driver Info #0:
    Max. Resolution: 1280x1024
    Vert. Sync Range: 50-160 Hz
    Hor. Sync Range: 30-96 kHz
    Bandwidth: 157 MHz
  Config Status: cfg=new, avail=yes, need=no, active=unknown

I can even reproduce this after installation:

1. configure xorg to use fbdev, for example:
# sax2 -r -a -m 0=fbdev

2. restart x server (ctrl-alt-backspace)
- now a copy of the mouse cursor stays on top of console AND X display
- display mode is 64.0khz, 60hz, PP (reported by monitor osd)

3. from konsole, let sax2 re-probe the hardware:
# sax2 -r

what happens:
- screen fb console appears
- screen goes garbled

further info:
* Calling sax2 without "-r", everythingok
* Calling "sax2 -r" from "nv" x-server, the virtual framebuffer console appears, then output gets garbled followed by switching back to the "nv" x-server which corrects the display
* Tried to make a screenshot but it looks ok.

=> Problem with fbdev driver?

*** Bug 223783 has been marked as a duplicate of this bug. ***

In reply to comment #19:

Stefan yes sax calls an X-server with -probeonly to detect the
amount of videoram. This happens in any case because people complained
about the wrong detected videoram. Unfortunately I see no other way
to get that value.

The value is used for some checks but not a "must have" value. It would
be a poor solution to remove this detection again just because the driver
is broken. But to avoid a blocker it would be possible with some effort
to remove the probeonly call

(In reply to comment #27)
> Stefan yes sax calls an X-server with -probeonly to detect the
> amount of videoram. This happens in any case because people complained
> about the wrong detected videoram. Unfortunately I see no other way
> to get that value.

I'm afraid there is simply no other way. :-(

> The value is used for some checks but not a "must have" value. It would
> be a poor solution to remove this detection again just because the driver
> is broken. But to avoid a blocker it would be possible with some effort
> to remove the probeonly call

Which kind of checks are this? Could you prepare a patch for removing this feature, so we can make a review? Probably some register values are not saved/restored when -probeonly is used. Fixing this - especially for the nv driver - would be very hard. Possibly only NVIDIA can do this. :-(

My proposal would be to disable the -probeonly feature for 10.2 and try to fix  the issue in the nv driver for 10.3.

BTW, I can reproduce this issue by calling "sax2 -r" on top of a fbdev Server with our GF 7300.

Ok. It's the "-probeonly" thing, which is broken. I verified this.

X (nv driver) without "-probeonly" restores the old settings.

Just for info:

I just tried to remove libddc.so, so no DDC probing is done - no effect.

This bug might be related to bug #160812.

Looks like this issue only occurs only on GF 7XXX GPUs. At least I can't reproduce it on a GF 6600 and Matthias couldn't reproduce it on a GF 6200.
Anyway, meanwhile 7XXX GPUs are very common ...

(In reply to comment #33)
> Looks like this issue only occurs only on GF 7XXX GPUs. At least I can't
> reproduce it on a GF 6600 and Matthias couldn't reproduce it on a GF 6200.
> Anyway, meanwhile 7XXX GPUs are very common ...
> 

mhh, two people here reported this on a Geforce 6200 (reporter and comment #5), so it maybe depends on the gfx card BIOS or something else.

Marcus disabled the "-probeonly" call for memory detection for now. Lowering severity therefore.

First results of investigating this issue by Egbert:
nv_setup.c:195 register 610 is changed but not restored ... but there are more issues. :-(

Created attachment 107179 [details]
xf86-video-nv-probeonly.diff

Egert fixed it! :-)

Hm - I think

  pNv->PRAMDAC0[0x0608/4] &= 0x0000EFFF;

could be nuked. Also, What do you think about register 0x0610? That one isn't saved at all...

That's what I mean with I wouldn't change this for the final RC. Though things could probably only get better, not worse :-]

Probably a question to Egbert.

As it turns out 0x610 doesn't need to be restored. Neither copy in the output == TRUE case. 
The line setting the top 17 bits to 0 could probably be removed. I did not print out the register values at the time - would be interesting to do this and to find out which bit really made the difference.

(In reply to comment #35)
> Marcus disabled the "-probeonly" call for memory detection for now. Lowering
> severity therefore.
Just gave RC3 installation a try - which includes this sax2 change - and it worked perfectly!

Just noticed that no one from NVidia is CC to this bug - this should be fixed in the driver.

Egbert has proposed a patch in attachment #107179 [details] that restores register 0x608 correctly.

Created attachment 107796 [details]
xf86-video-nv-bug220197.diff

Patch by NVIDIA (Aaron Plattner).

fixed for STABLE (openSUSE 10.3).

http://gitweb.freedesktop.org/?p=xorg/driver/xf86-video-nv.git;a=commitdiff;h=558ef7e26e361529a05360610abc3cbcdb04fd67

*** Bug 223516 has been marked as a duplicate of this bug. ***