Bugzilla – Bug 160812
Monitor remains blank after starting X
Last modified: 2007-03-15 21:56:53 UTC
KDS K770 @view monitor. Geforce 7300 Graphics card Intel Pentium D on D955XBK motherboard (955 chipset) Beta 8 installs just fine until the hardware config screen. When try to test graphics configuration the monitor just goes black and turns off after a moment (regardless of configuration). Ignoring this and continuing the install results in a black screen after starting X.
Could you attach /var/log/Xorg.0.log and /etc/X11/xorg.conf? Thanks.
Created attachment 75029 [details] Xorg log file
Created attachment 75030 [details] Xorg config file
This looks like a monitor configuration problem. Remove the ' UseModes "Modes[0]" ' line in /etc/X11/xorg.conf and attach /var/log/Xorg.0.log again. Is this a CRT or TFT monitor?
The monitor is a CRT.
Created attachment 75046 [details] Xorg log file
Ok. Looks like this didn't help. Could you try to add these lines to your Section Device and attach the according logfile? Option "FlatPanel" "off" Option "CrtcNumber" "0" And if this does not help these lines? Option "FlatPanel" "off" Option "CrtcNumber" "1"
Ted, could we get your feedback as soon as possible? Beta testing is nearly over now and I need to make the decision whether I need to configure this chip with fbdev driver. But I only want to do this when it's *not* a monitor detection issue.
Unfortunately we are now in the process of moving the machine into production on SUSE 10.0. I don't have a log file for the suggestions you gave above, however we did plug the machine into another monitor (LCD Acer Ferrari F-20) before we removed the 10.1 Beta 8 software. This monitor gave the same results as the KDS CRT we used earlier (went blank after boot) both for the DVI and VGA ports. Additionally, we have since installed SUSE 10.0. This has given us slightly different results upon completion of the installation. Although the 10.0 yast installation did not give us the opportunity to test various graphics configurations, upon first starting X, the monitor turned on and displayed the KDE desktop. However, the graphics were rendered in what I would describe as at best a 4 bit color palette (distorted though). Also the screen was displayed in such a manner that the image 'wrapped' around the monitor so that the far right hand side of the desktop actually appeared at the left hand side of the monitor. Lastly, we installed the proprietary nvidia driver and this has cleared the graphics problem away. To me this all points to a driver/graphics chip problem rather than a monitor detection problem. Also I should mention that the latest Live DVD Knoppix distribution has no apparent X quirks (appart from a default low refresh rate) straight from boot.
It's a really a pity that we can't investigate this any longer. Maybe we still can purchase one in time (60-80 EUR).
I'd like to see this fixed as well but do not consider this a blocker.
We talked about this, today and have decided that we can afford to not have the machine in production for a while longer. As such we will reinstall the Beta 8 software tomorrow. I realize that this doesn't give a great deal of time to do beta testing before the scheduled release of the release candidate but I hope it will be useful.
Thanks. Nevertheless it still makes sense for us to purchase such a card since it seems to be the new "cheap" nvidia card (maybe the successor of 6200).
As long as our card is not here yet ... it would be great to see any results for my questions in comment #7.
Created attachment 75866 [details] Xorg log file reflecting recomendations in comment #7 These recommendations did not change the result from starting X. Monitor eventually turned itself off.
Ted, is the logfile right above for ' Option "CrtcNumber" "0" ' or ' Option "CrtcNumber" "1" '? Could you also send the logfile for the other option value? Thanks.
Created attachment 75879 [details] Xorg log file with Crtcnumber "1" This log file is for the condition where Crtcnumber is equal to 1. (as per comment #7) The previous log file was for the condition where Crtcnumber was equal to 0. The monitor didn't turn off this time, however, the screen remained black.
Thanks for all testing so far. Unfortunately the conclusion for me is that we need to configure it with the "fbdev" driver for now. I expect that the next proprietary nvidia driver release will support it.
done. I'll leave it open with hig priority, so it won't get lost.
Was this change implemented before for the Beta 9 release or did it miss it?
The change is not in for Beta9 yet. I'll be in for RC1.
What can I do to test this? Is this a configurable in Xorg.conf, or is there more to it.
Use "sax2 -m 0=fbdev" to configure it. It's a very slow fallback and it isn't fun to use the desktop, I know ...
This has been an effective work-around. Obviously there is nothing in the way of hardware support (and I am unsure of how to alter the refresh rate), but it effective.
> I am unsure of how to alter the refresh rate You can't. It's 60 Hz. :-(
This should be tested again after switching to the latest nv driver (SUSE 10.2 Alpha). ==> LATER
JFYI, the new NVIDIA driver release does support your GPU now!
Update: Finally we managed to purchase such a card (7300GS by ASUS). No problems so far I can see with the nv driver in 1280x1024@24bpp. Tested on i386. I'll try on a x86_64 machine later.
Matthias will have a try on a x86_64 machine.
I get a black screen with the nv driver here, in both 32bit and 64bit modes. The binary only driver works fine. This is an Intel ICH7 chipset machine, maybe it depends on the PCIe bridge? Or on the BIOS? Andy, do you have any ideas?
Interesting. It did work on my 915G 32bit only machine (ICH6). See my comment #30.
I don't have any good ideas off hand. I would be surprised if there were something chipset-specific here. Matthias: can you please double check you were using the same software setup that Stefan was using in his testing? I guess I would start by identifying what is different between the two configs. Can you go back to Stefan's 915G system and reproduce the correct results there? If comparing the two configs doesn't help, please post a log and we can try to take a look. Thanks, - Andy
I have SL10.1, release, and YOU tells me there are no software updates available. I'll attach the logfile with -logverbose 255 (for the 32bit mode) and the used (stripped down) configuration. Note that we're using *exactly* the same graphics card (we only have one 7300). Note that the BIOS of the machine I'm using might be a bit - say - weired. So if the driver uses the BIOS for anything that might be the culprit on this machine. lspci output of my machine (black screen): 00:00.0 Host bridge: Intel Corporation 945G/GZ/P/PL Express Memory Controller Hub (rev 02) 00:01.0 PCI bridge: Intel Corporation 945G/GZ/P/PL Express PCI Express Root Port (rev 02) 00:1b.0 Audio device: Intel Corporation 82801G (ICH7 Family) High Definition Audio Controller (rev 01) 00:1c.0 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 1 (rev 01) 00:1c.1 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 2 (rev 01) 00:1c.2 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 3 (rev 01) 00:1c.3 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 4 (rev 01) 00:1c.4 PCI bridge: Intel Corporation 82801GR/GH/GHM (ICH7 Family) PCI Express Port 5 (rev 01) 00:1c.5 PCI bridge: Intel Corporation 82801GR/GH/GHM (ICH7 Family) PCI Express Port 6 (rev 01) 00:1d.0 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI #1 (rev 01) 00:1d.1 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI #2 (rev 01) 00:1d.2 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI #3 (rev 01) 00:1d.3 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI #4 (rev 01) 00:1d.7 USB Controller: Intel Corporation 82801G (ICH7 Family) USB2 EHCI Controller (rev 01) 00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev e1) 00:1f.0 ISA bridge: Intel Corporation 82801GH (ICH7DH) LPC Interface Bridge (rev 01) 00:1f.1 IDE interface: Intel Corporation 82801G (ICH7 Family) IDE Controller (rev 01) 00:1f.2 IDE interface: Intel Corporation 82801GB/GR/GH (ICH7 Family) Serial ATA Storage Controller IDE (rev 01) 00:1f.3 SMBus: Intel Corporation 82801G (ICH7 Family) SMBus Controller (rev 01) 01:00.0 VGA compatible controller: nVidia Corporation Unknown device 01df (rev a1) 02:00.0 Ethernet controller: Intel Corporation 82573E Gigabit Ethernet Controller (Copper) (rev 03) 02:00.2 IDE interface: Intel Corporation Unknown device 108d (rev 03) 02:00.3 Serial controller: Intel Corporation Intel(R) Active Management Technology - SOL (rev 03) 02:00.4 Class 0c07: Intel Corporation 82573E KCS (rev 03) 08:01.0 Ethernet controller: Digital Equipment Corporation DECchip 21140 [FasterNet] (rev 22)
Created attachment 85772 [details] Used stripped-down configuration file
Created attachment 85776 [details] X -logverbose 255
Since we're investigating this issue now, we can reopen it I think
Matthias: if you are suspicious of the SBIOS, does the nv driver work with other GPUs in the system? Does the nv driver work with this 7300 in other systems? It seems like you've tested in two different systems. If we had a third data point, that would help to suggest whether this is a problem specific to this combination of system+GPU+nv, or if it's a more general problem with this GPU+nv. Thanks.
lspci on the working 32bit 915G machine: # lspci 00:00.0 Host bridge: Intel Corporation 915G/P/GV/GL/PL/910GL Express Memory Controller Hub (rev 04) 00:01.0 PCI bridge: Intel Corporation 915G/P/GV/GL/PL/910GL Express PCI Express Root Port (rev 04) 00:1b.0 Audio device: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) High Definition Audio Controller (rev 03) 00:1c.0 PCI bridge: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) PCI Express Port 1 (rev 03) 00:1c.1 PCI bridge: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) PCI Express Port 2 (rev 03) 00:1c.2 PCI bridge: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) PCI Express Port 3 (rev 03) 00:1c.3 PCI bridge: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) PCI Express Port 4 (rev 03) 00:1d.0 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) USB UHCI #1 (rev 03) 00:1d.1 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) USB UHCI #2 (rev 03) 00:1d.2 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) USB UHCI #3 (rev 03) 00:1d.3 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) USB UHCI #4 (rev 03) 00:1d.7 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) USB2 EHCI Controller (rev 03) 00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev d3) 00:1f.0 ISA bridge: Intel Corporation 82801FB/FR (ICH6/ICH6R) LPC Interface Bridge (rev 03) 00:1f.1 IDE interface: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) IDE Controller (rev 03) 00:1f.2 IDE interface: Intel Corporation 82801FB/FW (ICH6/ICH6W) SATA Controller (rev 03) 00:1f.3 SMBus: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) SMBus Controller (rev 03) 01:00.0 VGA compatible controller: nVidia Corporation Unknown device 01df (rev a1) 04:00.0 Ethernet controller: Marvell Technology Group Ltd. 88E8050 PCI-E ASF Gigabit Ethernet Controller (rev 17) 06:02.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+ (rev 10) 06:03.0 FireWire (IEEE 1394): Texas Instruments TSB43AB23 IEEE-1394a-2000 Controller (PHY/Link)
Created attachment 85918 [details] X -verbose 255
I used the same config file as Matthias.
Ted, could you also add the output of "lspci", so we can compare the different chipsets?
(In reply to comment #39) > Matthias: if you are suspicious of the SBIOS, does the nv driver work with > other GPUs in the system? Does the nv driver work with this 7300 in other > systems? It seems like you've tested in two different systems. If we had a Stefan tested the same card, and it works for him. I tested this card both in 32bit and 64bit, and it fails in both cases. I just run a 6600GT, and it works out-of-the-box. Noteworthy is that in all cases no monitor DDC information was found, though in all cases it noted that a CRT monitor seems to be attached. As this case still works for the 6600GT, the driver appearantly does something different here. It also detects analog devices on both output A and B (compared to 7300 only on A), though only one monitor is attached. At first I thought this was due to me attaching the monitor by a bnc cable w/o DDC, but the chip doesn't detect DDC on a regular VGA cable either. > third data point, that would help to suggest whether this is a problem specific > to this combination of system+GPU+nv, or if it's a more general problem with > this GPU+nv. Sure. I assume it is nv+GPU+BIOS. That is, if you're using the BIOS for DDC in nv. If any more tests would help tracing narrowing this issue down, I'd be happy to help.
Other than making sure you test with the latest nv driver bits (Aaron reminded me that nv version 1.0.2.0 was the first to really support 7300), I'm not too sure what to suggest. Your observations about DDC might be interesting... does behavior change if you disable nv's use of DDC? Otherwise, I guess if you could capture X logs using the latest nv driver with the 7300 and the 6800GT, I could compare the logs to see if that yields any ideas.
00:00.0 Host bridge: Intel Corporation 955X Express Memory Controller Hub 00:01.0 PCI bridge: Intel Corporation 955X Express PCI Express Root Port 00:1b.0 Audio device: Intel Corporation 82801G (ICH7 Family) High Definition Audio Controller (rev 01) 00:1c.0 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 1 (rev 01) 00:1c.4 PCI bridge: Intel Corporation 82801GR/GH/GHM (ICH7 Family) PCI Express Port 5 (rev 01) 00:1c.5 PCI bridge: Intel Corporation 82801GR/GH/GHM (ICH7 Family) PCI Express Port 6 (rev 01) 00:1d.0 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI #1 (rev 01) 00:1d.1 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI #2 (rev 01) 00:1d.2 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI #3 (rev 01) 00:1d.3 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI #4 (rev 01) 00:1d.7 USB Controller: Intel Corporation 82801G (ICH7 Family) USB2 EHCI Controller (rev 01) 00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev e1) 00:1f.0 ISA bridge: Intel Corporation 82801GB/GR (ICH7 Family) LPC Interface Bridge (rev 01) 00:1f.1 IDE interface: Intel Corporation 82801G (ICH7 Family) IDE Controller (rev 01) 00:1f.2 IDE interface: Intel Corporation 82801GB/GR/GH (ICH7 Family) Serial ATA Storage Controller IDE (rev 01) 00:1f.3 SMBus: Intel Corporation 82801G (ICH7 Family) SMBus Controller (rev 01) 01:00.0 VGA compatible controller: nVidia Corporation Unknown device 01df (rev a1) 02:00.0 PCI bridge: Intel Corporation 80332 [Dobson] I/O processor (A-Segment Bridge) (rev 07) 02:00.2 PCI bridge: Intel Corporation 80332 [Dobson] I/O processor (B-Segment Bridge) (rev 07) 03:0e.0 RAID bus controller: Areca Technology Corp. ARC-1210 4-Port PCI-Express to SATA RAID Controller 06:00.0 Ethernet controller: Intel Corporation 82573V Gigabit Ethernet Controller (Copper) (rev 03) 07:00.0 Multimedia video controller: Internext Compression Inc iTVC15 MPEG-2 Encoder (rev 01) 07:04.0 FireWire (IEEE 1394): Texas Instruments TSB82AA2 IEEE-1394b Link Layer Controller (rev 01)
Thanks. This looks more and more like a chipset/host bridge specific problem: ICH6/915G: works ICH7/945G: does *not* work
Matthias, see questions by Andy in comment #45.
Date: Sat, 05 Aug 2006 19:19:24 +0200 From: MH <mhaag@telkomsa.net> To: sndirsch@suse.de Subject: Bug 160812 I apologize in advance if you find this annoying. I was trying to report a bug in OpenSUSE 10.1 and did a search to see if it had been reported. It had, and it showed status "INFO NEEDED", but I could find no way to submit any additional info. What I wanted to report is this: After installing OpenSUSE 10.1 (and SUSE 10.0 for that matter) the system boots to a BSOD (Black Screen of Death). Keyboard input is ignored, though the mouse pointer is responsive. Had to forcibly reboot the machine into "rescue" mode and edit inittab to boot to console. Once I booted into console, I recompiled and installed the NVIDIA driver and successfully booted into graphics mode. This happened with 3 different machines, two nearly identical AMD machines and an INTEL machine. I don't have the specs for the INTEL machine handy, but the AMD specs follow: Tyan Tomcat S2866 Nforce 4 SLI AMD X2 4400+ (AMD X2 3800+) 2GB OCZ CAS 2 DDR400 Adaptec 29160 SCSI Fujitsu 73GB SCSI 10,000 RPM Geforce 7800 GT (Geforce 7600 GS) SBLive! OpenSUSE 10.1 (SUSE 10.0) 2.6.16.13-4 SMP (32 and 64 bit)
Note on my personal workstation, I am using a GeForce 7800 GS (AGP card). This PC has a 865PE chipset running a Pentium 4 2.66 GHz CPU. The machine boots to a black screen after installation just like the 7300 card in my original bug report. However, looking at the screen carefully I can see a VERY dim desktop, so I believe the system is working, but is completely unusable. Using openSUSE 10.1 Available for testing.
Back to Matthias. :-)
Has anybody tested this on the upcoming 10.2 release? If so, what are the results?
Yes, by accident. On ICH7/945G GeForce 7300 still does not work with nv driver. :-(
In reply to comment #51) > Note on my personal workstation, I am using a GeForce 7800 GS (AGP card). > > This PC has a 865PE chipset running a Pentium 4 2.66 GHz CPU. > > The machine boots to a black screen after installation just like the 7300 card > in my original bug report. However, looking at the screen carefully I can see > a VERY dim desktop, so I believe the system is working, but is completely > unusable. Ted, you're probably hitting bug #220197. If this is the case, just restarting X after configuration should make it work ok (or: do "sax -r -a" and then start X). If it doesn't, these two bugs are probably actually the same, but occurring at different stages of the driver. It could be that the general signal level is too low, and monitors react differently to low sync signals. Andy, I'll do the tests on this i945 machine tomorrow.
Sorry for the big delay... I just verified with 10.2 rc2, the issue is still there. One thing that is noteworthy is that switching to a framebuffer console works perfectly. I'll attach log files with -logverbose 9 now. (In reply to comment #45) > Other than making sure you test with the latest nv driver bits (Aaron reminded > me that nv version 1.0.2.0 was the first to really support 7300), I'm not too > sure what to suggest. We're using X.org 7.2, the log files specifies module version 1.2. Hope that is recent enough, if it isn't, please tell me so. > Your observations about DDC might be interesting... does behavior change if you > disable nv's use of DDC? I removed libddc.so, no effect. Reinstalled it for this report. > Otherwise, I guess if you could capture X logs using the latest nv driver with > the 7300 and the 6800GT, I could compare the logs to see if that yields any > ideas. I can capture with this 7300 and a 6600 if that's ok.
Created attachment 107427 [details] Logfile -logverbose 9 of 7300 (black)
Created attachment 107428 [details] Logfile -logverbose 9 of 6600GT (working) Note that the only thing I changed between these two runs is the graphics hardware. I don't have the lightest clue why the module paths of the modules found are different. Note also that this is 64bit, but it shouldn't make a difference.
Created attachment 107430 [details] The used xorg.conf For consistency: the used configuration.
Any ideas, Andy? I'll try the fix from Egbert for bug #220197 - with not too much hope that it'll change anything here.
> -(II) Loading /usr/lib64/xorg/modules/input//mouse_drv.so > +(II) Loading /usr/lib64/xorg/modules//input/mouse_drv.so I don't understand this either, but it shouldn't matter. --- 6600 2006-11-29 17:18:04.000000000 +0100 +++ 7300 2006-11-29 17:17:56.000000000 +0100 @@ -544,8 +544,9 @@ compiled for 7.1.99.902, module version = 1.0.0 ABI class: X.Org Video Driver, version 1.0 (II) NV(0): Initializing int10 +(WW) NV(0): Bad V_BIOS checksum (II) NV(0): Primary V_BIOS segment is: 0xc000 -(--) NV(0): Chipset: "GeForce 7300 GS" +(--) NV(0): Chipset: "GeForce 6600 GT" (**) NV(0): Depth 24, (--) framebuffer bpp 32 (==) NV(0): RGB weight 888 (==) NV(0): Default visual is TrueColor @@ -574,7 +575,7 @@ (II) NV(0): Probing for analog device on output A... (--) NV(0): ...found one (II) NV(0): Probing for analog device on output B... -(--) NV(0): ...can't find one +(--) NV(0): ...found one (II) NV(0): Probing for EDID on I2C bus A... (II) NV(0): I2C device "DDC:ddc2" registered at address 0xA0. (II) NV(0): I2C device "DDC:ddc2" removed. Since the "found one/can't find one" is in NVIsConnected() it might be related to Egbert's fix, he did for the "-probeonly" issue (dark monitor). --> Bug #220197, comment #37.
No, it isn't. I just tried. I also tried to save 0x610 as well. Also, on both cards the driver detects: "CRTC 0 appears to have a CRT attached"
I have this problem too with a geforce 7900. Sax2 autodetects the correct settings but the screen just goes blank with the message "out of range". It doesn't matter which resolution, depth, refresh rate, screen, ratio etc. I choose, the result is always the same. I had to skip that step during install and use the proprietary driver instead.
From comment #47 I gather that the same card works on certain intel chipsets and doesn't on others. Please attach an lspci -v output from both systems. Note the '-v' option.
I'll do so.
Created attachment 109903 [details] i915G: works
Created attachment 109904 [details] i945G: does not work
(With regards to comments #66-69) Egbert, does this help?
Created attachment 111299 [details] Xorg.0.log.7300.i915.working Logfile -logverbose 9 of 7300 (working) on 915.
Created attachment 111300 [details] Xorg.0.log.diff Diff: --- Xorg.0.log.7300.i945.black +++ Xorg.0.log.7300.i915.working
Stefan, the non-working system uses a lib64 load path while the working one uses a lib load path. This suggests that the working system is 32 bit while the non-working system is 64 bit. IMHO we sould compare more comparable installations.
This is correct. I can install a 32bit system on the 945G machine.
Created attachment 111356 [details] Xorg.0.log.7300.i945.32bit.working Oh well. With a 32bit system the driver also works on a 945G machine.
Even better. I cannot reproduce this problem any longer with a 64bit system. I'll attach the logfile.
Created attachment 111362 [details] Xorg.0.log.7300.i945.64bit.working
Possibly the issue occured only on Matthias' 945 machine. He'll verify this.
Please obtain a log file from this machine. Did you generate the 'lspci -v' output on that box? If not, please get one also (please make sure the display is indeed blank).
> Possibly the issue occured only on Matthias' 945 machine. He'll verify this. > > Please obtain a log file from this machine. --> Matthias > > Did you generate the 'lspci -v' output on that box? If not, please get one > > also (please make sure the display is indeed blank). No, this was on the 945G machine, where the problem no longer occurs. :-( --> Matthias
It's getting even more complicated. I *could* reproduce on both 32bit and 64bit, but now it works on 32bit. I don't think I installed *anything* on the system. I'll attach log files etc. shortly.
Created attachment 112002 [details] Stripped down xorg conf used for following tests (same effect with original xorg.conf)
Created attachment 112003 [details] Xorg.0.log -logverbose 9 on gkar @SL10.2 64bit, no display output
Created attachment 112005 [details] Xorg.0.log -logverbose 9 on gkar @SL10.2 32bit, works
Created attachment 112007 [details] lspci -v on gkar @SL10.2 32bit
I finally found out when the Xserver doesn't display anything at all any more. It happens exactly (no matter weather 32 or 64bit) when a 1024x768 fb mode is set during boot (tried 0x317 (16bit) and 0x318 (24bit)). In this case both 1024x768 and 1280x1024 didn't produce any displayed image, and I assume other resolutions behave the same. If a 1280x1024 fb mode (0x31a) or a 800x600 fb mode (0x314) is used, both 1024x768 and 1280x1024 worked fine. Stefan, something for you to test with your i945 machine?
Strike! The same issue exists with a 7600GS.
The same issue on i915G (32bit only machine) with GF 7300. So this seems to be a general nv driver / fbdev issue. At least for GF 7xxx cards.
Lonni, could we open a bug in the NVIDIA bugtracking tool for this issue (*)? (*): Monitor gets no signal with nv driver when framebuffer resolution is set to 1024x768 (15/16bpp). It works with any other framebuffer resolution. The NVIDIA driver doesn't suffer from this problem.
Stefan, Is the framebuffer resolution being set with the vga= kernel parameter? If so, which value for vga= is needed to reproduce this problem? Also, is this specific to the GeForce 7300?
(In reply to comment #91) > Is the framebuffer resolution being set with the vga= kernel parameter? > If so, which value for vga= is needed to reproduce this problem? Yes, the "vga=" value is 0x317. > Also, is this specific to the GeForce 7300? At least it's specific to 7300 and 7600 GS. For me it looks like a general 7xxx issue.
Thanks, I've opened bug 280502
Thanks, Lonni! I'm assigning this one now to you, so you won't forget to add a comment once it's fixed in the nv driver. Hope that's ok.
Lonni, unfortunately I cannot address bug 280502 on the NVIDIA developer page: 0 records found I assume this is because no SUSE employee is CC'ed in the bug report. It's not strictly necessary, but it might help if additional information is needed.
Matthias, You should be able to view the bug now. thanks
I am :) Thanks a lot!
To: xorg-commit@lists.freedesktop.org Date: Thu, 15 Mar 2007 14:21:02 -0700 (PDT) From: Aaron Plattner <aplattner@kemper.freedesktop.org> Subject: xf86-video-nv: 2 commits - man/Makefile.am src/nv_hw.c src/nv_type.h man/Makefile.am | 4 ++-- src/nv_hw.c | 12 ++++++++++++ src/nv_type.h | 1 + 3 files changed, 15 insertions(+), 2 deletions(-) New commits: diff-tree 9d65abab153cdf3ab2b7e3e2843d573b22ea6769 (from 26a9f1fa5a92eba7d4b6ddfa47c0517e604be130) Author: Aaron Plattner <aplattner@nvidia.com> Date: Wed Mar 14 21:16:04 2007 -0700 Fix VGA output with vesafb on nv4x and G7x GPUs. SuSE bug #160812.
Patch added for STABLE/Factory. Check for the following entry in xorg-x11-driver-video RPM changelog: ------------------------------------------------------------------- Thu Mar 15 22:49:38 CET 2007 - sndirsch@suse.de - xf86-video-nv-vesafb-vga.diff: * Fix VGA output with vesafb on nv4x and G7x GPUs (Bug #160812)