# [SOLVED] Kernel 3.7 and Nouveau drivers

## radio_flyer

I have an older x86 (stable) system with an Nvidia GeForce 9400 GT video card. For years I ran it with the Nvidia binary blob just fine. However, with the recent

brouhahah with the stabilization of 3.7 and Nvidia, I thought this would be a good time to switch to the open source driver. So far, though, I've had no luck getting it to work. With KMS enabled, the boot screen quickly disappears at startup and is replaced with a black screen with a rapidly flashing cursor. The Xorg.0.log file shows that X is successfully running, but neither the X screen nor switching to a VT shows anything other than the blinking cursor.

If I disable KMS (options nouveau modeset=0), the boot screen remains visible and I can access the VTs, but X refuses to run, reporting an inability to access KMS.

The appropriate lspci output:

 *Quote:*   

> 
> 
> 01:00.0 VGA compatible controller: NVIDIA Corporation G96 [GeForce 9400 GT] (rev a1) (prog-if 00 [VGA controller])
> 
>         Flags: bus master, fast devsel, latency 0, IRQ 16
> ...

 

lsmod:

```

Module                  Size  Used by

nls_iso8859_1           3142  1 

nls_cp437               4812  1 

usb_storage            36214  1 

nouveau               836514  2 

vmnet                  34381  13 

vmblock                 8515  0 

vsock                  34874  0 

vmci                   63323  1 vsock

vmmon                  59228  0 

max6650                 5737  0 

ipv6                  234884  62 

wacom                  45859  0 

snd_aloop              12697  0 

snd_virmidi             2569  0 

snd_seq_virmidi         3511  1 snd_virmidi

snd_seq_midi_event      5305  1 snd_seq_virmidi

snd_seq                46300  3 snd_seq_midi_event,snd_seq_virmidi

snd_hrtimer             1293  1 

configfs               19977  0 

fuse                   61952  1 

ff_memless              4025  0 

joydev                  7393  0 

nfs                   114054  0 

nfsd                   71803  11 

exportfs                3055  1 nfsd

lockd                  55738  2 nfs,nfsd

sunrpc                162401  20 nfs,nfsd,lockd

firewire_sbp2          11002  0 

dm_crypt               13021  0 

dm_mod                 61040  1 dm_crypt

aes_i586                7134  0 

loop                   14953  0 

msr                     1842  0 

cpuid                   1516  0 

snd_usb_audio         104260  0 

snd_usbmidi_lib        17134  1 snd_usb_audio

snd_rawmidi            17786  2 snd_usbmidi_lib,snd_seq_virmidi

snd_seq_device          5289  2 snd_seq,snd_rawmidi

snd_hda_codec_realtek    59088  1 

snd_hda_intel          24013  3 

snd_hda_codec          87397  2 snd_hda_codec_realtek,snd_hda_intel

mxm_wmi                 1334  1 nouveau

video                  11144  1 nouveau

drm_kms_helper         26008  1 nouveau

coretemp                4318  0 

snd_hwdep               5173  2 snd_usb_audio,snd_hda_codec

hwmon                   1254  3 max6650,coretemp,nouveau

ttm                    52737  1 nouveau

snd_pcm                74801  5 snd_usb_audio,snd_aloop,snd_hda_codec,snd_hda_intel

kvm_intel             116867  0 

uhci_hcd               18741  0 

drm                   197573  4 ttm,drm_kms_helper,nouveau

ehci_hcd               33010  0 

snd_page_alloc          6721  2 snd_pcm,snd_hda_intel

intel_agp               9109  0 

usbcore               125435  6 wacom,uhci_hcd,snd_usb_audio,usb_storage,snd_usbmidi_lib,ehci_hcd

snd_timer              17307  4 snd_hrtimer,snd_pcm,snd_seq

i2c_algo_bit            4746  1 nouveau

intel_gtt              13279  1 intel_agp

snd                    55310  20 snd_virmidi,snd_hda_codec_realtek,snd_hrtimer,snd_usb_audio,snd_aloop,snd_hwdep,snd_timer,snd_pcm,snd_seq,snd_rawmidi,snd_usbmidi_lib,snd_hda_codec,snd_hda_intel,snd_seq_virmidi,snd_seq_device

kvm                   242378  1 kvm_intel

firewire_ohci          27210  0 

firewire_core          48880  2 firewire_ohci,firewire_sbp2

agpgart                25893  4 drm,ttm,intel_agp,intel_gtt

sky2                   42449  0 

psmouse                46749  0 

usb_common               703  1 usbcore

i2c_i801                8130  0 

soundcore               5356  1 snd

microcode               6247  0 

evdev                   7682  4 

```

The output from dmesg when I modprobe the nouveau driver (logged in over SSH from another computer):

 *Quote:*   

> 
> 
> [  231.427794] nouveau  [  DEVICE][0000:01:00.0] BOOT0  : 0x096080c1
> 
> [  231.427797] nouveau  [  DEVICE][0000:01:00.0] Chipset: G96 (NV96)
> ...

 

As soon as I modprobe the driver, the console VT disappears on the (DVI-connected) monitor and is replaced with the blinking cursor screen of doom.

Google-searching the PAGE_NOT_PRESENT error isn't coming up with much pertinent info, and I'm not sure if this is the cause of the blank screen or an artifact that can be safely ignored.

I've run down the troubleshooting steps here (fbcon built into the kernel, nvidia.ko blacklisted, etc.) and still no joy.

I don't game on this system, so just basic 3D compositing performance is all I'm looking for. However, it appears to me that this Nvidia open-source driver is still a long way from being usable. Is anyone else having success running the open source Nvidia drivers? Or some idea why the driver appears to run but produces no useful video output? Thanks.Last edited by radio_flyer on Wed Mar 06, 2013 4:51 am; edited 1 time in total

----------

## mv

Yes, the nouveau drivers are still a long way from being usable. It seems that a few particular cards which the developers possess work reasonably well, but with all other cards you are practically lost. Here is my history of experience with these drivers with two different cards, starting from the moment when they were declared as "fully supported (except for some 3D stuff)":

 Immediate crash at booting unless KMS is disabled. (Disabling KMS is practically the same as omittng to use the drivers).

 Several months later: Boots without crash, but screen turns black and stays black.

 About one year later: Boots successfully, switches resolution. Crash happens in the moment when you try to start X.

 About one year later: X starts but shows only a rubbish content.

 Several months later: X starts and crashes as soon as something should be shown.

 About 1-2 years later: X starts and seems to work, but system hangs randomly when you do such daring things like opening a window or writing a line into a terminal. On my other card, the hangs do not occur, but any attempts to use opengl lead to a crash; things like dpms do not work (deactivates the screen for 10 second, then screen is back, no matter what I do). (If you are not using the newest kernel and xorg, you are probably a bit back in this list for a few months or years; moreover, I suspect that not all cards have even reached this state as my relatively ancient and primitive cards...)

Given this speed of development, I estimate that it needs still at least several years until I can use the drivers on my two cards at least in 2D without anything else.

----------

## radio_flyer

Thanks mv. That's the sort of feedback I was looking for, and matches what I'm seeing fairly well   :Sad:    My other (newer, amd64) system uses an ATI card and I've been using the open-source radeon drivers for a year now with great success, 2D and 3D. I was expecting a similar sort of experience from the nouveau drivers when I read 'fully supported' on various websites. Truth be told, the nouveau driver reminds me of the open-source radeon drivers of 3-4 years ago--barely usable.

Looks like I'll be patching nvidia-drivers or masking kernel 3.7/3.8 for a while.

----------

## Apheus

Did you do

```
# eselect opengl set xorg-x11
```

Also, move /etc/X11/xorg.conf out of the way.

----------

## radio_flyer

 *Apheus wrote:*   

> Did you do
> 
> ```
> # eselect opengl set xorg-x11
> ```
> ...

 

Yes.

Part of the problem, however, is that if I enable KMS the video disappears once the nouveau driver is loaded, before it even gets to X. The X server then starts up and runs without error (I can SSH into the system, and top shows that X is running and Xorg.0.log looks fine) but there is nothing but a blank screen with a blinking cursor. The whole shebang seems to go wrong before X even gets started.

----------

## Hu

Perhaps I happen to have only cards that the Nouveau developers possess, but I have never had a problem with the Nouveau KMS support.  Its predecessor, the nv driver, was rather unpleasant, but Nouveau has been quite reliable for me.

 *radio_flyer wrote:*   

> Part of the problem, however, is that if I enable KMS the video disappears once the nouveau driver is loaded, before it even gets to X.

 A blank screen like this can indicate that you failed to include the framebuffer driver.

----------

## radio_flyer

I originally followed the steps in the Gentoo Nouveau Wiki that says no frame buffer driver should be compiled into the kernel. However, I then found the nouveau troubleshooting guide (noted in the original post) that mentioned CONFIG_FRAMEBUFFER_CONSOLE should be enabled. I did confirm that was the case. The output of the dmesg log I posted originally seems to indicate that nouveau has its own frame buffer (nouveaufb) and that it started correctly.

For now I'm going to mark this thread 'solved' as I went back to the binary nvidia blob and kernel 3.5.7, which is working fine. Various postings on slashdot and the like indicate that nouveau support is much further along in kernel 3.8 and later, so I'll wait until that kernel hits stable before giving the nouveau driver another go.

----------

## mv

 *Hu wrote:*   

> Its predecessor, the nv driver, was rather unpleasant, but Nouveau has been quite reliable for me.

 

For my cards, the nv driver worked well. No 3D-support, of course, but not hangs.

----------

## newfuntek

nouveau-9999 with 3D and noaccel=false is now stable for me without vdpau, vaapi use flags and lib stuff.

I have compiled nouveau-drm in kernel 3.9.4 with all possible framebuffers.

I had to add "-vdpau -vaapi" to USE and reemerge:

emerge adobe-flash mesa avidemux mplayer2 virtual/ffmpeg media-video/ffmpeg

media-libs/avidemux-core adobe-flash avidemux-plugins --keep-going

emerge libdrm xorg-server; 

#put all xf86* into xf86.txt

emerge `cat xf86.txt` --keep-going;

----------

## TomWij

 *newfuntek wrote:*   

> nouveau-9999 with 3D and noaccel=false is now stable for me without vdpau, vaapi use flags and lib stuff.
> 
> I have compiled nouveau-drm in kernel 3.9.4 with all possible framebuffers.
> 
> I had to add "-vdpau -vaapi" to USE and reemerge:
> ...

 

For the xf86 suggestion it sounds like you would want to do `emerge @x11-module-rebuild` instead, this automatically figures out which modules to rebuild. Please note that nouveau-9999 will not stay stable (it's live) so if you wish to retain what you have you will probably want to snapshot its contents such that you can reproduce it, or figure out which upcoming version will be close to what you have now such tha tyou can use that version instead. On a side note, if you just merge avidemux it will pull in avidemux-core and avidemux-plugins for you. Have a nice day!

----------

