Re: [Xen-devel] Xen 4.7.0 boot PANIC on kernel 4.7.0-4 + UEFI ?

[lists@xxxxxxxxxxxx]

> > A #GP fault in firmware code. Not much we can do about, I'm afraid,
> > except for having you go with one of the mentioned workarounds

I tried

        + efi=no-rs
        + efi=attr=uc

on the Xen cmd line.

With efi=attr=uc, crashes on reboot with or without /mapbs

With efi=no-rs, reboots OK with or without /mapbs

So *today's* simplest working combination seems to be 

- /mapbs, + efi=no-rs

Two weeks  or so ago, it was just

+ /mapbs

> > (and perhaps getting in touch with the BIOS vendor).

The BIOS vendor refuses to talk to end users.  They deflect to the Motherboard 
vendor.

The motherboard vendor is Supermicro.  We have four different servers running 
on their motherboards.

Supermicro are not interested in a small user's problems.  Their responses have 
included

        - we don't support linux
        - we don't support Xen
        - use Microsoft WIndows
        - we don't write the BIOS. there's nothing we can do.

and finally just ignoring our emails.

At least Supermicro, being a 'server grade' mobo provider, has tech support you 
can get to that seem aware of linux & Xen.

The 'consumer grade' providers were just completely hopeless the moment you 
mention linux, xen, and or server.

And to be honest, what exactly would *I* tell them?  "It doesn't work"? It's 
not like I have any real idea what's broken in detail or how to fix it.

Unless devs that know what they're talking about, and are from a big vendor or 
project with visible presence or clout, get in touch with them nothing will 
change. 

> One bit you snipped was
> 
> (XEN) [2016-08-03 13:06:54] Xen code around <000000009e746340>
> (000000009e746340):
> (XEN) [2016-08-03 13:06:54]  00 00 00 00 00 00 00 00 <00> 00 00 00 00 00
> 00 00 00 00 00 00 00 00 00 00
> (XEN) [2016-08-03 13:06:54] Xen stack trace from rsp=ffff83008ce27dc0:
> 
> which shows that the EFI firmware has ended up in a block of zeroes. 
> This clearly isn't conducive to its overall health.

What options to the Xen or EFI command line can fix that?
Or is that a Xen or kernel code fix?
Or again a "BIOS issue"?

Fwiw 3 of those 4 servers are now being migrated to other Hypervisor/Container 
platforms.

So far KVM, FreeBSD and Microsoft are all booting & rebooting on UEFI hardware 
OK. Or at least not seeing crashes.  Haven't gotten much further in testing 
than that yet.

I'm not clear why 'BIOS' problems are only showing up when we use Xen, and only 
since 'recent' upgrades (it was working a few weeks ago), and now need (at 
least) efi=no-rs when they didn't before.

If I tell Supermicro that their motherboard works on these other platforms, 
particularly Microsoft, but not with Xen, I'm pretty sure I know exactly what 
they'll say.  And as an enduser I don't have the detailed knowledge to argue 
with them.  Let alone get them to do anything about it.



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel