Nouveau - Sep 2010 - [Bug 30158] New: nouveau fails to display on external monitor

https://bugs.freedesktop.org/show_bug.cgi?id=30158

           Summary: nouveau fails to display on external monitor
           Product: xorg
           Version: unspecified
          Platform: x86-64 (AMD64)
        OS/Version: Linux (All)
            Status: NEW
          Severity: normal
          Priority: medium
         Component: Driver/nouveau
        AssignedTo: nouveau at lists.freedesktop.org
        ReportedBy: varp-b at gmx.de
         QAContact: xorg-team at lists.x.org


Hello,

I have an IBM/Lenovo Thinkpad W701. It has a NVIDIA Quadro FX 3800M built in. I
did a fresh install out of the box on a clean system with Ubuntu 10.04 64-bit.
As long as I am using the internal laptops monitor everything is fine and runs
very fast and stable.

But if I connect an external monitor via the docking stations DVI I receive a
blank screen with a non-blinking cursor in the upper left. X does start but it
is not visible (starting sound is heard). Also the console windows can be
accessed and used.

As I have found, forcing xorg.conf to throw an error, for example with a
statement anywhere in xorg.conf like "ForceError 1" which is not
parsable, X
will come up with an error saying something like "Syntax Error",
"X running in
low resolution", and then asks what I want to do. Please note that now
_this_
happens in a graphical display! I answer "run X with low settings for this
time", X says "restarting" and then everything is perfect and as
fast and
stable as with the internal monitor. X does _not_ run in low resolution, it
runs perfect just as with the internal monitor - if X has thrown an error
during init. Otherwise it is gone.

Seems like X does some preliminary initialization if it encounters an error in
the xorg.conf which nouveau has missed. But if X has correct config data it
assumes all necessary inits have already been made and nouveau displays its
screen somewhere in nirvana... X is reported to be running on screen 0 (which
would be correct), but the display actually is in nowhere-land.

I have searched for many days now but could not find a solution, for example an
additional init-command to be placed in xorg.conf. Though I can live with it
easily (have to press OK twice when starting, after that no problems at all)
this took me a long long time to get Linux installed, and it might arise from
some deeper problem not so easily to be circumvented by some other user. So I
decided to report this problem.

If you need any additional info please let me know. Have a good time, best
regards, Michael

PS: NVIDIA proprietary drivers don't run at all on my system. They crash
(very
early in the boot process requiring a reinstall/restore) whether internal or
external monitor is used. Using VESA of course isn't really an alternative
but
this runs without any problems. I didn't try NV yet and don't really
want to
(since this is a deep system operation hard to clean up and I have found a
circumvent working very good).

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

https://bugs.freedesktop.org/show_bug.cgi?id=30158

--- Comment #1 from Francisco Jerez <currojerez at riseup.net> 2010-09-14
05:24:12 PDT ---
Can you provide Xorg and kernel logs from the failure?

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

https://bugs.freedesktop.org/show_bug.cgi?id=30158

--- Comment #2 from Michael Boehm <varp-b at gmx.de> 2010-09-14 23:02:14
PDT ---
Created an attachment (id=38711)
 --> (https://bugs.freedesktop.org/attachment.cgi?id=38711)
log files for "X throws error, restarts, then everything ok"

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

https://bugs.freedesktop.org/show_bug.cgi?id=30158

--- Comment #3 from Michael Boehm <varp-b at gmx.de> 2010-09-14 23:04:46
PDT ---
Created an attachment (id=38712)
 --> (https://bugs.freedesktop.org/attachment.cgi?id=38712)
log files for "blank screen with non blinking cursor in the upper
left"

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

https://bugs.freedesktop.org/show_bug.cgi?id=30158

--- Comment #4 from Michael Boehm <varp-b at gmx.de> 2010-09-14 23:06:08
PDT ---
(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

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

https://bugs.freedesktop.org/show_bug.cgi?id=30158

--- Comment #5 from Marcin Slusarz <marcin.slusarz at gmail.com>
2010-09-15 08:33:42 PDT ---
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)

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

https://bugs.freedesktop.org/show_bug.cgi?id=30158

--- Comment #6 from Michael Boehm <varp-b at gmx.de> 2010-09-15 16:32:35
PDT ---
(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

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

https://bugs.freedesktop.org/show_bug.cgi?id=30158

--- Comment #7 from Michael Boehm <varp-b at gmx.de> 2010-09-16 00:11:28
PDT ---
(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

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

https://bugs.freedesktop.org/show_bug.cgi?id=30158

--- Comment #8 from Michael Boehm <varp-b at gmx.de> 2010-09-16 02:06:31
PDT ---
(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.

https://bugs.freedesktop.org/show_bug.cgi?id=30158

--- Comment #9 from Michael Boehm <varp-b at gmx.de> 2010-09-16 02:24:47
PDT ---
Created an attachment (id=38736)
 --> (https://bugs.freedesktop.org/attachment.cgi?id=38736)
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

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

https://bugs.freedesktop.org/show_bug.cgi?id=30158

--- Comment #10 from Michael Boehm <varp-b at gmx.de> 2010-09-16 13:49:55
PDT ---
(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

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

https://bugs.freedesktop.org/show_bug.cgi?id=30158

--- Comment #11 from Pekka Paalanen <pq at iki.fi> 2010-09-16 14:38:01 PDT
---
(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.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

https://bugs.freedesktop.org/show_bug.cgi?id=30158

--- Comment #12 from Michael Boehm <varp-b at gmx.de> 2010-09-16 23:09:10
PDT ---
(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.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

https://bugs.freedesktop.org/show_bug.cgi?id=30158

--- Comment #13 from Michael Boehm <varp-b at gmx.de> 2010-09-17 13:00:48
PDT ---
(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

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

https://bugs.freedesktop.org/show_bug.cgi?id=30158

--- Comment #14 from Pekka Paalanen <pq at iki.fi> 2010-09-18 01:14:23 PDT
---
(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.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

https://bugs.freedesktop.org/show_bug.cgi?id=30158

--- Comment #15 from Michael Boehm <varp-b at gmx.de> 2010-09-18 15:01:19
PDT ---
Created an attachment (id=38789)
 --> (https://bugs.freedesktop.org/attachment.cgi?id=38789)
dmesg for startx from textonly console with nouveau enabled (fails to blank
screen)

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

https://bugs.freedesktop.org/show_bug.cgi?id=30158

--- Comment #16 from Michael Boehm <varp-b at gmx.de> 2010-09-18 15:02:32
PDT ---
Created an attachment (id=38790)
 --> (https://bugs.freedesktop.org/attachment.cgi?id=38790)
kern.log for startx from textonly console with nouveau enabled (fails to blank
screen)

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

https://bugs.freedesktop.org/show_bug.cgi?id=30158

--- Comment #17 from Michael Boehm <varp-b at gmx.de> 2010-09-18 15:03:50
PDT ---
Created an attachment (id=38791)
 --> (https://bugs.freedesktop.org/attachment.cgi?id=38791)
Xorg.0.log for startx from textonly console with nouveau enabled (fails to
blank screen)

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

https://bugs.freedesktop.org/show_bug.cgi?id=30158

--- Comment #18 from Michael Boehm <varp-b at gmx.de> 2010-09-18 15:04:14
PDT ---
Created an attachment (id=38792)
 --> (https://bugs.freedesktop.org/attachment.cgi?id=38792)
xorg.conf for startx from textonly console with nouveau enabled (fails to blank
screen)

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

https://bugs.freedesktop.org/show_bug.cgi?id=30158

--- Comment #19 from Michael Boehm <varp-b at gmx.de> 2010-09-18 15:48:22
PDT ---
(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 videoand
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

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

https://bugs.freedesktop.org/show_bug.cgi?id=30158

Marcin Slusarz <marcin.slusarz at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #38789|application/octet-stream    |text/plain
          mime type|                            |

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

https://bugs.freedesktop.org/show_bug.cgi?id=30158

Marcin Slusarz <marcin.slusarz at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #38790|text/x-log                  |text/plain
          mime type|                            |

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

https://bugs.freedesktop.org/show_bug.cgi?id=30158

Marcin Slusarz <marcin.slusarz at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #38791|text/x-log                  |text/plain
          mime type|                            |

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

https://bugs.freedesktop.org/show_bug.cgi?id=30158

Marcin Slusarz <marcin.slusarz at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #38792|application/octet-stream    |text/plain
          mime type|                            |

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

https://bugs.freedesktop.org/show_bug.cgi?id=30158

Ilia Mirkin <imirkin at alum.mit.edu> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |INVALID

--- Comment #20 from Ilia Mirkin <imirkin at alum.mit.edu> ---
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

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/nouveau/attachments/20130818/5e4bc3ed/attachment-0001.html>