RedHat 9 + 1.0-4363 + GeForce 3 Ti 500 = black screen

[Hemoglobin]

Please note that I am attaching verbose output of XFree86 log.

Here's my system configuration:

- video card = PNY GeForce 3 Ti 500
- driver version = 1.0-4363
- distribution = RedHat 9
- video bios revision = 03.20.00.19.08
- processor = 2 GHz Intel Pentium 4
- motherboard model = Intel D850MV

The subject heading basically speaks for itself, although I would like to point out that if I wait about 4 minutes, the X session will finally start, although OpenGL applications still won't work

Here's the output when I try to start Quake3:

...loading libGL.so.1: Initializing OpenGL display
...setting mode 9: 1600 1200
Error couldn't open the X display
...WARNING: could not set the given mode (9)
Initializing OpenGL display
...setting mode 3: 640 480
Error couldn't open the X display
...WARNING: could not set the given mode (3)
Received signal 11, exiting...

Although glxgears seems to run fine:

[root@varestsward2 bin]# ./glxgears
18925 frames in 5.0 seconds = 3785.000 FPS
21697 frames in 5.0 seconds = 4339.400 FPS
22048 frames in 5.0 seconds = 4409.600 FPS
21189 frames in 5.0 seconds = 4237.800 FPS

Miscellaneous info:

- Option "IgnoreDisplayDevices" "CRT" makes things worse (X session never starts no matter how long you wait)
- Option "NoBandWidthTest" "1" doesn't have any effect
- rerunning "ldconfig" made no difference
- all necessary symlinks and libraries appear to be in place

I hope you can help me here... I wasted the better part of a weekend trying to get this stuff working. I can send other log files if you need them.

[rajones47]

I am having the same problem. 4 minute X start time.
At first I thought it was a total hardware lockup, but this post inspired me to wait on it. I noticed that the load average goes up to around 6.3 (this can be seen with 'uptime' after X starts)

I have *exactly* same card. Even same video bios.
I'm running RH9 with the kernel update: 2.4.20-9

the last line of XFree86.0.log is peculiar... something I've never seen:
"AUDIT: Sun May 11 22:00:32 2003: 2283 X: client 4 rejected from local host"

This looks like something possibly network related. This could explain the timeout period waiting for X to come up.

system configuration/stats:
- video card = PNY GeForce 3 Ti 500
- driver version = 1.0-4363
- distribution = RedHat 9
- video bios revision = 03.20.00.19.08
- processor = AMD Athlon XP 1500+
- motherboard model = Abit KG7
- 512MB DDR

I have 7 of these machines that have been running fine on RedHat 7.3 with older NVidia RPM versions of the drivers for over a year now. Only the OS and driver upgrade has caused this problem.

I have attached "logverbose 5" XFree86.0.log

-rajones47

[Hemoglobin]

I had a similar message in my XFree86 log earlier in the day. Something like "client 5 rejected from local host." Not sure if this message is significant, but I think it coincided with my typing "telinit 3" to return to text mode.

[Gyokuran]

There could be several reasons.
1.The /home partition could be full
2.A program in .xinitrc fails
3.Something strange

[atlas]

Hemoglobin,

I had the same problem until I upgraded my glibc. See: http://www.nvnews.net/vbulletin/show...=rh9+quake+iii

I have a regular Geforce3

I get past the 'couldn't start X display' for Quake. Couple things to note:

On 4349, I can get to where it shows the first frame of particular level. Then it freezes.
On 4363, same thing happens, but my Intellimouse doesn't work at all anywhere in Quake now. Noticed this time, however, that at lower resolutions (800x600) than 1600x1200, levels are playable, but still no mouse.

-atlas

[atlas]

Oh, wait, I never had a 4 minute start-up, though. I applied the glibc fix for running quake.

HTH,

atlas

[alien999999999]

the both of you who posted a log file didn't seem to have specified metamodes, you should do so, and the first person never waited for the Xserver to be completely started up, as he should have done so, the log isn't complete, but as some people said: certain partitions that need temporary files could be full, you could benefit from updates from all sorts and networking could be blocking something making it have to wait on a time-out several times...

happy hunting