Tails

#8 Updated by intrigeri 2016-09-25 10:17:03

> 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 2016-09-25 10:25:30

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

#11 Updated by Entriel 2016-09-25 15:25:23

> 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.

#14 Updated by Entriel 2016-09-26 04:38:18

> 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 2016-09-26 12:16:54

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(which is also GM204) 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.

#16 Updated by Entriel 2016-09-27 09:04:03

This(https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=838290) is discouraging…

#19 Updated by intrigeri 2016-09-30 03:08:09

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 (Bug #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 2016-10-02 12:34:41

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 (Bug #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 2016-10-02 12:36:11

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

#22 Updated by intrigeri 2016-10-02 12:59:40

> 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 2016-10-02 14:03:58

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 2016-10-02 14:09:48

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 2016-10-02 14:47:04

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 2016-10-02 23:31:30

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

#28 Updated by Entriel 2016-11-16 16:58:29

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 2016-11-16 17:44:50

> 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 2016-11-16 18:12:08

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 2016-11-17 08:09:12

> 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 2016-11-17 18:47:42

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 2016-11-18 18:31:05

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

#35 Updated by Entriel 2016-12-04 14:55:14

intrigeri wrote:
> I’ll ensure it’s in Tails 3.0~beta1.

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

#37 Updated by intrigeri 2016-12-21 11:59:14

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

#41 Updated by Entriel 2016-12-21 21:12:42

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 2016-12-22 17:33:41

> 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 :)

#44 Updated by Entriel 2016-12-22 21:35:47

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:

• http://askubuntu.com/questions/760825/cannot-boot-system-due-to-start-job-running-for-hold
• http://askubuntu.com/questions/792129/16-04-boot-stops-at-a-start-job-is-running-for-hold-until-boot-process-finish
• https://bbs.archlinux.org/viewtopic.php?id=216596

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 2016-12-23 12:22:18

> 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 2016-12-23 12:23:09

> 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.

#51 Updated by Entriel 2017-01-04 14:14:52

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 “tails-amd64-feature_stretch-unfrozen-3.0-20161227T2119Z-edba8da+feature_stretch@2986dbc.iso”.
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 “tails-amd64-feature_stretch-unfrozen-3.0-20170104T0959Z-b270029+feature_stretch@b1099c1.iso”. 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 2017-01-04 14:22:01

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

#55 Updated by intrigeri 2017-01-06 08:53:43

> I also tried with “tails-amd64-feature_stretch-unfrozen-3.0-20170104T0959Z-b270029+feature_stretch@b1099c1.iso”.
> 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 2017-01-06 08:53:44

> 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 2017-01-06 08:53:45

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

I don’t think so: Bug #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 2017-01-06 09:36:16

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.

#61 Updated by Entriel 2017-01-06 22:06:45

06012017*

#63 Updated by intrigeri 2017-01-07 08:44:45

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

Reproduced ⇒ Bug #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.

#66 Updated by buffers 2017-01-28 19:58:19

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 2017-01-29 19:49:37

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 2017-01-29 20:49:45

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

#69 Updated by buffers 2017-01-30 17:02:45

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 SettingsSystem>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 2017-03-19 10:14:43

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 2017-03-20 13:27:20

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.

#75 Updated by intrigeri 2017-03-21 08:35:36

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 2017-03-23 16:47:53

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 2017-03-23 22:49:56

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 2017-04-01 08:45:29

> 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 2017-04-01 08:53:12

> (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.

#82 Updated by intrigeri 2017-04-10 15:02:12

> I have tested the ISO (tails-amd64-feature_stretch-3.0-beta4-20170401T1510Z-d2c565b).
> 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 (0): 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.

#86 Updated by intrigeri 2017-05-16 09:28:28

#88 Updated by intrigeri 2017-05-16 12:32:06

> 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 2017-05-16 14:54:18

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: Bug #12438#note-1)

#90 Updated by Entriel 2017-05-19 12:22:08

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: Bug #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 2017-05-25 09:40:08

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. Feature #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 2017-05-25 10:06:22

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

#96 Updated by Entriel 2017-05-27 12:05:53

> 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 2017-05-27 12:43:46

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 2017-05-27 13:16:15

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.

> Bug #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 2017-05-28 10:56:11

> * Boot with nouveau.modeset=0 : […] works smoothly on 3.0.rc1

Great news!

I’ve reported these on Bug #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 (Bug #11831#note-82).

#102 Updated by intrigeri 2017-06-28 16:51:59

1:1.0.15-2 is now in Debian testing.

#111 Updated by intrigeri 2017-07-25 11:37:21

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.

#113 Updated by mmazing 2017-07-26 05:46:20

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 2017-07-26 06:56:53

> 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 2017-08-22 22:27:03

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.

#121 Updated by Entriel 2017-09-04 01:45:33

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 (through HDMI).

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 2017-09-04 01:50:24

What I have reported could be related to Bug #12730.

#123 Updated by intrigeri 2017-09-04 17:18:53

> What I have reported could be related to Bug #12730.

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

#124 Updated by intrigeri 2017-09-04 17:22:01

>> 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 (through HDMI).

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 2017-09-04 19:39:39

> > What I have reported could be related to Bug #12730.
>
> I don’t think so: Bug #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 2017-09-04 19:55:32

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 Feature #12732 :)

#130 Updated by 110100111011 2017-09-18 13:12:49

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.

#132 Updated by intrigeri 2017-09-21 14:06:45

> 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 Bug #14697. Feel free to add more info there, e.g. describes in more details when “Tails freezes” and what it means exactly.

#134 Updated by 110100111011 2017-10-19 00:30:26

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 2017-10-22 08:49:47

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 (Feature #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.