Re: [Xen-users] XEN bug at traps.c:3271

Re: [Xen-users] XEN bug at traps.c:3271

[Ian Campbell]

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.

> Where would I find the Xen startup log, anyway?

In a normal running system in "xl dmesg" or you can configure
xenconsoled to write it to a file. But with a crash on boot it is too
soon for all of that, the solution is usually to use a serial console
(see the wiki), but a photograph or just noting to the error as you've
done can work too.

I'll leave it to others on the dev list to request a serial log or a
photo if they think it would be useful to have the additional
information (e.g. register state, stack addresses etc).

Ian.

Re: [Xen-users] XEN bug at traps.c:3271

[Jan Beulich]

>>> On 20.01.14 at 11:15, Ian Campbell <Ian.Campbell@citrix.com> 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

Re: [Xen-users] XEN bug at traps.c:3271

[Martin Unzner]

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 <Ian.Campbell@citrix.com> 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
>