[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] fyi, Xen's EFI workarounds (/mapbs & efi=no-rs) on SuperMicro hardware; fixes solve 1/2 problems & SM responds that can't/won't fix their firmware


  • To: xen-devel@xxxxxxxxxxxxx
  • From: Doug Goldstein <cardoe@xxxxxxxxxx>
  • Date: Mon, 7 Dec 2015 11:15:54 -0600
  • Delivery-date: Mon, 07 Dec 2015 17:17:30 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xen.org>

On 12/7/15 8:20 AM, Konrad Rzeszutek Wilk wrote:
> On Mon, Dec 07, 2015 at 09:20:12AM -0500, Konrad Rzeszutek Wilk wrote:
>> On Sat, Dec 05, 2015 at 12:54:56PM -0800, PGNet Dev wrote:
>>> On 12/05/2015 11:44 AM, Konrad Rzeszutek Wilk wrote:
>>>>> Two issues exist with the SuperMicro EFI
>>>>>
>>>>>   (1) firmware EFI mis-mapping causing Xen PANIC on restart
>>>>
>>>> Can you try 'reboot=acpi' ?
>>>>
>>> ...
>>>>> I.e., what combination of
>>>>>
>>>>> /mapbs
>>>>> efi=no-rs
>>>>> reboot=acpi
>>>>>
>>>> All? It should be on the Xen command line.
>>>
>>> with /mapbs on the EFI exec line,
>>>
>>>     grep mapbs /boot/grub2/grub.cfg
>>>             chainloader $cmdpath/xen-4.6.0_04-398.efi xen-4.6.0_04-398.efi 
>>> config.1
>>> /mapbs
>>>
>>> and on the Xen Cmd Line,
>>>
>>>     grep efi= /boot/efi/EFI/opensuse/xen-4.6.0_04-398.cfg
>>>             options= dom0_mem=3072M,max:3072M ... loglvl=all 
>>> guest_loglvl=all
>>> efi=no-rs reboot=acpi
>>
>>>
>>> not clear to me what effect, if any, the addition of 'reboot=acpi' and
>>> '/mapbs' has, relative to just 'efi=no-rs' has.
>>
>>
>> Are you by chance an lawyer? :-)
>>
>> Try without /mapbs, efi=nr-rs and with reboot=acpi. That should use EFI 
>> routines
>> for everything (including reboot). Doing the 'reboot=acpi' will override
>> the reboot routine to only use the ACPI method.
>>
>> Granted if you did 'efi=nr-rs' we bypass EFI altogether and use 'acpi' 
>> method.
>>
>> My theory was that if use some EFI routines it inits the firmware enough
>> that ACPI reboot should work. But it may be that it is just not happy.
>>
>> There is an extra patch you can try to determine if the failure is
>> due to us doing ExitBootServices and not using virtual addresses (which
>> for example is the reason that under Lenovo it goes haywire).
>>
>> See attached patch (against staging). With that you would do:
> 
> Now attached.
>>
>> xen.efi /noexitboot /mapbs
>>
>> And you can try without 'efi=no-rs'.
>>
>> However I am wondering - why are you using '/mapbs' ? What did it
>> help? (The combination of 'efi=no-rs' means you are in effect not
>> using _any_ EFI operations - so doing /mapbs is not needed).
>>
>>
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@xxxxxxxxxxxxx
>> http://lists.xen.org/xen-devel

Konrad,

Can we land the /noexitboot (probably better to call it /noexitbs to
match rs) into the tree?

I have to have a very similar patch locally to bring up my machine and
it would make sense that if you and I are seeing this problem then
others are.

-- 
Doug Goldstein

Attachment: signature.asc
Description: OpenPGP digital signature

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

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.