From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:57662) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1avJPv-0003C6-Si for qemu-devel@nongnu.org; Wed, 27 Apr 2016 02:57:52 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1avJPu-0005uk-Qt for qemu-devel@nongnu.org; Wed, 27 Apr 2016 02:57:47 -0400 Received: from hall.aurel32.net ([2001:bc8:30d7:100::1]:48641) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1avJPu-0005op-L2 for qemu-devel@nongnu.org; Wed, 27 Apr 2016 02:57:46 -0400 Date: Wed, 27 Apr 2016 08:57:24 +0200 From: Aurelien Jarno Message-ID: <20160427065724.GA24455@aurel32.net> References: <20160427031211.GA15548@roeck-us.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160427031211.GA15548@roeck-us.net> Subject: Re: [Qemu-devel] 'tcg fatal error' with qemu v2.6.0-rc3 (bisected) List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Guenter Roeck Cc: qemu-devel@nongnu.org, Richard Henderson On 2016-04-26 20:12, Guenter Roeck wrote: > Hi, > > when running qemu version 2.6.0-rc3, I get the following error message. > > /opt/buildbot/qemu/qemu/tcg/tcg.c:1769: tcg fatal error > > qemu command line is as follows. > > qemu-system-ppc64 -M mpc8544ds \ > -cpu e5500 \ > -m 1024 -kernel arch/powerpc/boot/uImage -initrd busybox-ppc.cpio \ > -nographic -vga none -monitor null -no-reboot \ > --append "rdinit=/sbin/init console=tty console=ttyS0" \ > -machine "dt_compatible=fsl,,P5020DS" > > Files are from my test suite at https://github.com/groeck/linux-build-test. I have try to reproduce the issue with a kernel build with my toolchain and your defconfig, but it worked for me. Could you please share the binaries so that it is easier to reproduce the issue? > Bisect points to commit 40ae5c62ebaaf7d9d3b93b88c2d32bf6342f7889 ("tcg: > Introduce temp_load"). Bisect log is attached. I look at this patch again quickly, and I don't think the bug is actually introduced by this commit, it is just that it does more strict tests on the value. I guess it was working before by chance by loading a random value into the register. That said to look deeper into it, it would be better to be able to reproduce the issue. Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurelien@aurel32.net http://www.aurel32.net