There were two problems here:
  1. misleading error message
  2. abusing KILL QUERY in the test case

1. The server reported "'DELETE FROM t1' failed: 1689: Wait on a lock was
aborted due to a pending exclusive lock", while the proper error message
should be "'DELETE FROM t1' failed: 1317: Query execution was interrupted".

The problem is that the server has two different flags for
signalling that a query is being killed: THD::killed and
mysys_var::abort. The test case triggers a race: sometimes
mysys_var::abort is set earlier than THD::killed. That leads
to the following situation:

  - thr_lock() checks mysys_var::abort and returns error status,
    since mysys_var::abort is set;

  - the caller (mysql_lock_tables()) gets an error from thr_lock(),
    but THD::killed is not set, so it decides that thr_lock() couldn't
    get a lock due to a pending exclusive lock.

This is a known issue with the server and it's not going to be fixed soon.

5.5 differs from 5.1 here as follows: when thr_lock() returns an error:
  - 5.1 continues trying thr_lock() until success;
  - 5.5 propagates the error

2. The test case uses KILL QUERY is a highly concurent environment.

The fix is to wait for the dying statement to rest in peace before
executing another DELETE FROM t1.

as done in 6.0 due to bug #47146.

experimental due to Bug 52202.

The patch is ready and will be pushed via -bugfixing.

This is a post-fix cleanup to move rpl.rpl_timezone out
of 'experimental' state.

resulution of bug #46895.

  - main.outfile_loaddata @solaris due to Bug#46895
  - main.signal_demo3 @solaris due to Bug#47791
  - main.sp @solaris due to Bug#47791
  - rpl.rpl_slave_load_remove_tmpfile @windows due to Bug#50474

The 'rpl_get_master_version_and_clock' test verifies if the slave I/O
thread tries to reconnect to master when it tries to get the values of
the UNIX_TIMESTAMP, SERVER_ID from master under network disconnection.
So the master server is restarted for making the transient network
disconnection, during the period the COM_REGISTER_SLAVE failures are
produced in server log file when the slave I/O thread tries to
register on master.

To fix the problem, suppress COM_REGISTER_SLAVE failures in server log
file by mtr suppression, because they are expected.

  - rpl.rpl_slave_load_remove_tmpfile
  - rpl.rpl_sync

Add the test to disabled list and remove from the experimental list.

      
Add the test to disabled list and remove from the experimental list.

and rpl.rpl_get_master_version_and_clock.

Disabled rpl_cross_version (instead of setting it experimental).
Fixed outstanding warning fix in main.debug_sync.

rpl.rpl_heartbeat_basic and rpl.rpl_cross_version set as experimental.

instead of making it experimental.

The bug has been closed.

rpl.rpl_trigger.test fails with valgrind errors with the innodb plugin

2. Mark ndb, rpl_ndb test suites experimental.