37 replies to this topic

[taccoboss]

Today i tried 0 A.D alpha 2 on my desktop. The game starts and i can see the menu, but when i move the mouse the game crashes. I used Ubuntu 10.10 32bit and an Nvidia Quadro fx 4600 (driver 260.19.12). Here's the output:


maverick@maverick:~$ 0ad
TIMER| InitVfs: 59.1991 ms
TIMER| InitScripting: 1.70082 ms
TIMER| CONFIG_Init: 7.03646 ms
TIMER| write_sys_info: 1.82107 ms
TIMER| InitRenderer: 75.5288 ms
TIMER| ps_console: 4.13675 ms
TIMER| ps_lang_hotkeys: 4.41667 ms
TIMER| common/setup.xml: 2.993 ms
TIMER| common/styles.xml: 1.03582 ms
TIMER| common/sprite1.xml: 6.73469 ms
TIMER| common/init.xml: 3.79531 ms
TIMER| pregame/sprites.xml: 2.43587 ms
TIMER| pregame/styles.xml: 511.331 us
TIMER| pregame/mainmenu.xml: 22.3863 ms
TIMER| common/global.xml: 1.36218 ms
SND| alc_init: success, using PulseAudio Software
Segmentation fault

[Ykkrosh]

This seems to be a common problem with the NVIDIA drivers on Ubuntu 10.10 - I don't know if we can do anything about it ourselves.

[RandomUsername]

Same problem here and I do indeed have an Nvidia card with the proprietary drivers installed.

I get this in the syslog if it helps:

Oct 20 16:15:49 lucid-desktop kernel: [ 2839.480967] pyrogenesis[5052]: segfault at b77d2014 ip b773d4fe sp b2de9180 error 7 in libGL.so.260.19.06[b76c5000+9c000]

[Kasoroth]

I'm having this problem as well. The output to the terminal is the same as what taccoboss showed above.
I'm using Ubuntu 10.10 64 bit with proprietary nVidia drivers.
I downloaded the newest source code from SVN

I can get to the main menu, but it doesn't immediately crash when I move the mouse.

Moving the Mouse over the "Single Player", "MultiPlayer" or "Scenario Editor" options will sometimes (but not always) immediately cause a Segmentation fault. When it doesn't crash, the highlighting of the icon works correctly, and that particular icon will continue to work reliably at least until the next time I run the program.

Sometimes some of these icons will not crash on hover, but others will

The text popup in the upper right corner works correctly for all menu options (except when hovering causes a crash, obviously), but actually clicking on any menu option except the inactive ones (Campaigns, Options, History) will cause a crash. Even the "Quit" button will cause a Segmentation fault when I click it.

Trying to directly launch the editor with
./pyrogenesis -editor
will briefly show a window which immediately closes, and the terminal will have this output:
TIMER| LoadDLL: 75.04 ms
TIMER| InitVfs: 463.874 us
Segmentation fault

Has anyone successfully run this with nVidia drivers on Ubuntu 10.10, or is this problem universal with this configuration?

-Kasoroth

[Kasoroth]

Update:
After repeatedly restarting the program, I discovered that it occasionally doesn't crash, and woudl get to the menus for setting up a single player or multiplayer game. Changing various settings would sometimes cause a crash.

After many tries, I actually managed to get a single player game to start and load a map, but it crashed as soon as I clicked on a unit.

This is the terminal output for that session:
TIMER| InitVfs: 2.02582 ms
TIMER| InitScripting: 725.744 us
TIMER| CONFIG_Init: 1.86479 ms
TIMER| write_sys_info: 526.819 us
TIMER| InitRenderer: 51.7162 ms
TIMER| ps_console: 1.8139 ms
TIMER| ps_lang_hotkeys: 1.56407 ms
TIMER| common/setup.xml: 967.413 us
TIMER| common/styles.xml: 324.158 us
TIMER| common/sprite1.xml: 1.64207 ms
TIMER| common/init.xml: 3.57911 ms
TIMER| pregame/sprites.xml: 828.509 us
TIMER| pregame/styles.xml: 252.597 us
TIMER| pregame/mainmenu.xml: 10.6112 ms
TIMER| common/global.xml: 481.419 us
SND| alc_init: success, using PulseAudio Software
TIMER| common/setup.xml: 636.31 us
TIMER| common/styles.xml: 224.497 us
TIMER| common/sprite1.xml: 1.49897 ms
TIMER| gamesetup/setup.xml: 376.7 us
TIMER| gamesetup/sprites.xml: 94.653 us
TIMER| gamesetup/styles.xml: 104.506 us
TIMER| gamesetup/gamesetup.xml: 4.19012 ms
TIMER| common/setup.xml: 687.991 us
TIMER| common/styles.xml: 404.004 us
TIMER| common/sprite1.xml: 1.4571 ms
TIMER| common/init.xml: 1.72852 ms
TIMER| loading/loading.xml: 2.0164 ms
TIMER| common/global.xml: 376.017 us
TIMER| LoadDLL: 821.481 us
WARNING: FCollada warning 98: Unknown or missing polygonal material symbol in geometry.
TIMER| common/setup.xml: 536.967 us
TIMER| common/styles.xml: 324.326 us
TIMER| common/sprite1.xml: 1.60027 ms
TIMER| common/icon_sprites.xml: 8.73683 ms
TIMER| session_new/sprites.xml: 5.4623 ms
TIMER| session_new/styles.xml: 2.50863 ms
TIMER| session_new/session.xml: 48.944 ms
TIMER| common/global.xml: 956.054 us
GAME STARTED, ALL INIT COMPLETE
Segmentation fault



After a few more tries, I eventually was able to select and move a unit before it crashed.
I've also noticed that trying to select a "Gallic Solduros" crashes it much more frequently than selecting a "Bodu". Occasionally just hovering the mouse cursor over a Gallic Solduros will crash it. Sometimes it will survive selection but crash when attempting to move the unit.

It also seems that (like the main menu items) once a particular type of unit has been selected, that type of unit can be selected reliably at least until the next time the game is run. Likewise, once a particular type of unit has been moved, that type of unit can reliably be moved, but any attempt to select a different type of unit will immediately crash.

I've also noticed that the menus have gradually become more reliable after repeated use. I initially took me about 5 tries just to hover over the Single Player icon without crashing, another 10 or 15 before it didn't crash when I clicked it, and it took about 20 attempts to get past the "Match Setup" screen for the first time. Now I can get it to load all the way to a map about one out of three times. I haven't tried rebooting my system to see if this improved reliability persists after a shutdown.

I hope this information is helpful.

-Kasoroth

[fabio]

Kasoroth, on Oct 21 2010, 06:50 AM, said:

I've also noticed that the menus have gradually become more reliable after repeated use. I initially took me about 5 tries just to hover over the Single Player icon without crashing, another 10 or 15 before it didn't crash when I clicked it, and it took about 20 attempts to get past the "Match Setup" screen for the first time. Now I can get it to load all the way to a map about one out of three times. I haven't tried rebooting my system to see if this improved reliability persists after a shutdown.

This could be related to the texture compression which get executed only the first time the game is run. This is a specific problem of the Ubuntu package, see:
http://www.wildfireg...showtopic=13670

[meltingpoint]

I also have this problem (I have an nVidia 8400MG chip) and I noticed after changing my drivers from the proprietary ones (to version 173 I believe) the game did indeed load fine with no crashes.

The only problem with this was that the rest of my desktop was incredibly choppy, Compiz wasn't working properly and I couldn't watch any videos through VLC. So I changed back and the desktop is liquid smooth again, but 0AD still crashes all the bloody time.

Any input on a fix would be great, as changing the drivers to fix 0AD breaks everything else - which is no good to me.

[fabio]

You may want to create the ~/.config/0ad/config/local.cfg with the following content:

fancywater = false
shadows = false
renderpath = fixed
novbo = true
noframebufferobject = true

If it works then try deleting every line until you find out which line triggers the problem.

[Ykkrosh]

fabio, on Oct 21 2010, 08:03 AM, said:

Quote

I've also noticed that the menus have gradually become more reliable after repeated use. I initially took me about 5 tries just to hover over the Single Player icon without crashing, another 10 or 15 before it didn't crash when I clicked it, and it took about 20 attempts to get past the "Match Setup" screen for the first time. Now I can get it to load all the way to a map about one out of three times. I haven't tried rebooting my system to see if this improved reliability persists after a shutdown.

This could be related to the texture compression which get executed only the first time the game is run. This is a specific problem of the Ubuntu package, see:
http://www.wildfireg...showtopic=13670

Hrm, I hadn't thought of that. If that's the case, deleting ~/.cache/0ad/ should reset the game to its initial state (where it crashes immediately on startup). If so, the proper release packages shouldn't crash (since they don't do runtime texture conversion) but we still ought to understand and avoid the problem.

Texture compression shouldn't be system-dependent unless it's using CUDA acceleration via NVTT - see Compressor::Compressor() in libraries/nvtt/src/src/nvtt/Compressor.cpp for the detection. Can anyone tell if the game has compile-time and/or run-time CUDA support? (Apparently running the game in gdb typically causes it to work without crashing, so it may be tricky to reliably debug this.)

If that's the problem, can someone trying editing source/graphics/TextureConverter.cpp around line 517 (immediately after "nvtt::Compressor compressor;", before "compressor.process") and add the line "compressor.enableCudaAcceleration(false);" and see if that makes any difference?

[Kasoroth]

fabio, on Oct 21 2010, 05:16 AM, said:

You may want to create the ~/.config/0ad/config/local.cfg with the following content:

fancywater = false
shadows = false
renderpath = fixed
novbo = true
noframebufferobject = true

If it works then try deleting every line until you find out which line triggers the problem.

This didn't seem to fix the problem.

-Kasoroth

[Kasoroth]

Ykkrosh, on Oct 21 2010, 07:48 AM, said:

This could be related to the texture compression which get executed only the first time the game is run. This is a specific problem of the Ubuntu package, see:
http://www.wildfireg...showtopic=13670

Hrm, I hadn't thought of that. If that's the case, deleting ~/.cache/0ad/ should reset the game to its initial state (where it crashes immediately on startup). If so, the proper release packages shouldn't crash (since they don't do runtime texture conversion) but we still ought to understand and avoid the problem.

Texture compression shouldn't be system-dependent unless it's using CUDA acceleration via NVTT - see Compressor::Compressor() in libraries/nvtt/src/src/nvtt/Compressor.cpp for the detection. Can anyone tell if the game has compile-time and/or run-time CUDA support? (Apparently running the game in gdb typically causes it to work without crashing, so it may be tricky to reliably debug this.)

If that's the problem, can someone trying editing source/graphics/TextureConverter.cpp around line 517 (immediately after "nvtt::Compressor compressor;", before "compressor.process") and add the line "compressor.enableCudaAcceleration(false);" and see if that makes any difference?

I've rebuilt it with:

		// Perform the compression
		nvtt::Compressor compressor;
		compressor.enableCudaAcceleration(false);
		result->ret = compressor.process(request->inputOptions, request->compressionOptions, request->outputOptions);

The problem is still present.

I'll try getting the precompressed textures next to verify that that fixes the problem.

Thanks for the help.

-Kasoroth

[Kasoroth]

I've tried a fresh build using the data and source code from:
http://releases.wildfiregames.com/0ad-r084...nix-data.tar.gz
and
http://releases.wildfiregames.com/0ad-r084...ix-build.tar.gz

This has the same segmentation fault problem that I had with the version downloaded from svn.

I also experimented with unzipping the contents of public.zip into the mods/public folder and removing the zip file, but that did not seem to make a difference.

I've tried a CONFIG=Debug build with both sets of code and data, and that runs fine with no crashing in both cases.

-Kasoroth

Edited by Kasoroth, 22 October 2010 - 02:45 AM.

[Random-Dude]

Hey guys.

Hate to burst your bubble guys, but I think your all barking up the wrong tree here!

Firstly, I don't think that this bug is related or limited to any of the following things:

* Compresson
* Build type
* uBuntu
* configuration
* 0AD

Note, the last one said "0AD" That means that I don't think this is a 0AD bug at all, you see. I believe
this bug is not limited to 0AD, and can affect other applications as well.

If you take notice, you'll notice the issue is only affecting Nvidia users. and that these users are all using the 260.19.* drivers.

The error being (from mine):

pyrogenesis[4139]: segfault at 354ac0e8f1 ip 000000377709483f sp 00007fc56b1e8c60 error 7 in libGL.so.260.19.12[3777000000+b7000]

now, you were already aware of this, but read again.. take note it says " error 7 in libGL.so.260.19.12"

Notice it's not a 0-AD file? but rather a Nvidia Driver file? That is because this is a 260.19.* series regression. You will probably notice this also happens with the Alpha 1 of 0AD.

See here. You will find, just like I did, downgrading your nvidia drivers to 256.53 will fix this issue :-). At least, it did for me.

You can grab those here and here :-).

Hope this helps resolve the issue for you guys, it did for me (Fedora 12 x86_64) :-)

Edited by Random-Dude, 23 October 2010 - 02:25 AM.

[Ykkrosh]

Random-Dude, on Oct 23 2010, 03:23 AM, said:

Firstly, I don't think that this bug is related or limited to any of the following things:
[...]
* 0AD

It crashes when running 0 A.D., therefore it is definitely related at least to that extent . But I agree it's sounding like a driver bug we can't avoid (except by telling people to use other drivers), if it affects other games too (that's useful information), and other distros, and when definitely not using CUDA (so pretty much the only 'unusual' thing we're doing to potentially trigger the crash is putting some CPU load onto an unrelated thread).

Since we seem to have lots of Ubuntu users hitting this problem, is there a good way we can recommend to them to install older working drivers (presumably better using the proper package manager rather than manual installation)?

[Random-Dude]

Ykkrosh, on Oct 23 2010, 04:01 AM, said:

It crashes when running 0 A.D., therefore it is definitely related at least to that extent . But I agree it's sounding like a driver bug we can't avoid (except by telling people to use other drivers), if it affects other games too (that's useful information), and other distros, and when definitely not using CUDA (so pretty much the only 'unusual' thing we're doing to potentially trigger the crash is putting some CPU load onto an unrelated thread).

Since we seem to have lots of Ubuntu users hitting this problem, is there a good way we can recommend to them to install older working drivers (presumably better using the proper package manager rather than manual installation)?

Hmm downgrading drivers via apt(?) on ubuntu, I'm not entirely sure, as I have rarely used ubuntu (LiveCD at most). In Fedora world, it could be recommended to do "yum downgrade [packagehere]" I think apt may be able to do this also...

Eh a quick google search led me to this which could potentially work. However I cannot confirm, or deny that as I currently have no ubuntu box to test it with :-(.

However since then ubuntu may have got a apt-get downgrade or something, I don't know.

..........

or better yet, they may be able to simply uninstall them, then re-install them, by grabbing packages directly from here and here?

PS:
I also wrote "or limited to" in previous post in a sense, the bug is not just limited to 0AD does/could affect others.

[freedom2]

Random-Dude, on Oct 22 2010, 10:33 PM, said:

Hmm downgrading drivers via apt(?) on ubuntu, I'm not entirely sure, as I have rarely used ubuntu (LiveCD at most). In Fedora world, it could be recommended to do "yum downgrade [packagehere]" I think apt may be able to do this also...

Eh a quick google search led me to this which could potentially work. However I cannot confirm, or deny that as I currently have no ubuntu box to test it with :-(.

However since then ubuntu may have got a apt-get downgrade or something, I don't know.

..........

or better yet, they may be able to simply uninstall them, then re-install them, by grabbing packages directly from here and here?

PS:
I also wrote "or limited to" in previous post in a sense, the bug is not just limited to 0AD does/could affect others.

Hello, newbie here,

As an ubuntu user, I looked but did not find easy way to downgrade my nvidia drivers without having to go to rescue mode . Also as an nvidia + ubuntu user for the past 3.5 years, I'm really hesitant to modify my hard-earned stability and features that the current nvidia build affords. I really like my system that does almost everything that I need it to, except unfortunately play 0A.D..

Hmm, maybe time to invest in that spare pc for a new fedora box .....

Continuing best wishes on this project,

f

[Random-Dude]

freedom2, on Oct 24 2010, 04:11 AM, said:

Hello, newbie here,

As an ubuntu user, I looked but did not find easy way to downgrade my nvidia drivers without having to go to rescue mode . Also as an nvidia + ubuntu user for the past 3.5 years, I'm really hesitant to modify my hard-earned stability and features that the current nvidia build affords. I really like my system that does almost everything that I need it to, except unfortunately play 0A.D..

Hmm, maybe time to invest in that spare pc for a new fedora box .....

Continuing best wishes on this project,

f

I see. I install drivers manually usually (like my Nvidia, it's installed via the .run) So I tend to "forget" that people like to use their package managers for Nvidia Drivers.

However, your issue, of needing to go into rescue mode merely to install/update/downgrade a Nvidia driver seems a bit strange.

And I don't personally think you should invest in a box with fedora, merely due to a driver bug (as this bug is from what I can tell, multi-distro.)

In Fedora world, I tend to bump into quite a few things, which are supposedly "uBuntu only" which is kinda annoying. But I wouldn't switch to uBuntu because of it instead I would attempt to force it to work, as such I wouldn't expect anyone here to go about switching to Fedora just because of this bug.

So, what I've done is grabbed a copy of uBuntu and installed it in a virtual machine so I can see what it can and can't do, I've partially written a small bash script, which, with a bit more work, should allow easy downgrade of the Nvidia drivers :-). It's not done yet, and haven't tested it yet. When it's done I'll throw it up here :-) I don't yet know if it'll work or not yet, or even pass testing, so don't get your hopes up :-)

I was bored, so I thought "Why not sort this issue out?" :-)

PS: Yes I know Nvidia drivers do not work in a virtual machine (Virtualbox) however, as long as I don't reboot, it won't try to use them. Which is the plan, it would allow me to play around with the package manager enough to get the basic testing done :-)

- Jake

[Random-Dude]

Ok folks. So I done some basic testing, and made a small 3/4 poorly counted line script, which from what I can tell, successfully, downgrades the Nvidia drivers. However I cannot reboot my virtual machine to check to see if they actually work after. However I'm assuming they do.

This is an "early days" script, so use at your own risk. If you get any problems, let me know. I will try to fix them. Worse case scenario if the driver downgrade fails the scripts "reverse mode" should fix it. This will simply re-upgrade them using apt-get upgrade. (or you could do it your self using apt-get upgrade)

Their is also a purposely left commented out section in the i386 section, which has a apt-get remove which could be used to remove all parts of Nvidia, and then you could re-install them if it goes @#$% up :-)

Though I do recommend not using this script on an important system until someone who can reboot their machine after the update/downgrade has said whether or not it boots back up properly :-)

Run script with "help" at end to get a list of options.

To use essentially do this:

'/media/shared/script1.sh' 260.19.06-i386 all noclean

or

'/media/shared/script1.sh' 260.19.06-x86_64 all noclean

"all" and "noclean" are not required.

This script should work for both i386, and x86_64, however is untested on x86_64. But I don't see why it shouldn't work.

Now, onto the script:

Create a nvdowngrader.sh file with the following contents:

#!/bin/bash
# This small script (v0.4) will help users downgrade their Nvidia drivers.
# This is intended to downgrade the 260.19.06 drivers. No Later no earlier.

# 260.19.12 is currently unsupported due to apparently uBuntu does not publish
# these, so for now, the support is not required. If it becomes required it should
# be easy to update/add.

# Great now that is set up we can move on.
# Different versions of ubuntu may provide different drivers.
# So we simply ask the user which driver they currently have.
if [ "$1" == "260.19.06-x86_64" ]
	then
		# We need to grab the packages
		echo "Changing directory to /tmp/nvidiadrivers/"				
		mkdir /tmp/nvidiadrivers		
		cd /tmp/nvidiadrivers
		echo "Downloading 256.53 x86_64 Deb packages..."
		wget https://launchpad.net/ubuntu/+source/nvidia-graphics-drivers/256.53-0ubuntu3/+build/1973339/+files/nvidia-185-kernel-source_256.53-0ubuntu3_amd64.deb
		wget https://launchpad.net/ubuntu/+source/nvidia-graphics-drivers/256.53-0ubuntu3/+build/1973339/+files/nvidia-185-libvdpau_256.53-0ubuntu3_amd64.deb
		wget https://launchpad.net/ubuntu/+source/nvidia-graphics-drivers/256.53-0ubuntu3/+build/1973339/+files/nvidia-185-libvdpau-dev_256.53-0ubuntu3_amd64.deb
		wget https://launchpad.net/ubuntu/+source/nvidia-graphics-drivers/256.53-0ubuntu3/+build/1973339/+files/nvidia-185-modaliases_256.53-0ubuntu3_amd64.deb
		wget https://launchpad.net/ubuntu/+source/nvidia-graphics-drivers/256.53-0ubuntu3/+build/1973339/+files/nvidia-current_256.53-0ubuntu3_amd64.deb
		wget https://launchpad.net/ubuntu/+source/nvidia-graphics-drivers/256.53-0ubuntu3/+build/1973339/+files/nvidia-current-dev_256.53-0ubuntu3_amd64.deb
		wget https://launchpad.net/ubuntu/+source/nvidia-graphics-drivers/256.53-0ubuntu3/+build/1973339/+files/nvidia-current-modaliases_256.53-0ubuntu3_amd64.deb
		wget https://launchpad.net/ubuntu/+source/nvidia-graphics-drivers/256.53-0ubuntu3/+build/1973339/+files/nvidia-glx-185_256.53-0ubuntu3_amd64.deb
		wget https://launchpad.net/ubuntu/+source/nvidia-graphics-drivers/256.53-0ubuntu3/+build/1973339/+files/nvidia-glx-185-dev_256.53-0ubuntu3_amd64.deb
		echo "Package download complete."
		# Phew! Glad the wgets are over!
		# then we need to downgrade the old ones:
			
		echo "Downgrading Packages..."
		dpkg --install nvidia-glx-185_256.53-0ubuntu3_amd64.deb
		dpkg --install nvidia-current-modaliases_256.53-0ubuntu3_amd64.deb
		dpkg --install nvidia-185-modaliases_256.53-0ubuntu3_amd64.deb
		if [ "$2" == "all" ]
			then
				dpkg --install nvidia-glx-185-dev_256.53-0ubuntu3_amd64.deb
				dpkg --install nvidia-185-libvdpau_256.53-0ubuntu3_amd64.deb
				dpkg --install nvidia-185-libvdpau-dev_256.53-0ubuntu3_amd64.deb
		fi
		dpkg --install nvidia-current_256.53-0ubuntu3_amd64.deb 
		if [ "$2" == "all" ]
			then
				dpkg --install nvidia-current-dev_256.53-0ubuntu3_amd64.deb
		fi
		# And now clean up!
		if [ "$2" == "noclean" ] || [ "$3" == "noclean" ]
			then
				echo "Not Cleaning!"
		else
			echo "Cleaning temporary files we created (disable with noclean)..."
			rm -rfv /tmp/nvidiadrivers*
		fi		
elif [ "$1" == "260.19.06-i386" ]
	then
		# We need to grab the packages
		echo "Changing directory to /tmp/nvidiadrivers/"				
		mkdir /tmp/nvidiadrivers		
		cd /tmp/nvidiadrivers
		echo "Downloading 256.53 i386 Deb packages..."
		wget https://launchpad.net/ubuntu/+source/nvidia-graphics-drivers/256.53-0ubuntu3/+build/1973340/+files/nvidia-185-kernel-source_256.53-0ubuntu3_i386.deb
		wget https://launchpad.net/ubuntu/+source/nvidia-graphics-drivers/256.53-0ubuntu3/+build/1973340/+files/nvidia-185-libvdpau_256.53-0ubuntu3_i386.deb
		wget https://launchpad.net/ubuntu/+source/nvidia-graphics-drivers/256.53-0ubuntu3/+build/1973340/+files/nvidia-185-libvdpau-dev_256.53-0ubuntu3_i386.deb
		wget https://launchpad.net/ubuntu/+source/nvidia-graphics-drivers/256.53-0ubuntu3/+build/1973340/+files/nvidia-185-modaliases_256.53-0ubuntu3_i386.deb
		wget https://launchpad.net/ubuntu/+source/nvidia-graphics-drivers/256.53-0ubuntu3/+build/1973340/+files/nvidia-current_256.53-0ubuntu3_i386.deb
		wget https://launchpad.net/ubuntu/+source/nvidia-graphics-drivers/256.53-0ubuntu3/+build/1973340/+files/nvidia-current-dev_256.53-0ubuntu3_i386.deb
		wget https://launchpad.net/ubuntu/+source/nvidia-graphics-drivers/256.53-0ubuntu3/+build/1973340/+files/nvidia-current-modaliases_256.53-0ubuntu3_i386.deb
		wget https://launchpad.net/ubuntu/+source/nvidia-graphics-drivers/256.53-0ubuntu3/+build/1973340/+files/nvidia-glx-185_256.53-0ubuntu3_i386.deb
		wget https://launchpad.net/ubuntu/+source/nvidia-graphics-drivers/256.53-0ubuntu3/+build/1973340/+files/nvidia-glx-185-dev_256.53-0ubuntu3_i386.deb
		echo "Package download complete."
		# Phew! Glad the wgets are over!
		# then we need to downgrade the old ones:
		echo "Downgrading Packages..."
		dpkg --install nvidia-glx-185_256.53-0ubuntu3_i386.deb
		dpkg --install nvidia-current-modaliases_256.53-0ubuntu3_i386.deb
		dpkg --install nvidia-185-modaliases_256.53-0ubuntu3_i386.deb
		if [ "$2" == "all" ]
			then
				dpkg --install nvidia-glx-185-dev_256.53-0ubuntu3_i386.deb
				dpkg --install nvidia-185-libvdpau_256.53-0ubuntu3_i386.deb
				dpkg --install nvidia-185-libvdpau-dev_256.53-0ubuntu3_i386.deb
		fi
		dpkg --install nvidia-current_256.53-0ubuntu3_i386.deb 
		if [ "$2" == "all" ]
			then
				dpkg --install nvidia-current-dev_256.53-0ubuntu3_i386.deb
		fi
		# And now clean up!
		if [ "$2" == "noclean" ] || [ "$3" == "noclean" ]
			then
				echo "Not Cleaning!"
		else
			echo "Cleaning temporary files we created (disable with noclean)..."
			rm -rfv /tmp/nvidiadrivers*
		fi
elif [ "$1" == "reverse" ]
	then
		# We merely tell apt to re-update the drivers to where they was :-D.
		# of course, a user could do this part them selves easily.
		# It would be bad to make a script without a undo process. 
		echo "I am now, undoing what I had done before."
		if [ "$2" == "all" ]
			then
				apt-get upgrade
		else
				apt-get upgrade nvidia-current nvidia-current-modaliases nvidia-glx nvidia-185-libvdpau
		fi
elif [ "$1" == "removenvidia" ]
	then
		# We remove all nvidia. Warning. This is potentially dangerous.
		# I added this so that, a comment could be removed, and the command however preserved. 
		apt-get remove nvidia-185-kernel-source nvidia-185-libvdpau nvidia-185-libvdpau nvidia-185-modaliases nvidia-current nvidia-current-dev nvidia-current-modaliases nvidia-glx nvidia-glx
elif [ "$1" == "inserttrojan" ]
	then
		# This is a joke, their is no real trojan, don't worry. I just got bored while waiting for
		# uBuntu to finish downloading/installing :| This does not edit any files, or do any modifications! :-)
		echo "Opening /etc/passwd"
		echo "Decrypting"
		echo "Password Found"
		echo "Sending Password to the Doc"
		echo "Editing initrd.."
		echo "Rebuilding initrd.."
		echo "Success!"
		echo "Incoming Message:"
		echo "I am The Evil Doctor Porkchop, and I have inserted a trojan! Muhahahaha"
		echo "Message event closed."
		echo "Exiting"
elif [ "$1" == "help" ]
	then
		echo "Usage: ./nvdowngrader.sh [driverversion] [OPTION2] [OPTION3]"
		echo "The Nvidia downgrader will downgrade your Nvidia drivers. Use with caution."
		echo ""
		echo "Options:"
		echo "	 help			Where are you now?;)"
		echo "	 noclean		 This option will tell the script to not do any cleaning."
		echo "	 all			 This will install *all* downloaded Nvidia packages."
		echo "	 reverse		 Puts program into reverse gear, and upgrades the packages."
		echo "	 removenvidia	Removes all installed Nvidia drivers. This is dangerous."
		echo "	 inserttrojan	Unknown :o"
else
	echo "You must specify what version of Nvidia drivers you currently have installed."
	echo "To check these, open up the Nvidia Control Panel. That should tell you."
	echo "Once you know your version of Nvidia Drivers, you must specify them at the end of the script like so:"
	echo "./nvdowngrader.sh 260.19.06-x86_64"
	echo "./nvdowngrader.sh 260.19.06-i386"
	echo ""
	echo "Once done, this script will set off, and downgrade your Nvidia drivers to version 256.53."
	echo "Warning: Narwhal is not currently supported."
	echo ""
	echo "If you would like this script to undo what it has done, simply run the script like so:"
	echo "./nvdowngrader.sh reverse"
	echo ""
	echo "Add help to end of the script for more information."
fi

# Changelog:
# * v0.4
#	- 32-bit nvidia-glx is i386 not i368...
# * v0.3
#	- Fix Dependancy Problem
# * v0.2
#	- Fixed a wrong reference in 64-bit section (Thanks Freedom2 for spotting this)
#	- Minor grammar issues fixed.
#	- Removed unnecessary commented out code.
#	- Added "removenvidia" to remove all Nvidia stuff, this saves having it in a comment. Which is kinda hidden away.
#	- Moved the installer bits around to attempt to get a "cleaner" downgrade.
# * v0.1
#	 - Initial Script
# Copyleft
# This script is provided AS IS without any warranty of any kind. As such I will not be held
# responsible for any damage this script may do. While I consider it unlikely that this script
# will do any damage. I cannot guarantee it will not. You run this script at your own risk.
#
# You may copy/modify/redistribute this script all you like :-)

Give it execution permission, and run as root (sudo script.sh or sudo su - then script.sh)

Any problems/comments/suggestions let me know :-)

Enjoy!

PS: Script only tested on uBuntu 10.10.

Edit: Updated Script

Edited by Random-Dude, 26 October 2010 - 10:27 AM.

[freedom2]

Thanks for writing this script!

I ran the x86_64 option and had to modify the following, as there were still 386.deb references here:

 
				echo "Downgrading Packages..."
				dpkg --install nvidia-glx-185_256.53-0ubuntu3_amd64.deb
				if [ $2 == "all" ]
					then
						dpkg --install nvidia-glx_256.53-0ubuntu3_amd64.deb
						dpkg --install nvidia-185-libvdpau_256.53-0ubuntu3_amd64.deb
						dpkg --install nvidia-current-dev_256.53-0ubuntu3_amd64.deb
						dpkg --install nvidia-185-modaliases_256.53-0ubuntu3_amd64.deb
						dpkg --install nvidia-glx-185-dev_256.53-0ubuntu3_amd64.deb
				#		echo "true"
				fi
				dpkg --install nvidia-current_256.53-0ubuntu3_amd64.deb 
				dpkg --install nvidia-current-modaliases_256.53-0ubuntu3_amd64.deb
				if [ $2 == "all" ]
					then
						dpkg --install nvidia-current-dev_256.53-0ubuntu3_amd64.deb
				fi

I am now running nvidia 256 drivers with no pain as of yet!

Thanks again.


However, am still getting hangs when trying to run 0AD.

Is there a shortcut key combination to kill the 0AD game without rebooting computer on linux, or a way to run it windowed so I can access desktop and kill the process?

[freedom2]

Am also getting huge lag on Gnome X0rg consuming 100% CPU.

Should I try the install all option perhaps?