From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id 1BB6D1A1E3C for ; Tue, 18 Oct 2016 00:43:42 -0700 (PDT) Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 6EEF94FC; Tue, 18 Oct 2016 07:43:41 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-116-72.phx2.redhat.com [10.3.116.72]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u9I7hdhv003128; Tue, 18 Oct 2016 03:43:40 -0400 To: Bruce Cran References: <025d38a8-b5d9-c519-3f03-59ffcbe114bf@cran.org.uk> From: Laszlo Ersek Cc: edk2-devel@ml01.01.org Message-ID: Date: Tue, 18 Oct 2016 09:43:39 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <025d38a8-b5d9-c519-3f03-59ffcbe114bf@cran.org.uk> X-Scanned-By: MIMEDefang 2.68 on 10.5.11.27 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.29]); Tue, 18 Oct 2016 07:43:41 +0000 (UTC) Subject: Re: OvmfPkg: hang in SetInterruptState with git 245cda6641ade1f1013c2d5c9c838f2706636828 X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Oct 2016 07:43:42 -0000 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit On 10/18/16 02:06, Bruce Cran wrote: > I've just built both OVMF _and_ Qemu from the latest git sources, so I > don't know which is at fault - but I'm seeing a hang in: > > #0 0x000000007f9dc030 in SetInterruptState (InterruptState=104 'h') > at /home/bcran/workspace/edk2/MdePkg/Library/BaseLib/Cpu.c:60 > > It's at line 60 when it calls EnableInterrupts(). > > The entire backtrace is: > > #0 0x000000007f9dc030 in SetInterruptState (InterruptState=104 'h') > at /home/bcran/workspace/edk2/MdePkg/Library/BaseLib/Cpu.c:60 > #1 0x000000007f9d6c57 in UpdateIdtTable (IdtTable=0xd, > TemplateMap=0x7fadd478, ExceptionHandlerData=0x7f9e2460) > at > /home/bcran/workspace/edk2/UefiCpuPkg/Library/CpuExceptionHandlerLib/PeiDxeSmmCpuException.c:146 > > #2 0x000000007f9d5ff0 in InitializeCpuInterruptHandlers (VectorInfo=0xd) > at > /home/bcran/workspace/edk2/UefiCpuPkg/Library/CpuExceptionHandlerLib/DxeException.c:111 > > #3 0x000000007f9d65fd in HasErrorCode () > #4 0x000000000000000d in ?? () > #5 0x000000007fadd478 in ?? () > #6 0x000000007fa7b748 in ?? () > #7 0x0000000000000012 in ?? () > #8 0x000000007fadd4a0 in ?? () > #9 0x0000000000000000 in ?? () > > > I _have_ tried going back to older revisions of qemu so I'm wondering if > this could be a problem introduced by OVMF? > Introduced when? :) It's been a while since we committed anything to OvmfPkg that could cause this. Similarly, I don't recall anything risky like this going into UefiCpuPkg. I rebuild OVMF every few days, against current master, and I'm not seeing this. (Just retested at aaba2a44c24e.) So, we'll need more data here: - Did you update KVM too perhaps? - What is the last edk2 tree that works for you? (If you don't remember, then looking at git reflog --date=local master | less in your edk2 clone can help -- it will tell you the dates at which you pulled master, and at what new commits) - What are the KVM, qemu, edk2 versions that reproduce the bug? - How did you build OVMF? - What is your QEMU command line? (And how did you build QEMU?) - Do you see anything in the OVMF log or on the serial console of the VM? In particular, the fact that you are inside CpuExceptionHandlerLib (according to your backtrace), implies that there was a page fault (or other kind of exception). CpuExceptionHandlerLib dumps the registers and the offending module to the serial console; so if you are lucky, you might get that dump before CpuExceptionHandlerLib itself gets stuck (for whatever reason). Thanks! Laszlo