From mboxrd@z Thu Jan 1 00:00:00 1970 From: Martin Unzner Subject: Re: [Xen-users] XEN bug at traps.c:3271 Date: Mon, 20 Jan 2014 18:16:48 +0100 Message-ID: <52DD5A00.8070502@gmx.de> References: <52DBC709.80707@gmx.de> <1390212958.20516.21.camel@kazak.uk.xensource.com> <52DD19B10200007800115046@nat28.tlf.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <52DD19B10200007800115046@nat28.tlf.novell.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Jan Beulich Cc: Ian Campbell , xen-devel List-Id: xen-devel@lists.xenproject.org OK, well, that is unfortunate. I suppose you will announce new versions of Xen on the xen-users mailing list, or is there another channel where you would communicate a solution for this issue? Thanks! Am 20.01.2014 12:42, schrieb Jan Beulich: >>>> On 20.01.14 at 11:15, Ian Campbell wrote: >> On Sun, 2014-01-19 at 13:37 +0100, Martin Unzner wrote: >>> Hi list, >>> >>> I just installed Xen 4.3.1 for EFI according to >>> https://bbs.archlinux.org/viewtopic.php?pid=1359933 and tried to boot >>> it. There was a crash at the very beginning, notifying me of a bug at >>> traps.c:3271. I could not find any logs, so I just noted the stack trace >>> on a sheet of paper: >>> >>> do_device_not_available >>> handle_exception >>> efi_get_time >>> get_cmos_time >>> init_xen_time >>> __start_xen >>> >>> Does that mean my hardware is incompatible? >> No, just that you've found a bug I think. >> >> I'm copying the devel list here to see if anyone has any clues. > We've seen that before: You unfortunately have got one of those > UEFI implementations that utilize XMM (or, unlikely, FPU) registers, > and Xen doesn't allow this. Which is a consequence of the UEFI > specification being imprecise here: Some firmware implementors > read it to allow such, while my reading of it results in this not being > allowed. This is currently being brought up with the USWG for a > resolution. I'm afraid there's nothing you can do to work around > this for the time being (short of not booting via xen.efi, which - > depending on how you do it and depending on your firmware - > may have other bad side effects). > > Jan >