Bug #12189

Xorg "segmentation fault" with switchable GPU

Added by houbahop69 2017-01-29 16:30:38 . Updated 2017-05-25 18:58:56 .

Status:
Resolved
Priority:
Elevated
Assignee:
Category:
Target version:
Tails_3.0
Start date:
2017-01-29
Due date:
% Done:

100%

Feature Branch:
Type of work:
End-user documentation
Blueprint:

Starter:
Affected tool:
Deliverable for:

Description

Hi,

Firts of all Tails is starting properly if booted in troubleshooting mode.

But with the default boot it cannot go further than a blue screen after the greater with whatever language or option.
After the greater appears and the start button is launched there is a blue screen for few seconds a grey screen then blue screen and finally the greater comes back, if start again the blue screen remains with an active mouse and nothing moves…

If trying to finish with Ctrl-Alt-Suppr a popup appears with
gnome-settings-daemon.desktop not responding

Thanks

Cannot do anything but power off

Files

segfault_switchable.patch (5134 B) goupille, 2017-03-18 16:45:28

Subtasks

History

#1 Updated by thenomad 2017-01-30 07:29:50

Same problem here. Running dual-GPU lenovo Y notebook.

#2 Updated by thenomad 2017-01-30 08:52:24

Fixed by disabling switchable graphics in BIOS

#3 Updated by goupille 2017-02-05 20:53:52

  • Subject changed from evolution of bug#7505 (?) freeze on blue screen (switchable graphics ?) to Xorg "segmentation fault" with switchable GPU
  • Assignee set to goupille
  • Type of work changed from Code to Research

it was reported that adding “modprobe.blacklist=nouveau” to the boot command line works

#4 Updated by emmapeel 2017-02-08 13:30:28

Does not happen with Tails 3.0beta1, according to some reporters.

#5 Updated by ColonelThirtyTwo 2017-02-09 02:35:36

I believe I have a similar problem, though it works differently.

After the greeter appears, I enter my persistent volume password, then press the button to continue. After a pause, the loading splash screen with the 3 squares appears again for a second, then the greeter loads again. If I continue with the second greeter, I am dropped to a blue screen. The mouse works, but otherwise the desktop is empty.

Blacklisting the nouveau module as goupille suggested fixes the issue. Tails also works on my desktop machine, which has a discrete nVidia card.

The laptop I am having this issue with is an MSI GE60 Apache-629.

#6 Updated by intrigeri 2017-02-09 13:53:52

> Does not happen with Tails 3.0beta1, according to some reporters.

Do you mean, on hardware that exposes this problem on Tails 2.10?

#7 Updated by akemwave 2017-02-13 07:06:28

Tested on Lenovo Flex3-1580, Intel Sky Lake graphics, GM108M [GeForce 940M].
Previous Tails 2.09 booted properly.
Tails 2.10 did not as previously noted.
Adding modprobe.blacklist=nouveau to boot command, then tails 2.10 worked properly.
Test with new install of Tails 3.0 beta and it booted & worked properly.

#8 Updated by goupille 2017-02-17 10:27:30

intrigeri :

>>Does not happen with Tails 3.0beta1, according to some reporters.
>
>Do you mean, on hardware that exposes this problem on Tails 2.10?

exactly.

#9 Updated by intrigeri 2017-03-03 08:18:31

  • Status changed from New to Confirmed
  • Target version set to Tails_2.12
  • Type of work changed from Research to End-user documentation

akemwave wrote:
> Adding modprobe.blacklist=nouveau to boot command, then tails 2.10 worked properly.

Thanks! goupille, can you please document this on the Known Issues page?

#10 Updated by Siffy 2017-03-15 06:12:45

If got the same problem in 2.11 none of the bug fixes work. the usb stick i used to secure install tails worked but after i secure installed it on the other usb it did not work. I deleted tails from the 1st usb bc it was from a friend so what shall I do ?

#11 Updated by goupille 2017-03-15 12:10:57

Hi Siffy, you may not be affected byt this bug (maybe Bug #12334 ?) could you test an experimental 2.12 iso (https://nightly.tails.boum.org/build_Tails_ISO_devel/lastStable/archive/build-artifacts/) and report back on tails-bugs@boum.org (or on https://labs.riseup.net/code/issues/12334 if your computer does have a intel skylake graphics) ?

#12 Updated by intrigeri 2017-03-17 10:49:48

  • Priority changed from Normal to Elevated

I was forwarded bug reports about it, which confirms this is a real problem that affects a number of users => bumping priority for updating the Known Issues page accordingly.

#13 Updated by goupille 2017-03-18 16:49:26

this patch add the workaround on the known issues page (and organize the graphics issues in a section of its own)

#14 Updated by goupille 2017-03-18 16:49:48

  • Assignee changed from goupille to emmapeel

#15 Updated by emmapeel 2017-03-18 17:46:29

  • Status changed from Confirmed to In Progress
  • Assignee deleted (emmapeel)
  • QA Check set to Ready for QA
  • Feature Branch set to emmapeel:doc/knownissues-nouveau

I made a couple of changes, please review
https://git-tails.immerda.ch/emmapeel/tails/log/?h=doc/knownissues-nouveau

#16 Updated by emmapeel 2017-03-20 09:07:39

intrigeri wrote:
> > Does not happen with Tails 3.0beta1, according to some reporters.
>
> Do you mean, on hardware that exposes this problem on Tails 2.10?

Yes. Later this week I could provide maybe a list of hardware but it is hard to look for those tickets, I told users to try Tails 3.0beta1 and they never answered back, so I guess it worked (I remember one user asking if it was safe to use the beta for daily use, for example).

#17 Updated by intrigeri 2017-03-20 09:25:02

  • Assignee set to intrigeri
  • % Done changed from 0 to 30

#18 Updated by intrigeri 2017-03-20 09:38:23

  • Assignee changed from intrigeri to sajolida

I’ve had a quick look at the branch, and my conclusion is that I would vastly prefer if sajolida reviewed it, as part of onboarding emmapeel wrt. doc writing skills (I would not merge it as-is without rewriting most of the added text to fit our doc style guide, and I have no clue what’s the current preferred way of sharing these skills / providing feedback / ensuring things are merged quickly while being first put in good shape, in this onboarding process).

sajolida: please don’t close as resolved once done with the known issue, as documenting it won’t solve the real problem.

#19 Updated by intrigeri 2017-03-20 09:54:23

IMO we should document only one solution (blacklisting nouveau): it’s our job to pick the best one, and we should not delegate this burden to users :)

#20 Updated by sajolida 2017-04-18 19:11:44

  • Target version changed from Tails_2.12 to Tails_3.0

#21 Updated by sajolida 2017-04-28 17:43:26

  • Assignee changed from sajolida to emmapeel
  • QA Check changed from Ready for QA to Dev Needed

I’m fine with being a bit more relaxed regarding the style in the known issues page but here I see to many sloppy things, you’ve been contributing to documentation for several years now, and you might get paid to do write some documentation in the near future. So please review your draft.

A non-exhaustive list of things that you can improve:

  • Use ‘start’ instead of ‘boot’ except when referring to boot options. In that case check how we do that in /first_steps/reset/linux.mdwn.
  • Wrap your lines. We don’t have a strict wrapping policy but your line “Booting in Troubleshooting” is 167 chars long and that’s clearly too much. Shorter line makes it easier for version control.
  • Use title capitalization consistently. See /contribute/how/documentation/guidelines.
  • Use ‘Tails 2.1 or earlier’ instead of ‘Tails 2.1\*’.
  • Use ‘\Tails Greeter\’.

#22 Updated by intrigeri 2017-05-01 09:16:14

FTR, apparently this branch was merged anyway already.

#23 Updated by emmapeel 2017-05-03 13:31:29

sajolida wrote:
> I’m fine with being a bit more relaxed regarding the style in the known issues page but here I see to many sloppy things, you’ve been contributing to documentation for several years now, and you might get paid to do write some documentation in the near future. So please review your draft.
>

IMO the fear to this kind of public scolding ends up refraining people from contributing.

#24 Updated by intrigeri 2017-05-11 09:13:53

> IMO the fear to this kind of public scolding ends up refraining people from contributing.

If you want to discuss this privately (with or without sajolida), I can make myself available for it.

#25 Updated by sajolida 2017-05-16 14:43:16

Indeed I merged this by mistake.

Emma, I think still it would be good for you to spend a bit more time on this.

#26 Updated by emmapeel 2017-05-24 07:34:02

  • Assignee changed from emmapeel to goupille
  • Feature Branch deleted (emmapeel:doc/knownissues-nouveau)

Ok maybe more work is needed but I will leave it to the original writer then!

#27 Updated by sajolida 2017-05-25 17:37:24

  • Status changed from In Progress to Resolved
  • Assignee deleted (goupille)
  • % Done changed from 30 to 100

I’m sorry I didn’t read the whole ticket through before doing my review and since the commit was on your name I thought that you did that work when actually goupille wrote the original patch. I did my review accordingly and would have wrote it very differently if I had understood that I was reviewing goupille’s work and not yours.

So I improved a bit the phrasing with f6624229de and we can close this ticket now.

#28 Updated by intrigeri 2017-05-25 18:58:56

> I’m sorry I didn’t read the whole ticket through before doing my review and since the commit was on your name I thought that you did that work when actually goupille wrote the original patch. I did my review accordingly and would have wrote it very differently if I had understood that I was reviewing goupille’s work and not yours.

Thanks a lot for clarifying! :)