[arch-general] Nvidia Driver issues
First off I just would like to start off by saying please do not tell me to use nouveau. They do not work and have not worked for me on multiple distros for well over a year now. I also need cuda support on my laptop. I am currently running the xorg-nv driver.
I am at a complete loss as far as what is going wrong or what I am missing when trying to install the Nvidia proprietary driver. I have a Nvidia GeForce GTS 360m card. I am fully updated, just updated xorg to 1.14-1. I have been trying since installing which started me at xorg 1.11.
What is going wrong is that everything installs fine, but any time I try and shutdown/reboot it goes to a red screen and locks up there, no blinking indicators on the keyboard, so does not appear to be a Kernel panic but an xorg issue. If I do not get the red screen, what happens it the screen goes black and sits there with a blinking cursor. There is no way to change terminals either.
I have tried the nvidia nvidia-beta drivers and both have the same issue. Is this due to the nvidia and xorg 1.11 issues I keep reading about? What are my options to try and get this working properly? I have followed the wiki, postings on the bbs. I have tried basically everything I could find minus actually downgrading to xorg 1.10. Which from what I read is the only way to get the proprietary to work, but on arch forums and on here I read of many people with no issue with current X and nvidia closed source drivers, so I would think it must be me who is causing the issue.
Thanks for any help, info and most of all your time
Hi,
do you have any log files? Because helping you just by reading about the issues is quite hard. I haven't experienced anything similar to your description so far.
Am 29.01.2012 19:54, schrieb Don deJuan:
but on arch forums and on here I read of many people with no issue with current X and nvidia closed source drivers, so I would think it must be me who is causing the issue.
I'm currently also using the nvidia closed source drivers, although I'm switching between nouveau and the proprietary ones quite often.
Do you use any kind of framebuffer? I had to install uvesafb in order to get the closed source driver working properly, e.g. switching between consoles.
Best regards, Karol Babioch
On 01/29/2012 11:28 AM, Karol Babioch wrote:
Hi,
do you have any log files? Because helping you just by reading about the issues is quite hard. I haven't experienced anything similar to your description so far.
Sadly I can not find any logs that state anything relating to the issue I have. Nothing in Xorg logs, everything.log, nothing in Nvidia logs show there even was a hang/lock up. Its really bizarre
Is there a way I can start things to possibly log this?
Am 29.01.2012 19:54, schrieb Don deJuan:
but on arch forums and on here I read of many people with no issue with current X and nvidia closed source drivers, so I would think it must be me who is causing the issue.
I'm currently also using the nvidia closed source drivers, although I'm switching between nouveau and the proprietary ones quite often.
Do you use any kind of framebuffer? I had to install uvesafb in order to get the closed source driver working properly, e.g. switching between consoles.
Best regards, Karol Babioch
No I am not it is just how it installs from the driver install no changes other than running. nvidia-xconfig
Sorry for not being able to give better info, this is why I have tried so long to figure this out myself since there is not much to show whats happening, as I have things now. Hopefully there is some way to get whats happening into a log file of some kind.
On 01/29/2012 11:28 AM, Karol Babioch wrote:
Hi,
do you have any log files? Because helping you just by reading about the issues is quite hard. I haven't experienced anything similar to your description so far.
Am 29.01.2012 19:54, schrieb Don deJuan:
but on arch forums and on here I read of many people with no issue with current X and nvidia closed source drivers, so I would think it must be me who is causing the issue.
I'm currently also using the nvidia closed source drivers, although I'm switching between nouveau and the proprietary ones quite often.
Do you use any kind of framebuffer? I had to install uvesafb in order to get the closed source driver working properly, e.g. switching between consoles.
Best regards, Karol Babioch
Well still unable to dig up anything in any logs that seem relevant or useful. Everything relating to the reboots just say switching to run level 6. then the next message would be relating to the next boot after the hang.
But I have been able to get some smooth reboots (have not tried shutting down yet) by enabling pcie_aspm=force and issuing shutdown -rF 1 Doing reboots in this manner gives me about 60% percent success at this point.
I have also tried booting with no xorg.conf and had no noticeable change.
If anyone has any other tips/suggestions I am open to them. Thanks for your time.
On Sun, 29 Jan 2012 23:47:33 -0800 Don deJuan wrote:
If anyone has any other tips/suggestions I am open to them. Thanks for your time.
I know nothing about the binary blob on arch but download the more upto date blob from nvidia.com for my TVs running mythbuntu, MCE etc.. Are you installing via pacman and if so will the nvidia.com .run script tell you anything. It will certainly buld a module to match whatever kernel you have.
Hi,
Am 30.01.2012 13:33, schrieb Kevin Chadwick:
I know nothing about the binary blob on arch but download the more upto date blob from nvidia.com for my TVs running mythbuntu,
Well, Arch is a rolling release distro and it usually takes just hours to a few couple of days until the official releases hit the repositories ;).
Sure enough, the Arch package is up to date, so this shouldn't be a problem. As long as you don't run a custom kernel you don't have to worry about any kernel modules either.
Am 30.01.2012 08:47, schrieb Don deJuan:
If anyone has any other tips/suggestions I am open to them. Thanks for your time.
Obviously I don't know that much about the nvidia package myself, so unfortunately there isn't much I can tell you. When running into the already mentioned problems with the closed source driver, I was pointed to [1], which seems to be the official place to go when running into trouble.
Just another guess: Have you tried any other distro (or even Windows for that matter) in order to exclude any kind of hardware defect?
Best regards, Karol Babioch
On 01/30/2012 08:23 AM, Karol Babioch wrote:
Hi,
Am 30.01.2012 13:33, schrieb Kevin Chadwick:
I know nothing about the binary blob on arch but download the more upto date blob from nvidia.com for my TVs running mythbuntu,
Well, Arch is a rolling release distro and it usually takes just hours to a few couple of days until the official releases hit the repositories ;).
Sure enough, the Arch package is up to date, so this shouldn't be a problem. As long as you don't run a custom kernel you don't have to worry about any kernel modules either.
I am on the stock arch kernel. I verified my card is still supported by the main blob. I normally do download the blob directly and install it on other OS's but its the same version through pacman as on the site right now.
Am 30.01.2012 08:47, schrieb Don deJuan:
If anyone has any other tips/suggestions I am open to them. Thanks for your time.
Obviously I don't know that much about the nvidia package myself, so unfortunately there isn't much I can tell you. When running into the already mentioned problems with the closed source driver, I was pointed to [1], which seems to be the official place to go when running into trouble.
Just another guess: Have you tried any other distro (or even Windows for that matter) in order to exclude any kind of hardware defect?
Fedora15, Debian-Sid both run without the shutdown/reboot issue that I have on Arch, both I am using the exact same Nvidia blob. Windows also works fine as well.
Best regards, Karol Babioch
Thanks for the link, I will check it out and post there if this continues after more testing. Though I did gain some ground last night.
I re read the wiki again and went through each step then hit the issues section and found a part I either skipped before or thought was not relevant for some reason but adding in: options nvidia NVreg_Mobile=2 (since mine is a non-copal toshiba) removed xorg.conf did not boot with pcie_aspm=force those times also did not issue shutdown as shutdown -rF 1 I just did the standard 0 and worked.
It seems I am able to shutdown/reboot now. I tested it rebooting and shutting down 5 times before passing out for the night, and successfully did 4 out of 5.
What I am noticing now, is the red screen I was seeing flashes for a brief second then shutdown finishes. So my best (which probably is not that good) guess is that when nvidia goes to switch either from runlevel 5 to 6 or when nvidia is shutting down Xorg that is where I see that red screen flash. Something is not happy during that period. Generally its just wifi that is running when shutting down, though I have tried it with and without wifi running and had same issues.
Again thanks for both of you guys trying to help! I will test with my new settings for another day and if all seems good I will mark this as solved and put a link to the wiki page for reference.
On 01/30/2012 08:23 AM, Karol Babioch wrote:
Hi,
Am 30.01.2012 13:33, schrieb Kevin Chadwick:
I know nothing about the binary blob on arch but download the more upto date blob from nvidia.com for my TVs running mythbuntu,
Well, Arch is a rolling release distro and it usually takes just hours to a few couple of days until the official releases hit the repositories ;).
Sure enough, the Arch package is up to date, so this shouldn't be a problem. As long as you don't run a custom kernel you don't have to worry about any kernel modules either.
Am 30.01.2012 08:47, schrieb Don deJuan:
If anyone has any other tips/suggestions I am open to them. Thanks for your time.
Obviously I don't know that much about the nvidia package myself, so unfortunately there isn't much I can tell you. When running into the already mentioned problems with the closed source driver, I was pointed to [1], which seems to be the official place to go when running into trouble.
Just another guess: Have you tried any other distro (or even Windows for that matter) in order to exclude any kind of hardware defect?
Best regards, Karol Babioch
Well still nothing in the logs that even resemble any help for me which is becoming frustrating.
Though with further testing what I thought helped does not appear to have. I was able to shutdown/reboot about 10 times smoothly. Then after that each shutdown or reboot I tried went back to the old behavior of having the red screen.
I am back to having to use shutdown -hF 1 or longer wait to get it to smoothly shutdown or reboot.
Thanks again to those who have offered some insite so far, I will keep trying more things to see if I can track this down, or fingers crossed some miraculous update comes that automagically fixes me ;P
On Mon, Jan 30, 2012 at 02:19:05PM -0800, Don deJuan wrote:
Well still nothing in the logs that even resemble any help for me which is becoming frustrating.
Though with further testing what I thought helped does not appear to have. I was able to shutdown/reboot about 10 times smoothly. Then after that each shutdown or reboot I tried went back to the old behavior of having the red screen.
I am back to having to use shutdown -hF 1 or longer wait to get it to smoothly shutdown or reboot.
Thanks again to those who have offered some insite so far, I will keep trying more things to see if I can track this down, or fingers crossed some miraculous update comes that automagically fixes me ;P
Just an idea change some of the shutdown scripts, explicitly unload the nvidia blob etc and maybe include some kind of "milestone" debug information in the scripts in /etc/rc.*shutdown ... you might just by accident find the culprit and get things right with a while kill -0 loop or sleep.
cheers! mar77i
On 01/30/2012 04:23 PM, Martti Kühne wrote:
On Mon, Jan 30, 2012 at 02:19:05PM -0800, Don deJuan wrote:
Well still nothing in the logs that even resemble any help for me which is becoming frustrating.
Though with further testing what I thought helped does not appear to have. I was able to shutdown/reboot about 10 times smoothly. Then after that each shutdown or reboot I tried went back to the old behavior of having the red screen.
I am back to having to use shutdown -hF 1 or longer wait to get it to smoothly shutdown or reboot.
Thanks again to those who have offered some insite so far, I will keep trying more things to see if I can track this down, or fingers crossed some miraculous update comes that automagically fixes me ;P
Just an idea change some of the shutdown scripts, explicitly unload the nvidia blob etc and maybe include some kind of "milestone" debug information in the scripts in /etc/rc.*shutdown ... you might just by accident find the culprit and get things right with a while kill -0 loop or sleep.
cheers! mar77i
Thanks for more suggestions, I had nothing other than what is stock in the shutdown files. So i read through more things in relation to shutting down and openbox. I found someone in the arch forums having similar issues so I thought I would try it and it seems to be able to do everything in shutdown/reboot as I would expect. The weird thing is though when it executes it shows an error as not working properly when being called through shutdown/reboot but from normal command line it works as it should. I added
pgrep -P `pidof openbox` | xargs kill -s SIGTERM sleep 5
it throws an error in regards to pgrep, I believe but it goes by so quickly I can not read the whole thing.
So not really sure whats going on but even though it does not work 100% properly it gets passed locking up with a red screen or just with a cursor. If I can sort this out further I will post back the results and mark this solved.
Thanks again for the help I have gotten so far.
On Thu, Feb 02, 2012 at 07:08:34AM -0800, Don deJuan wrote:
pgrep -P `pidof openbox` | xargs kill -s SIGTERM sleep 5
it throws an error in regards to pgrep, I believe but it goes by so quickly I can not read the whole thing.
So not really sure whats going on but even though it does not work 100% properly it gets passed locking up with a red screen or just with a cursor. If I can sort this out further I will post back the results and mark this solved.
Thanks again for the help I have gotten so far.
Actually it should be unrelated because afaict you're executing this command from a terminal emulator which is a child process of the process tree you're attempting to kill, which leads to a self-reference, which the kernel should handle okay. So, it likely says "broken pipe" or something that way?
cheers! mar77i
On 02/04/2012 07:08 AM, Martti Kühne wrote:
On Thu, Feb 02, 2012 at 07:08:34AM -0800, Don deJuan wrote:
pgrep -P `pidof openbox` | xargs kill -s SIGTERM sleep 5
it throws an error in regards to pgrep, I believe but it goes by so quickly I can not read the whole thing.
So not really sure whats going on but even though it does not work 100% properly it gets passed locking up with a red screen or just with a cursor. If I can sort this out further I will post back the results and mark this solved.
Thanks again for the help I have gotten so far.
Actually it should be unrelated because afaict you're executing this command from a terminal emulator which is a child process of the process tree you're attempting to kill, which leads to a self-reference, which the kernel should handle okay. So, it likely says "broken pipe" or something that way?
cheers! mar77i
Yes was a broken pipe message.
Still trying to sort this out. I have come across something else that I am not sure about. If I run ck-list-sessions I get
Session1: unix-user = '1000' realname = '(null)' seat = 'Seat2' session-type = '' active = FALSE x11-display = ':0.0' x11-display-device = '' display-device = '' remote-host-name = '' is-local = TRUE on-since = '2012-02-06T23:31:15.440354Z' login-session-id = '1'
There is nothing being shown in display-device. From what I have seen on the message boards and other things through google most seem to show something in there. I am using slim, openbox and .xinitrc could this maybe be the cause? I have seen people mention with it empty means console-kit broke on boot, but I could be reading about that incorrectly.
Thanks everyone.
participants (4)
-
Don deJuan
-
Karol Babioch
-
Kevin Chadwick
-
Martti Kühne