No live DE in Vivid using nouveau w/GeForce 7025/nForce 630a

Here's what Ubuntu GNOME Vivid 20150119 i386 boots to when it should display Try or Install. I was able to enter the advanced boot menu and run check disc for defects so I know it's not just a bad burn.

This bug has been reported on the Ubuntu ISO testing tracker.

A list of all reports related to this bug can be found here:
http://iso.qa.ubuntu.com/qatracker/reports/bugs/1412602

Oh, I forgot to mention that I have tried the nomodeset boot parameter to no avail.

Looks like this might be https://bugs.freedesktop.org/show_bug.cgi?id=87361

can you try disable MSI As mentioned in that bug report (kernel paramater: nouveau.config=NvMSI=0).

I tried the 3.19.0-031900rc5-generic mainline kernel on that installation and both mutter and compiz based DE's work OK with nouveau, but the nvidia module fails to build properly against that kernel. I haven't yet researched what kernel we intend to ship with Vivid.

I started some testing with Ubuntu GNOME 20150125 but it's been bumped to 20150126 now so I'll wait until I've repeated those tests with the latest build before commenting further.

The latest two daily builds are failing for what must be a totally unrelated issue because they're also failing with different hardware so I went back to testing the Ubuntu GNOME Alpha 2 live image and it does boot successfully with the boot parameter nouveau.config=NvMSI=0. So do we need to edit the bug tags? I'm thinking we may want to add linux but I'm not sure.

Trusty 3.13.0-44 was OK but 3.13.0-45 is affected.

This was fixed upstream with this patch:
http://git.kernel.org/cgit/linux/kernel/git/stable/stable-queue.git/tree/releases/3.18.4/drm-nv4c-mc-disable-msi.patch

This change was made by a bot.

Commit 4761703 is in mainline as of v3.19-rc4. It was also sent to stable.

Not applicable in upstream 3.13.
It is in upstream 3.16 as of v3.16.7-ckt5.
It is in upstream 3.18 as of v3.18.4.

Can folks affected by this bug test the following kernels to see if this bug is fixed:

 v3.16.7-ckt5: http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.16.7-ckt5-utopic/
v3.18.5: http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.18.5-vivid/

@ Joseph Salisbury,

I'll be glad to do that but it'll be a couple of days due to prior commitments.

@ Joseph Salisbury,

There seemed to be some improvement in Ubuntu GNOME Utopic with the amd64 version of 3.16.7-031607-generic, at least I was able to boot that kernel w/o adding the nouveau.config=NvMSI=0 boot parameter, but then after spending a couple of minutes fiddling around when I attempted to open the System Settings UI the screen tore and X froze. So nouveau is still a failure with that specific GPU.

I doubt it's arch specific so I'll move on to testing the Vivid mainline kernel next.

Perhaps oddly (perhaps not oddly at all) I decided to reboot and select GNOME Classic rather than booting into the standard GNOME Shell and it seems to work fine - no screen tearing or X-freezes under fairly heavy use. So maybe nouveau itself is simply not capable of running GNOME Shell.

I find that a bit odd as I'd assumed both use mutter but Tim could probably provide some insight in that regard. I should probably try that same kernel with Ubuntu in a Unity session to see what happens.

ATM I'm inclined to think that kernel fixes this specific issue, but that other underlying issues exist in nouveau itself which may actually be an Xorg issue beyond the scope of this bug ................ or is it???????

Lance, gnome-classic is gnome-shell with a bunch of extensions, so for classic to work and Shell not does seem odd. Was the issue in gnome-shell repeatable or a one of crash?

I have been able to reproduce that a few times in a gnome-shell session but it's not specific to any one task. It "crashed/froze" twice just looking for logs and once again while launching Firefox. OTOH I can use the classic session w/o a problem - in fact I'm streaming the nightly news right now.

I know that X actually freezes when the screen tears because I'd set Ctrl+Alt+Backspace to kill X and tested it in both sessions. When the screen tears as shown in the attached pic the keyboard is just totally unresponsive causing me to do a hard reset.

There are no .xsession-errors in Home and I don't see anything unusual in /var/log/Xorg.0.log but there is also an /var/log/Xorg.0.log.old that I can't read.

FYI sometime tomorrow I'll add some storage to that box so I can retain 4 or 5 installs at the same time. That way I can dig for logs and/or do some retesting without having to reinstall and update each time.

That looks like video corruption, and it is possible that gnome-classic has some of the animations disabled compared to gnome-shell, but I can't think of any other difference.

.xsession-errors is obsolete, logs will by default be in ~/.cache/upstart/gnome-session-GNOME.log under upstart boot or `journalctl -b /usr/bin/gnome-session` under systemd init.

But either way it seems likely that is a bug in Nouveau, so those logs might not be too useful either.

Sorry to take so long getting back to this. The affected PC is usually used as my media center but I've now been able to move it into my testing suite so hopefully once 14.04.2 milestone testing is out of the way I'll be able to respond more quickly and efficiently.

Regarding the screen corruption in Utopic I've now found that it does eventually occur even running GNOME Classic but just much less frequently than in a GNOME Shell session. This includes both the stock Utopic kernel as well as the 3.16.7-031607-generic kernel Joseph Salisbury requested I try.

So, moving on to Vivid for the moment - last night I installed Ubuntu GNOME Vivid Alpha 2 and this AM I booted it using the nouveau.config=NvMSI=0 boot parameter, then applied all available updates, and it seems to be running GNOME Shell just fine with the latest Vivid kernel using the nouveau driver:

lance@lance-AMD-desktop:~$ uname -r
3.18.0-13-generic

lance@lance-AMD-desktop:~$ sudo lshw -c video
[sudo] password for lance:
  *-display
       description: VGA compatible controller
       product: C61 [GeForce 7025 / nForce 630a]
       vendor: NVIDIA Corporation
       physical id: d
       bus info: pci@0000:00:0d.0
       version: a2
       width: 64 bits
       clock: 66MHz
       capabilities: pm msi vga_controller bus_master cap_list rom
       configuration: driver=nouveau latency=0
       resources: irq:21 memory:fb000000-fbffffff memory:e0000000-efffffff memory:fc000000-fcffffff memory:80000000-8001ffff

So some recent kernel update in Vivid appears to have fixed this issue. Is there still any point in trying the 3.18.5-031805-generic mainline kernel?

For the next 5 or 6 days I'll be shifting my focus almost totally onto 14.04.2, in fact my next two tests on this hardware will be 14.04.1 with the latest Trusty kernel and then 14.04.2 with the Utopic HWE.

I was encountering some issues installing 14.04.1 which I'll get into later, but for now I moved on to testing 14.04.2, this one installed w/Ubuntu-GNOME 14.04.2 LTS "Trusty Tahr" - Release amd64 (20150203), and while 3.16.0-30-generic was affected I pulled 3.16.0-31-generic from trusty-proposed and it appeared to be OK for a while, at least I was not getting the same screen corruption.

In fact I began a forum post from that Trusty install but before I was done the screen became unresponsive, but not entirely frozen because I could move the mouse pointer, then after a minute or two the screen displayed the error in the attached pic.

It turns out that both 14.04 and 14.04.1 are affected by this bug. I had to look in the installer log to see what version I'd begun with (and have been running on that box as my stable OS) = Ubuntu 14.04 LTS "Trusty Tahr" - Alpha i386 (20140129). So I was undoubtedly able to install Trusty at that point but hadn't noticed a problem because I was already using the third-party nvidia driver after that date.

@ Tim Lunn,

This is totally unrelated, but to be certain that Vivid is working properly w/3.18.0-13-generic I've been using it to post all of these messages and on the last boot apport presented me with a gdm error so I accepted the automated reporting which is bug #1421991. Poorly written for sure, but I really had no idea what was going on.

Lance, this is getting a little confusing to follow, can you file separate bugs for the corruption and lockups above.
The original nouveau.config=NvMSI=0 bug should be fixed in vivid now? is it fixed in trusty 14.04.2?

Hi Tim,

As far as I can tell ATM the only difference in most of these crashes/freezes/screen-corruptions is the frequency with which they occur and the screen color depending on what point during boot and/or operation the "freeze" occurs.

Like this is the pic I included with original bug report:

https://launchpadlibrarian.net/195348138/IMG_4796.JPG

And this is a pic from Ubuntu GNOME Utopic with the amd64 version of 3.16.7-031607-generic (mainline kernel):

https://launchpadlibrarian.net/196872607/IMG_4817.JPG

The frequency of crashes/freezes (or the point at which they occur) is sometimes random with the exact same images. Sometimes it may prevent me from even getting to the live desktop or booting to the desktop of an installed OS. Other times it may not happen until I'm performing some random task on the desktop. Or it may occur at any random point during installation.

It seems to affect Unity, GNOME Shell, and Flashback w/Compiz somewhat more frequently that GNOME Classic and I've not been able to reproduce this bug with the same versions of Lubuntu so I assume it's a "load" or "demand" related issue???

The one exception is 14.04.2 with 3.16.0-31-generic from trusty-proposed which may (or may not) fix this issue but results in an unrelated crash (see comment #19) so I'll check the changelogs and see if there is a tracking bug # to refer to. I'll then file a new bug report ASAP.

But yes, this does appear to be fixed in Vivid w/3.18.0-13-generic. I will be glad to try the 3.18.5-031805-generic mainline kernel in Vivid also if desired.

I should also probably test Utopic again and see if I can find the equivalent of trusty-proposed 3.16.0-31-generic since it really is part of the 14.04.2 LTS HWE for Trusty.

OK I did some more testing last night and this AM, so here's a quick recap to reduce any confusion (both for others and myself):

Vivid: This is fixed in 3.18.0-13 generic. I verified that this AM by testing the Ubuntu GNOME Vivid 20150215 amd64 iso.

Utopic: This is fixed in 3.16.0-31 generic which is in utopic-proposed. No additional problems were encountered.

Trusty with the Utopic HWE: This is fixed in 3.16.0-31 generic which is in trusty-proposed. The bug I mentioned in comment #19 was observed and I think it may be bug #1291574. I'll follow up on that separate issue appropriately ASAP.

Trusty with the OEM 3.13 series kernel: This remains under investigation. I know that both the 14.04 and 14.04.1 images are affected as well as 3.13.0-45-generic. I'll also follow up on this ASAP.

Regarding Trusty with the OEM 3.13 series kernel: This is NOT fixed in 3.13.0-46-generic from trusty-proposed. That can be verified because using the nouveau.config=NvMSI=0 boot parameter gets me past the screen corruption/X freeze. So evidently the upstream fix has not yet trickled down to the 3.13 series kernel.

No surprise but since the 14.04.2 20150217 images still have 3.16.0-30 generic they are affected.

Since it's a hardware specific corner issue I don't know if it's worth mentioning in the release notes or not.