Attaching d6001-2a-waitTimeout.diff which increases the wait timeout for testDeadlockTimeout to 60 seconds. The test still completes in just a few seconds, as the higher timeout just gives it a larger window, it doesn't require the test to use the entire available time slot.
Since the test now uses different timeout values for testLockTimeout and testDeadlockTimeout, I also reduced the wait timeout for the former test case to speed it up. That test case is single-threaded and not timing sensitive, so reducing the timeout should not reduce the chance of success.
I also reduced the deadlock timeout for testDeadlockTimeout to 1 second, as it is the difference between the wait timeout and the deadlock timeout that's determining the chance of success, not the size of the deadlock timeout. So we could just as well keep it short to make the test complete faster (even if it's just one second faster).
I'm running the test in a loop on one of the machines where I've seen the problem (successfully so far). The problem happens a lot less frequently when the test runs standalone, though, so I'm sure that necessarily will help finding out if it's fixed.
(suites.All takes 15 hours on that platform, so I'm not going to run suites.All in a loop to verify the fix...)