668. Controlling the fan speed of an Nvidia card when you're using the nouveau driver and no xorg.conf

 My old GT210 has served me well, but I've had a few odd freezes recently, coupled with weird graphics behaviour. It's a pity, since it's a nice, silent fan-less graphics card from way back when: https://www.gigabyte.com/Graphics-Card/GV-N210SL-1GI#ov

Although some of it may be due to switching back and forth between VGA and HDMI output (between an old HP 19'' and my new fancy xp pen display) I ripped it out and replaced it with an almost as ancient GT 520 (https://www.gigabyte.com/Graphics-Card/GV-N520OC-1GI#ov)

The fan isn't loud, but it's there, and it's distracting since I'm working in a home environment (Corona!).

Looking online I found these posts:
http://floppym.blogspot.com/2013/07/fan-control-with-nouveau.html
https://forums.opensuse.org/showthread.php/501517-OS-13-1-Driver-quot-nouveau-quot-Unable-to-command-fan-speed-Nvidia-6800-GS
https://www.kernel.org/doc/Documentation/thermal/nouveau_thermal

So, first to check if fan control is possible:

me@indium:~$ find /sys -name pwm1_enable
find: ‘/sys/kernel/debug’: Permission denied
/sys/devices/platform/it87.2624/hwmon/hwmon2/pwm1_enable
/sys/devices/platform/it87.2656/hwmon/hwmon3/pwm1_enable
/sys/devices/pci0000:00/0000:00:03.0/0000:05:00.0/hwmon/hwmon0/pwm1_enable
me@indium:~$ readlink /sys/devices/pci0000:00/0000:00:03.0/0000:05:00.0/driver
../../../../bus/pci/drivers/nouveau

Good, and we got the hwmon number -- 0. 

I then created a script called gpufan.sh:

sudo sh -c "echo 1 > /sys/class/hwmon/hwmon0/pwm1_enable"
sudo sh -c "echo 35 > /sys/class/hwmon/hwmon0/pwm1_min"
sudo sh -c "echo 45 > /sys/class/hwmon/hwmon0/pwm1"

I set the min% to 35 -- it used to be 65. And I tested my way to 45% as a good compromise between noise and temperature. By default the fan speed was >4,000 rpm. Output from sensors now:

nouveau-pci-0500
Adapter: PCI adapter
GPU core:     +0.90 V  (min =  +0.90 V, max =  +1.11 V)
fan1:        2790 RPM
temp1:        +34.0°C  (high = +95.0°C, hyst =  +3.0°C)
                       (crit = +105.0°C, hyst =  +5.0°C)
                       (emerg = +135.0°C, hyst =  +5.0°C)

357. Annoying desktop experience -- zoneminder, nouveau, nvidia and other things

This isn't a how-to post. It's basically just a description of what I went through this morning -- hopefully it'll help someone. I don't like playing around with nvidia -- and I don't have time anyway -- so I won't try to ferret out exactly what went wrong. Maybe everything was due to me failing to discover that the upgrade hadn't finished properly.

So..
(the system in question was running nvidia/kernel 3.7 at the beginning)

I had issues starting virtualbox (playing with gentoo for an upcoming post) the other day, and so decided to reboot after running apt-get upgrade (I only do it once per week/month or so -- it's my futile attempt at stability in spite of running wheezy/testing...).

On rebooting everything looked fine and I was greeted with the login screen in GDM. Trying to log in everything looks fine at the beginning...the screen flickers as if the resolution is being changed, the desktop background looks fine, conky is running...and then I'm thrown back to the GDM login again.

I'm not a stranger to other desktops. Trying KDE, LXDE, etc via GDM gave the same error.

Looking in the terminal I noticed that I had guake segfault errors, and errors along the lines of
"segfault at 968 ip [..] error 4 in libX11.so.6.3.0"

Logging in as another user gives me a message saying that I'm thrown back in to gnome classic due to lack of acceleration. Also, the desktop didn't have menus etc., and with various d-bus related errors.

Looking at
~/.xsession-errors:

update-notifier: Fatal IO error 0 (Success) on X server :0.
No protocol specified

and
/var/log/Xorg.0.log:

Display does not support NVIDIA 3D.

I then ran SMXI with the intent to test Nouveau instead of Nvidia.

As part of its process, SMXI does a dist-upgrade. It's not often I encounter errors during apt-get, so when errors popped up, I paid attention.

Turns out that Zoneminder had some issue -- zoneminder had held back the configuration of packages that I pulled in during the apt-get upgrade at the very beginning. And given that I don't do it very often, there were a lot of packages that were left unconfigured, including Xorg.

I auto-remove zoneminder and completed the upgrade. So far so good!

If that had been the end of it there would be no blog post. Still things weren't working.

Since I was already exploring the possibility of switching to Nouveau, I decided to go through with it. First I backed up my old /etc/X11/xorg.conf which has served me well in the past. Then, using SMXI I installed Nouveau (after blacklisting nvidia, and removing any nouveau blacklisting).

GDM started up fine, but I had no acceleration and GNOME 3 started in fallback mode (gnome 'classic'). I tried glxgears which told me  libGL.so.1 was missing.

However, libGL.so.1 actually existed in /usr/lib/x86_64-gnu/ -- but it pointed to libGL.so.1.2 via a symlink, and libGL.so.1.2 didn't exist.

I flailed about for a little while:
sudo apt-get install --reinstall glx-alternative-mesa
Which seemed to actually do stuff -- pulled in nvidia-installer-cleanup, glx-diversions, glx-alternative-mesa. It added lots of seemingly relevant diversions, but there was still no target for the libGL.so.1 symlink.

I then got fed up with the Nouveau/GNOME 3 combination.

I decided to bet on NVIDIA again, and had the fairly reasonable idea that the issue was the updated Xorg version -- simple nvidia update might've helped

Since I had kernel 3.7 installed, and 3.8 supports NVIDIA/DKMS I figured I might as well install a 3.8 kernel I had compiled on a different computer before continuing.

After upgrading to kernel 3.8, I blacklisted nouveau in /etc/modprobe.d/blacklist.conf ('blacklist nouveau').
I manually made sure that there was no nvidia or nouveau loaded by rmmod:ing them and checking with lsmod.

I then ran smxi and installed debian-nvidia.

Reboot.

Black screen with cursor. No graphical environment.

lsmod showed that nouveau hadn't respected my blacklisting.

Edited my /etc/default/grub to read
GRUB_CMDLINE_LINUX_DEFAULT="quiet nouveau.blacklist=1"
then ran update-grub, followed by restoring my old xorg.conf.

And...then everything worked! lsmod shows that nouveau isn't loading anymore (blacklisting should be ok,  no?) and I can now log in to gnome 3 as normal with normal acceleration.

I'm not sure what the underlying problem was -- nouveau not respecting my blacklisting hasn't been an issue before, so that was a bit of a surprise. But it was probably fine before I installed nouveau (I can't uninstall it for some retarded reason since it pulls too many packages with it), and not the source of the original issues. Probably the new xorg version didn't play fine with the installed version of nvidia, which is almost expected.

I'm still peeved with the Nouveau/GNOME 3 situation though -- binary blobs shouldn't be required to simply to use a basic desktop. I can understand if nouveau isn't a stand in for nvidia -- it's a reverse engineered open source alternative after all -- but why is gnome 3 requiring so much grunt?

228. Setting up Asus (nvidia) GF 210 on Debian Testing

NOTE:  Unless I remove the legacy driver, *DM will not start. Instead I only get a blank screen with a blinking cursor. See below for solution.

Here's how to get ASUS (nvidia) GF210 up and running in debian testing (wheezy)

First edit /etc/modules, and add
blacklist nouveau

You can either reboot at this point or try
sudo rmmod nouveau

To see whether nouveau got unloaded, do
lsmod |grep nouv

If nothing is returned, then you're good.

Make sure that your card got recognised:

lspci

01:00.0 VGA compatible controller: NVIDIA Corporation GT218 [GeForce 210] (rev a2)

I like smxi, so here's how to get the drivers up and running using smxi, which is a fancy shell script.

sudo su
cd /usr/local/bin
wget -Nc smxi.org/smxi.zip
unzip smxi.zip
smxi

The first time you run smxi you have a couple of things to sort out -- lots of little questions to answer. If you don't feel comfortable yet with linux, avoid liquorix since it'll make your debian box deviate more from the standard setup (the liquorix kernel is fine and safe and I've used it in the past before I started rolling my own kernel, but it's more difficult for someone to troubleshoot your system the more it deviates from their own). Other than that most questions aren't that important. I enable non-free immediately after setting up a new box, and while there are sound political reasons for NOT doing it, there are plenty of practical reasons in favour of it.

Anyway, eventually you're done with the setup, and with making sure that your system is up to date. Select Continue to Graphics, then select debian-nvidia

If all goes well you'll get the dkms install of the nvidia driver. You're probably asked whether to generate a new xorg.conf, which you should. You may also get a message about the nvidia driver needing to be added to your xorg.conf.

Once you're done installing the driver, you're asked whether to start your desktop or to quit. While it's fine to start your desktop at this point, why not select quit and check that all went well?

lsmod|grep nvi
nvidia               8028141  0
i2c_core               24002  2 i2c_piix4,nvidia

cat /etc/X11/xorg.conf|grep nvi
        Driver  "nvidia"
        Driver  "nvidia"
        Driver  "nvidia"

Looks fine.

I often have problems with the legacy drivers (blank screen with blinking cursor), so
sudo apt-get purge nvidia-*-legacy-173xx-*

Do
aptitude search 173 
to make sure all the legacy drivers are gone.

Purge if there's still something around.

Framebuffer 
If possible I like to enable framebuffer (it gives you fancier graphics capabilities in terminal mode e.g. browsing with images using w3m). I've had all manner of headaches doing so with the newer nvidia drivers though, so don't be too surprised if it doesn't pan out.

Edit the following line in your /etc/default/grub

GRUB_CMDLINE_LINUX_DEFAULT="quiet text vga=0x0318 nomodeset"

To see what code to use, look here.
This method is supposed to be deprecated, but I don't have any experience using vbetool.

As for the other options, only 'text' is important -- it will make you boot into the terminal and you will have to start your (default) desktop by doing startx. IF you want to boot into e.g. gdm3, kdm or another *dm, then DO NOT ADD text.

Reboot. To see whether your framebuffer is active do
ls /etc/fb*

/dev/fb0

208. Weird things with desktops -- nvidia cockup?

Just in case someone else is having an equally entertaining Friday the 13th (of July 2012).

So, I had a little gnome 3 crash. You know the ones with the frowny screen and a message saying that "yeah, we probably could have let you save everything you're working one but screw you 'cos we're logging you out"? (hmm...don't remember seeing that with gnome 2/metacity -- have we in fact been turned into Metro/Win8 guinea pigs?!)

Well, anyway, I had one of those and rebooted.

I got to gdm3, logged in and...nothing. I mean, I saw the desktop background, but no menus, nothing. Nothing at all. Moving the mouse to the top left corner would give me the typical gnome-shell splash pattern and make the screen a bit darker. I didn't get anything else though (like a list over programs, icons or anything). Oh, and the conky stuff briefly flashed by each time (but in the top left area instead of flush to the right side of the screen)

Given that I played around with testing different desktops recently I figured I might have upset the update-alternatives balance, and played around with --config x-window-manager and --config x-session-manager. I mean, I was hoping that the lack of a menu of some sort was due to having the wrong window manager, in spite of all the signs pointing to me actually using gnome-shell.

That not working I spent another hour playing with installing and uninstalling nvidia. For some reason smxi pulled in the 173 driver, before replacing it with 302. Every time. Finally, I managed to get everything to the point where I could do startx with the nouveau drivers installed.

Not that things were perfect -- in fact my screen was scaled to 1024*768 (supposed to be 1920x1280), and the flicker whenever I moved my mouse was not funny, but at least it kind of worked.

So back to the terminal, sudo rmmod nouveau, sudo smxi, install the nvidia driver again -- but this time selecting nvidia current instead of debian-nvidia, and then startx

Huh. This time I kind of got the icon panel and the bottom panel, and the gnome-shell hot corner worked ok. It's almost like...no way...is it pretending I have two displays???

I then went to System settings/Displays and the bloody thing had set it up so there were two active display (I don't OWN two displays and certainly did not set this willingly).

Here it's been deactivated. But seriously, wtf???

So if you find yourself in a similar situation without panels and stuff: check your settings. Now how the hell did this come about? And who can I blame? Debian? Nvidia? Nvidia has been the cause of most of my more severe problems with debian...I just wish nouveau was a better alternative than it currently is for my setup.

PS I do realise that some of the language in the post above is more fitting for a valley girl, but screw this: I'm a busy person with a tight schedule (semester starts in two weeks and still hammering away on lectures, not to mention research) who lost three valuable Friday afternoon hours on a stupid thing. Not happy.

166. Briefly: nvidia API mismatch on debian when running ecce

UPDATE: There's a much better way to do this: "One thing that I did notice is your issues with OpenGL where you suggested moving the shared libraries to another directory. While that's perfectly workable, this would be another instance where consulting the $ECCE_HOME/siteconfig/site_runtime file would be useful. There you would learn about the $ECCE_MESA_OPENGL and $ECCE_MESA_EXCEPT variables that control whether to use the ECCE-supplied GL libraries or native ones (e.g. hardware OpenGL card drivers) on your machine." I'll update this post again when I've had a time to look into it. Lecture slides and grant rejoinders don't write themselves...

Original post:
If you get an error along the lines of this:
 http://www.linuxquestions.org/questions/debian-26/api-mismatch-nvidia-kernel-module-871115/
only when you're running ECCE i.e. there's an API mismatch error with a difference in kernel module version vs the nvidia driver component (in my case 295.49 and 290.10, respectively), thenyou may want to have a look in your apps folder before you launch a major investigation, e.g.

ecce-6.3/apps/rhel5-gcc4.1.2-m64/3rdparty/mesa/liblibGL.so    libGL.so.295.49  libGLU.so.1           libnvidia-glcore.so.295.49
libGL.so.1  libGLU.so        libGLU.so.1.3.071100  libnvidia-tls.so.295.49

You can symmlink the correct drivers, or -- which is even easier -- just move your 3rdparty/mesa library to e.g.3rdparty/bakmesa and see if it solves it

11. Sorting out problems with NVIDIA or ATI graphics cards on Debian Testing

This bug has been a problem for a while now when running debian testing - if you do a dist-upgrade, chances are your prorietary drivers get borked.

Symptoms include gdm not starting i.e. no Gnome login window. Instead you get dumped into the terminal.

There are two fixes - one quick and dirty one and one which is more long term.

1. Quick and dirty
If you want Gnome up and running without necessarily using graphics acceleration, simply log in in your terminal and rename your xorg.conf.

sudo mv xorg.conf xorg.conf.old

This will allow you to use the graphics card on your motherboard again. It won't help with a PCI card much.

2. A real fix
SMXI. It may seems scary, but is fairly straightforward. Log in (presumably in the terminal)

sudo su
cd /usr/local/bin && wget -Nc smxi.org/smxi.zip && unzip smxi.zip && smxi


The sudo su logs you in as root. You could also sudo each command individually above.

Follow the instructions and let the smxi script install your graphics drivers.