On Wily/mesa-kms starting a server with a "test client" crashes the server

[Alan Griffiths]

$ sudo bin/mir_demo_server --display-config sidebyside --test-client bin/mir_demo_client_basic

Expect: the server to start (and the client to connect then exit immediately)

Actual: server crashes

ERROR: /home/alan/display_server/mir1/src/common/fatal/fatal.cpp(55): Throw in function void mir::fatal_error_except(const char*, ...)
Dynamic exception type: boost::exception_detail::clone_impl<boost::exception_detail::error_info_injector<std::runtime_error> >
std::exception::what: Failed to schedule page flip

Note this may be related to lp:1489689 which notes similar symptoms starting at the same time.

I see the problem with both trunk and 0.14 (not with mesa-x11, not with vivid)

[Alan Griffiths (alan-griffiths)]

More information:

--- src/platforms/mesa/server/kms/kms_page_flipper.cpp 2015-07-23 02:39:20 +0000
+++ src/platforms/mesa/server/kms/kms_page_flipper.cpp 2015-08-28 10:42:02 +0000
@@ -65,7 +65,10 @@
                                &pending_page_flips[crtc_id]);

     if (ret)
+ {
+ printf("DEBUG cannot flip CRTC for connector %u (%d): %m\n", crtc_id, errno);
         pending_page_flips.erase(crtc_id);
+ }

     return (ret == 0);
 }

~~~~

DEBUG cannot flip CRTC for connector 24 (13): Permission denied
DEBUG: Dying, outputs=1
DEBUG cannot flip CRTC for connector 20 (13): Permission denied
DEBUG: Dying, outputs=1
ERROR: /home/alan/display_server/mir1/src/common/fatal/fatal.cpp(55): Throw in function void mir::fatal_error_except(const char*, ...)
Dynamic exception type: boost::exception_detail::clone_impl<boost::exception_detail::error_info_injector<std::runtime_error> >
std::exception::what: Failed to schedule page flip

[Andreas Pokorny (andreas-pokorny)]

The same happens here i915/i965 the same command with --launch-client works though.

[Daniel van Vugt (vanvugt)]

We could dance around page flip scheduling and only do it when we think it's safe, but that's not a reliable solution and I suspect we already do that.

If we find there are still realistic ways of causing this error that are not themselves Mir bugs then we need to treat it as a warning only (one that does not repeat and flood the log).

[Daniel van Vugt (vanvugt)]

mir (0.16.0+15.10.20150921.1-0ubuntu1) wily; urgency=medium