On Wed, 16 Sep 2020 at 23:51, Jacobo Pantoja <jacobopantoja@xxxxxxxxx> wrote: > > 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 Done
