Problems switching VTs

Bug #1634888 reported by Michael Terry
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Mir
New
Undecided
Unassigned
mir (Ubuntu)
New
Undecided
Unassigned

Bug Description

I've hit an issue where LightDM trying to switch directly from a USC-owned VT to an X-owned VT crashes X instead and doesn't switch VTs after all.

I'm not sure exactly where the problem lies or exactly what the root cause is. But here's my reproduction steps:

1) bileto host-upgrade 1679 # upgrades unity8 to have an in-session lockscreen -- you must be in vivid, xenial, or zesty
2) sudo apt update && sudo apt upgrade
3) sudo apt install unity8-desktop-session
4) Reboot
5) Log one user into a unity7 session.
6) Switch users and log a separate user into a unity8 session.
7) In unity8, press Ctrl+L to show the in-session lockscreen and switch to the unity7 user.
8) Usually this breaks things and the switch doesn't happen. Sometimes it will work in which case switch back and forth until it does.

That's a bit of a pain, I understand. It's just the how I hit this bug. I think switching directly from a USC-owned VT to an X-owned VT is hitting a new and odd code path.

What happens under the cover that I've found is that X fails during EnterVT and aborts. Which confuses everyone else, including lightdm.

RAOF says "The hypothesis is that Mir fails to drop master for whatever reason, which results in it (correctly) NAKing the VT switch. (We call drmDropMaster, but that can fail; if it does, we throw an exception, (silently) catch it, and NAK the VT switch)"

I have a USC log with MIR_SERVER_DISPLAY_REPORT=log set (though I can't see any display report spew...?) but it's not very revealing: http://paste.ubuntu.com/23348320

Michael Terry (mterry)
Changed in mir (Ubuntu):
assignee: nobody → Chris Halse Rogers (raof)
description: updated
description: updated
Revision history for this message
Daniel van Vugt (vanvugt) wrote :

Crashing X (or any display server) can happen if it tries to make drm calls when not owning DRM mastership. Each display server needs to have its own guarantees that it only calls drm functions after successfully taking DRM mastership.

Revision history for this message
Chris Halse Rogers (raof) wrote :

X will crash if it cannot claim DRM master. Do we have an X log for this bit?

Revision history for this message
Chris Halse Rogers (raof) wrote :

However, the USC log strongly suggests that USC has successfully dropped master.

Revision history for this message
Michael Terry (mterry) wrote :

The X log says "Fatal server error: EnterVT failed for screen 0". Nothing more specific.

Some more bits of info:

- Nothing bad happens if I manually (Ctrl+Alt+FN) switch between the VTs. But I'm guessing that's a deep kernel thing, a different code path.

- If I instead try to reproduce by using unity8-greeter (which uses Mir and USC just like a unity8 session does) and logging into an existing unity7 session -- i.e. the same reproduction steps just with a greeter instead of a session -- I can't reproduce. So the biggest difference here is that the USC/greeter session is torn down as part of the switch (I don't know if before or after the switch yet). With my original repro steps, USC stays around the whole time.

Next step is to use chvt to test whether removing LightDM from the mix helps.

Revision history for this message
Michael Terry (mterry) wrote :

I tested with chvt over ssh, didn't reproduce.

HOWEVER, this seems a touch harder to reproduce than I had thought originally. So my earlier lack of success reproducing in different cases carry less weight than I hoped.

However, with RAOF's help, I have a bit more of a verbose message from X. I also now see this error: "(WW) intel(0): drmDropMaster failed: Invalid argument"

Revision history for this message
Michael Terry (mterry) wrote :

But that message comes after, not before the EnterVT error. And seems to happen during a LeaveVT call. So that might simply be a response to the previous EnterVT failure.

Changed in mir (Ubuntu):
assignee: Chris Halse Rogers (raof) → nobody
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

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