Re: [PATCH 2/2] efi/x86: Add a quirk to support command line arguments on Dell EFI firmware

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

 



On Wed, 16 Sep 2020 at 19:45, Arvind Sankar <nivedita@xxxxxxxxxxxx> wrote:
>
> On Wed, Sep 16, 2020 at 06:50:15PM +0200, Jacobo Pantoja wrote:
> > Hi, I'd like to update my testing and share my thoughts.
> >
> > Regarding the patches:
> > 1) The patches in email 1/2 (the functions "efi_warn", etc.) are not working
> > properly. I got some suggestions for testing from Ard in a separate email.
> >   3a. If, in this 2nd patch, I switch the "efi_warn_once" with an
> > "efi_printk", the
> >   messages appear.
> >   1a. I've set CONFIG_CONSOLE_LOGLEVEL_DEFAULT=5, same result
> >   2a. I've switched from "efi_warn_once" to "efi_warn", same result.
>
> I had tested on QEMU, and the messages appear there. Not sure what might
> cause efi_warn to not work if efi_printk is working.

I was changing the wrong "config", so LOGLEVEL was really 4. Now, being set
as 5, everything appears as expected (after almost 2 hours recompiling, lucky
ThreadRipper owners).
Sorry for the noise

>
> > 2) Even if they would be working, since it is not logged anywhere, I
> > don't really
> > think these messages make sense. Idk if these can be made available to dmesg.
>
> They're useful mostly in the case the boot hangs in the EFI stub. If the
> boot works, they will generally disappear very quickly, making them
> difficult to notice/read.
>
> > 3) The function "efi_apply_loadoptions_quirk" is called twice, it seems to me
> > that calling it from the "file.c" is redundant, but probably I'm
> > missing something.
>
> file.c reads the original UTF-16 command line. It's possible to refactor
> the code so it doesn't have to quirk twice, but this was the smallest
> change for now.
>

Understood, thanks for the explanation.

> >
> > Regarding the quirk itself, in my opinion we should wait for Mario's
> > news, since,
> > again in my opinion, this is something that should be fixed in the
> > firmware itself.
> > Being Dell a serious company, I think it is feasible that, at least
> > for their enterprise
> > products, they might fix it.
> >
> > On Tue, 15 Sep 2020 at 17:09, Ard Biesheuvel <ardb@xxxxxxxxxx> wrote:
> > >
> > > On Tue, 15 Sep 2020 at 00:35, Arvind Sankar <nivedita@xxxxxxxxxxxx> wrote:
> > > >
> > > > At least some versions of Dell EFI firmware pass the entire
> > > > EFI_LOAD_OPTION descriptor, rather than just the OptionalData part, to
> > > > the loaded image. This was verified with firmware revision 2.15.0 on a
> > > > Dell Precision T3620 by Jacobo Pontaja.
> >
> > Please be so kind to correct my name, if it's being included in the commit msg.
>
> Oops, sorry about that. Ard, can you fix that up?
Thanks
>
> Thanks.



[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux