Make CI great again

[czapiga]

We have to either fix failing tests or disable them. Now every time someone changes pull request he has to check travis logs because it's the only way to find out if your change broke something or is it regurarly failing testcases

[rafalcieslak]

I'm glad I'm not the only one who is bother by this. I've been trying to solve this for the past few weeks, and I have a feeling we're very close. All currently observable Travis failures are fixed by #234, and if it was up to me I'd merge that branch a long time ago, but @cahirwpz dislikes my primitive locking strategy and prefers to implement major changes to the scheduler while we're at it...

The problem is that there are no particular failing tests - entire kernel is falling apart - so it's not solvable by simply disabling a test or two until we fix things. It's also possible that even after we're done with #234 Travis will still report errors, but I am unable to fix them beforehand, as testing the kernel on other (local) machines does not yield any problems.

So stay patient - I'm on it, but my progress is currently blocked by #234. I understand this is not a satisfying answer, but it's all I can do for now.

[cahirwpz]

Though I consider #234 to be a hack, I've merged it, as there's no simple solution to the problem. I've spent several hours reading *BSD sources and proper locking strategy for scheduler is another long story.

@rafalcieslak It's not that I dislike your change. I'm just trying to figure out if there's a better solution. The answer is yes – but not without significant effort, which we cannot afford now.