From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:33419) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zvja1-0001tR-7a for qemu-devel@nongnu.org; Mon, 09 Nov 2015 05:21:42 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZvjZz-000195-Dk for qemu-devel@nongnu.org; Mon, 09 Nov 2015 05:21:41 -0500 Received: from mx1.redhat.com ([209.132.183.28]:53840) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZvjZz-00018y-6c for qemu-devel@nongnu.org; Mon, 09 Nov 2015 05:21:39 -0500 References: <56406315.6050402@redhat.com> From: Paolo Bonzini Message-ID: <564073AE.6010602@redhat.com> Date: Mon, 9 Nov 2015 11:21:34 +0100 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] Qemu: Guest Linux hangs on Mac OS X 10.11 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Maydell Cc: Aaron Elkins , "qemu-devel@nongnu.org Developers" On 09/11/2015 11:02, Peter Maydell wrote: > On 9 November 2015 at 09:10, Paolo Bonzini 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? >=20 > 2b5a79f is definitely bad even rebuilt from clean. I'm going Hmm, so the list is pretty short: ------------- Eduardo Habkost (3): pc: Set hw_version on all machine classes osdep: Rename qemu_{get, set}_version() to qemu_{, set_}hw_version(= ) megasas: Use qemu_hw_version() instead of QEMU_VERSION Fam Zheng (1): scripts/text2pod.pl: Escape left brace Igor Mammedov (1): file_ram_alloc: propagate error to caller instead of terminating QE= MU John Snow (2): configure: disallow ccache during compile tests configure: disable FORTIFY_SOURCE under clang Paolo Bonzini (4): target-i386: fix pcmpxstrx equal-ordered (strstr) mode ioport: do not use CPU_LOG_IOPORT qemu-log: remove -d ioport memory: call begin, log_start and commit when registering a new lis= tener Pavel Fedin (1): backends/hostmem-file: Allow to specify full pathname for backing f= ile Stefan Weil (1): cpu-exec: Fix compiler warning (-Werror=3Dclobbered) ------------- The only patches that could possibly fix the bug are: target-i386: fix pcmpxstrx equal-ordered (strstr) mode memory: call begin, log_start and commit when registering a new listener cpu-exec: Fix compiler warning (-Werror=3Dclobbered) It's probably the second. The first has been there forever, while the last doesn't have any effect under clang. Paolo