On 31/03/15 19:23, Paolo Bonzini wrote:
On 31/03/2015 13:16, Brad Campbell wrote:
If you look at the bisect point I'm currently at it's a mix of i2c and
arm. The only vaguely relevant (as far as I can see) commit is the
addition of the getrandom() syscall, so my bisect is looking dodgy at
best. If I can come up with a better test case on a non-critical box
then I'll be in a better position to try and help get to the bottom of
the issue.
Yes, the bisect went wrong somewhere. Still, the 'bad' commit leave
both a net-next and a KVM merge, so it could be worse. :)
So the bisect went horribly wrong _again_ and I've been completely
unable to reproduce this problem on a test or staging machine (tried
both), so I'm down to trying the 4 commits you suggested (pre/post KVM &
pre/post net) to see if I can find bookends for another targeted bisect.
I'm 23 hours into the pre-kvm commit, so I probably need another week or
two to at least identify some new bisect points as I really to want to
leave it run for 4 or 5 days for a good kernel.
I tried running iperf in various automated incarnations to speed up the
determination of a bad kernel, but it made absolutely no difference at
all to the fault time. The other thing that occurred to me is of course
I'm sucking in about 1.5Mb/s through the network and immediately
streaming it out to disk, so it's entirely possible it may be disk
related too.
I'll keep plugging away. In the mean time if anyone has any ideas I'm
all ears.
Regards,
Brad
--
Dolphins are so intelligent that within a few weeks they can train
Americans to stand at the edge of the pool and throw them fish.
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
