Bug 30158

Can you provide Xorg and kernel logs from the failure?

Created attachment 38711 [details]
log files for "X throws error, restarts, then everything ok"

Created attachment 38712 [details]
log files for "blank screen with non blinking cursor in the upper left"

(In reply to comment #1)
> Can you provide Xorg and kernel logs from the failure?

I am adding attachments to my bug report. I don't know if this is the correct way? But I can't find an other way to do it. So please see for attachments to the original bug report to find the files you requested. BTW I am a almost complete linux newbie (just learned the basics but 20 years ago) so please bear with me if acting like a noob.

[ logs-X-starting.tar ] are the Kernel and X log files if X comes up (i.e. X throws an error and restarts after that everything fine). I have included the corresponding xorg.conf. Please note that X generates 5 log files for this case, I have included them all.

[ logs-X-blankscreen.tar ] are the Kernel and X log files if X doesn't come up and I receive that blank screen with a non-blinking cursor in the upper left. I can open a console, though, and have access to the log files for this case, too. X generates only 2 log files in this case. I have included the corresponding xorg.conf for this case, too. Please note: A non-existing xorg.conf leads to exactly the same result.

Best regards & thanks for taking care of this issue, Michael

try to blacklist vga16fb first - see https://wiki.ubuntu.com/X/Troubleshooting/Nouveau#Disable%20vga16fb

(the log says it is "not registering due to another framebuffer present", but it's not completely true)

(In reply to comment #5)
> try to blacklist vga16fb first - see
> https://wiki.ubuntu.com/X/Troubleshooting/Nouveau#Disable%20vga16fb
> 
> (the log says it is "not registering due to another framebuffer present", but
> it's not completely true)

I have blacklisted vga16fb via adding [ blacklist vga16fb ] to /etc/modprobe.d/blacklist-framebuffer.conf and verified with [ lsmod |grep -i vga16fb ] and [ hwinfo --gfx |grep -i vga16fb ] that it is not present (I hope that was sufficient?).

Now, if starting with a xorg.conf without error I receive the same result as before - blank screen with a non blinking cursor in the upper left, but terminals accessible.

So as far as I can see, blacklisting vga16fb does not make any difference. I still need an intentional error in xorg.conf to make X working. Do you need new log files for the case with vga16fb disabled?

Best regards, Michael

(In reply to comment #5)
> try to blacklist vga16fb first - see
> https://wiki.ubuntu.com/X/Troubleshooting/Nouveau#Disable%20vga16fb
> 
> (the log says it is "not registering due to another framebuffer present", but
> it's not completely true)

Thanks to your link I have now tried to enable nv. I had thought this would be very difficult and hard to undo but with your link it wasn't at all. Means I blacklisted nouveau on startup with nouveau.modeset=0 and tell X to use nv instead of nouveau. Result: nv runs without problems, and the performance is quite ok (sufficient for my needs, actually). So with nv I don't need to force an error in X anymore to bring X up.

Maybe this helps with circling the problem - nouveau runs fine on my internal monitor but fails with my external monitor whereas nv runs fine both on the internal monitor as the external monitor.

Again, if you need the log-files for this case, too, please give a note.

Best regards, Michael

(In reply to comment #5)
> try to blacklist vga16fb first - see
> https://wiki.ubuntu.com/X/Troubleshooting/Nouveau#Disable%20vga16fb
> 
> (the log says it is "not registering due to another framebuffer present", but
> it's not completely true)

I have interesting news. After I had enabled nv I checked with hwinfo --gfx and lsmod to see if it was active. It wasn't. Instead the system still reported nouveau to be active. That puzzled me quite a bit but explained why performance was so good. I then tried again to put [ driver "nouveau" ] into the xorg.conf while still [ nouveau.modeset=0 ] - hard crash (no terminals, requiring repair from live-cd). Next I tried xorg.conf with back to [ driver "nv" ] but removed the [ nouveau.modeset=0 ] boot-statement (the link you provided said "to enable nv make X to use [ driver "nv" ] and disable nouveau with [ nouveau.modeset=0 ]).

And - everything is fine now. X comes up perfectly without an error. And as far as I can tell from the output of hwinfo --gfx and lsmod I am not running nv but nouveau.

So my problem seems to be solved. The solution was to put [ driver "nv" ] into the xorg.conf instead of the "nouveau" which is documented. After that, X seems to be still using the nouveau driver, doesn't complain at all and comes up ok without having to force an error.

I'm adding an attachment containing kern.log, Xorg.0.log (there is only one logfile now), the output of lsmod, the output of hwinfo --gfx and my xorg.conf as they are now.

Please note nevertheless that this IS a (since probs come ONLY with the external monitor, minor) bug since live-cd will use an empty xorg.conf which fails to blank screen and if following documentation and creating an xorg.conf with [ driver "nouveau" ] this crashes. Means, as it comes out of the box (and I had a fresh install on a clean system) it does NOT work, and what you have to do to circumvent the problem is absolutely against the documentation and really not understandable if you ask me - I use nouveau but have to tell X to use nv though it can't, actually (should be error "modesetting driver in use"), but it doesnt report the modesetting-in-use-error (as it would for example with [ driver "vesa" ]) but then runs fine.

I'd be very thankful if you could check against my attached files whether I am now running nv or nouveau? I am still not sure about that.

From my side, if you could confirm nouveau is actually running, the problem is then solved since I have found a working circumvent. Thank you all very much for your help on this matter.

And one more bit of info: I also tried again, with [ nouveau.modeset=0 ] and vga16fb blacklisted to install the proprietary nvidia drivers. They still crash very hard requiring a restore. So this means, at least when referring to my system, nouveau (or nv?) does a far better job than nvidia - congratulations.

Best regards, Michael

PS Maybe it might be interesting to analyze further, I have always disabled the "splash" boot-option. Did not try with it, yet. If you want me to, please give a note.

Created attachment 38736 [details]
Log files for "X configured to driver nv but nouveau enabled"

had to gzip the tar because bugzilla didn't accept it saying it was too big

(In reply to comment #5)
> try to blacklist vga16fb first - see
> https://wiki.ubuntu.com/X/Troubleshooting/Nouveau#Disable%20vga16fb
> 
> (the log says it is "not registering due to another framebuffer present", but
> it's not completely true)

Well, I was a too quick. If I don't disable kernel mode setting for nouveau (omit nouveau.modeset=0) and set X to nv as in Message #8 X does come up, but I don't have terminals and the system might crash on shutting down. To be specific what I see is a random pattern of colored ascii signs when opening a terminal with for example CTRL+ALT+F1, and I see the same kind of pattern on shutdown.

I went back to the state of Message #7 - I disable nouveau kernel mode setting on boot and configure xorg.conf to use nv. This works fine, though I still don't know if I am running nouveau or nv (nouveau is reported to be active and can't find a trace of nv). Maybe you could help me on this matter, please.

Best regards, Michael

(In reply to comment #8)
> I have interesting news. After I had enabled nv I checked with hwinfo --gfx and
> lsmod to see if it was active. It wasn't. Instead the system still reported
> nouveau to be active. That puzzled me quite a bit but explained why performance
> was so good. I then tried again to put [ driver "nouveau" ] into the xorg.conf
> while still [ nouveau.modeset=0 ] - hard crash (no terminals, requiring repair
> from live-cd). Next I tried xorg.conf with back to [ driver "nv" ] but removed
> the [ nouveau.modeset=0 ] boot-statement (the link you provided said "to enable
> nv make X to use [ driver "nv" ] and disable nouveau with [ nouveau.modeset=0
> ]).

The "nv" driver has no kernel part at all, therefore it will never show up in lsmod, and I guess the same applies to hwinfo, since "nv" never registers with the kernel. "nv" pokes the hardware directly from user space, corrupting any state a proper kernel driver (nouveau) has set up.

If you have Nouveau KMS enabled (maybe even if you just have the nouveau kernel module loaded), "nv" X.org driver will corrupt the card state, and when the kernel driver attempts to do anything, it will probably crash somehow (just like you later experienced).

If you use *any* other X.org driver than "nouveau", then you *must* disable the Nouveau kernel module, or at least disable Nouveau KMS with nouveau.modeset=0.
Do note, that without an explicit X.org driver configuration, X will attemp several different drivers one by one, and use the one that happens to initialize.

> I'm adding an attachment containing kern.log, Xorg.0.log (there is only one
> logfile now), the output of lsmod, the output of hwinfo --gfx and my xorg.conf
> as they are now.

I haven't checked any of the logs, because they are packaged, and I'm not really that interested. Please, see http://nouveau.freedesktop.org/wiki/Bugs .

I just wanted to correct some misconceptions.

> I'd be very thankful if you could check against my attached files whether I am
> now running nv or nouveau? I am still not sure about that.

The X log should be fairly self-explanatory on that. And if you run Nouveau, the kernel log will have many lines (a lot more than 5) from nouveau. You will know, when you see them.

(In reply to comment #11)

Hello,

thanks for the clarifications and sorry about the packed log files, I didn't know that.

As you suggest I took a look into the log files myself. The log files for the config I have now (comes up without error, works fine) actually do show nv is used.

But in the log files for the other config that was at least working somehow (nouveau kernel mode setting enabled and X forced to throw an error) I really can't figure which driver is used. Don't find any output either for nv, nouveau or anything else that might be a driver.

The log file for the case "blank screen" does show nouveau is used, there is - as you say - a lot of output from it. But as far as I can tell there are no nouveau errors to be seen. So nouveau configured correctly does not work and does not throw an error. But only for the external monitor, internal monitor does work.

I hope somebody will be interested and take care of this bug. It took me such a long time and hard effort to get around this prob and also, I'd like to use a proper kernel mode driver (as you put it). Using the config that forces X to throw an error isn't really a permanent option, because a) I can't figure if that is using nouveau and b) this considerably makes startup time longer since it needs 2 user interactions plus an X server restart. Also, a config that begins with a system error is nothing I can trust in, might cause problems later I just didn't encounter yet.

I use nv now and wait to see if that bug gets fixed sometime.

Best regards, Michael

PS I don't think I have to disable / unload nouveau completely to use nv. I followed the link given above to the nouveau troubleshooting FAQ, and there they said, you may unload nouveau, but you don't have to - disabling kernel mode switching should be sufficient. I'd prefer to use nouveau when sometime the bug will be fixed so I don't want do disable it completely now. The nv config I have now works correct, as of yet I did not find any graphics related problem and I have checked quite some points now with it, so as of now I don't see the necessity / benefit of unloading nouveau completely.

(As an update to comment #12)

In the meanwhile I have clearly found that for the case when X throws an error and restarts, then all fine, nouveau actually IS running. hwinfo --gfx has an entry I had before overseen that says [ driver "nouveau" ] this entry is not present when running nv. Still, X log files don't have the slightest indication that nouveau was started, but it must be running. Which is also quite obvious, since with this case kernel mode setting is active and X cannot switch to any other driver. BTW it is quite easy to make X throw that error, do not disable kernel mode switching for nouveau (omit nouveau.modeset=0 in the boot options) but set the boot option xforcevesa. That will make X throw that error since it can't change to vesa ("kernel mode setting driver in use") regardless if there is a xorg.conf or not, and regardless of the content of xorg.conf.

This is a strange bug. It happens only for the external monitor and if X relies on the init done by nouveau, then the bug will come up (= blank screen, but terminals accessible). If X should do the init, but fails with it and restarts, the bug is gone.

For a beginner or for someone first installing ubuntu this is a hard hurdle. Definitely the live-cd won't install or run. One just sits in front of an empty screen. If one follows all the faqs on problems like this it will lead to no result or even heavy crashes, because what you have to do is against all documentation: do not block nouveau modeset but do enforce xforcevesa. Which leads to an X error but makes the system usable / installation possible. After once the system has been set up to get a clean system without system error, making the system possibly unstable, the only way is to go back to nv with blocking kernel mode setting for nouveau and configuring X to use nv.

As from my side, my problem is solved. As for nouveau, there IS a bug, and I hope it will be fixed in one of the next releases. Shouldn't be so difficult, I hope, since there is just some initialization / table lookup / whatever that X performs in case of init-error and nouveau doesn't in it's regular init. I hope that can be fixed sometime, since I'd prefer to use nouveau - from the little I saw, it is quite a bit superior to nv.

I thank everybody who has given me very valuable advice here that led my on the right path to find a solution for my problem, and again I apologize if I, as a linux-beginner, maybe at some points didn't behave as it is expected here.

To the makers of Linux/Ubuntu/Nouveau/other GPL software - thank you so much for keeping the idea of free software and free programming alive, and for all the efforts and hard work you contribute. Intel is planning now a "walled garden" for Intel-Processor-based software like Apple already has with its app-store (that's why Intel purchased McAfee as they recently explained on a press meeting), and if that happens, you guys are the only hope that software and programming will stay a free resource for free people.

Best regards, Michael

(In reply to comment #13)
> 
> In the meanwhile I have clearly found that for the case when X throws an error
> and restarts, then all fine, nouveau actually IS running. hwinfo --gfx has an
> entry I had before overseen that says [ driver "nouveau" ] this entry is not
> present when running nv. Still, X log files don't have the slightest indication
> that nouveau was started, but it must be running. Which is also quite obvious,
> since with this case kernel mode setting is active and X cannot switch to any
> other driver.

See my previous post, why I think hwinfo gets it wrong.

If X log does not have a lot of lines from NOUVEAU, (accelerated) Nouveau is *not* used by X.

It is quite possible to be able to start X with a user mode driver (that is, one that pokes the hardware bypassing the kernel), while still having a kernel mode driver active. This is a bug, and I recall some efforts have been made to detect it, but I would not count on it yet. The situation leads to an unstable system, where two drivers drive the same hardware without knowing about each other.

What happens with Ubuntu: it first tries the normal config, and if X fails, it will switch to a fail-safe config. I have no idea what drivers the fail-safe config tries to use. Quite likely "vesafb" is one of those, and is incompatible with Nouveau kernel mode driver, too.

The only X driver apart from "nouveau" that can work with the Nouveau kernel driver, is "fbdev". If it gets used automatically, you are fine, you just do not get any graphics acceleration whatsoever and probably lack other features, too. "fbdev" uses the generic kernel framebuffer interface, which is very much hardware agnostic.

I don't have the time to help you further now, or check your logs, but don't give up. It could be nice to boot Ubuntu to text-mode (non-graphical), set up Nouveau, and start X with the command 'startx'. When it fails, the fail-safe-X should not kick in. In that situation, the complete (starting at current boot-up) kernel and X logs would be most useful in debugging this.

More about KMS and checking if it is active:
http://nouveau.freedesktop.org/wiki/KernelModeSetting

Cheers.

Created attachment 38789 [details]
dmesg for startx from textonly console with nouveau enabled (fails to blank screen)

Created attachment 38790 [details]
kern.log for startx from textonly console with nouveau enabled (fails to blank screen)

Created attachment 38791 [details]
Xorg.0.log for startx from textonly console with nouveau enabled (fails to blank screen)

Created attachment 38792 [details]
xorg.conf for startx from textonly console with nouveau enabled (fails to blank screen)

(In reply to comment #14)

Hello,

I have established the test case as you suggested. Booted with kernel mode setting enabled and the option single 3 to receive a textonly console. xorg.conf was configured to use nouveau, then startx. The result was again this blank screen, but with terminals accessible (as before). From one of these terminals I saved the log-files dmesg, kern.log (shortened for the last boot), Xorg.0.log and the config-file xorg.conf. I have created attachments for these, find them above.

But this message is written with nouveau enabled! Your link in comment #14 finally brought a solution!

There is a section in the link (quite at the end) about the boot option video= and with this I now disable DVI-D-2 (video=DVI-D-2:d) but with, of course, kernel mode setting enabled and xorg.conf configured to nouveau, and then... nouveau starts and everything is fast, stable and perfect!

I came to the idea because I was puzzled about the Xorg log files. nv only talks of DVI-1 (DVI1 in it's log files), never any DVI-2, whereas nouveau always had entries for DVI-D-1 and DVI-D-2. But if the laptop is closed there is no DVI-2 (which would be the external monitor if laptop is open), then the external monitor is mapped to DVI-1 (which I concluded from the fact that nv is using DVI-1). So basically, I was (partially) right, the bug is a remapping / table lookup problem. The external monitor is connected to DVI-D-2 but if the internal monitor is inactive (closed laptop) this DVI-D-2 gets mapped to DVI-D-1 and exactly this is the point which nouveau is missing (but nv doesn't). But I wasn't right about the point that X does a "better" init, because what happens if you force X to throw the error that causes a X-server-restart, is, that X is using nv. Now, that I have finally seen nouveau alive, I can clearly distinguish what X actually was running under this condition - it was NOT nouveau, it must, although corresponding Xorg.0.log statements are missing, have been nv (much too fast for any vesa / vga driver type, and right resolution, too).

So thanks a lot for that very valuable link, and I hope the information about how to stop the failure can help to fix this bug.

I'd have never ever gone to such length to get this bug out if I had not before installed Ubuntu on an other system (with a NVIDIA GTX 295) where everything went completely fine and without any problems, and if I had not, from this install / usage, developed a real liking for Ubuntu already. Had I first tried to install Ubuntu on my laptop I'd have just discarded Ubuntu as unusable and incompatible. That's why I think fixing this bug could be worthwhile, although I am aware of the fact that maybe this is a problem not many people will have. On the other hand many laptops have external monitor connectors, and many laptops are used in the office in a desktop style (like I do). The remapping / table lookup problem might therefore affect a lot more machines than only mine or maybe even arises from some internal chaos in the NVIDIA Quadro FX 3800M, so it is well possible that this bug could be of concern to quite some users.

Best regards, and thanks again for your very very helpful advice, Michael

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