Bug #11095
GNOME session fails to start with some AMD/ATI radeon GPU
0%
Description
we’ve got multiple reports of users unable to get to the desktop after the greeter, using computers with AMD/ATI radeon GPU.
most of them get the “oh no! Something has gone wrong. A problem has occurred and the system can’t recover. Please contact a system administrator” screen
other get to the desktop for few seconds, then they are sent back to the greeter. log in again result in a black screen or the console and a freeze.
one get to the desktop but with a very low resolution
I have tails-debugging-info from failsafe sessions (none of the users could get one from a ‘real’ session) that show this error multiple times:
[drm] VGACON disable radeon kernel modesetting.
[drm:radeon_init] *ERROR* No UMS support in radeon module!this happened with these GPU :
Advanced Micro Devices, Inc. [AMD/ATI] Mars XTX [Radeon HD 8790M]
Advanced Micro Devices, Inc. [AMD/ATI] Mars XTX [Radeon HD 8790M] (rev ff)
Advanced Micro Devices, Inc. [AMD/ATI] Cedar [Radeon HD 5000/6000 7350/8350 Series]
Advanced Micro Devices, Inc. [AMD/ATI] Broadway PRO [Mobility Radeon HD 5850]
Advanced Micro Devices, Inc. [AMD/ATI] RV730/M96 [Mobility Radeon HD 4650/5165](the last one is the one able to access the desktop)
Subtasks
Related issues
|
Related to Tails - |
Resolved | 2016-03-12 | |
|
Related to Tails - |
Rejected | 2016-04-29 | |
|
Related to Tails - |
Rejected | 2017-04-26 |
History
#1 Updated by intrigeri 2016-02-09 13:37:12
- Assignee changed from intrigeri to goupille
- QA Check set to Info Needed
I see two cases:
- either it’s expected that this hardware is not supported with Jessie’s kernel and X.Org: please check this if you didn’t do it yet; in this case, we’ll need to:
- check if it’ll be fixed by upgrading the kernel (covered by
Feature #10298), or the X.Org radeon driver (a backport might be an option): I could do that; - document this as a known issue for now: there you go;
- check if it’ll be fixed by upgrading the kernel (covered by
- or, it works on Debian Jessie but not in Tails, and then I’ll need debugging info from at least one session that exposes one of these bugs; frankly, I doubt this is the case.
> I have tails-debugging-info from failsafe sessions (none of the users could get one from a ‘real’ session) that show this error multiple times:
> [drm] VGACON disable radeon kernel modesetting.
> [drm:radeon_init] ERROR No UMS support in radeon module!
Failsafe explicitly disables KMS, so we’re on UMS, and then some graphics drivers don’t support UMS anymore on Jessie, so this is quite expected.
#2 Updated by intrigeri 2016-02-10 11:31:10
- Subject changed from X fails to start with some AMD/ATI radeon GPU to GNOME session fails to start with some AMD/ATI radeon GPU
#3 Updated by goupille 2016-02-11 10:25:51
it seems to work with a live Debian-jessie, but another user proposed to add
radeon.modeset=0at the boot as a workaround.
#4 Updated by intrigeri 2016-02-11 10:41:00
> it seems to work with a live Debian-jessie
On which hardware?
> but another user proposed to add
>
> radeon.modeset=0
> > at the boot as a workaround.
… and what are the effects for this user? On which hardware?
#5 Updated by goupille 2016-02-12 11:53:58
the workaround is reported working with [AMD/ATI] Mars XTX [Radeon HD 8790M] and [AMD/ATI] Cedar HDMI Audio [Radeon HD 5400/6300 Series]
and Debian Jessie (live) is starting gnome without the issue with [AMD/ATI] Mars XTX [Radeon HD 8790M]
#6 Updated by goupille 2016-02-15 14:41:50
the workaround is reported working on ATI Radeon 3200 graphics. the user says that the icons are larger than they should and “out of proportions” but “very usable”.
#8 Updated by intrigeri 2016-03-12 16:09:11
> nomodeset
FYI, nomodeset means “disable KMS for all drivers”, that is it’s essentialy radeon.modeset=0 i915.modeset=0 [...]. We have nomodeset in “failsafe” mode. So it’s good that our already documented workaround for such problems works => we don’t have to handle it with a very high priority. So, even if it would be nice if the basic hardware compatibility research requested a month ago was done some day, we can go on taking it easy.
> xorg-driver=fbdev
Maybe that’s a candidate for the “Tails does not start entirely” doc? Now, I’m confused since https://tails.boum.org/doc/first_steps/bug_reporting/tails_does_not_start/ does not even suggest the failsafe option, so I’m not quite sure where these suggestions should go. OTOH wiki/src/install/inc/steps/not_entirely.inline.mdwn mentions failsafe.
#9 Updated by emmapeel 2016-03-12 23:13:46
Please review excerpt for the Known Issues page, at emmapeel:docs/11095
#10 Updated by emmapeel 2016-03-13 09:17:07
- related to
Bug #11225: Known Issues: Add Gnome ATI Crash problem with workaround added
#11 Updated by elouann 2016-04-21 11:19:17
Another user reported a similar issue, and added that he/she was able to bypass the greeter by removing ‘noautologin’ from the boot options: the desktop loads directly. Then it’s possible to get more informations with ‘sudo tails-debugging’, which works without admin password
#12 Updated by intrigeri 2016-04-29 13:54:03
Anyone affected: please try the experimental ISO at http://nightly.tails.boum.org/build_Tails_ISO_feature-11303-mesa-backport/lastSuccessful/archive/latest.iso and report back.
@frontdesk people: please ask your bug reporters to do that :)
#13 Updated by intrigeri 2016-04-29 14:35:35
> Another user reported a similar issue, and added that he/she was able to bypass the greeter by removing ‘noautologin’ from the boot options: the desktop loads directly. Then it’s possible to get more informations with ‘sudo tails-debugging’, which works without admin password
Cool, please consider documenting this as part of “do whatever small tasks will make the frontdesk job’s easier in the future”. Beware though, the resulting system will have undefined (and potentially dangerous) behaviour and should not be used for anything else than bug reporting. Now, let’s stop discussing this here, since we’re drifting off-topic :)
#14 Updated by elouann 2016-04-29 15:21:40
intrigeri wrote:
> @frontdesk people: please ask your bug reporters to do that :)
Done
> Cool, please consider documenting this […]
Ok, this is now tracked in Bug #11392
#15 Updated by BitingBird 2016-06-29 06:45:53
- related to
Bug #11392: Tails does not start: document workarounds to reach debug information added
#16 Updated by mercedes508 2016-07-16 09:37:54
- Status changed from New to Confirmed
#17 Updated by intrigeri 2016-08-11 10:54:11
- Assignee changed from goupille to elouann
elouann wrote:
> intrigeri wrote:
> > @frontdesk people: please ask your bug reporters to do that :)
>
> Done
Any feedback from them?
#18 Updated by intrigeri 2016-08-11 10:56:14
Also, it would be useful if they tested experimental ISO images from http://nightly.tails.boum.org/build_Tails_ISO_devel/lastSuccessful/archive/.
#19 Updated by intrigeri 2017-04-29 10:56:34
- related to
Bug #12482: Stuck on 'Start job waiting...' using Radeon driver with 3.0-betax added
#20 Updated by intrigeri 2017-05-16 10:05:52
intrigeri wrote:
> elouann wrote:
> > intrigeri wrote:
> > > @frontdesk people: please ask your bug reporters to do that :)
> >
> > Done
>
> Any feedback from them?
elouann, 9 months later: ping?
#21 Updated by Anonymous 2017-06-29 10:04:26
- Status changed from Confirmed to Resolved
- QA Check deleted (
Info Needed)
The documentation task is tracked on Bug #11392.
Emmapeels branch to improve the known issues page was merged. Closing.