Maverick was particularly prone to graphics freezes with the standard Open-Source nouveau drivers.
You can uplift you X-System using the X-Updates PPA
sudo add-apt-repository ppa:ubuntu-x-swat/x-updates
sudo apt-get update && sudo apt-get upgrade
You can then install the latest NVIDIA drivers.
As you have noted, the Open-Source drivers still seems to take precedent over the NVIDIA drivers.
One-way to force the use of the NVIDIA drivers is to black-list the open-source drivers:
To do this:
:
blacklist nouveau
blacklist lbm-nouveau
blacklist nvidia-173
blacklist nvidia-96
alias nvidia nvidia-current
Now install the nvidia-current driver:
sudo apt-get install nvidia-current
One happy side-effect of using the nvidia drivers rather than the old maverick open-source drivers is that the temperature/battery usage is greatly reduced.
source
alternative force usage of nvidia driver
The following will actually remove the nouveau driver before reinstalling the nvidia driver (again).
sudo apt-get --purge remove xserver-xorg-video-nouveau
Now make sure you have the headers installed before reinstalling the nvidia driver
sudo apt-get install linux-headers-$(uname -r)
sudo apt-get install --reinstall nvidia-current
Now rename your xorg.conf before recreating the file:
sudo mv /etc/X11/xorg.conf /etc/X11/xorg.conf.backup
gksudo nvidia-xconfig
If nvidia-xconfig still gives you an issue run,
gksudo nvidia-settings
reversing
if you get black-screens then do the following to reverse:
First, boot with recovery and choose terminal with networking
Then rename the xorg.conf file
sudo mv /etc/X11/xorg.conf /etc/X11/xorg.conf.backup2
The reinstall the opensource driver:
sudo apt-get install xserver-xorg-video-nouveau
You may or may not also have to remove the "blacklist" lines added at the top of this answer.
I figured I could just test it, so I ran:
sudo mount -o remount,size=2800M /run
Worked like a charm:
Filesystem Size Used Avail Use% Mounted on
tmpfs 2.8G 45M 2.7G 2% /run
So I filled it a bit:
fallocate -l 1G /run/test.img
fallocate -l 1G /run/test2.img
fallocate -l 500M /run/test3.img
Result:
Filesystem Size Used Avail Use% Mounted on
tmpfs 2.8G 2.6G 208M 93% /run
System is still up and running. Swap availability dropped, which proves it was used:
- 17:10: create 2.5 GB of files in
/run
- 17:20: remove the 500M file
Total swap is reduced by the amount taken by /run
.
I'd test 10GB on a VM, because I don't know if the kernel will refuse the remount or just have an unexpected behavior.
I'm still looking for an actual answer, but the pragmatic way showed it works.
Best Answer
You have got two problems here, apparently.
The REISUB sequence not working could be caused by magic SysRq not being activated - check out
You want 4 (R) + 64 (E,I) + 16 (S) + 32 (U) + 128 (B) = 244 for classic REISUB (the effect is the same as the skinny elephant version; as a mnemonic, it's BUSIER spelled backwards).
For the swappiness of the system: it's working as expected. The cause of the behaviour is that you have lots of memory used - that could be the 95% you're getting - and then something else is requesting a whole lot of new RAM, forcing most of that 95% onto swap and fighting all the way.
The best thing you could do is install more RAM. Otherwise, see whether you can tame either the small processes building up to that 95%, or the big one eating a further 40-50%. The
top
utility might help you there.As a fancy solution you could increase apparent swappiness and keep the small fry "pared down" with some process that monitored the system and, if the big hog was not running and the memory footprint was too large, started allocating and releasing large swaths of memory - say, all remaining memory plus 64M, to force 64M of small fry onto the cache, then +128M, and so on, until the allocation delay grew beyond a given time threshold or the big hog started.
This answer could give you a good start if you really want to do that.