Ubuntu Desktop ISO fails to boot with nouveau on a displayport

Bug #1723619 reported by Chris Glass on 2017-10-14
56
This bug affects 8 people
Affects Status Importance Assigned to Milestone
Linux
Confirmed
Medium
Release Notes for Ubuntu
Undecided
Unassigned
linux (Ubuntu)
Undecided
Unassigned

Bug Description

On the latest daily artful image (/current as of 2017-10-14), the following occurs on a system with nVidia graphics (on my system, a GTX970) when connected to a 4k display over a displayport: https://photos.app.goo.gl/gLUva3Vgvtv0lAmj2

Steps to reproduce:
- Download latest daily image, check checksums, burn to USB
- Boot from USB.
- Choose "Install Ubuntu" or "try ubuntu" at the menu.

This happens on the livecd, but also upon ugrading the system from a previous daily with a different kernel: my "old" daily booted and installed fine with kernel 4.12.0-12, then failed with same error once dist-upgraded.

On the faulty system I could test with, it seems to *only* happen over displayport/on a 4k screen (I don't own a non-4k displayport screen to test the 4k out).

summary: - System fails to boot with nouveau
+ Ubuntu Desktop ISO fails to boot with nouveau

This bug is missing log files that will aid in diagnosing the problem. While running an Ubuntu kernel (not a mainline or third-party kernel) please enter the following command in a terminal window:

apport-collect 1723619

and then change the status of the bug to 'Confirmed'.

If, due to the nature of the issue you have encountered, you are unable to run this command, please add a comment stating that fact and change the bug status to 'Confirmed'.

This change has been made by an automated script, maintained by the Ubuntu Kernel Team.

Changed in linux (Ubuntu):
status: New → Incomplete

I cannot run apport-collect because the livecd doesn't boot :(

Chris Glass (tribaal) wrote :

The livecd boots fine on another machine of mine with a nvidia GT 640 (so, an older generation), fromt eh same daily and same image burn.

I am out of extra hardware to try this on.

Ubuntu QA Website (ubuntuqa) wrote :

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/1723619

tags: added: iso-testing
Chris Glass (tribaal) wrote :

Another machine (GTX950m on an integrated screen) boots as well.

From my limited understanding of the error message in the screenshot - perhaps the problem is that the screen is connected to displayport (the GT 640 uses HDMI).

The failing system has a 4k screen connected to displayport.

Chris Glass (tribaal) wrote :

Switching the faulty system to using HDMI + 1080p succeeded. Updating bug description.

summary: - Ubuntu Desktop ISO fails to boot with nouveau
+ Ubuntu Desktop ISO fails to boot with nouveau on a displayport
description: updated
Changed in linux (Ubuntu):
status: Incomplete → Confirmed
Andy Whitcroft (apw) wrote :

I think from you description you can install this system from the new ISO using hdmi. Would you therefore be able to check out some of the interim kernels between 4.12.0-12 and 4.13.0-16 to see which of those work. They should be available in the launchpad librarian. Don't forget to install both linux-image and linux-image-extra when testing.

Chris Glass (tribaal) wrote :

I've done further testing as you suggested. Here's a breakdown of my findings:

I tested the following kernel versions on 4k + displayport (installed from launchpad librarian, with their matching -extra package and an "update-grub"):

- 4.12.0-12: Boots. System seems to crash after a few seconds on the 4k desktop (cannot switch VTs). Maybe a separate bug however, at least it makes it to login+desktop.

- 4.12.0-13: Boots. Same symptoms as previous kernel (crashes after a few seconds on the desktop).

- 4.13.0-10: Does not boot. Fails with a slightly different output than initially reported (see below)

- 4.13.0-11: Does not boot. Same symptoms.

- 4.13.0-12: Does not boot. Same symptoms. Screenshot https://photos.app.goo.gl/ztJvK7Im2LVCK0ss1

- 4.13.0-15: Does not boot. Same symptoms.

- 4.13.0-16: Does not boot. Same symptoms.

None of the tested kernels exhibit any problematic behavior when the HDMI + 1080p screen is plugged in.

Kai-Heng Feng (kaihengfeng) wrote :

Please try mainline kernel 4.13-rc*, so we can know which one contains the first bad commit that causes the regression.

Chris Glass (tribaal) wrote :

Tested all mainline kernels I could find for 4.13-rc*:

- 4.13-rc1: DisplayPort setup boots. Login screen appears. Choosing the default option (wayland) results in broken desktop (https://photos.app.goo.gl/xisx9EgTKTFoLXmJ3). Choosing the xorg fallback works perfectly.

- 4.13-rc2: DisplayPort setup boots. Login screen appears. Choosing the default option (wayland) results in broken desktop. Choosing the xorg fallback works perfectly.

- 4.13-rc3: DisplayPort setup does NOT boot (https://photos.app.goo.gl/ASCw1tDI6fHD1i6w1)

- 4.13-rc4: DisplayPort setup does NOT boot.

(could not find a -rc5)

- 4.13-rc6: DisplayPort setup does NOT boot.

- 4.13-rc7: DisplayPort setup does NOT boot.

Kai-Heng Feng (kaihengfeng) wrote :

Then it's highly likely that the culprit is one of the following commits:

$ git log --pretty=oneline v4.13-rc2..v4.13-rc3 drivers/gpu/drm | grep -E 'dp|nouveau'
38bcb208f60924a031b9f809f7cd252ea4a94e5f drm/nouveau/bar/gf100: fix access to upper half of BAR2
a90e049cacd965dade4dae7263b4d3fd550e78b6 drm/nouveau/disp/nv50-: bump max chans to 21
746c842d1f64caad81d82f0054c0e063c8aa5399 drm/nouveau/kms: remove call to drm_crtc_vblank_off() during unload/suspend
4a5431af19bc52c4dd491e989543c66a52380f00 drm/nouveau/kms/nv50: update vblank state in response to modeset actions
587f577e0beb4d20ee60bac8d21134b4c5a9fd29 drm/nouveau/disp: add tv encoders to output resource mapping
13a86519202c5d119d83640d6f781f3181205d2c drm/nouveau/i2c/gf119-: add support for address-only transactions
967003bb2cae121d345fd807eb757d9422229713 drm/dp: Don't trust drm_dp_downstream_id()
c11a93f5fd9229dc7c8b90570c75cf70bc3976c2 drm/dp: Fix read pointer for drm_dp_downsteam_debug()

Kai-Heng Feng (kaihengfeng) wrote :

Do you know how you build kernel? I can build test kernels in deb format if you don't know how to make one.

tags: added: nouveau
Chris Glass (tribaal) wrote :

As discussed on IRC kaihengfeng and I will sync up tomorrow and bissect the problem together.

Kai-Heng Feng (kaihengfeng) wrote :

Try kernel here: http://people.canonical.com/~khfeng/lp1723619-1/

Build on commit
4a5431af19bc52c4dd491e989543c66a52380f00 drm/nouveau/kms/nv50: update vblank state in response to modeset actions

Changed in linux (Ubuntu):
assignee: nobody → Kai-Heng Feng (kaihengfeng)
Chris Glass (tribaal) wrote :

The kernel at #14 fails to boot.

Kai-Heng Feng (kaihengfeng) wrote :

But "blacklist=nouveau modprobe.blacklist=nouveau" can boot, right?

13a86519202c5d119d83640d6f781f3181205d2c drm/nouveau/i2c/gf119-: add support for address-only transactions:
http://people.canonical.com/~khfeng/lp1723619-2/

Chris Glass (tribaal) wrote :

Blacklisting nouveau allows a full boot (at a very low screen resolution, obviously).

Kernel at #16 fails to boot.

Andy Whitcroft (apw) on 2017-10-17
Changed in ubuntu-release-notes:
status: New → Confirmed
Kai-Heng Feng (kaihengfeng) wrote :

Built on commit prior to c11a93f5fd9229dc7c8b90570c75cf70bc3976c2:
http://people.canonical.com/~khfeng/lp1723619-3/

Kai-Heng Feng (kaihengfeng) wrote :

The previous one is good.

Built on commit 967003bb2cae121d345fd807eb757d9422229713 drm/dp: Don't trust drm_dp_downstream_id():
http://people.canonical.com/~khfeng/lp1723619-4/

Kai-Heng Feng (kaihengfeng) wrote :

Chris said 967003bb2cae121d345fd807eb757d9422229713 is good.
So the bad commit is
13a86519202c5d119d83640d6f781f3181205d2c drm/nouveau/i2c/gf119-: add support for address-only transactions

Kai-Heng Feng (kaihengfeng) wrote :

Mainline kernel with 13a86519202c5d119d83640d6f781f3181205d2c reverted:
http://people.canonical.com/~khfeng/lp1723619-revert/

Seth Forshee (sforshee) wrote :

Unfortunately that commit says that it fixes regressions from something else, so I think it's too risky to simply revert it.

Have you tested any 4.14-rc kernels to see if the problem still exists there?

amano (jyaku) wrote :

uname -r
4.14.0-rc5-lp1723619+revert

That's (sadly) not my issue (the one that cropped up on October 6th. It took me 4 times again to have Plymouth not freezing/GDM starting up.

Chris Glass (tribaal) wrote :

I just tested 4.15-rc5 and the problem still persists.

A (bit painful) workaround if you don't have a choice:

- Boot liveCD, enable "expert mode" (F6 at boot menu"

- Edit the boot line to have "blacklist=nouveau modprobe.blacklist=nouveau" BOTH before AND after the "--" at the end of the line. The second part should transfer to your installed system.

- Boot into the live session. You now have horribly low resolution but it should allow you to run ubiquity.

- Install Ubuntu normally using horrible graphics

- Reboot. Hopefully your kernel cmdline parameters were saved and therefore you will reboot into a happy (still horrible) fresh system. Congratulations.

- If your reboot crashes odds are parts of the command line was not carried over. No worries, spam ESC to get in the grub menu then edit the kernel's entry to have both "blacklist=nouveau" and "modprobe.blacklist=nouveau". Boot into your ugly new system as previous point.

- Install the nvidia proprietary drivers: "sudo ubuntu-drivers" then install the appropriate nvidia-XXX package (was nvidia-384 in my case but it depends on your hardware).

- Reboot into hopefully glorious native resolution.

Chris Glass (tribaal) wrote :

For the record since I forgot to comment previously: kernel in #21 (mainline kernel with suspicious patch reverted) does boot fine with nouveau.

(However just reverting it will probably cause other regressions)

Chris Glass (tribaal) wrote :

A bug has been filed upstream here: https://bugs.freedesktop.org/show_bug.cgi?id=103351

Changed in linux:
importance: Unknown → Medium
status: Unknown → Confirmed
Changed in ubuntu-release-notes:
status: Confirmed → Fix Released
Steve Langasek (vorlon) on 2017-10-26
description: updated
Nikita (nikital) wrote :

I stumbled upon this bug independently running Fedora 27 on Lenovo T420 with GeForce 119M, but because I plugged the monitor only after the boot I have a stacktrace with hopefully helpful dmesg log. I attached the log to the upstream bug report.

Ersin (ersin-ertan) wrote :

Today's 18.04 upgrade from 17.10, using 4k or 1080 monitor with display port or with HDMI for Radeon RX 460 booting until bios,then screen flashing with jumbled colors every few seconds, shutdown displays Ubuntu logo.
Removing graphics card and using onboard HDMI for both is same as above, but shows Ubuntu loading animation, then no signal.
Starting without monitor the plugging in 1080 shows attached picture between flashing

Chris (cseilus) wrote :

Have a similar problem. Ubuntu 18.04 with nvidia gtx 970. After the screen locks, it's impossible to wake it up. Need to disconnect and reconnect power to get it working again.

chrone (chrone81) wrote :

Could not install on GTX960 as well. Hopefully, 18.04.1 ISO installer on next July 26th will fix this issue with Nvidia DisplayPort.

Kai-Heng Feng (kaihengfeng) wrote :

Please try drm-tip [1] for this issue, there are some new runtime PM fixes for nouveau.

[1] http://kernel.ubuntu.com/~kernel-ppa/mainline/drm-tip/current/

Changed in linux (Ubuntu):
assignee: Kai-Heng Feng (kaihengfeng) → nobody
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.