Created attachment 49450 [details]
logs for vga=775 before starting X

Created attachment 49451 [details]
logs for vga=775 after starting X (stuck on black screen)

Created attachment 49452 [details]
logs without "vga=" boot option (first attempt)

Created attachment 49453 [details]
logs without "vga=" boot option (second attempt)

I have only managed to get it working for the first time with the original kernel driver from vanilla kernel 3.0.0 by using the "NoAccel" option set to "True" in xorg.conf at section "Device". However everything is very slow.

I am now going to attach the output log collected from Xorg.log, dmesg and lsmod (filename nouveau-discrete-3.0.0-NoAccel-no_glx_module.txt).

But I would like to use acceleration, so this is not a stable situation... The bug remains open. Next I am going to try the git kernel driver from freedesktop built out-of-place.

Created attachment 49468 [details]
logs when the driver is working with the NoAccel option (very slow)

Hi Guido

Can you try booting into runlevel 3 - append " 3" to your kernel command line

If the above produces working system (i.e. the display is not black) please try the following

1 Note that there is something a bit odd in your Xorg.log as libglx.so tries to load twice. In may be good idea trying the minimal xorg.conf [1]

2. Try disabling AIGLX in your xorg.conf

Cheers
Emil

[1] http://nouveau.freedesktop.org/wiki/InstallNouveau

Just finished trying the kernel module from snapshot master-4fc2e2fc0157433883f10e0d7327c73069c66d63 instead of module from vanilla kernel 3.0.0 and it does not work either.

I can still try out the freedesktop git trying to build only that module out-of-place or otherwise I could try the upstream kernel 3.0.0-git3.

Emil, thanks very much for your advice. I always start from runlevel 3 until things are stable. I tried disabling AIGLX several times before, without any benefit. I will now disable it permanently and also double-check that glx is not invoked twice from xorg.conf. If glx is loaded twice because of a problem that does not depend on the configuration, then I suppose there is little I can do about it...

Any other idea ?

Emil, I tried following your advice, using the original driver which comes with kernel 3.0.0-git3 but the problem is still there (it gets stuck on an unresponsive black screen which only displays a small underscore "_" in the top left corner and I do not get the gdm greeter).

I am going to attach the logs (as file nouveau-discrete-with_Accel-kernel_3.0.0-git3-driver-no-aiglx-do_not_require_glx.txt), but I am sure they are very similar to the previous ones except from AIGLX being disabled and GLX loading only once (by default).

I will keep those two settings as you suggested from now on, but so far nothing has changed unfortunately !

Next I will try the kernel driver from the snapshot (commit 4fc2e2fc0157433883f10e0d7327c73069c66d63) on the 3.0.0-git3, but at this point I really doubt it would sort things out.

I am not sure but perhaps the only difference between the kernel module shipped with the upstream kernel and the out-of-place kernel module from the snapshot is that the following line is missing in the snapshot:

[drm] nouveau 0000:01:00.0: Pointer to BIT loadval table invalid

Other than that with kernel 3.0.0 there was no practical difference between the two kernel drivers (upstream and freedesktop snapshot).

Created attachment 49476 [details]
logs with module from kernel 3.0.0-git3 (AIGLX disabled and GLX not required but loaded by default)

(In reply to comment #9)
> Emil, I tried following your advice, using the original driver which comes with
> kernel 3.0.0-git3 but the problem is still there (it gets stuck on an
> unresponsive black screen which only displays a small underscore "_" in the top
> left corner and I do not get the gdm greeter).
If you are starting at runlevel 3 there will be no kdm/gdm/xdm greeter

Thus I take that the display is _not_ black but there is still nothing relevant on it

> ....
> [drm] nouveau 0000:01:00.0: Pointer to BIT loadval table invalid
> 
AFAIK the above message is not crucial

There are a few things you can try - all without loading X

1. Play with the module options "noaccel" and/or "nofbaccel" (modinfo nouveau for more info)

2. Select different resolution - append "video=..." [1] to your kernel command line

3. Add some printf() statements in the kernel module to narrow in which state the issue occurs

Cheers
Emil

[1] http://nouveau.freedesktop.org/wiki/KernelModeSetting - Forcing Mode

Hi Emil, thanks once again very much for offering your support !

Yes, there will be no gdm greeter in runlevel 3, but I shall get some gnome-terminals and the gnome-panel too. Doesn't matter...

By the way, the minimal xorg.conf did not help (and it actually enables AIGLX).

The freedesktop snapshot kernel driver on 3.0.0-git3 did not sort things out either.

Perhaps, the only difference that I recently noticed is that with NoAccel (only usable configuration) and AIGLX disabled in xorg.conf, I get:

[   541.369] (**) Option "AIGLX" "off"
...
[   541.562] (**) AIGLX disabled
[   541.562] (II) Loading extension GLX
...
[   542.281] (II) AIGLX: Loaded and initialized /usr/lib64/dri/swrast_dri.so
[   542.281] (II) GLX: Initialized DRISWRAST GL provider for screen 0

I think this is not very relevant. Perhaps it just means that it has loaded the SW rasterizer (the one used by the "nv" driver). It does not speed up anything (acceleration is disabled). It could be that earlier on Mesa did not produce that module after building it and therefore it was not getting loaded.

I will now try to follow your latest advice. I will take some time to play around with all possible different configurations and options...

However in the earliest logs (at the end of dmesg's output) there is some extra debugging output from the kernel drm module. Does that tell you anything ?

Created attachment 49480 [details]
Xorg.0.log & dmesg. The person that submitted these logs has now sorted out his problem.

I think https://bugzilla.novell.com/show_bug.cgi?id=706305 and https://bugzilla.novell.com/show_bug.cgi?id=707110 are this, so instead of filing new as per comment 6 in the latter, attaching messages and Xorg.0.log here. http://download.opensuse.org/repositories/home:/jobermayr/openSUSE_Factory/i586/drm-nouveau-kmp-desktop-20110721.2009_k3.0.0_2-2.3.i586.rpm used instead of normal Factory rpm.

Emil, unfortunately I have tried the following options for the kernel module and none of them works:

msi=1 tv_disable=1 agpmode=0 noaccel=1 nofbaccel=1

except from noaccel=1 which is equivalent to NoAccel in xorg.conf (pointless).

The "video" option in kernel boot, should only affect the framebuffer console, therefore I am not sure it would sort out the problem with acceleration, but I might try it later on...

I could also disseminate printf() in the kernel module, but I do not know anything about it and in any case, there is no crash as in oops or segfault. As already pointed out, I believe the drm debug output should be very informative to the developers, but nobody is getting back...

Felix, the bugs you are describing seem different from mine because:

- I have a different NVidia card (mine is GeForce GT 330M);
- I am not using openSUSE;
- I do not have a blinking cursor in the upper left corner (it's a steady white underscore);
- keyboard and mouse are both working fine for me.

Felix, just a quick comment on your logs. I am no expert at all, but I noticed something:

- xserver is trying to load the "nvidia" driver (binary driver from NVidia) and fortunately it's failing to load it because it's missing (otherwise it might conflict with nouveau); lsmod should not show that "nvidia" kernel module is loaded; Xorg.log should not show that it is trying to load nvidia_drv.so
- xserver is loading the "nv" driver (successfully) and that could interfere with nouveau. you should avoid loading that. use 'Driver "nouveau"' in xorg.conf or otherwise remove the file nv_drv.so from /usr/lib/xorg/modules/drivers.

Summing up, only the following drivers/modules should be loaded when using nouveau:

- kernel module (check with lsmod): nouveau, drm, drm_kms_helper, ttm
- Xorg module (check from Xorg.log): /usr/lib/xorg/modules/drivers/nouveau_drv.so

(In reply to comment #14)
> Felix, the bugs you are describing seem different from mine because:
 
> - I have a different NVidia card (mine is GeForce GT 330M);

It also happens with a much older GeForce2 MX400.

> - I do not have a blinking cursor in the upper left corner (it's a steady white
> underscore);

Mine stopped blinking after switching to Jobermayr's drm-nouveau-kmp-desktop and 3.0.0-2 (both installed at same time).

> - keyboard and mouse are both working fine for me.

PS/2 connected, or USB? Mine are both USB with the 8600GT, but PS/2 on the old NV11.

(In reply to comment #15)
> Felix, just a quick comment on your logs. I am no expert at all, but I noticed
> something:

> - xserver is trying to load the "nvidia" driver (binary driver from NVidia) and
> fortunately it's failing to load it because it's missing (otherwise it might
> conflict with nouveau); lsmod should not show that "nvidia" kernel module is
> loaded; Xorg.log should not show that it is trying to load nvidia_drv.so
> - xserver is loading the "nv" driver (successfully) and that could interfere
> with nouveau. you should avoid loading that. use 'Driver "nouveau"' in
> xorg.conf or otherwise remove the file nv_drv.so from
> /usr/lib/xorg/modules/drivers.

I only have a vague notion of the inner workings of X as they appear in the logs, but I think you see the result of prioritization of drivers to try. It prefers nvidia, regardless whether installed (which is never the case on any of my systems), next tries nouveau, next nv, and last vesa. I always see their *.sos listed, but only that actually used shows up in the capitalized repeats show which is actually used, such as in this case (II) NOUVEAU(0):

>> - I have a different NVidia card (mine is GeForce GT 330M);
> It also happens with a much older GeForce2 MX400.

Yours is 'NOUVEAU(0): Chipset: "NVIDIA NV84"', mine is 'NOUVEAU(0): Chipset: "NVIDIA NVa5"'.

The identification from the kernel is similar but not exactly the same: yours is "Detected an NV50 generation card (0x084200a2)", mine is "Detected an NV50 generation card (0x0a5480a2)". The BIOS version is also very different.

It could be an issue with similar effects but due to a different bug.

I am not an expert, therefore I have nothing else to add. We should wait for developers to get back, I suppose...

> Mine stopped blinking after switching to Jobermayr's drm-nouveau-kmp-desktop
> and 3.0.0-2 (both installed at same time).

Well, at least you can revert back to previous versions ! Mine has never been working !!

> PS/2 connected, or USB?

I use an internal Touchpad from Synaptics, but external USB mouse also works fine.

> I only have a vague notion of the inner workings of X as they appear in the
> logs, but I think you see the result of prioritization of drivers to try. It
> prefers nvidia, regardless whether installed (which is never the case on any of
> my systems), next tries nouveau, next nv, and last vesa. I always see their
> *.sos listed, but only that actually used shows up in the capitalized repeats
> show which is actually used, such as in this case (II) NOUVEAU(0):

The file that you attached (https://bugs.freedesktop.org/attachment.cgi?id=49480) also shows "(II) NV:" and not just "(II) NOUVEAU(0):".

But, it's up to you, if you think it's pointless to try adjusting that...

https://bugzilla.novell.com/show_bug.cgi?id=707110 enabled me to get mine working.

Comment on attachment 49480 [details]
Xorg.0.log & dmesg. The person that submitted these logs has now sorted out his problem.

The person that submitted these logs has now sorted out his problem.

Emil, unfortunately (and as I was expecting) the "video" option in the kernel boot parameters did not sort out anything other than changing the resolution of the initial framebuffer console. The last option that you proposed was to disseminate printk() in the kernel module and try to trace the code path and try to understand where it gets stuck. That's not easy to do without any indication at all, because the it's several drivers (drm, drm_kms_helper, nouveau, ttm). Also there is no crash as in kernel oops or userspace segfault and I have already debug output from drm. I bet the problem lies there (drm or drm_kms_helper), but I really do not know where to begin without the assistance of one of the developers.

Felix, I am glad to hear that you managed to sort out your issues. I am quite sure mine are not exactly related to yours and I am not using openSUSE, therefore trying the same packages has a very low priority for me now. I would really need to hear back from the developers...

Upgrading to kernel version 3.0.0-git4 did not change the situation... I am quite desperate about this problem. Several hours spent trying different options and different versions without achieving anything. A lot of money spent on a graphic card which does not even work with the original driver from its manufacturer ! Being a laptop, I cannot even smash it against the wall unfortunately !

Let's get to some important conclusions...

From Comment 18 (https://bugs.freedesktop.org/show_bug.cgi?id=39498#c18) I backtraced and compared the steps performed by Felix.

- xorg driver xf86-video-nouveau shipped by openSUSE as from jobermayr is exactly or basically the same source code;

- libdrm is exactly or basically the same source code;

- not tried pscnv driver yet, but do not expect much from it (seems it is a fork with tackles ttm architecture)

- the drm kernel modules (20110721.2009-2.3) use the build option CONFIG_DRM_NOUVEAU_KMS=y, which as far as I remember was set to 'n' in the Makefile from the Nouveau DRM wiki (although I did also try enabling that once on the git source without achieving anything): in any case I did not touch the kernel module, still using the already mentioned one from freedesktop snapshot

- however can anyone comment something on the above mentioned build option ? what's that for exactly ?

- the drm kernel module shipped by jobermayr and tagged as 20110721.2009-2.3 on openSUSE does ship separate vgaarb and vga_switcheroo which I have built into the kernel but they are exactly the same version and code

- same as above for acerhdf which however is exactly the same version as in latest kernel and it's not even very relevant to this problem

- same as above for wmi and mxm-wmi which however is exactly the same version as in latest kernel

- same as above for acer-wmi (Acer WMI Laptop Extras, I have an Acer Aspire 5745G) which is not the same as in vanilla kernel 3.0.0-git4, I have not tried it, it's not relevant, such module should be just for the functionality of extra special keys on the keyboard

- glew is a different version, I also have the newer one installed (1.6.0) on my system

- I do not have library Mesa-libtxc_dxtn at all (S3 Texture Compression library). The website http://people.freedesktop.org/~cbrill/libtxc_dxtn/ says it does not support NVidia cards anyway but it appears to get at least loaded when installed

- I do not have libva and libvdpau: installed them from their respective git versions, just in case

- I have not checked the difference between Mesa git that I am using and the Mesa source provided by jobermayr, but the build options are very different, I shall try building what I already have with those options, just in case

At the end of the whole story above, I finally managed to get the Nouveau driver working with NoAccel disabled ! And it seems to be fast enough, surely much faster than when NoAccel was enabled...

The logs are going to be attached in a minute.

It is now very important to understand what exactly was causing the problem, amongst the few steps performed above. My bet is on Mesa build options from openSUSE in the jobermayr tree, but I am not an expert and I might well be wrong. Everything should be documented officially preferably by the experts and developers rather than myself, so that it won't ever happen again to anyone as it is too annoying and time-wasting.

$ xdriinfo 
Screen 0: nouveau

Gnome Control Center (System Info section) shows: Graphics Gallium 0.4 on NVA5

$ xdpyinfo
name of display:    :0.0
version number:    11.0
vendor string:    The X.Org Foundation
vendor release number:    11003000
X.Org version: 1.10.3
maximum request size:  16777212 bytes
motion buffer size:  256
bitmap unit, bit order, padding:    32, LSBFirst, 32
image byte order:    LSBFirst
number of supported pixmap formats:    7
supported pixmap formats:
    depth 1, bits_per_pixel 1, scanline_pad 32
    depth 4, bits_per_pixel 8, scanline_pad 32
    depth 8, bits_per_pixel 8, scanline_pad 32
    depth 15, bits_per_pixel 16, scanline_pad 32
    depth 16, bits_per_pixel 16, scanline_pad 32
    depth 24, bits_per_pixel 32, scanline_pad 32
    depth 32, bits_per_pixel 32, scanline_pad 32
keycode range:    minimum 8, maximum 255
focus:  window 0x360001f, revert to Parent
number of extensions:    28
    BIG-REQUESTS
    Composite
    DAMAGE
    DOUBLE-BUFFER
    DPMS
    DRI2
    GLX
    Generic Event Extension
    MIT-SCREEN-SAVER
    MIT-SHM
    RANDR
    RECORD
    RENDER
    SECURITY
    SGI-GLX
    SHAPE
    SYNC
    X-Resource
    XC-MISC
    XFIXES
    XFree86-DGA
    XFree86-VidModeExtension
    XINERAMA
    XInputExtension
    XKEYBOARD
    XTEST
    XVideo
    XVideo-MotionCompensation
default screen number:    0
number of screens:    1

screen #0:
  dimensions:    1366x768 pixels (361x203 millimeters)
  resolution:    96x96 dots per inch
  depths (7):    24, 1, 4, 8, 15, 16, 32
  root window id:    0x195
  depth of root window:    24 planes
  number of colormaps:    minimum 1, maximum 1
  default colormap:    0x20
  default number of colormap cells:    256
  preallocated pixels:    black 0, white 16777215
  options:    backing-store NO, save-unders NO
  largest cursor:    64x64
  current input event mask:    0xfa8033
    KeyPressMask             KeyReleaseMask           EnterWindowMask          
    LeaveWindowMask          ExposureMask             StructureNotifyMask      
    SubstructureNotifyMask   SubstructureRedirectMask FocusChangeMask          
    PropertyChangeMask       ColormapChangeMask       
  number of visuals:    120
  default visual id:  0x21
  visual:
    visual id:    0x21
    class:    TrueColor
    depth:    24 planes
    available colormap entries:    256 per subfield
    red, green, blue masks:    0xff0000, 0xff00, 0xff
    significant bits in color specification:    8 bits

There is also a problem, but it's not very relevant:
[drm:drm_debugfs_create_files] *ERROR* Cannot create /sys/kernel/debug/dri/IL�J���/3

No kernel parameters have been used, except from pcie_aspm=off which has always been there and I do not even know whether it is strictly necessary.

Created attachment 49551 [details]
Logs for Nouveau driver (git) working with acceleration (after few changes mainly from openSUSE/jobermayr)

Logs for Nouveau driver (git) working with acceleration (after few changes mainly from openSUSE/jobermayr and mainly to Mesa build options).

Need to find root cause of the bloody NoAccel problem resulting in black screen hang. It could be just Mesa build options but it needs to be carefully analysed and documented where most appropriate.

The only odd thing in Xorg.log is:

[   177.426] (II) AIGLX: Loaded and initialized /usr/lib64/dri/swrast_dri.so
[   177.426] (II) GLX: Initialized DRISWRAST GL provider for screen 0

What does that really mean ? I hope not that it's using the software rasterizer.

Hi Guido

If you apply this patch [1] the message "[drm:drm_debugfs_create_files] *ERROR* Cannot create /sys/kernel/debug/dri/IL�J���/3" should provide more meaningful output

Whereas for your issue I assume that X needs a dri driver even if AIGLX is disabled - i.e. when building your mesa make sure swrast is enabled [2]

Can this bug be marked as resolved?

Cheers
Emil

[1] http://lists.freedesktop.org/archives/dri-devel/2011-July/013317.html
[2] http://nouveau.freedesktop.org/wiki/GalliumHowto

I think the bug cannot be closed yet.

It used to get resolved by compiling Mesa with the following options (as in openSUSE as from jobermayr):

--enable-dri --enable-glx --enable-osmesa --with-dri-drivers=i810,i915,i965,nouveau,swrast --enable-shared-dricore --enable-gles1 --enable-gles2 --enable-openvg --enable-shared-glapi --with-gallium-drivers=i915,i965,nouveau,svga,swrast --enable-xcb --enable-xorg --enable-xa --enable-gallium-egl --with-egl-platforms=x11,drm --enable-debug --with-x --enable-gallium-llvm --enable-gbm --enable-gallium-gbm --enable-gallium-g3dvl --enable-xvmc --enable-vdpau --enable-texture-float --with-egl-displays=x11,drm --enable-selinux

...and everything was running fine until about the 3rd of August (all components from git, latest vanilla kernel).

Then recently (after syncing Mesa, libdrm, nouveau driver and so on from git) it is happening again unfortunately.

Mesa is currently building swrast_dri.so and it also used to build swrastg_dri.so until Aug 27th (not anymore as of Aug 28th).

And for the sake of precision:

- [1] should be already in git;
- [2] does not resolve the issue (build options and xorg.conf option).

Hi Guido

Can you please attach more recent logs - dmesg/Xorg.log

Cheers

Created attachment 50902 [details]
dmesg produced on 04092011 with driver from git 0e12a92fa2b887898b04c7f64edfd6d20122bdd9

Created attachment 50903 [details]
Xorg log produced on 04092011 with driver from git 0e12a92fa2b887898b04c7f64edfd6d20122bdd9

Hi Emil,

more recent logs have been attached as requested.

X server seems to be getting stuck at "NOUVEAU(0): Opened GPU channel 2" again with a blank unresponsive (backlit) screen.

It seems that it has resumed normal functioning with nouveau-drm git ffa83e36fa75baa63af89dd571226a2dac8288ac, Mesa git f0bfc0daa87578ce8b11383afb99dbf2d2630e23, Mesa GLUT git bca07f1fc0ba22055414cf78849e078d4978f347, Mesa libtxc_dxtn git a875bdef81facae08267c002590ad5b7f90e1eaf and libdrm git 2acaf160df584a5ef7b5c5b84819389948cd97ad on xserver 1.11.0.

And the xserver driver xf86-video-nouveau is at git version 169512fbe91f0671a90dfee5e280357f0a4ef701.

What was causing the problem ?

For a little while yesterday I could not build the whole of Mesa from git as there were build failures with gallium i915, gallium i916 and/or gallium nouveau but then it has been sorted at some point today.

With all due respect your issue does sound like an operator error or a miss-matched/incorrectly configured components - ddx/mesa/kernel

Build failures are not uncommon for git, if you look at the actual message you would be able to narrow down/resolve the problem

Most likely your build was resolved by 7e302168 (st/dri: remove the call to driInitExtensions)


Reported fixed, closing bug

It is now showing up again after building and installing the latest components from git (git from the last 24 hours or so).

It appears that this bug report has laid dormant for quite a while. Sorry we haven't gotten to it. Since we fix bugs all the time, chances are pretty good that your issue has been fixed with the latest software. Please give it a shot. (Linux kernel 3.10.7, xf86-video-nouveau 1.0.9, mesa 9.1.6, or their git versions.) If upgrading to the latest isn't an option for you, your distro's bugzilla is probably the right destination for your bug report.

In an effort to clean up our bug list, we're pre-emptively closing all bugs that haven't seen updates since 2011. If the original issue remains, please make sure to provide fresh info, see http://nouveau.freedesktop.org/wiki/Bugs/ for what we need to see, and re-open this one.

Thanks,

The Nouveau Team