On 9 November 2015 at 09:10, Paolo Bonzini <pbonz...@redhat.com> wrote: > > > On 08/11/2015 23:55, Peter Maydell wrote: >> So the good news is that on mainline this doesn't happen any more. >> The bad news is that something weird is going on such that git >> bisect doesn't give helpful answers. Specifically if I start by >> compiling older versions and work forwards, then >> 0fd7e09 kvmclock: add a new function to update env->tsc. >> shows the bug, and >> 6388acc Revert "Introduce cpu_clean_all_dirty" >> does not. (And I've got to that commit both via a git-bisect >> and by a second round of manually trying to identify the commit, >> so it's consistent about where it changes behaviour.) >> However that makes no sense because that revert commit >> is just removing unused code. And then if I go backwards again >> to 0fd7e09 the bug doesn't repro there. > > Even 0fd7e09 does not change behavior unless you use KVM (which you > obviously don't do under Mac OS X). So if you go backwards to 0fd7e09^ > it shouldn't reproduce there either. > > What is the known bad SHA1?
2b5a79f is definitely bad even rebuilt from clean. I'm going to do a re-bisect building each step from clean this morning. thanks -- PMM