195.36.08: Freeze on starting xorg with 8500GT

[bactrimel]

After upgrading from 190.53, startx freezes with a black screen. Keyboard doesn't respond although the machine is accessible through ssh.

Xorg.0.log.old is from last working configuration.

---

[bactrimel]

No luck with 195.36.15 either System freezes on xorg startup and is unresponsive even to ssh. So back to 190.53 it is...

Any suggestions would be greatly appreciated!

[cyberf0x]

Hello,

First of all get rid of useless options form xorg.conf. Try with a fresh config file without nvagp and so on, most of those are set properly by default. Try to check without all the twinview options etc. and hash out extensions section to enable composite by default.Second of all if you're using xorg>1.6 , just downgrade to anything <1.7 and use 180.60 driver with a patch that can be obtained on these forums and try again. The log is just useless because it's hanging and there is no information why, the last thing that's in the log is that the file is not readable. That's not your fault it's the devlopers fault for not introducing a proper debug for the driver. And don't expect any useful replies from developers also, believe me I've tried for over 2 years with a similar issue (win driver works, linux driver works only until 180.60 and xorg 1.6, maybe 1.7.1 but not 1.7.4 because of missing resvgashared, doesn't with anything higer than 185.xx). They have no idea what's wrong and the only option they can offer you is to check the hardware and/or replace it.
It works for some people but not everybody and anybody who's left with this issue , he/she has it on it'w own from now on, which is funny especially when you have a high end laptop and somebody tells you to replace the card .

best regards
cyberf0x

[bactrimel]

Thanks for the useful comments. I gave it a couple of tries using a bare-bones xorg.conf with and withoud explicitly enabling composite, but again no luck. I attach the bug reports for both configurations. If I'm reading the docs correctly, Centos 5.4 must be using xorg 1.1.1, which I guess is a pretty old version.

Could this problem, mentioned in another thread, be another manifestation of the same bug (since RHEL 5 uses practically the same binary packages)?

http://www.nvnews.net/vbulletin/showthread.php?t=149399

[AaronP]

For a problem like this where the system completely freezes, unfortunately it sometimes means that the kernel is unable to write error messages to the system log. You might be able to get better results if you remount the filesystem your logs are on with "mount -o remount,sync" before reproducing the problem. If that doesn't help, setting up a serial console or a netconsole to capture the log messages.

Please also start X with "startx -- -logverbose 6" to capture more information to the log file.

Does the freeze still occur if instead of starting X, you run "cat /dev/nvidia0"?

[bactrimel]

Thank you for the helpful reply.

I tried the remount,sync trick and I've actually managed to grab dmesg just before the ssh console died. cat /dev/nvidia0 seems to be causing the same error as startx, although without blanking the consoles. In both cases, nvidia-bug-report.sh was unable to give any output before ssh froze completely.

I hope this helps.

[bactrimel]

Please note the MSI stuff is just leftovers from experimenting with 190.53, the same freeze has been occuring with 195.36.* even before I've added the "options nvidia NVreg_EnableMSI=1" line in /etc/modprobe.conf.

Regards,

B

[AaronP]

Thank you, that's very helpful. I've forwarded your thread to the kernel experts.

[bactrimel]

Seems to be fixed in 256.35. Thanks!