Project

General

Profile

Bug #11831

NVIDIA Maxwell series graphic card: X.Org doesn't start, or slow graphics operations

Added by Entriel about 3 years ago. Updated about 2 years ago.

Status:
Resolved
Priority:
Normal
Assignee:
-
Category:
Hardware support
Target version:
Start date:
04/10/2017
Due date:
% Done:

100%

Feature Branch:
feature/12732-linux-4.12
Type of work:
Code
Blueprint:
Starter:
Affected tool:

Description

Firstly, the problem has started with Tails 2.0, before that between versions 1.3.2 and 1.8.2 I used Tails with the same hardware with no difficulties. I opened a bug here back then, but it was merged with [[https://labs.riseup.net/code/issues/10298]]. I was hoping that the new kernel would be the end of my problem and was happy to hear that you manage to update Tails to the 4.x kernel in version 2.6 instead of 3.0. Yet the problem is not solved in this version, so I decided to delve into the reason of the problem myself, to the point of my knowledge and intellect of course.

My problem:

I have a NVidia GeForce GTX 970M video card in my
laptop.It is the only VGA in the laptop, so there is 
no problem like detecting an Intel onboard one or 
such. 
All graphic operations are slow. OS works in about 0.5 
fps. I can see the screen loading the next frame from 
top to bottom. Other then that everything works fine. 
It's like the OS works in the background just fine, 
but sends me only screenshots every now and then as a 
display option.

I saw that at the boot time, after I choose "Live" from the menu, the system prints the message below for a short time, and then goes to the login screen. The message disappears pretty quick, but I managed to take a photo of it, so I know what it says.

Loading, please wait...
[    2.086560] mmc0: Unknown controller version (3). You may experience problems.
[    2.151987] nouveau 0000:01:00.0: firmware: failed to load nvidia/gm204/gr/sw_nonctx.bin (-2)
[    2.152041] nouveau 0000:01:00.0: gr ctor failed, -2

After that I decided to check the logs to see if there is any failure log exists. Boot log was clean, but I believe I found what I was looking for in "Xorg.0.log". I am attaching the log file here, so that you can check it too.
If I followed the log correctly, the system uses VESA driver instead of the expected Nouveau one for NVidia hardware. Since VESA is the basic of the basic and the last resort to show something to user, I believe I am closing on on the problem.

At this point I decided to check the websites of Xorg and nouveau to see if there is any known problems with my video card. I saw that nouveau is the only open-source nvidia driver solution for linux, and nvidia does not make their jobs easy for them, so they are following the cards a little bit from behind. Yet I also see that they are claiming that with their latest stable release they are now supporting(at least for basic operations(?)) the Maxwell series devices (970M is one of them with GM204 Board). Nouveau's latest stable version is 1.0.12, but if I interpreted the log right, we are using the version 1.0.11. If I'm not mistaken, there is more than one year's work between these versions and the most of that work is on Maxwell devices.

Now, after defining my problem and giving all the info I've found about it, I have two questions(I would be very happy if you could find time to answer them):

1. Why are we using nouveau version 1.0.11 instead of 1.0.12?
2. If using 1.0.12 would not help, can't we use Nvidia's own driver instead of the opensource one? 
What would be the risks of using it, and how could we install it in our own Tails setups in a persistent way, if Tails team decides not to use them and we decide that we could take that risk?

Please ask any necessary information I may provide. I could happily do some tests if you point me in the right direction, and I could try testing any nightly build iso files. I have a pretty decent internet connection, so downloading and testing them would not be a problem for me.

Thank you for your time. I hope we could solve this.

PS: I kow that my bug report is a little bit different, but I do not mean to disrespect anyone. My aim was only to be as helpful as possible while conveying my ongoing problem. Please bear in mind that English is not my native language and i may have unintentionally sound somewhat rude. I can see that my wording of the issue is not exactly appropriate, but I was barely able to (I hope) convey my thoughts. So I again ask for your forgiveness.

PPS: [[https://labs.riseup.net/code/issues/11180]] looks related to my problem, but since they are not able to boot at all, I believe they may have some other problems as well.

Xorg.0.log View - Xorg.0.log (61.8 KB) Entriel, 09/23/2016 05:31 PM

Xorg.0.log View - Xorg log after adding nouveau.modeset=0 to the kernel command line (61.6 KB) Entriel, 09/24/2016 12:00 PM

Xorg.0.log View - Xorg.0.log of Tails v1.8.2 (66.9 KB) Entriel, 09/25/2016 08:54 AM

boot.log View - tails-amd64-feature_stretch-3.0-20161221T1625Z-febdcdc.iso (8.11 KB) Entriel, 12/22/2016 08:17 PM

config.log View - tails-amd64-feature_stretch-3.0-20161221T1625Z-febdcdc.iso (2.41 KB) Entriel, 12/22/2016 08:17 PM

Xorg.0.log View - tails-amd64-feature_stretch-3.0-20161221T1625Z-febdcdc.iso (75.4 KB) Entriel, 12/22/2016 08:17 PM

journalctl.log View - journalctl -a "tails-amd64-feature_stretch-3.0-20161221T1625Z-febdcdc.iso" (1.61 MB) Entriel, 12/24/2016 02:18 AM

journalctl-a-ubuntu-16.10-nomodeset.log View - Ubuntu Desktop 16.10 live nomodeset journalctl (406 KB) Entriel, 01/05/2017 01:13 AM

journalctl-a-ubuntu-16.10.log View - Ubuntu Desktop 16.10 live default journalctl (1.43 MB) Entriel, 01/05/2017 01:13 AM

journalctl-nightly-06012016-nomodeset.log View (2.88 MB) Entriel, 01/06/2017 08:47 PM

journalctl-nightly-06012016.log View (4.98 MB) Entriel, 01/06/2017 09:04 PM

jctl.log View - Journalctl -a "tails-amd64-bugfix_11831-newer-nouveau-xorg-driver-3.0-beta4-20170320T1533Z-6828082+feature_stretch@6b4d23d.iso" (2.57 MB) Entriel, 03/20/2017 05:50 PM

jctla.log View (4.87 MB) Entriel, 04/02/2017 02:32 PM

jctla_nms.log View (2.83 MB) Entriel, 04/02/2017 02:32 PM

3c3fcdfb2a7baf73f2734ff4178915ca.gpg (56.8 KB) anonym, 05/16/2017 11:15 AM

jctla-3.0.rc1-noaccel.log View - 3.0.rc1 - nouveau.noaccel=1 (157 KB) Entriel, 05/27/2017 11:19 AM


Related issues

Related to Tails - Bug #11180: Tails >= 2.0 locks up during boot when using some Nvidia graphic cards Rejected 02/29/2016
Related to Tails - Bug #11853: ISO build from devel fails with mesa 12.0.3-1~bpo8+1 Resolved 09/30/2016
Related to Tails - Bug #12542: Consider installing xserver-xorg-legacy Resolved 05/16/2017
Related to Tails - Bug #12438: Document workarounds for NVIDIA Maxwell series graphics cards Resolved 04/10/2017
Related to Tails - Bug #14697: Document workaround for Tails freezing with NVIDIA GTX 1080 when HTC Vive headset is connected to HDMI Resolved 09/21/2017
Related to Tails - Bug #15116: X.Org does not start with some NVidia Maxwell and Pascal graphic cards Confirmed 12/27/2017
Blocked by Tails - Bug #12116: cupsd AppArmor profile fails to load on Stretch Resolved 01/07/2017
Blocks Tails - Feature #13234: Core work 2017Q3: Foundations Team Resolved 06/29/2017
Blocked by Tails - Feature #12732: Upgrade Linux to 4.12 Resolved 06/18/2017

Associated revisions

Revision 54e58e8f
Added by anonym over 2 years ago

Merge remote-tracking branch 'origin/feature/12732-linux-4.12' into devel

Fix-committed: #12732, #11831, #12730

History

#1 Updated by intrigeri about 3 years ago

  • Related to Bug #11180: Tails >= 2.0 locks up during boot when using some Nvidia graphic cards added

#2 Updated by intrigeri about 3 years ago

  • Assignee set to Entriel
  • QA Check set to Info Needed
> Loading, please wait...
> [    2.086560] mmc0: Unknown controller version (3). You may experience problems.
> [    2.151987] nouveau 0000:01:00.0: firmware: failed to load nvidia/gm204/gr/sw_nonctx.bin (-2)
> [    2.152041] nouveau 0000:01:00.0: gr ctor failed, -2
> 

It would be interesting to see if adding the missing firmware (that can be found at https://git.kernel.org/cgit/linux/kernel/git/firmware/linux-firmware.git/tree/nvidia/gm204/gr) helps. I'll build an experimental ISO image that includes it, so you can test this, once you've reported about the simpler test I'm asking you to do below.

Now, it seems that this might not be enough as there could be a bug in Linux 4.6's nouveau driver that affects this graphics adapter:

Also, can you try adding nouveau.modeset=0 to the kernel command line in the bootloader menu?

Yet I also see that they are claiming that with their latest stable release they are now supporting(at least for basic operations(?)) the Maxwell series devices (970M is one of them with GM204 Board).

https://nouveau.freedesktop.org/wiki/FeatureMatrix/ says that for the NV110 family, basic 2D support is WIP. So I'm not surprised it does not work well.

1. Why are we using nouveau version 1.0.11 instead of 1.0.12?

Tails is based on Debian stable. If someone backported xserver-xorg-video-nouveau for jessie-backports we could include it.

2. If using 1.0.12 would not help, can't we use Nvidia's own driver instead of the opensource one?

No, we're not including non-free software that runs on the main CPU.

What would be the risks of using it, and how could we install it in our own Tails setups in a persistent way, if Tails team decides not to use them and we decide that we could take that risk?

This would not be supported and you would entirely be on your own (starting with the risks analysis). Sorry!

#3 Updated by emmapeel about 3 years ago

  • Description updated (diff)

#4 Updated by Entriel about 3 years ago

I've tried adding nouveau.modeset=0 to the kernel command line as you asked. The problem persists, but there is a little bit of a difference between the outputs.

This time the message after the selection 'Live' does not include the last two lines. It is as below now:

Loading, please wait...
[    2.xxxxxx] mmc0: Unknown controller version (3). You may experience problems.

And the new Xorg.0.log is attached here.

Tails is based on Debian stable. If someone backported xserver-xorg-video-nouveau for jessie-backports we could include it.

I couldn't find a package for it. But it seems that the Debian Stretch(testing) has version 1.0.12, and Debian Sid(unstable) has version 1.0.13(it seems it came out 2 days ago) packages. So they are on the way.

No, we're not including non-free software that runs on the main CPU.

Excuse my ignorance. You are right of course.

This would not be supported and you would entirely be on your own (starting with the risks analysis). Sorry!

Thank you anyway, I can see why discouraging people from doing that is a wise thing to do from your point of view. I will try things out by myself then.

If there is any more info needed please let me know, and I will be waiting for a link of the experimental iso you mentioned.

#5 Updated by intrigeri about 3 years ago

  • Status changed from New to Confirmed
  • Assignee changed from Entriel to intrigeri
  • Target version set to Tails_2.7
  • QA Check changed from Info Needed to Dev Needed

I'll build an ISO that includes the missing firmware; if this helps I'll ask the Linux maintainers in Debian to include it. But I have little hope that it works, so likely this will be postponed to whenever someone prepares + maintains a backport of the nouveau driver (ideally), or to Tails 3.0 that will have a newer nouveau driver for free.

#6 Updated by intrigeri about 3 years ago

  • Subject changed from Tails 2.6 ongoing NVidia Maxwell series graphic card driver problem to Slow graphics operations with NVidia Maxwell series graphic card

#7 Updated by Entriel about 3 years ago

I will be waiting for the ISO file then.

Btw I have some new information about the issue. As I mentioned before Tails 1.8.2 was working perfectly well with the same hardware configuration. So I decided to give it a go and compare the outputs to see what has changed since then.

I saw that Tails 1.8.2 also gives the message below, but there is nothing related to any missing firmware in the message.

Loading, please wait...
[    2.xxxxxx] mmc0: Unknown controller version (3). You may experience problems.

The shocker was to see that according to the Xorg.0.log v1.8.2 also uses the Vesa driver in my hardware configuration, but I experience no problems with it.
So it seems that not using nouveau is not the reason of this problem. Vesa seems to work just alright. I guess I still have no acceleration support with Vesa, but it's not 0.5 fps either.

So I looked for any other differences in the Xorg.0.log file and I saw that only other difference is on extension modules of Xorg server.

According to the log:

  • Tails 2.6 has (sub)modules: glx, nouveau, nv(!), modesetting(!), fbdev(!), vesa, fbdevhw(!), vbe, int10, ddc, shadow, fb, and evdev
  • Tails 1.8.2 has (sub)modules: extmod, dbe, glx, record, dri, dri2, nouveau, nv(!), vesa, fbdev(!), fbdevhw(!), vbe, int10, ddc, shadow, fb, and evdev
  • (!) means the module is unloaded and underlined modules are the extra ones.
    There are also a lot of extensions in v1.8.2 while v2.6 does not have any.

So I'm thinking that the problem may indeed be with the missing firmware or maybe one of the missing module or extensions of Xorg may be the solution we are looking for.

I'm attaching the Xorg.0.log of v1.8.2 here for you to compare it too.

#8 Updated by intrigeri about 3 years ago

The shocker was to see that according to the Xorg.0.log v1.8.2 also uses the Vesa driver in my hardware configuration, but I experience no problems with it.
So it seems that not using nouveau is not the reason of this problem. Vesa seems to work just alright. I guess I still have no acceleration support with Vesa, but it's not 0.5 fps either.

With Tails 1.x, the vesa driver can plausibly have had good enough performance.
With Tails 2.x (and GNOME Shell), it can't.
I think this explains what you're reporting.

#9 Updated by intrigeri about 3 years ago

FTR there's already a Debian bug report about including the GM20x firmware: https://bugs.debian.org/823637

#10 Updated by intrigeri about 3 years ago

  • Subject changed from Slow graphics operations with NVidia Maxwell series graphic card to Slow graphics operations with NVIDIA Maxwell series graphic card

#11 Updated by Entriel about 3 years ago

With Tails 1.x, the vesa driver can plausibly have had good enough performance.
With Tails 2.x (and GNOME Shell), it can't.
I think this explains what you're reporting.

I guess you are right, but the performance difference is so huge it seems strange.

With Tails 1.x I get 30+ fps (a 30fps video plays normally, I don't know what the actual frame rate is)
With tails 2.x I get about 0.5 fps.

So there is at least a 60x performance difference between them.

FTR there's already a Debian bug report about including the GM20x firmware: https://bugs.debian.org/823637

That is a nice find. So this sums some things up. You wouldn't include the non-free firmware and nouveau currently does not work without it for GM20x devices.

So we have two options remaining then.
we either
  • will wait for nouveau team to fully support GM20x devices without a signed firmware
    • which may even be not possible because of Nvidia's stand on this topic.
    • even if it's possible, considering that the nouveau team does not sound so confident that they could solve this problem, it could take much more time then I'm comfortable with. The Maxwell cards are currently 2 years old and Nvidia already released the next card family. And I'm waiting for the solution of this problem from the release time of Tails 2.0.
or
  • will try to find out why Vesa driver performance degrades this much in Tails 2.x
    • adding any of the Xorg extensions which was included in Tails 1.x may or may not help with this.

If you are willing to try our luck on option two, which seems to be the only logical option remaining now, I will be more than happy to try and help you with anything I can.

Otherwise only other solution remaining to me is to learn how to compile and build a Tails iso from your git repository and try to add non-free firmware myself before building the iso and repeating the process for every stable release of Tails from now on.

Btw I'm still waiting for the experimental ISO, if you think it may be wise to try it anyway. It will not be a problem for me to download and test it, if it's not a problem for you to build and share it.

#12 Updated by intrigeri about 3 years ago

  • Status changed from Confirmed to In Progress
  • % Done changed from 0 to 10
  • Feature Branch set to bugfix/11831-nvidia-maxwell-firmware

#13 Updated by intrigeri about 3 years ago

  • Assignee changed from intrigeri to Entriel
  • QA Check changed from Dev Needed to Info Needed

So there is at least a 60x performance difference between them.

… which is totally expected.

So we have two options remaining then.
we either
  • will wait for nouveau team to fully support GM20x devices without a signed firmware
    • which may even be not possible because of Nvidia's stand on this topic.
    • even if it's possible, considering that the nouveau team does not sound so
      confident that they could solve this problem, it could take much more time then I'm
      comfortable with. The Maxwell cards are currently 2 years old and Nvidia already
      released the next card family. And I'm waiting for the solution of this problem from
      the release time of Tails 2.0.

Either the latest nouveau driver + firmware supports your card, and then a backport would solve the problem and we would include the needed firmware => one needs to find someone in Debian to prepare & maintain the backport (I don't think I'll do that myself given we plan to migrate to Debian Stretch in a bit more than 6 months, so committing to maintain a backport for 3 years is not something I'm going to do, I think; one option could be to do a Tails-specific backport, but I'm not super enthusiastic at this idea; I would need to know more about how many graphics cards would benefit from it). Or it doesn't, and then there's not much we can do on the Tails side.

or
  • will try to find out why Vesa driver performance degrades this much in Tails 2.x
    • adding any of the Xorg extensions which was included in Tails 1.x may or may not help with this.

I would not bet anything at all on making the Vesa driver able to run GNOME Shell smoothly. If I were you, I would just forget this option.

Another option might be to add to that box a cheap graphics card that works fine on Linux. I'm truly sorry that recent shiny high-end graphics adapters produced by brands that don't help free software much are poorly supported on Linux, but that's not something we at Tails can do much about :/

Btw I'm still waiting for the experimental ISO,

"still", seriously? It actually required some work, hence some time, to produce it. Even Tails developers happen to enjoy week-ends sometimes. I did that work over the week-end anyway, and an experimental ISO should appear in http://nightly.tails.boum.org/build_Tails_ISO_bugfix-11831-nvidia-maxwell-firmware/lastSuccessful/archive/ within 24h.

#14 Updated by Entriel about 3 years ago

Either the latest nouveau driver + firmware supports your card, and then a backport would solve the problem and we would include the needed firmware => one needs to find someone in Debian to prepare & maintain the backport (I don't think I'll do that myself given we plan to migrate to Debian Stretch in a bit more than 6 months, so committing to maintain a backport for 3 years is not something I'm going to do, I think; one option could be to do a Tails-specific backport, but I'm not super enthusiastic at this idea; I would need to know more about how many graphics cards would benefit from it). Or it doesn't, and then there's not much we can do on the Tails side.

I see, I totally agree with you on this point. If nouveau driver + firmware is an acceptable solution, and since we saw that people are adding the latest nouveau drivers to Debian Stretch, waiting for it is the logical decision. I think it's still early to even think about a Tails-specific backport. There is still other possible solutions. So there is no need to even think about adding more work to your already cramped schedules.

I would not bet anything at all on making the Vesa driver able to run GNOME Shell smoothly. If I were you, I would just forget this option.

Oh, ok. Thank you for your opinion. I value your expertise on the point and will not waste my time on it as you suggested.

Another option might be to add to that box a cheap graphics card that works fine on Linux. I'm truly sorry that recent shiny high-end graphics adapters produced by brands that don't help free software much are poorly supported on Linux, but that's not something we at Tails can do much about :/

Hmm, I will look up if I could use an external cheap and supported VGA. This option didn't occur to me. Thanks for pointing it out.
Before this problem I didn't know NVidia's stand on free software about their products. In fact I was thinking that they were supporting it just by releasing linux drivers in their website's support sections. There is nothing you can do about it. Your decision to not include non-free software that runs on the main CPU is a solid one from security point of view, and I feel much more safe and happy because of it. I would live with this problem but not with a compromised security :).

"still", seriously? It actually required some work, hence some time, to produce it. Even Tails developers happen to enjoy week-ends sometimes. I did that work over the week-end anyway, and an experimental ISO should appear in http://nightly.tails.boum.org/build_Tails_ISO_bugfix-11831-nvidia-maxwell-firmware/lastSuccessful/archive/ within 24h.

See, I was apologizing about my english in my first post just because these kind of situations. I was not trying to be impatient. I greatly value your time and in fact feel thankful that you even answered my questions at the weekend. I was just trying to convey that if you decided to not try the ISO, I'm not aware of your decision and think that you will provide a link at an available time. I was just trying to ask if you will still share an ISO with me or not.

And thank you for the link. After it became available, I will test it out in my earliest convenience.
I just feel enthusiastic about fixing this bug. Sorry to drag you into my enthusiasm in your weekend. I'm really thankful for your support.

#15 Updated by Entriel about 3 years ago

Well, bad news as you've pretty much expected.

Experimental iso didn't work either. The error message has changed as below. But Xorg log is pretty much the same. System still seems to use the Vesa driver.

Loading, please wait...
[    2.087824] mmc0: Unknown controller version (3). You may experience problems.
[    2.153182] nouveau 0000:01:00.0: fb: init failed, -22
[    2.153355] nouveau 0000:01:00.0: init failed with -22
[    2.153410] nouveau: DRM:00000000:00000000: init failed with -22

Now that I look at it, it seems that adding a firmware to this nouveau driver is probably pointless. Because the driver is dated August 28th 2014, while GM204 cards got released October 7th 2014.

But according to this article (http://www.phoronix.com/scan.php?page=article&item=nouveau-maxwell-kepler&num=1), nouveau 1.0.12 works for GTX980 along with a lot of other cards from Maxwell series with Linux 4.6 kernel. Also news below from https://nouveau.freedesktop.org/wiki/ seems to support this claim.

Mar, 2016: GM20x acceleration support (with redistributable signed firmware) merged in Linux 4.6 and Mesa 11.2

Articles benchmark configuration:

Ubuntu 16.04 x86_64 with the Linux 4.6 Git kernel following the DRM-Next merge, xf86-video-nouveau 1.0.12 DDX, and Mesa 11.3-devel Git from the Oibaf PPA

According to this (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=823637), Nvidia released the firmware in February 2016, and the article above is from March 2016, so I am hopeful about nouveau 1.0.12.

So I guess this bug will have to wait for either nouveau 1.0.12+ to get ported to Debian Jessie, or Tails to use Debian Stretch which already have nouveau 1.0.12 package. Am I right?

PS: I will direct my research according to this article(http://www.phoronix.com/scan.php?page=news_item&px=Nouveau-Vs-Modesetting) now. It seems to indicate that xf86-video-modesetting could be a possible alternative.

#17 Updated by intrigeri about 3 years ago

  • Assignee changed from Entriel to intrigeri
  • Target version changed from Tails_2.7 to Tails_3.0
  • QA Check changed from Info Needed to Dev Needed

Well, bad news as you've pretty much expected.

Experimental iso didn't work either.

Thanks for testing and confirming. Too bad :(

Now that I look at it, it seems that adding a firmware to this nouveau driver is probably pointless. Because the driver is dated August 28th 2014, while GM204 cards got released October 7th 2014.

But according to this article (http://www.phoronix.com/scan.php?page=article&item=nouveau-maxwell-kepler&num=1), nouveau 1.0.12 works for GTX980 along with a lot of other cards from Maxwell series with Linux 4.6 kernel. Also news below from https://nouveau.freedesktop.org/wiki/ seems to support this claim.

Mar, 2016: GM20x acceleration support (with redistributable signed firmware) merged in Linux 4.6 and Mesa 11.2

So not only we need to include the firmware and a newer nouveau driver, but we also need a newer Mesa (jessie-backports only has 11.1.3-1~bpo8+1 at the moment).

So I guess this bug will have to wait for either nouveau 1.0.12+ to get ported to Debian Jessie, or Tails to use Debian Stretch which already have nouveau 1.0.12 package. Am I right?

Exactly. At this point I'm giving up until either all the missing pieces (except the firmware, that we can include ourselves) are in jessie-backports, or Tails 3.0 (based on Debian Stretch), whichever happens first.

#18 Updated by intrigeri about 3 years ago

  • Related to Bug #11853: ISO build from devel fails with mesa 12.0.3-1~bpo8+1 added

#19 Updated by intrigeri about 3 years ago

intrigeri wrote:

So not only we need to include the firmware and a newer nouveau driver, but we also need a newer Mesa (jessie-backports only has 11.1.3-1~bpo8+1 at the moment).

Mesa 12.0.3 made it into jessie-backports, and it'll probably be included in Tails 2.8 (#11853). So the missing pieces now are the firmware (that we could include ourselves, as done in the feature branch) and the xserver-xorg-video-nouveau backport... or waiting for Tails 3.0.

#20 Updated by Entriel about 3 years ago

intrigeri wrote:

intrigeri wrote:

So not only we need to include the firmware and a newer nouveau driver, but we also need a newer Mesa (jessie-backports only has 11.1.3-1~bpo8+1 at the moment).

Mesa 12.0.3 made it into jessie-backports, and it'll probably be included in Tails 2.8 (#11853). So the missing pieces now are the firmware (that we could include ourselves, as done in the feature branch) and the xserver-xorg-video-nouveau backport... or waiting for Tails 3.0.

I have some bad news. Throughout last week I installed Debian Stretch on a USB stick, and fiddled with it. It came with xserver-xorg-video-nouveau 1.0.12-2and Gnome desktop environment didn't work on it. So I checked the logs from recovery mode, and saw that I was missing "nvidia/gm204/gr/...." firmware. I downloaded the "nvidia/gm204" folder from kernel.org git and placed it under "/lib/firmware/". Then I saw that xserver-xorg-video-nouveau 1.0.13-1 package is released for Stretch and updated it to 1.0.13. These changes didn't help either.

I looked at the logs again to see what went wrong. The related lines are as below:

[    x.xxxxxx] nouveau 0000:01:00.0: NVIDIA GM204(124180a1)
[    x.xxxxxx] nouveau 0000:01:00.0: bios: version 84.04.3e.00.02
[    x.xxxxxx] nouveau 0000:01:00.0: mxm: BIOS version 3.0
[    x.xxxxxx] nouveau 0000:01:00.0: disp: dcb 15 type 8 unknown
[    x.xxxxxx] nouveau 0000:01:00.0: firmware: direct-loading firmware  nvidia/gm204/gr/sw_nonctx.bin
[    x.xxxxxx] nouveau 0000:01:00.0: firmware: direct-loading firmware  nvidia/gm204/gr/sw_ctx.bin
[    x.xxxxxx] nouveau 0000:01:00.0: firmware: direct-loading firmware  nvidia/gm204/gr/sw_bundle_init.bin
[    x.xxxxxx] nouveau 0000:01:00.0: firmware: direct-loading firmware  nvidia/gm204/gr/sw_method_init.bin
[    x.xxxxxx] nouveau 0000:01:00.0: gr ctor failed, -28
[    x.xxxxxx] nouveau: probe of 0000:01:00.0 failed with error -28

So if I'm not mistaken there is a bug in either nvidia firmwares or xserver-xorg-video-nouveau 1.0.13 driver that tries to use that firmware. This means that neither Tails 2.8 nor 3.0 would fix this problem unless nouveau fixes it first. I'm wondering if the problem is specific to 970M cards. Because we have reports of the drivers working on GM204 chipsets as mentioned in the edits above.

Lastly I have a question. Where do you think I should submit this bug? A link would be very helpful. I'm a little bit lost on that point.

#21 Updated by Entriel about 3 years ago

Btw I only downloaded the "nvidia/gm204" folder. Not the "nvidia/gm20a" folder you included in the experimental ISO.

#22 Updated by intrigeri about 3 years ago

Btw I only downloaded the "nvidia/gm204" folder. Not the "nvidia/gm20a" folder you included in the experimental ISO.

Do include that one: many files in the gm204 folder are symlinks to the other one.

#23 Updated by Entriel about 3 years ago

I included all the contents of nvidia folder (from http://git.kernel.org/cgit/linux/kernel/git/firmware/linux-firmware.git/tree/nvidia) in "/lib/firmware/nvidia".
The result is the same. There is no "gm20a" though, only "gm20b". Maybe I remembered it wrong(?).

#24 Updated by Entriel about 3 years ago

Entriel wrote:

There is no "gm20a" though, only "gm20b". Maybe I remembered it wrong(?).

Symlinks are pointing to "gm200", and it was included.

#25 Updated by Entriel about 3 years ago

Apparently the firmware files I downloaded was corrupted. MD5s does not match. Neither the sizes. I will try again and report here...

#26 Updated by Entriel about 3 years ago

It seems that downloading the git repository under a Windows environment can mess up symlinks...
As a remedy, I copied the real files to "gm204" folder and deleted the symlinks.

Unfortunately, it is still giving errors. The lines are as below:

[    x.xxxxxx] nouveau 0000:01:00.0: NVIDIA GM204(124180a1)
[    x.xxxxxx] nouveau 0000:01:00.0: bios: version 84.04.3e.00.02
[    x.xxxxxx] nouveau 0000:01:00.0: mxm: BIOS version 3.0
[    x.xxxxxx] ACPI Warning: \_SB.PCI0.PEG0.PEGP._DSM: Argument #4 type mismatch - Found [Buffer], ACPI requires [Package] (20160108/nsarguments-95)
[    x.xxxxxx] nouveau 0000:01:00.0: disp: dcb 15 type 8 unknown
[    x.xxxxxx] nouveau 0000:01:00.0: firmware: direct-loading firmware  nvidia/gm204/gr/sw_nonctx.bin
[    x.xxxxxx] nouveau 0000:01:00.0: firmware: direct-loading firmware  nvidia/gm204/gr/sw_ctx.bin
[    x.xxxxxx] nouveau 0000:01:00.0: firmware: direct-loading firmware  nvidia/gm204/gr/sw_bundle_init.bin
[    x.xxxxxx] nouveau 0000:01:00.0: firmware: direct-loading firmware  nvidia/gm204/gr/sw_method_init.bin
[    x.xxxxxx] nouveau 0000:01:00.0: fb: 6144 MiB GDDR5
[    x.xxxxxx] nouveau 0000:01:00.0: fb: init failed, -22
[    x.xxxxxx] nouveau 0000:01:00.0: init failed with -22
[    x.xxxxxx] nouveau: DRM:00000000:00000080: init failed with -22
[    x.xxxxxx] nouveau: probe of 0000:01:00.0 failed with error -22

#27 Updated by intrigeri about 3 years ago

  • Assignee changed from intrigeri to Entriel
  • QA Check changed from Dev Needed to Info Needed

Can you please test an ISO from https://nightly.tails.boum.org/build_Tails_ISO_feature-stretch/lastSuccessful/archive/build-artifacts/ ? You probably will need to press CTRL+ALT+F2 after clicking "Login" in Tails Greeter, otherwise the GNOME session may not start.

#28 Updated by Entriel about 3 years ago

I tested the ISO, unfortunately it hangs on the boot before showing the Tails Greeter and after I choose "Live" from the boot menu. The screen starts flickering, and keeps flickering for a time and then just shows that it tried to start the GNOME session manager.The last lines on the screen are something like:

Starting GNOME session manager...
[OK] Started GNOME session manager. 

If I try pressing Ctrl+Alt+F2 after choosing "Live", I got a console asking me login credentials for amnesia.

Btw it still gives the message:

[    2.151987] nouveau 0000:01:00.0: firmware: failed to load nvidia/gm204/gr/sw_nonctx.bin (-2)
[    2.152041] nouveau 0000:01:00.0: gr ctor failed, -2

So does Tails 2.7, but at least it works (albeit in 1 fps).

#29 Updated by intrigeri about 3 years ago

I tested the ISO,

What's the exact filename of the ISO you tried?
That branch is changing very fast these days.

#30 Updated by Entriel about 3 years ago

intrigeri wrote:

What's the exact filename of the ISO you tried?

tails-amd64-feature_stretch-3.0-20161116T1330Z-286e3ff.iso

#31 Updated by intrigeri about 3 years ago

tails-amd64-feature_stretch-3.0-20161116T1330Z-286e3ff.iso

Thank you. Indeed, that ISO lacks the firmware you need, sorry!

I've upgraded our bugfix/11831-nvidia-maxwell-firmware branch (that includes the firmware) to be based on the experimental Tails/Stretch work. Within 24 hours max., https://nightly.tails.boum.org/build_Tails_ISO_bugfix-11831-nvidia-maxwell-firmware/lastSuccessful/archive/build-artifacts/ should have an ISO image ⇒ please test it. Thanks in advance!

#32 Updated by Entriel about 3 years ago

intrigeri wrote:

Thank you. Indeed, that ISO lacks the firmware you need, sorry!

Not a problem, I am happy to help.

I've tested the new ISO, and I have both good and bad news.

Good news first. It loads nouveau driver and screen resolution goes to full HD. First time seeing it with Tails. The lines on the screen seem so small after getting used to using it in lower resolutions.

Bad news is, it still hangs. It hangs when there are only 3 squares(orange-white-orange) displayed on the screen. If I start it with 'splash' and 'quiet' removed from the kernel parameters, the last lines on the screen are as below:

[ OK ] Started Load/Save Screen Backlight Brightness of backlight:acpi_video0.
[ OK ] Started GNOME Display Manager.
[ OK ] Started Authorization Manager.
[ OK ] Started Accounts Service.
[ OK ] Listening on Load/Save RF Kill Switch Status /dev/rfkill Watch.
       Starting Load/Save RF Kill Switch Status...
[ OK ] Started Load/Save RF Kill Switch Status.
[ OK ] Reached target Bluetooth.
[ OK ] Started Modem Manager.
[ OK ] Created slice User Slice of Debian-gdm
       Starting User Manager for UID 114...
[ OK ] Started Session c1 of user Debian-gdm.
[ OK ] Started User Manager for UID 114.

#33 Updated by Entriel about 3 years ago

Is there anything else I could try? Or do you need any more information from me? Should I try 3.0 alpha test build?

#34 Updated by intrigeri about 3 years ago

  • Assignee changed from Entriel to intrigeri
  • QA Check deleted (Info Needed)

firmware-nonfree (20161130-1) changelog entry reads:

   * misc-nonfree: Include Nvidia GM200, GM204, GM206, GM20B and GP100
     signed firmware (Closes: #823637, #826996)

I'll ensure it's in Tails 3.0~beta1.

Or do you need any more information from me? Should I try 3.0 alpha test build?

No, it lacks the firmware anyway.

#35 Updated by Entriel about 3 years ago

intrigeri wrote:

I'll ensure it's in Tails 3.0~beta1.

Then I will test Tails 3.0~beta1 and report back here.

#36 Updated by intrigeri almost 3 years ago

  • Feature Branch changed from bugfix/11831-nvidia-maxwell-firmware to feature/stretch

#37 Updated by intrigeri almost 3 years ago

Uploaded firmware-nonfree 20161130-2 to our feature-stretch APT suite.

#38 Updated by intrigeri almost 3 years ago

  • % Done changed from 10 to 20

#39 Updated by intrigeri almost 3 years ago

  • Assignee changed from intrigeri to Entriel
  • % Done changed from 20 to 30

#40 Updated by intrigeri almost 3 years ago

  • QA Check set to Info Needed

#41 Updated by Entriel almost 3 years ago

I have tested "tails-amd64-feature_stretch-3.0-20161221T1625Z-febdcdc.iso"

It still hangs after the lines below:

[ OK ] Created slice User Slice of Debian-gdm
       Starting User Manager for UID 114...
[ OK ] Started Session c1 of user Debian-gdm.
[ OK ] Started User Manager for UID 114.

I had the chance to test my installation on another computer and now I know that it should show me the "greeter" right after that last line.

I decided to wait more just to see if anything changes, and it stayed at that line for about 5 minutes. After that I started trying Ctrl+Alt+F* combinations. F2 to F6 gives me tty consoles, which are useless because Tails do not have a root password. But I saw that F9 gives me something else. I think it is where the GUI should reside in.

The first time I tried F9, screen was black for about 15 seconds and then it printed some lines like the ones below:

[  199.409731] nouveau 0000:01:00.0: disp: Base 4 - Image 1:
[  199.409733] nouveau 0000:01:00.0: disp: Ö0420: 00000000
[  199.409735] nouveau 0000:01:00.0: disp: Ö0424: 00000000
[  199.409738] nouveau 0000:01:00.0: disp: Ö0428: 00000000
[  199.409740] nouveau 0000:01:00.0: disp: Ö042c: 00000000
[  199.409744] nouveau 0000:01:00.0: disp: Ö0430: 0000e900
[  199.409766] systemd-journald[563] : /dev/kmsg buffer overrun, some messages lost. 

Since it says something about buffer overrun, I decided to try and switch to F9 without waiting so long. When I did that, system showed me a one line message alternating between the two lines below:

[  *✸* ] (1 of 2) A start job is running for Wait for Tor to Have Bootstrapped (2min 17s / no limit)
[ *✸*  ] (2 of 2) A start job is running for Hold until boot process finishes up (2min 18s / no limit)

Long story short it still hangs before showing the greeter. But the resolution is way high, so I know that nouveau firmware took effect...

If there is anything else I can try, please let me know.

#42 Updated by intrigeri almost 3 years ago

If there is anything else I can try, please let me know.

Please set a root password on the kernel command-line with rootpw=YOUR_PASSWORD. Do this only for testing purposes as that's unsafe: all processes will be able to learn about that password. This should allow you to log in via a text console, and gather useful information :)

#43 Updated by Entriel almost 3 years ago

intrigeri wrote:

Please set a root password on the kernel command-line with rootpw=YOUR_PASSWORD. Do this only for testing purposes as that's unsafe: all processes will be able to learn about that password. This should allow you to log in via a text console, and gather useful information :)

I logged in via tty2 and took copies of the *.log files that could be relevant. I am attaching them here, so please check and tell me if you could see what goes wrong from them.

I couldn't find anything obvious, so I will be waiting for your response.

I have to leave for work, but when I came back I will try to check the [Starting-Started] pairs in the boot.log, and see if I could figure something out from there...

#44 Updated by Entriel almost 3 years ago

I think these lines points to the source of the problem:

[  *✸* ] (1 of 2) A start job is running for Wait for Tor to Have Bootstrapped (2min 17s / no limit)
[ *✸*  ] (2 of 2) A start job is running for Hold until boot process finishes up (2min 18s / no limit)

They are the only jobs that have not printed "Started" logs...

The one about the Tor may be expected since I need Tor bridges to be configured in this area. And tor bridge configuration needs to be entered at the greeter, so I think it would not be a stopper.

But the other line had me worried and I googled it. Results surprised me. Some of them:

The issue seems to be related to gdm, plymouth-gdm, lightdm, xserver-xorg and nvidia.

Please let me know what else I can try at this point...

#45 Updated by intrigeri almost 3 years ago

I logged in via tty2 and took copies of the *.log files that could be relevant. I am attaching them here, so please check and tell me if you could see what goes wrong from them.

Thanks! But really, in current Tails what matters most is the content of the systemd Journal, so please attach the output of journalctl -a.
Thanks in advance!

#46 Updated by intrigeri almost 3 years ago

I think these lines points to the source of the problem:

> [  *✸* ] (1 of 2) A start job is running for Wait for Tor to Have Bootstrapped (2min 17s / no limit)
> [ *✸*  ] (2 of 2) A start job is running for Hold until boot process finishes up (2min 18s / no limit)
> 

I don't think so. This happens on any Tails system, but usually one doesn't see it since they're doing their "work" in the background.
I say don't worry about it.

#47 Updated by Entriel almost 3 years ago

intrigeri wrote:

please attach the output of journalctl -a.

The output of the command is attached. I have seen some interesting output around 02:03:28 and 02:03:32. After that comes a 5 minute hang and my tty2 login.

intrigeri wrote:

they're doing their "work" in the background.

Thanks for letting me know, I wiil not waste time on that end then.

Please let me know if there is anything else I can do to help.

#48 Updated by intrigeri almost 3 years ago

  • Assignee changed from Entriel to intrigeri

The output of the command is attached.

Thanks, I'll look at it next time I'm back to working on Tails 3.0 :)
(End of January to the latest.)

#49 Updated by intrigeri almost 3 years ago

  • QA Check deleted (Info Needed)

#50 Updated by intrigeri almost 3 years ago

  • Assignee changed from intrigeri to Entriel
  • QA Check set to Info Needed

"https://nouveau.freedesktop.org/wiki/FeatureMatrix/ says that for the NV110 family, basic 2D support is WIP. So I'm not surprised it does not work well" still holds. However, there was a bug in the firmware-nonfree package included in the ISO you tested, so please retry with that one: https://nightly.tails.boum.org/build_Tails_ISO_feature-stretch-unfrozen/lastSuccessful/archive/build-artifacts/

#51 Updated by Entriel almost 3 years ago

intrigeri wrote:

"https://nouveau.freedesktop.org/wiki/FeatureMatrix/ says that for the NV110 family, basic 2D support is WIP. So I'm not surprised it does not work well" still holds.

Well, on the other hand, there are reports of people running nouveau on Linux 4.6 with Maxwell series graphic cards. [[http://www.phoronix.com/scan.php?page=article&item=nouveau-maxwell-kepler&num=1]]

I tried with "".
Unfortunately it still hangs at the same place. Moreover it seems that I can't even get tty consoles this time. Ctrl+Alt+F2 to F6 all shows the lines below alternating between them. So I couldn't even get journalctl output.

[  *✸* ] (1 of 2) A start job is running for Wait for Tor to Have Bootstrapped (2min 17s / no limit)
[ *✸*  ] (2 of 2) A start job is running for Hold until boot process finishes up (2min 18s / no limit)

I also tried with "". But for some reason it stops at a Busybox console and prints some aufs errors saying that it couldn't find a live file system.

I am waiting for further instructions.

#52 Updated by Entriel almost 3 years ago

PS: It's just a guess but not being able to open tty consoles may be related to Bug #12079. Because one time when I tried to change to different consoles it printed some error regarding some 'locale' problems...

#53 Updated by intrigeri almost 3 years ago

  • Assignee changed from Entriel to intrigeri

#54 Updated by Entriel almost 3 years ago

I tried Ubuntu 16.10 Desktop(live) edition, to see how does it fare with my video card. It also hangs at boot, but if I start with nomodeset kernel command added, it starts in 1920x1080 resolution and has fairly good performance.

I would be quite happy if I could use Tails at that performance level. I am wondering what is the difference between the two systems.

I don't know if they would be helpful or not but here, attached, are the journalctl outputs of standart and nomodeset boots of Ubuntu 16.10.

#55 Updated by intrigeri almost 3 years ago

I also tried with "".
But for some reason it stops at a Busybox console and prints some aufs errors saying that it couldn't find a live file system.

Reproduced, I'm on it.

#56 Updated by intrigeri almost 3 years ago

I tried Ubuntu 16.10 Desktop(live) edition, to see how does it fare with my video card. It also hangs at boot, but if I start with nomodeset kernel command added, it starts in 1920x1080 resolution and has fairly good performance.

Interesting! I'd love to see what happens in Tails (once I've fixed feature/stretch-unfrozen) with nomodeset.

#57 Updated by intrigeri almost 3 years ago

PS: It's just a guess but not being able to open tty consoles may be related to Bug #12079.

I don't think so: #12079 only affects the GNOME session started after the Greeter.

Because one time when I tried to change to different consoles it printed some error regarding some 'locale' problems...

I'd love to see the exact error message.

#58 Updated by Entriel almost 3 years ago

intrigeri wrote:

Interesting! I'd love to see what happens in Tails (once I've fixed feature/stretch-unfrozen) with nomodeset.

Let me know when you fix it, and I will try. Currently, if I add nomodeset it hangs earlier than before and screen starts flickering. It keeps flickering even if I switch to tty consoles.

intrigeri wrote:

I'd love to see the exact error message.

I am sorry, I tried my best but couldn't reproduce it. I was switching between tty consoles at the time and couldn't really read the message. Maybe it was the message about "Laptop Mode Tools - Battery Polling Service" which shows up about three minutes into booting process, and I mistakenly saw the word "locale" before switching to the next console.

#59 Updated by intrigeri almost 3 years ago

  • Assignee changed from intrigeri to Entriel

intrigeri wrote:

Interesting! I'd love to see what happens in Tails (once I've fixed feature/stretch-unfrozen) with nomodeset.

Let me know when you fix it, and I will try.

https://nightly.tails.boum.org/build_Tails_ISO_feature-stretch-unfrozen/lastSuccessful/archive/build-artifacts/ should fix the aufs problem.

#60 Updated by Entriel almost 3 years ago

intrigeri wrote:

https://nightly.tails.boum.org/build_Tails_ISO_feature-stretch-unfrozen/lastSuccessful/archive/build-artifacts/ should fix the aufs problem.

Yeah, it seems that aufs problem is fixed, but now apparmor initialization fails.
Other than that nothing has changed. Same behavior all over. Btw, I discovered that if I wait patiently on nomodeset boot, screen flickering stops eventually.

journalctl outputs are attached.

#61 Updated by Entriel almost 3 years ago

06012017*

#62 Updated by intrigeri almost 3 years ago

  • Blocked by Bug #12116: cupsd AppArmor profile fails to load on Stretch added

#63 Updated by intrigeri almost 3 years ago

Yeah, it seems that aufs problem is fixed, but now apparmor initialization fails.

Reproduced ⇒ #12116.

Other than that nothing has changed. Same behavior all over. Btw, I discovered that if I wait patiently on nomodeset boot, screen flickering stops eventually.

journalctl outputs are attached.

Thanks.

#64 Updated by intrigeri almost 3 years ago

  • Assignee changed from Entriel to intrigeri

#65 Updated by intrigeri almost 3 years ago

  • QA Check deleted (Info Needed)

#66 Updated by buffers almost 3 years ago

Some 2 cents here. I'm on a GTX 960. It's not absurdly slow, but won't go FullHD either. Tried a snapshot from December 26 and it had been working fine, even booting to 4k. I updated to 2.10 since, though, and it's back to the same issue.

In both cases, I noticed X is using Gallium (0.4 on llvmpipe (LLVM 3.8, 128 bits)), which is kinda weird, given it says it's transitioning to nouveau from VESA during boot.

The only time I had it freeze on me was when I accidentally booted the snapshot with stable Tails on a second stick. Then it loaded the snapshot normally in full-res (4k), but showed me the old greeting screen (from Tails 2.9) and entirely froze the machine. Haven't tried the newer snapshots, though.

One last info is that, with Tails 2.10, if I add vga=ask to kernel boot, i'm able to choose 4k (VESA) right from the start and then it switches drivers from VESA to nouveau right before X, but falls back to Gallium and SVGA once X loads.

Does all this help in any way?
P.S.: to grab messages that flick too fast, try filming the monitor at 60fps or faster with a camera or mobile, then you can pause the video at the right frame and read it.

#67 Updated by Entriel almost 3 years ago

Hi buffers,

Thank you for your input. I have some difficulty understanding the specifics though. Could you please spare some time to clarify some things for me? It may sound unreasonable for me to ask these questions since I am also only a user of Tails, but the answers would help me a lot.

buffers wrote:

Some 2 cents here. I'm on a GTX 960. It's not absurdly slow, but won't go FullHD either. Tried a snapshot from December 26 and it had been working fine, even booting to 4k. I updated to 2.10 since, though, and it's back to the same issue.

Here, the snapshot you are referring is from feature/stretch-unfrozen branch, right?
And, what do you mean by "the same issue"? Are you also experiencing the slow graphics in 2.10? If so, you were only referring to the snapshot when you said that it was not absurdly slow for you, right?

buffers wrote:

In both cases, I noticed X is using Gallium (0.4 on llvmpipe (LLVM 3.8, 128 bits)), which is kinda weird, given it says it's transitioning to nouveau from VESA during boot.

How did you check that information? I'm asking so that I can check it in my system too. Please forgive my ignorance.

buffers wrote:

The only time I had it freeze on me was when I accidentally booted the snapshot with stable Tails on a second stick. Then it loaded the snapshot normally in full-res (4k), but showed me the old greeting screen (from Tails 2.9) and entirely froze the machine. Haven't tried the newer snapshots, though.

I couldn't understand what you described here. Could you please elaborate a little bit?

buffers wrote:

One last info is that, with Tails 2.10, if I add vga=ask to kernel boot, i'm able to choose 4k (VESA) right from the start and then it switches drivers from VESA to nouveau right before X, but falls back to Gallium and SVGA once X loads.

Thanks for that kernel command, I can't check it right away but I will try it in my earliest convenience.

PS: Thank you in advance if you could spare the time to answer my questions, if not thank you anyway...

#68 Updated by Entriel almost 3 years ago

Btw, I noticed that 2.10 performs almost 2 times better than 2.9 in my system graphic wise...

#69 Updated by buffers almost 3 years ago

No worries, mate!

Entriel wrote:

buffers wrote:

Some 2 cents here. I'm on a GTX 960. It's not absurdly slow, but won't go FullHD either. Tried a snapshot from December 26 and it had been working fine, even booting to 4k. I updated to 2.10 since, though, and it's back to the same issue.

Here, the snapshot you are referring is from feature/stretch-unfrozen branch, right?
And, what do you mean by "the same issue"? Are you also experiencing the slow graphics in 2.10? If so, you were only referring to the snapshot when you said that it was not absurdly slow for you, right?

Yes, it was the stretch-unfrozen. "Same issue" was lo-res and not-so-fast graphics. I suspect the speed difference in my case will be the CPU - mine is way faster than Intrigeri's. As the driver isn't accelerated, it's the CPU that does most of the hard work. And yes, in 2.10 too, though I can't say I noticed any significant difference (performance or otherwise) from 2.9. I didn't explain properly, though, performance with the snapshot was way better, even at 4k (3840x2160x32).

For example, in 2.10 video playing is barely acceptable, whereas with the snapshot it was fine up to 1080p60, with just a few dropped frames here and there.

buffers wrote:

In both cases, I noticed X is using Gallium (0.4 on llvmpipe (LLVM 3.8, 128 bits)), which is kinda weird, given it says it's transitioning to nouveau from VESA during boot.

How did you check that information? I'm asking so that I can check it in my system too. Please forgive my ignorance.

From either the "Power Down" icon or "Activities Overview" menu, go Settings->System->Details. If you know of a more accurate tool, please let me know.

buffers wrote:

The only time I had it freeze on me was when I accidentally booted the snapshot with stable Tails on a second stick. Then it loaded the snapshot normally in full-res (4k), but showed me the old greeting screen (from Tails 2.9) and entirely froze the machine. Haven't tried the newer snapshots, though.

I couldn't understand what you described here. Could you please elaborate a little bit?

The snapshot was working fine. I had 2.9 in another USB-stick, though, and I once booted the snapshot with this 2.9 stick still in. For all I could check, it was indeed booting the snapshot, but after X loaded it showed me the old, 2.9 greeting screen (not the new one in the snapshot) and immediately froze everything.

I didn't have a chance to check if it was loading some files from that other USB-stick or some other error, but I suppose it will behave the same if you have a second Tails - or maybe another Linux - in your HD.

I didn't test the newer snapshots,so I don't know if they will work fine or if I'll have the same issues as Intrigeri's. I'll try to find some time to do so and report back. Would you suggest me a specific version?

And please keep asking, that's how we'll take this one down. ;)

#70 Updated by intrigeri over 2 years ago

https://tracker.debian.org/news/841100 says that xserver-xorg-video-nouveau (1:1.0.14-1) "[provides] acceleration support for Maxwell cards". We'll see if it makes it into Stretch.

#71 Updated by Entriel over 2 years ago

intrigeri wrote:

https://tracker.debian.org/news/841100 says that xserver-xorg-video-nouveau (1:1.0.14-1) "[provides] acceleration support for Maxwell cards". We'll see if it makes it into Stretch.

That's good news. I was beginning to lose hope on this one. I hope it makes it into Stretch before long. Please let me know when you put it in a nightly build, then I could test and report back.

#72 Updated by intrigeri over 2 years ago

  • Assignee changed from intrigeri to Entriel
  • QA Check set to Info Needed

Please let me know when you put it in a nightly build, then I could test and report back.

Just pushed to the bugfix/11831-newer-nouveau-xorg-driver branch, so a nightly build from that branch should appear in one our or so.

#73 Updated by Entriel over 2 years ago

Unfortunately, it still hangs. But the logs have changed a lot. I am attaching the journalctl output. It seems that the nouveau now correctly identifies the card(line# ~1700 in the log). But the greeter screen never shows up.

#74 Updated by intrigeri over 2 years ago

  • Assignee changed from Entriel to intrigeri
  • QA Check deleted (Info Needed)

Thanks for testing!

#75 Updated by intrigeri over 2 years ago

Entriel wrote:

Unfortunately, it still hangs. But the logs have changed a lot. I am attaching the journalctl output. It seems that the nouveau now correctly identifies the card(line# ~1700 in the log). But the greeter screen never shows up.

I could not find anything that explains this in the logs :/ Now I wonder if a newer kernel (4.10) would help. We'll see once it's available in Debian unstable, or whenever a newer nouveau X.Org driver is uploaded.

#76 Updated by Entriel over 2 years ago

intrigeri wrote:

I could not find anything that explains this in the logs :/ Now I wonder if a newer kernel (4.10) would help. We'll see once it's available in Debian unstable, or whenever a newer nouveau X.Org driver is uploaded.

Neither could I :S I will try other linux distros with nouveau. Sadly my thumbdrive has broken. I ordered a new one but it will take some time for it to reach me. I will report anything I could find out when I get it.

#77 Updated by Entriel over 2 years ago

I have spent some more time looking into the logs. There are some sections I am interested in. Could you please shed some light on what would these lines indicate? Could they be a part of the problem?

(EE) open /dev/fb0: Permission denied

I guess fbdev is short form of framebuffer device. I have read something here(http://unix.stackexchange.com/questions/149985/startx-cannot-open-dev-fb0-permission-denied) about rootless X.
amnesia spice-vdagent[4943]: Cannot access vdagent virtio channel /dev/virtio-ports/com.redhat.spice.0
amnesia gnome-session[4919]: gnome-session-binary[4919]: WARNING: App 'spice-vdagent.desktop' exited with code 1
amnesia gnome-session-binary[4919]: WARNING: App 'spice-vdagent.desktop' exited with code 1
amnesia systemd[1]: systemd-timesyncd.service: Cannot add dependency job, ignoring: Unit systemd-timesyncd.service is masked.
amnesia tails-greeter.desktop[4989]: /usr/share/tails-greeter/set-cursor.py:6: PyGIWarning: Gtk was imported without 
    specifying a version first. Use gi.require_version('Gtk', '3.0') before import to ensure that the right version gets loaded.
amnesia pulseaudio[4999]: [pulseaudio] authkey.c: Failed to open cookie file '/var/lib/gdm3/.config/pulse/cookie': No such file or directory
amnesia pulseaudio[4999]: [pulseaudio] authkey.c: Failed to load authentication key '/var/lib/gdm3/.config/pulse/cookie': No such file or directory
Received SIGRTMIN+21 from PID 242 (plymouthd).
amnesia /usr/lib/gdm3/gdm-x-session[4892]: (II) AIGLX: Suspending AIGLX clients for VT switch
amnesia /usr/lib/gdm3/gdm-x-session[4892]: (II) NOUVEAU(0): NVLeaveVT is called.

#78 Updated by intrigeri over 2 years ago

Neither could I :S I will try other linux distros with nouveau.

Meanwhile, I suggest testing stuff on regular (non-Tails) Debian Stretch: this will allow you to test combinations that are hard or impossible to test in Tails currently, e.g. installing Linux 4.10 from experimental. I'm interested in results both with and without nomodeset.

#79 Updated by intrigeri over 2 years ago

(EE) open /dev/fb0: Permission denied

Interesting. I'm going to add the Debian-gdm user to the video group, in case that's needed to make X start with some drivers. I'll let you know once there's a new ISO to test :)

> amnesia /usr/lib/gdm3/gdm-x-session[4892]: (II) AIGLX: Suspending AIGLX clients for VT switch
> amnesia /usr/lib/gdm3/gdm-x-session[4892]: (II) NOUVEAU(0): NVLeaveVT is called.
> 

Let's see if this happens again in future ISOs. Hold on.

All the other quoted error messages are fully expected or unrelated.

#80 Updated by intrigeri over 2 years ago

  • Assignee changed from intrigeri to Entriel
  • QA Check set to Info Needed

intrigeri wrote:

(EE) open /dev/fb0: Permission denied

Interesting. I'm going to add the Debian-gdm user to the video group, in case that's needed to make X start with some drivers. I'll let you know once there's a new ISO to test :)

It's just finished building. Please test a new ISO from https://nightly.tails.boum.org/build_Tails_ISO_feature-stretch/lastSuccessful/archive/build-artifacts/ and report back (both with and without nomodeset) the outcome + the exact filename of the ISO you'all have tested.

#81 Updated by Entriel over 2 years ago

intrigeri wrote:

It's just finished building. Please test a new ISO from https://nightly.tails.boum.org/build_Tails_ISO_feature-stretch/lastSuccessful/archive/build-artifacts/ and report back (both with and without nomodeset) the outcome + the exact filename of the ISO you'all have tested.

I have tested the ISO. The behavior is the same(no gui shows up for normal boot, screen flickers for a couple of minutes and then no gui again for nomodeset boot). The logs are different though. They are attached(both with and without nomodeset).

PS: Do you have a remedy for those unnecessary nouveau logs? I had to manually remove some of those in order to decrease the size of the log file.

#82 Updated by intrigeri over 2 years ago

I have tested the ISO.
The behavior is the same(no gui shows up for normal boot, screen flickers for a couple of minutes and then no gui again for nomodeset boot). The logs are different though. They are attached(both with and without nomodeset).

Thanks. This confirms that this graphics adapter requires the nouveau driver 1.0.14+: in these logs, it seems that the modesetting driver is used as the nouveau one says "Unknown chipset: NV124", while when you tested with 1.0.14 it said "NOUVEAU: Chipset: "NVIDIA NV124". Also, I think we can forget about the nomodeset idea as it prevents the kernel from creating the devices any of these two X.Org drivers needs.

PS: Do you have a remedy for those unnecessary nouveau logs? I had to manually remove some of those in order to decrease the size of the log file.

I don't know, sorry. I would start with looking at modinfo nouveau and trying whatever option could help. OTOH you will need those logs if you want to take the matter upstream.

So, let's acknowledge that support for the NV110 (Maxwell) family is still WIP. We don't have the resources to do drivers development at Tails, I've already spent 4 hours on this topic, and I have no idea how I can help more :(

So at this point I think you have two options:

  • either wait until it gets better (and get a 2nd-hand ThinkPad X200 or similar to run Tails);
  • or try harder to get this fixed upstream: reproduce with other distros (Debian Stretch + Linux 4.10 + nouveau 1.0.14, latest Fedora release live CD, or Fedora Rawhide live CD if there's any such thing), gather logs, and report this upstream so they have all the info they need to improve things / suggest you a workaround.

#83 Updated by intrigeri over 2 years ago

  • Target version deleted (Tails_3.0)
  • Feature Branch deleted (feature/stretch)

#84 Updated by intrigeri over 2 years ago

  • Subject changed from Slow graphics operations with NVIDIA Maxwell series graphic card to NVIDIA Maxwell series graphic card: X.Org doesn't start, or slow graphics operations

#85 Updated by intrigeri over 2 years ago

  • Related to Bug #12542: Consider installing xserver-xorg-legacy added

#86 Updated by intrigeri over 2 years ago

#12542 might help (with nouveau.modeset=0).

#87 Updated by anonym over 2 years ago

I'm attaching a whisperback log (encrypted to me and intrigeri) of the same issue for a "Nvidia Geforce 980 GPU".

#88 Updated by intrigeri over 2 years ago

I'm attaching a whisperback log (encrypted to me and intrigeri) of the same issue for a "Nvidia Geforce 980 GPU".

That bug report is from Tails 2.x, so I'm not quite sure what we can do with it (except adding to the list of Maxwell chipsets we don't support anymore in 3.x).

#89 Updated by anonym over 2 years ago

Here's a potential workaround! Could someone affected by this bug please test adding the following to their kernel command-line:

nouveau.noaccel=1

and report back here. (Refs: #12438#note-1)

#90 Updated by Entriel over 2 years ago

intrigeri wrote:

I'm attaching a whisperback log (encrypted to me and intrigeri) of the same issue for a "Nvidia Geforce 980 GPU".

That bug report is from Tails 2.x, so I'm not quite sure what we can do with it (except adding to the list of Maxwell chipsets we don't support anymore in 3.x).

anonym wrote:

Here's a potential workaround! Could someone affected by this bug please test adding the following to their kernel command-line:
[...]
and report back here. (Refs: #12438#note-1)

I am sorry to break the news to you guys, but when you are adding the chipset to your list you should also update the unsupported Tails version to 2.12+ instead of 3.x. Because 2.12 also hangs and it is not possible to run Tails on my computer anymore.

It's ironic that reporting this bug (and following it for months) made it worse for me.

And I tried nouveau.noaccel=1 with Tails 2.12. It still hangs.

I've stopped using Tails with version 2.12. But I will still help you with testing if you also wish to chase down this bug.

Regards..

#91 Updated by intrigeri over 2 years ago

Hi!

I am sorry to break the news to you guys, but when you are adding the chipset to your list you should also update the unsupported Tails version to 2.12+ instead of 3.x.

Sure, this makes sense. #12348 already makes it clear that 2.x is affected so this should be taken into account once emmapeel gets to work on it.

It's ironic that reporting this bug (and following it for months) made it worse for me.

I (think I) understand how you feel, but the logical link you're assuming is wrong: we would have got the updated firmware and drivers anyway, even without this bug report. Actually, no change to our code was made at all as a result of this bug report.

And I tried nouveau.noaccel=1 with Tails 2.12. It still hangs.

Could you please try it with 3.0~rc1?

But I will still help you with testing if you also wish to chase down this bug.

Thanks!

#92 Updated by emmapeel over 2 years ago

The user that reported the workaround working, did it for Tails 3.0beta3, so I don't think it will work in Tails 2.12

#93 Updated by Entriel over 2 years ago

I (think I) understand how you feel, but the logical link you're assuming is wrong: we would have got the updated firmware and drivers anyway, even without this bug report. Actually, no change to our code was made at all as a result of this bug report.

You are right, I am just a little bit frustrated. Every time I try a different thing and I hope for it to work. I guess after a while getting my hopes crushed again and again has started to wear me out.

Could you please try it with 3.0~rc1?

I did so. It hanged, but this time we have a journalctl output with a lot of "error"s and "failed"s.

PS: I cleaned the output by deleting unnecessary "nouveau disp" logs. It's about 1400 lines now.

#94 Updated by intrigeri over 2 years ago

  • Assignee changed from Entriel to intrigeri

You are right, I am just a little bit frustrated. Every time I try a different thing and I hope for it to work. I guess after a while getting my hopes crushed again and again has started to wear me out.

You're not alone: I'm in a similar position every time I ask you to test something new, and then learn it's at least as broken as the old thing :/

Could you please try it with 3.0~rc1?

I did so. It hanged, but this time we have a journalctl output with a lot of "error"s and "failed"s.
PS: I cleaned the output by deleting unnecessary "nouveau disp" logs. It's about 1400 lines now.

Thanks, I'll look into it shortly.

#95 Updated by intrigeri over 2 years ago

  • Assignee changed from intrigeri to Entriel

It seems the issue happens when configuring screen mode. How about trying with only 1 screen connected, instead of 3?

#96 Updated by Entriel over 2 years ago

It seems the issue happens when configuring screen mode. How about trying with only 1 screen connected, instead of 3?

Interesting, because I do not have 3 screens. It's a laptop. I generally use it with a TV via its HDMI output. But, for this test I specifically disconnected the HDMI cable (by plugging it out of laptop's HDMI port physically), and used only the screen of the laptop.

#97 Updated by Entriel over 2 years ago

Oh my god, it works...

I decided to check it out once more, and try all the different things we have tried so far with 3.0.rc1. And one of them worked.

I added "nouveau.modeset=0" to the kernel commands, and now it works. It even plays a 1080p video without problems.

I guess newer versions of nouveau helped :).

I am here if you wish to ask for any more info.

#98 Updated by Entriel over 2 years ago

I tried with HDMI still attached and it still works (no HDMI output though).

I tried it with 2.12. It no longer hangs, and It managed to get the old slow graphics output (1 fps) back.

#12542 might help (with nouveau.modeset=0).

I think I've missed this input of yours, because I tried nouveau.noaccel=1, but not nouveau.modeset=0 afterwards.

So, the final situation is like this:

  • Normal boot hangs with 2.12+.
  • Boot with nouveau.modeset=0 :
    works at 1 fps on 2.12
    works smoothly on 3.0.rc1

and HDMI output is not working for any of them.

#99 Updated by intrigeri over 2 years ago

  • Boot with nouveau.modeset=0 : [...] works smoothly on 3.0.rc1

Great news!

I've reported these on #12438 so this is added to the Known Issues page. I guess the root cause is in the nouveau kernel module. There's not much more we can do on our side without access to the hardware nor (more importantly) kernel development skills, so we'll wait for a Linux kernel update to magically fix that, or for someone to help upstream fix it (#11831#note-82).

#100 Updated by intrigeri over 2 years ago

  • Assignee deleted (Entriel)
  • QA Check deleted (Info Needed)
  • Type of work changed from Code to Wait

#101 Updated by intrigeri over 2 years ago

  • Assignee set to intrigeri
  • Target version set to Tails_3.2

These changes made it into Debian unstable:

xserver-xorg-video-nouveau (1:1.0.14-1)
  * New upstream release.
    - Provide acceleration support for Maxwell cards.

xserver-xorg-video-nouveau (1:1.0.15-1)
  * New upstream release.
    - Add support for Pascal cards.

Once they reach Debian testing, I'll look into the possibility of backporting the new driver for Stretch.

#102 Updated by intrigeri over 2 years ago

1:1.0.15-2 is now in Debian testing.

#103 Updated by intrigeri over 2 years ago

  • Type of work changed from Wait to Code

#104 Updated by intrigeri over 2 years ago

#105 Updated by intrigeri over 2 years ago

  • Related to Bug #12438: Document workarounds for NVIDIA Maxwell series graphics cards added

#106 Updated by intrigeri over 2 years ago

  • Priority changed from High to Normal
  • % Done changed from 100 to 0

#107 Updated by intrigeri over 2 years ago

  • % Done changed from 0 to 10
  • Feature Branch set to bugfix/11831-newer-nouveau-xorg-driver

I've pushed a branch that installs the X.Org nouveau driver from Buster. I'll ask Entriel and other affected people to test a "nightly" built ISO of that branch once there's one ready. Now, it might be that a newer kernel is needed as well (#12732), we'll see.

#108 Updated by intrigeri over 2 years ago

#109 Updated by intrigeri over 2 years ago

  • Assignee changed from intrigeri to Entriel
  • % Done changed from 10 to 20
  • QA Check set to Info Needed

@Entriel: please test https://nightly.tails.boum.org/build_Tails_ISO_bugfix-11831-newer-nouveau-xorg-driver/lastSuccessful/archive/build-artifacts/ and report back how it goes (with and without the tweak you've been using on the kernel command line).

@Help desk: please point whoever is affected by this bug to this same nightly build ISO image.

#110 Updated by intrigeri over 2 years ago

  • Assignee changed from Entriel to intrigeri
  • QA Check changed from Info Needed to Dev Needed

Hold on, for some reason that ISO has the old driver. Sorry for the noise.

#111 Updated by intrigeri over 2 years ago

intrigeri wrote:

Hold on, for some reason that ISO has the old driver. Sorry for the noise.

Fixed the root cause, will notify you folks once a new ISO is ready.

#112 Updated by intrigeri over 2 years ago

  • Assignee changed from intrigeri to Entriel
  • QA Check changed from Dev Needed to Info Needed

#113 Updated by mmazing over 2 years ago

Was having trouble booting and greeter not loading with a GTX 960M card (on an Dell Inspiron 7559), the laptop also required nomodeset with other linux distros to boot and fix some CPU soft lockup issue. Problem is, combining nomodeset and nouveau.noaccel=1 was not working.

Solution for me was to instead use nouveau.modeset=0 and nouveau.noaccel=1 in combination, without nomodeset. Works for me on the test ISO and on regular 3.0.1 stable.

#114 Updated by intrigeri over 2 years ago

Solution for me was to instead use nouveau.modeset=0 and nouveau.noaccel=1 in combination, without nomodeset. Works for me on the test ISO

And what happens on the test ISO without any added startup options?

#115 Updated by Entriel over 2 years ago

intrigeri wrote:

https://nightly.tails.boum.org/build_Tails_ISO_bugfix-11831-newer-nouveau-xorg-driver/lastSuccessful/archive/build-artifacts/ has xserver-xorg-video-nouveau 1:1.0.15-2, please test :)

Sorry, I didn't get any e-mail about your updates, thus the late response.

I tried the iso(tails-amd64-bugfix_11831-newer-nouveau-xorg-driver-3.2-20170822T1550Z-c7628c6a71+devel@95fbb97122), and it's the same all over. Greeter does not show up without the additional kernel commands.

#116 Updated by intrigeri over 2 years ago

#117 Updated by intrigeri over 2 years ago

#118 Updated by intrigeri over 2 years ago

  • Assignee changed from Entriel to intrigeri
  • QA Check changed from Info Needed to Dev Needed

Thanks. I'll prepare another test branch with the newer nouveau driver + Linux 4.12 once the latter has made it into our devel branch.

#119 Updated by intrigeri over 2 years ago

  • Feature Branch changed from bugfix/11831-newer-nouveau-xorg-driver to bugfix/11831-newer-nouveau-xorg-driver+linux-4.12

intrigeri wrote:

Thanks. I'll prepare another test branch with the newer nouveau driver + Linux 4.12

Done. I'll ask you folks to test once I've confirmed it builds fine.

#120 Updated by intrigeri over 2 years ago

  • Assignee changed from intrigeri to Entriel
  • QA Check changed from Dev Needed to Info Needed

#121 Updated by Entriel over 2 years ago

intrigeri wrote:

Please test https://nightly.tails.boum.org/build_Tails_ISO_bugfix-11831-newer-nouveau-xorg-driver-linux-4.12/lastSuccessful/archive/build-artifacts/ and report back the exact filename of the ISO being tested. Thanks!

Good news. I've tested the iso(tails-amd64-bugfix_11831-newer-nouveau-xorg-driver+linux-4.12-3.2-20170903T0206Z-6f4bf5bee9+devel@95fbb97122). It works without the need of any additional kernel commands. I even get output on my TV.

There is some new bugs related to dual screen usage though. It starts on default by adding the second screen as extra desktop space, but when I try to change the setup to a mirror display, OS just gets stuck. The display on my laptop goes black, and even though I can see the last image on the TV screen and seem to be able to move my mouse around, the image is just frozen and I can't click anything.

Anyway it is a new bug. This one(11831) seems to be solved for my case after the last changes.

I don't know what to say. It's a happy day. After countless trials and errors, it finally works :).

#122 Updated by Entriel over 2 years ago

What I have reported could be related to #12730.

#123 Updated by intrigeri over 2 years ago

What I have reported could be related to #12730.

I don't think so: #12730 is fixed is Linux 4.12 ⇒ can you please file another ticket about the remaining issues?

#124 Updated by intrigeri over 2 years ago

Please test https://nightly.tails.boum.org/build_Tails_ISO_bugfix-11831-newer-nouveau-xorg-driver-linux-4.12/lastSuccessful/archive/build-artifacts/ and report back the exact filename of the ISO being tested. Thanks!

Good news. I've tested the iso(tails-amd64-bugfix_11831-newer-nouveau-xorg-driver+linux-4.12-3.2-20170903T0206Z-6f4bf5bee9+devel@95fbb97122). It works without the need of any additional kernel commands. I even get output on my TV.

Woooooohooo! So now I want to know whether upgrading to Linux 4.12 is enough, or if the newer nouveau driver is needed as well (Linux 4.12 will be in Tails 3.2 unless something terrible happens. But if we don't really need the newer nouveau driver, then I don't want to switch to it as it will have a non-negligible maintenance cost and might break other use cases.)

So, please test https://nightly.tails.boum.org/build_Tails_ISO_feature-12732-linux-4.12/lastSuccessful/archive/build-artifacts/ and report back results + the exact filename of the ISO being tested.

I don't know what to say. It's a happy day. After countless trials and errors, it finally works :).

:)

#125 Updated by Entriel over 2 years ago

What I have reported could be related to #12730.

I don't think so: #12730 is fixed is Linux 4.12 ⇒ can you please file another ticket about the remaining issues?

I will wait for the official release before opening a ticket, if it is all right with you. (Because the new bug is not present in the latest build, yet there is still something wrong going on with HDMI output - HDMI audio is not available-.

So, please test https://nightly.tails.boum.org/build_Tails_ISO_feature-12732-linux-4.12/lastSuccessful/archive/build-artifacts/ and report back results + the exact filename of the ISO being tested.

I've tested the iso(tails-amd64-feature_12732-linux-4.12-3.2-20170904T1422Z-7bb17bfc39+devel@95fbb97122).
Good news. It seems that Linux 4.12 is enough to solve the problem. Everything works(even screen mirroring) except the HDMI audio problem I mentioned before.

#126 Updated by intrigeri over 2 years ago

Assignee: anonym
QA Check: Ready for QA

I've tested the iso(tails-amd64-feature_12732-linux-4.12-3.2-20170904T1422Z-7bb17bfc39+devel@95fbb97122).
Good news. It seems that Linux 4.12 is enough to solve the problem. Everything works(even screen mirroring) except the HDMI audio problem I mentioned before.

Excellent! anonym, please mark as fix committed once you merge #12732 :)

#127 Updated by intrigeri over 2 years ago

  • Assignee changed from Entriel to anonym
  • QA Check changed from Info Needed to Ready for QA

#128 Updated by intrigeri over 2 years ago

  • Feature Branch changed from bugfix/11831-newer-nouveau-xorg-driver+linux-4.12 to feature/12732-linux-4.12

#129 Updated by anonym over 2 years ago

  • Status changed from In Progress to 11
  • Assignee deleted (anonym)
  • % Done changed from 20 to 100
  • QA Check changed from Ready for QA to Pass

#130 Updated by 110100111011 about 2 years ago

Just want to report that this actually seems to fix the same issue with a GTX 1080 (and probably other Pascal GPUs) too. With Tails 3.1 a GTX 1080 would not work, Tails would just show black or crash with artifacts on startup. With Tails 3.2 RC1, graphics with a GTX 1080 work fine.

One issue that exists is that Tails doesn't like when a HTC Vive headset is connected to HMDI, then some text that talks about some nouveau error appears and Tails freezes. The fix for that is to just disconnect the HTC Vive before starting Tails. You should add this to the known issue list. Obviously I don't know if this only happens with a GTX 1080 + HTC Vive or if it affects other GPUs too, but I would guess that it affects more GPUs, at least GTX 1070 and GTX 1060 since those are all Pascal GPUs.

#131 Updated by intrigeri about 2 years ago

  • Related to Bug #14697: Document workaround for Tails freezing with NVIDIA GTX 1080 when HTC Vive headset is connected to HDMI added

#132 Updated by intrigeri about 2 years ago

Just want to report that this actually seems to fix the same issue with a GTX 1080 (and probably other Pascal GPUs) too. With Tails 3.1 a GTX 1080 would not work, Tails would just show black or crash with artifacts on startup. With Tails 3.2 RC1, graphics with a GTX 1080 work fine.

Great, thanks!

One issue that exists is that Tails doesn't like when a HTC Vive headset is connected to HMDI, then some text that talks about some nouveau error appears and Tails freezes. The fix for that is to just disconnect the HTC Vive before starting Tails. You should add this to the known issue list. Obviously I don't know if this only happens with a GTX 1080 + HTC Vive or if it affects other GPUs too, but I would guess that it affects more GPUs, at least GTX 1070 and GTX 1060 since those are all Pascal GPUs.

Reported on #14697. Feel free to add more info there, e.g. describes in more details when "Tails freezes" and what it means exactly.

#133 Updated by anonym about 2 years ago

  • Status changed from 11 to Resolved

#134 Updated by 110100111011 about 2 years ago

Unfortunately, I'm seeing GPU issues with Tails again :(

I've replaced one of my older monitors with a newer one, before I had DP,DP,DVI for my monitors, now I use DP,DP,DP. (DP = Displayport).

Tails doesn't like that new combination though. While DP,DP,DVI would work, now with DP,DP,DP I can't get Tails to boot. I see the blinking cursor for a few seconds, then for 1 or 2 frames an error message appears, and then Tails seems to crash and no longer has any GPU output (monitors either black or saying "connect stuff").

I did film it with my phone so that I'm able to read the error message, it is just one line:

[2.984265] nouveau 0000:03:00:0 DRM: Pointer to flat panel table invalid

Using DP,DP,HDMI for my monitors gives the same result. Connecting only 2 monitors with DP,DP works fine, if I then connect a 3rd one while Tails runs, it crashes (shows some graphics corruption for a few seconds, then turns all monitors off).

My old monitor combination had only one 1080p monitor, now I have two. Even with only two 1080p monitors connected, it feels like graphics operations are running slower than they should. When dragging windows around, it isn't fully smooth and it looks like the image is constantly "breaking apart", as if "vsync" would be disabled. So it looks like if first the upper half of the monitor is updated, and then a while later the lower part is. The height where that cut is is random though, so it moves up/down all the time. So when dragging a window around, the upper half or third etc is sometimes 1 cm further to the left/right (depending in which direction you move it) than the lower half/third/whatever of the window. It is very ugly. I did see that already when my old 3 monitors were still working, it was just less intense.

One other example for it feeling "slow" is that if I open a youtube video (even just 720p) on one monitor, and try to use the browser on a website like this on the other monitor, even the scrolling in the browser starts to feel very laggy. If I pause the youtube video, scrolling feels way better. So I'm not sure if its actually fully software rendering everything or if the GPU stuff is only working in some very slow mode.

I am using a GTX 1080 and Tails 3.2. Does Tails 3.3 have any improvements regarding the kernel or nouveau drivers that might fix these issues? Is there any ISO I could test to see if stuff is improved by it?

I have tried to play around with commands like nouveau.modeset=X and nouveau.noaccel=X, but setting those to either 0 or 1 doesn't improve anything, either it does nothing or it makes it worse.

#135 Updated by intrigeri about 2 years ago

110100111011 wrote:

Unfortunately, I'm seeing GPU issues with Tails again :(

I've replaced one of my older monitors with a newer one, before I had DP,DP,DVI for my monitors, now I use DP,DP,DP. (DP = Displayport).

Tails doesn't like that new combination though. While DP,DP,DVI would work, now with DP,DP,DP I can't get Tails to boot.

Please report a dedicated ticket about it: what this one was about has been fixed in the general case, and the problem you're experiencing seems to happen only in a very specific corner case.

[2.984265] nouveau 0000:03:00:0 DRM: Pointer to flat panel table invalid

I've found lots of similar reports online but no clear solution (except using the proprietary NVIDIA drivers but that's not an option here).

I am using a GTX 1080 and Tails 3.2. Does Tails 3.3 have any improvements regarding the kernel or nouveau drivers that might fix these issues?

We might upgrade to Linux 4.13 (#14789). I don't know if 4.13 improves anything in this respect.

Is there any ISO I could test to see if stuff is improved by it?

You could give this one a try: https://nightly.tails.boum.org/build_Tails_ISO_feature-buster/lastSuccessful/archive/build-artifacts/

If you follow-up on this, please do so on a new ticket.

#136 Updated by intrigeri almost 2 years ago

  • Related to Bug #15116: X.Org does not start with some NVidia Maxwell and Pascal graphic cards added

#137 Updated by intrigeri almost 2 years ago

#138 Updated by intrigeri almost 2 years ago

Also available in: Atom PDF