[U-Boot,1/1] x86: show UEFI images involved in crash
diff mbox series

Message ID 20190825175512.13911-1-xypron.glpk@gmx.de
State Accepted
Delegated to: Bin Meng
Headers show
Series
  • [U-Boot,1/1] x86: show UEFI images involved in crash
Related show

Commit Message

Heinrich Schuchardt Aug. 25, 2019, 5:55 p.m. UTC
If a crash occurs, show the loaded UEFI images to facilitate analysis.

This is an example output:

=> bootefi 0x1000000
Found 0 disks
Hello world of bugs!
Invalid Opcode (Undefined Opcode)
EIP: 0010:[<06ceb06e>] EFLAGS: 00010206
Original EIP :[<fec9906e>]
EAX: 00000000 EBX: 06cec000 ECX: 00000fd0 EDX: 00000001
ESI: 06ced18a EDI: 07d0fe10 EBP: 07fe27a0 ESP: 07d0fde0
 DS: 0018 ES: 0018 FS: 0020 GS: 0018 SS: 0018
CR0: 00000033 CR2: 00000000 CR3: 00000000 CR4: 00000000
DR0: 00000000 DR1: 00000000 DR2: 00000000 DR3: 00000000
DR6: ffff0ff0 DR7: 00000400
Stack:
    0x07d0fde8 : 0x00000000
    0x07d0fde4 : 0x06ced040
--->0x07d0fde0 : 0x07fe27a0
    0x07d0fddc : 0x00010206
    0x07d0fdd8 : 0x00000010
    0x07d0fdd4 : 0x06ceb06e
UEFI image [0x06cea000:0x06cf0fff] pc=0x106e '/bug-i386.efi'
### ERROR ### Please RESET the board ###

With the additional information provided by this patch we know that the
problem occurred 0x106e after the load address of bug-i386.efi.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
---
 arch/x86/cpu/i386/interrupt.c | 14 ++++++++++++++
 1 file changed, 14 insertions(+)

--
2.20.1

Comments

Bin Meng Aug. 26, 2019, 6:13 a.m. UTC | #1
Hi Heinrich,

On Mon, Aug 26, 2019 at 1:55 AM Heinrich Schuchardt <xypron.glpk@gmx.de> wrote:
>
> If a crash occurs, show the loaded UEFI images to facilitate analysis.
>
> This is an example output:
>
> => bootefi 0x1000000
> Found 0 disks
> Hello world of bugs!
> Invalid Opcode (Undefined Opcode)
> EIP: 0010:[<06ceb06e>] EFLAGS: 00010206
> Original EIP :[<fec9906e>]
> EAX: 00000000 EBX: 06cec000 ECX: 00000fd0 EDX: 00000001
> ESI: 06ced18a EDI: 07d0fe10 EBP: 07fe27a0 ESP: 07d0fde0
>  DS: 0018 ES: 0018 FS: 0020 GS: 0018 SS: 0018
> CR0: 00000033 CR2: 00000000 CR3: 00000000 CR4: 00000000
> DR0: 00000000 DR1: 00000000 DR2: 00000000 DR3: 00000000
> DR6: ffff0ff0 DR7: 00000400
> Stack:
>     0x07d0fde8 : 0x00000000
>     0x07d0fde4 : 0x06ced040
> --->0x07d0fde0 : 0x07fe27a0
>     0x07d0fddc : 0x00010206
>     0x07d0fdd8 : 0x00000010
>     0x07d0fdd4 : 0x06ceb06e
> UEFI image [0x06cea000:0x06cf0fff] pc=0x106e '/bug-i386.efi'
> ### ERROR ### Please RESET the board ###
>
> With the additional information provided by this patch we know that the
> problem occurred 0x106e after the load address of bug-i386.efi.
>
> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
> ---
>  arch/x86/cpu/i386/interrupt.c | 14 ++++++++++++++
>  1 file changed, 14 insertions(+)
>
> diff --git a/arch/x86/cpu/i386/interrupt.c b/arch/x86/cpu/i386/interrupt.c
> index 47df3172b7..1445204878 100644
> --- a/arch/x86/cpu/i386/interrupt.c
> +++ b/arch/x86/cpu/i386/interrupt.c
> @@ -12,6 +12,7 @@
>
>  #include <common.h>
>  #include <dm.h>
> +#include <efi_loader.h>
>  #include <asm/control_regs.h>
>  #include <asm/i8259.h>
>  #include <asm/interrupt.h>
> @@ -64,6 +65,18 @@ static char *exceptions[] = {
>         "Reserved"
>  };
>
> +/**
> + * show_efi_loaded_images() - show loaded UEFI images
> + *
> + * List all loaded UEFI images.
> + *
> + * @eip:       instruction pointer
> + */
> +static void show_efi_loaded_images(uintptr_t eip)
> +{
> +       efi_print_image_infos((void *)eip);
> +}
> +
>  static void dump_regs(struct irq_regs *regs)
>  {
>         unsigned long cs, eip, eflags;
> @@ -144,6 +157,7 @@ static void dump_regs(struct irq_regs *regs)
>                 printf("0x%8.8lx : 0x%8.8lx\n", sp, (ulong)readl(sp));
>                 sp -= 4;
>         }
> +       show_efi_loaded_images(eip);

Should we wrap the call with #ifdef CONFIG_EFI_LOADER or something?

>  }

Regards,
Bin
Heinrich Schuchardt Aug. 26, 2019, 5:26 p.m. UTC | #2
On 8/26/19 8:13 AM, Bin Meng wrote:
> Hi Heinrich,
>
> On Mon, Aug 26, 2019 at 1:55 AM Heinrich Schuchardt <xypron.glpk@gmx.de> wrote:
>>
>> If a crash occurs, show the loaded UEFI images to facilitate analysis.
>>
>> This is an example output:
>>
>> => bootefi 0x1000000
>> Found 0 disks
>> Hello world of bugs!
>> Invalid Opcode (Undefined Opcode)
>> EIP: 0010:[<06ceb06e>] EFLAGS: 00010206
>> Original EIP :[<fec9906e>]
>> EAX: 00000000 EBX: 06cec000 ECX: 00000fd0 EDX: 00000001
>> ESI: 06ced18a EDI: 07d0fe10 EBP: 07fe27a0 ESP: 07d0fde0
>>   DS: 0018 ES: 0018 FS: 0020 GS: 0018 SS: 0018
>> CR0: 00000033 CR2: 00000000 CR3: 00000000 CR4: 00000000
>> DR0: 00000000 DR1: 00000000 DR2: 00000000 DR3: 00000000
>> DR6: ffff0ff0 DR7: 00000400
>> Stack:
>>      0x07d0fde8 : 0x00000000
>>      0x07d0fde4 : 0x06ced040
>> --->0x07d0fde0 : 0x07fe27a0
>>      0x07d0fddc : 0x00010206
>>      0x07d0fdd8 : 0x00000010
>>      0x07d0fdd4 : 0x06ceb06e
>> UEFI image [0x06cea000:0x06cf0fff] pc=0x106e '/bug-i386.efi'
>> ### ERROR ### Please RESET the board ###
>>
>> With the additional information provided by this patch we know that the
>> problem occurred 0x106e after the load address of bug-i386.efi.
>>
>> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
>> ---
>>   arch/x86/cpu/i386/interrupt.c | 14 ++++++++++++++
>>   1 file changed, 14 insertions(+)
>>
>> diff --git a/arch/x86/cpu/i386/interrupt.c b/arch/x86/cpu/i386/interrupt.c
>> index 47df3172b7..1445204878 100644
>> --- a/arch/x86/cpu/i386/interrupt.c
>> +++ b/arch/x86/cpu/i386/interrupt.c
>> @@ -12,6 +12,7 @@
>>
>>   #include <common.h>
>>   #include <dm.h>
>> +#include <efi_loader.h>
>>   #include <asm/control_regs.h>
>>   #include <asm/i8259.h>
>>   #include <asm/interrupt.h>
>> @@ -64,6 +65,18 @@ static char *exceptions[] = {
>>          "Reserved"
>>   };
>>
>> +/**
>> + * show_efi_loaded_images() - show loaded UEFI images
>> + *
>> + * List all loaded UEFI images.
>> + *
>> + * @eip:       instruction pointer
>> + */
>> +static void show_efi_loaded_images(uintptr_t eip)
>> +{
>> +       efi_print_image_infos((void *)eip);
>> +}
>> +
>>   static void dump_regs(struct irq_regs *regs)
>>   {
>>          unsigned long cs, eip, eflags;
>> @@ -144,6 +157,7 @@ static void dump_regs(struct irq_regs *regs)
>>                  printf("0x%8.8lx : 0x%8.8lx\n", sp, (ulong)readl(sp));
>>                  sp -= 4;
>>          }
>> +       show_efi_loaded_images(eip);
>
> Should we wrap the call with #ifdef CONFIG_EFI_LOADER or something?

In include/efi_loader.h we have

static inline void efi_print_image_infos(void *pc) { }

if EFI_LOADER is not defined.

Best regards

Heinrich

>
>>   }
>
> Regards,
> Bin
>
Bin Meng Aug. 27, 2019, 1:18 a.m. UTC | #3
Hi Heinrich,

On Tue, Aug 27, 2019 at 1:26 AM Heinrich Schuchardt <xypron.glpk@gmx.de> wrote:
>
> On 8/26/19 8:13 AM, Bin Meng wrote:
> > Hi Heinrich,
> >
> > On Mon, Aug 26, 2019 at 1:55 AM Heinrich Schuchardt <xypron.glpk@gmx.de> wrote:
> >>
> >> If a crash occurs, show the loaded UEFI images to facilitate analysis.
> >>
> >> This is an example output:
> >>
> >> => bootefi 0x1000000
> >> Found 0 disks
> >> Hello world of bugs!
> >> Invalid Opcode (Undefined Opcode)
> >> EIP: 0010:[<06ceb06e>] EFLAGS: 00010206
> >> Original EIP :[<fec9906e>]
> >> EAX: 00000000 EBX: 06cec000 ECX: 00000fd0 EDX: 00000001
> >> ESI: 06ced18a EDI: 07d0fe10 EBP: 07fe27a0 ESP: 07d0fde0
> >>   DS: 0018 ES: 0018 FS: 0020 GS: 0018 SS: 0018
> >> CR0: 00000033 CR2: 00000000 CR3: 00000000 CR4: 00000000
> >> DR0: 00000000 DR1: 00000000 DR2: 00000000 DR3: 00000000
> >> DR6: ffff0ff0 DR7: 00000400
> >> Stack:
> >>      0x07d0fde8 : 0x00000000
> >>      0x07d0fde4 : 0x06ced040
> >> --->0x07d0fde0 : 0x07fe27a0
> >>      0x07d0fddc : 0x00010206
> >>      0x07d0fdd8 : 0x00000010
> >>      0x07d0fdd4 : 0x06ceb06e
> >> UEFI image [0x06cea000:0x06cf0fff] pc=0x106e '/bug-i386.efi'
> >> ### ERROR ### Please RESET the board ###
> >>
> >> With the additional information provided by this patch we know that the
> >> problem occurred 0x106e after the load address of bug-i386.efi.
> >>
> >> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
> >> ---
> >>   arch/x86/cpu/i386/interrupt.c | 14 ++++++++++++++
> >>   1 file changed, 14 insertions(+)
> >>
> >> diff --git a/arch/x86/cpu/i386/interrupt.c b/arch/x86/cpu/i386/interrupt.c
> >> index 47df3172b7..1445204878 100644
> >> --- a/arch/x86/cpu/i386/interrupt.c
> >> +++ b/arch/x86/cpu/i386/interrupt.c
> >> @@ -12,6 +12,7 @@
> >>
> >>   #include <common.h>
> >>   #include <dm.h>
> >> +#include <efi_loader.h>
> >>   #include <asm/control_regs.h>
> >>   #include <asm/i8259.h>
> >>   #include <asm/interrupt.h>
> >> @@ -64,6 +65,18 @@ static char *exceptions[] = {
> >>          "Reserved"
> >>   };
> >>
> >> +/**
> >> + * show_efi_loaded_images() - show loaded UEFI images
> >> + *
> >> + * List all loaded UEFI images.
> >> + *
> >> + * @eip:       instruction pointer
> >> + */
> >> +static void show_efi_loaded_images(uintptr_t eip)
> >> +{
> >> +       efi_print_image_infos((void *)eip);
> >> +}
> >> +
> >>   static void dump_regs(struct irq_regs *regs)
> >>   {
> >>          unsigned long cs, eip, eflags;
> >> @@ -144,6 +157,7 @@ static void dump_regs(struct irq_regs *regs)
> >>                  printf("0x%8.8lx : 0x%8.8lx\n", sp, (ulong)readl(sp));
> >>                  sp -= 4;
> >>          }
> >> +       show_efi_loaded_images(eip);
> >
> > Should we wrap the call with #ifdef CONFIG_EFI_LOADER or something?
>
> In include/efi_loader.h we have
>
> static inline void efi_print_image_infos(void *pc) { }
>
> if EFI_LOADER is not defined.
>
> Best regards
>

I feel a little bit strange of show_efi_loaded_images() being called
in the dump_regs(). The dump_regs() is called in the exception
handler. It's a bit odd we show the EFI image info in the exception
handler. Shouldn't we print the EFI image info from the command line
interface?

Regards,
Bin
Heinrich Schuchardt Aug. 27, 2019, 2:43 a.m. UTC | #4
On 8/27/19 3:18 AM, Bin Meng wrote:
> Hi Heinrich,
>
> On Tue, Aug 27, 2019 at 1:26 AM Heinrich Schuchardt <xypron.glpk@gmx.de> wrote:
>>
>> On 8/26/19 8:13 AM, Bin Meng wrote:
>>> Hi Heinrich,
>>>
>>> On Mon, Aug 26, 2019 at 1:55 AM Heinrich Schuchardt <xypron.glpk@gmx.de> wrote:
>>>>
>>>> If a crash occurs, show the loaded UEFI images to facilitate analysis.
>>>>
>>>> This is an example output:
>>>>
>>>> => bootefi 0x1000000
>>>> Found 0 disks
>>>> Hello world of bugs!
>>>> Invalid Opcode (Undefined Opcode)
>>>> EIP: 0010:[<06ceb06e>] EFLAGS: 00010206
>>>> Original EIP :[<fec9906e>]
>>>> EAX: 00000000 EBX: 06cec000 ECX: 00000fd0 EDX: 00000001
>>>> ESI: 06ced18a EDI: 07d0fe10 EBP: 07fe27a0 ESP: 07d0fde0
>>>>    DS: 0018 ES: 0018 FS: 0020 GS: 0018 SS: 0018
>>>> CR0: 00000033 CR2: 00000000 CR3: 00000000 CR4: 00000000
>>>> DR0: 00000000 DR1: 00000000 DR2: 00000000 DR3: 00000000
>>>> DR6: ffff0ff0 DR7: 00000400
>>>> Stack:
>>>>       0x07d0fde8 : 0x00000000
>>>>       0x07d0fde4 : 0x06ced040
>>>> --->0x07d0fde0 : 0x07fe27a0
>>>>       0x07d0fddc : 0x00010206
>>>>       0x07d0fdd8 : 0x00000010
>>>>       0x07d0fdd4 : 0x06ceb06e
>>>> UEFI image [0x06cea000:0x06cf0fff] pc=0x106e '/bug-i386.efi'
>>>> ### ERROR ### Please RESET the board ###
>>>>
>>>> With the additional information provided by this patch we know that the
>>>> problem occurred 0x106e after the load address of bug-i386.efi.
>>>>
>>>> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
>>>> ---
>>>>    arch/x86/cpu/i386/interrupt.c | 14 ++++++++++++++
>>>>    1 file changed, 14 insertions(+)
>>>>
>>>> diff --git a/arch/x86/cpu/i386/interrupt.c b/arch/x86/cpu/i386/interrupt.c
>>>> index 47df3172b7..1445204878 100644
>>>> --- a/arch/x86/cpu/i386/interrupt.c
>>>> +++ b/arch/x86/cpu/i386/interrupt.c
>>>> @@ -12,6 +12,7 @@
>>>>
>>>>    #include <common.h>
>>>>    #include <dm.h>
>>>> +#include <efi_loader.h>
>>>>    #include <asm/control_regs.h>
>>>>    #include <asm/i8259.h>
>>>>    #include <asm/interrupt.h>
>>>> @@ -64,6 +65,18 @@ static char *exceptions[] = {
>>>>           "Reserved"
>>>>    };
>>>>
>>>> +/**
>>>> + * show_efi_loaded_images() - show loaded UEFI images
>>>> + *
>>>> + * List all loaded UEFI images.
>>>> + *
>>>> + * @eip:       instruction pointer
>>>> + */
>>>> +static void show_efi_loaded_images(uintptr_t eip)
>>>> +{
>>>> +       efi_print_image_infos((void *)eip);
>>>> +}
>>>> +
>>>>    static void dump_regs(struct irq_regs *regs)
>>>>    {
>>>>           unsigned long cs, eip, eflags;
>>>> @@ -144,6 +157,7 @@ static void dump_regs(struct irq_regs *regs)
>>>>                   printf("0x%8.8lx : 0x%8.8lx\n", sp, (ulong)readl(sp));
>>>>                   sp -= 4;
>>>>           }
>>>> +       show_efi_loaded_images(eip);
>>>
>>> Should we wrap the call with #ifdef CONFIG_EFI_LOADER or something?
>>
>> In include/efi_loader.h we have
>>
>> static inline void efi_print_image_infos(void *pc) { }
>>
>> if EFI_LOADER is not defined.
>>
>> Best regards
>>
>
> I feel a little bit strange of show_efi_loaded_images() being called
> in the dump_regs(). The dump_regs() is called in the exception
> handler. It's a bit odd we show the EFI image info in the exception
> handler. Shouldn't we print the EFI image info from the command line
> interface?

We have a command to  display loaded images from the command line
(efidebug images). But when a crash occurs in an UEFI application, I
cannot reach the command line anymore.

When running complex UEFI applications like the SCT multiple UEFI images
are involved with loading addresses which I cannot control from the
command line. So it is hard to find out where a crash occurred.

For ARM we already have the same information in crash dumps.

If not UEFI image is loaded, no line is added to the crash dump.

Best regards

Heinrich
Bin Meng Aug. 27, 2019, 2:48 a.m. UTC | #5
Hi Heinrich,

On Tue, Aug 27, 2019 at 10:43 AM Heinrich Schuchardt <xypron.glpk@gmx.de> wrote:
>
> On 8/27/19 3:18 AM, Bin Meng wrote:
> > Hi Heinrich,
> >
> > On Tue, Aug 27, 2019 at 1:26 AM Heinrich Schuchardt <xypron.glpk@gmx.de> wrote:
> >>
> >> On 8/26/19 8:13 AM, Bin Meng wrote:
> >>> Hi Heinrich,
> >>>
> >>> On Mon, Aug 26, 2019 at 1:55 AM Heinrich Schuchardt <xypron.glpk@gmx.de> wrote:
> >>>>
> >>>> If a crash occurs, show the loaded UEFI images to facilitate analysis.
> >>>>
> >>>> This is an example output:
> >>>>
> >>>> => bootefi 0x1000000
> >>>> Found 0 disks
> >>>> Hello world of bugs!
> >>>> Invalid Opcode (Undefined Opcode)
> >>>> EIP: 0010:[<06ceb06e>] EFLAGS: 00010206
> >>>> Original EIP :[<fec9906e>]
> >>>> EAX: 00000000 EBX: 06cec000 ECX: 00000fd0 EDX: 00000001
> >>>> ESI: 06ced18a EDI: 07d0fe10 EBP: 07fe27a0 ESP: 07d0fde0
> >>>>    DS: 0018 ES: 0018 FS: 0020 GS: 0018 SS: 0018
> >>>> CR0: 00000033 CR2: 00000000 CR3: 00000000 CR4: 00000000
> >>>> DR0: 00000000 DR1: 00000000 DR2: 00000000 DR3: 00000000
> >>>> DR6: ffff0ff0 DR7: 00000400
> >>>> Stack:
> >>>>       0x07d0fde8 : 0x00000000
> >>>>       0x07d0fde4 : 0x06ced040
> >>>> --->0x07d0fde0 : 0x07fe27a0
> >>>>       0x07d0fddc : 0x00010206
> >>>>       0x07d0fdd8 : 0x00000010
> >>>>       0x07d0fdd4 : 0x06ceb06e
> >>>> UEFI image [0x06cea000:0x06cf0fff] pc=0x106e '/bug-i386.efi'
> >>>> ### ERROR ### Please RESET the board ###
> >>>>
> >>>> With the additional information provided by this patch we know that the
> >>>> problem occurred 0x106e after the load address of bug-i386.efi.
> >>>>
> >>>> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
> >>>> ---
> >>>>    arch/x86/cpu/i386/interrupt.c | 14 ++++++++++++++
> >>>>    1 file changed, 14 insertions(+)
> >>>>
> >>>> diff --git a/arch/x86/cpu/i386/interrupt.c b/arch/x86/cpu/i386/interrupt.c
> >>>> index 47df3172b7..1445204878 100644
> >>>> --- a/arch/x86/cpu/i386/interrupt.c
> >>>> +++ b/arch/x86/cpu/i386/interrupt.c
> >>>> @@ -12,6 +12,7 @@
> >>>>
> >>>>    #include <common.h>
> >>>>    #include <dm.h>
> >>>> +#include <efi_loader.h>
> >>>>    #include <asm/control_regs.h>
> >>>>    #include <asm/i8259.h>
> >>>>    #include <asm/interrupt.h>
> >>>> @@ -64,6 +65,18 @@ static char *exceptions[] = {
> >>>>           "Reserved"
> >>>>    };
> >>>>
> >>>> +/**
> >>>> + * show_efi_loaded_images() - show loaded UEFI images
> >>>> + *
> >>>> + * List all loaded UEFI images.
> >>>> + *
> >>>> + * @eip:       instruction pointer
> >>>> + */
> >>>> +static void show_efi_loaded_images(uintptr_t eip)
> >>>> +{
> >>>> +       efi_print_image_infos((void *)eip);
> >>>> +}
> >>>> +
> >>>>    static void dump_regs(struct irq_regs *regs)
> >>>>    {
> >>>>           unsigned long cs, eip, eflags;
> >>>> @@ -144,6 +157,7 @@ static void dump_regs(struct irq_regs *regs)
> >>>>                   printf("0x%8.8lx : 0x%8.8lx\n", sp, (ulong)readl(sp));
> >>>>                   sp -= 4;
> >>>>           }
> >>>> +       show_efi_loaded_images(eip);
> >>>
> >>> Should we wrap the call with #ifdef CONFIG_EFI_LOADER or something?
> >>
> >> In include/efi_loader.h we have
> >>
> >> static inline void efi_print_image_infos(void *pc) { }
> >>
> >> if EFI_LOADER is not defined.
> >>
> >> Best regards
> >>
> >
> > I feel a little bit strange of show_efi_loaded_images() being called
> > in the dump_regs(). The dump_regs() is called in the exception
> > handler. It's a bit odd we show the EFI image info in the exception
> > handler. Shouldn't we print the EFI image info from the command line
> > interface?
>
> We have a command to  display loaded images from the command line
> (efidebug images). But when a crash occurs in an UEFI application, I
> cannot reach the command line anymore.
>
> When running complex UEFI applications like the SCT multiple UEFI images
> are involved with loading addresses which I cannot control from the
> command line. So it is hard to find out where a crash occurred.
>
> For ARM we already have the same information in crash dumps.
>
> If not UEFI image is loaded, no line is added to the crash dump.

OK, could you please provide a sample EFI image of such to trigger the
issue? I would like to have a test.

Regards,
Bin
Heinrich Schuchardt Aug. 27, 2019, 6:14 a.m. UTC | #6
On 8/27/19 4:48 AM, Bin Meng wrote:
> Hi Heinrich,
>
> On Tue, Aug 27, 2019 at 10:43 AM Heinrich Schuchardt <xypron.glpk@gmx.de> wrote:
>>
>> On 8/27/19 3:18 AM, Bin Meng wrote:
>>> Hi Heinrich,
>>>
>>> On Tue, Aug 27, 2019 at 1:26 AM Heinrich Schuchardt <xypron.glpk@gmx.de> wrote:
>>>>
>>>> On 8/26/19 8:13 AM, Bin Meng wrote:
>>>>> Hi Heinrich,
>>>>>
>>>>> On Mon, Aug 26, 2019 at 1:55 AM Heinrich Schuchardt <xypron.glpk@gmx.de> wrote:
>>>>>>
>>>>>> If a crash occurs, show the loaded UEFI images to facilitate analysis.
>>>>>>
>>>>>> This is an example output:
>>>>>>
>>>>>> => bootefi 0x1000000
>>>>>> Found 0 disks
>>>>>> Hello world of bugs!
>>>>>> Invalid Opcode (Undefined Opcode)
>>>>>> EIP: 0010:[<06ceb06e>] EFLAGS: 00010206
>>>>>> Original EIP :[<fec9906e>]
>>>>>> EAX: 00000000 EBX: 06cec000 ECX: 00000fd0 EDX: 00000001
>>>>>> ESI: 06ced18a EDI: 07d0fe10 EBP: 07fe27a0 ESP: 07d0fde0
>>>>>>     DS: 0018 ES: 0018 FS: 0020 GS: 0018 SS: 0018
>>>>>> CR0: 00000033 CR2: 00000000 CR3: 00000000 CR4: 00000000
>>>>>> DR0: 00000000 DR1: 00000000 DR2: 00000000 DR3: 00000000
>>>>>> DR6: ffff0ff0 DR7: 00000400
>>>>>> Stack:
>>>>>>        0x07d0fde8 : 0x00000000
>>>>>>        0x07d0fde4 : 0x06ced040
>>>>>> --->0x07d0fde0 : 0x07fe27a0
>>>>>>        0x07d0fddc : 0x00010206
>>>>>>        0x07d0fdd8 : 0x00000010
>>>>>>        0x07d0fdd4 : 0x06ceb06e
>>>>>> UEFI image [0x06cea000:0x06cf0fff] pc=0x106e '/bug-i386.efi'
>>>>>> ### ERROR ### Please RESET the board ###
>>>>>>
>>>>>> With the additional information provided by this patch we know that the
>>>>>> problem occurred 0x106e after the load address of bug-i386.efi.
>>>>>>
>>>>>> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
>>>>>> ---
>>>>>>     arch/x86/cpu/i386/interrupt.c | 14 ++++++++++++++
>>>>>>     1 file changed, 14 insertions(+)
>>>>>>
>>>>>> diff --git a/arch/x86/cpu/i386/interrupt.c b/arch/x86/cpu/i386/interrupt.c
>>>>>> index 47df3172b7..1445204878 100644
>>>>>> --- a/arch/x86/cpu/i386/interrupt.c
>>>>>> +++ b/arch/x86/cpu/i386/interrupt.c
>>>>>> @@ -12,6 +12,7 @@
>>>>>>
>>>>>>     #include <common.h>
>>>>>>     #include <dm.h>
>>>>>> +#include <efi_loader.h>
>>>>>>     #include <asm/control_regs.h>
>>>>>>     #include <asm/i8259.h>
>>>>>>     #include <asm/interrupt.h>
>>>>>> @@ -64,6 +65,18 @@ static char *exceptions[] = {
>>>>>>            "Reserved"
>>>>>>     };
>>>>>>
>>>>>> +/**
>>>>>> + * show_efi_loaded_images() - show loaded UEFI images
>>>>>> + *
>>>>>> + * List all loaded UEFI images.
>>>>>> + *
>>>>>> + * @eip:       instruction pointer
>>>>>> + */
>>>>>> +static void show_efi_loaded_images(uintptr_t eip)
>>>>>> +{
>>>>>> +       efi_print_image_infos((void *)eip);
>>>>>> +}
>>>>>> +
>>>>>>     static void dump_regs(struct irq_regs *regs)
>>>>>>     {
>>>>>>            unsigned long cs, eip, eflags;
>>>>>> @@ -144,6 +157,7 @@ static void dump_regs(struct irq_regs *regs)
>>>>>>                    printf("0x%8.8lx : 0x%8.8lx\n", sp, (ulong)readl(sp));
>>>>>>                    sp -= 4;
>>>>>>            }
>>>>>> +       show_efi_loaded_images(eip);
>>>>>
>>>>> Should we wrap the call with #ifdef CONFIG_EFI_LOADER or something?
>>>>
>>>> In include/efi_loader.h we have
>>>>
>>>> static inline void efi_print_image_infos(void *pc) { }
>>>>
>>>> if EFI_LOADER is not defined.
>>>>
>>>> Best regards
>>>>
>>>
>>> I feel a little bit strange of show_efi_loaded_images() being called
>>> in the dump_regs(). The dump_regs() is called in the exception
>>> handler. It's a bit odd we show the EFI image info in the exception
>>> handler. Shouldn't we print the EFI image info from the command line
>>> interface?
>>
>> We have a command to  display loaded images from the command line
>> (efidebug images). But when a crash occurs in an UEFI application, I
>> cannot reach the command line anymore.
>>
>> When running complex UEFI applications like the SCT multiple UEFI images
>> are involved with loading addresses which I cannot control from the
>> command line. So it is hard to find out where a crash occurred.
>>
>> For ARM we already have the same information in crash dumps.
>>
>> If not UEFI image is loaded, no line is added to the crash dump.
>
> OK, could you please provide a sample EFI image of such to trigger the
> issue? I would like to have a test.

You can elicit the output with

=> setenv efi_selftest exception
=> bootefi selftest

Best regards

Heinrich
Bin Meng Aug. 29, 2019, 4:46 a.m. UTC | #7
On Mon, Aug 26, 2019 at 1:55 AM Heinrich Schuchardt <xypron.glpk@gmx.de> wrote:
>
> If a crash occurs, show the loaded UEFI images to facilitate analysis.
>
> This is an example output:
>
> => bootefi 0x1000000
> Found 0 disks
> Hello world of bugs!
> Invalid Opcode (Undefined Opcode)
> EIP: 0010:[<06ceb06e>] EFLAGS: 00010206
> Original EIP :[<fec9906e>]
> EAX: 00000000 EBX: 06cec000 ECX: 00000fd0 EDX: 00000001
> ESI: 06ced18a EDI: 07d0fe10 EBP: 07fe27a0 ESP: 07d0fde0
>  DS: 0018 ES: 0018 FS: 0020 GS: 0018 SS: 0018
> CR0: 00000033 CR2: 00000000 CR3: 00000000 CR4: 00000000
> DR0: 00000000 DR1: 00000000 DR2: 00000000 DR3: 00000000
> DR6: ffff0ff0 DR7: 00000400
> Stack:
>     0x07d0fde8 : 0x00000000
>     0x07d0fde4 : 0x06ced040
> --->0x07d0fde0 : 0x07fe27a0
>     0x07d0fddc : 0x00010206
>     0x07d0fdd8 : 0x00000010
>     0x07d0fdd4 : 0x06ceb06e
> UEFI image [0x06cea000:0x06cf0fff] pc=0x106e '/bug-i386.efi'
> ### ERROR ### Please RESET the board ###
>
> With the additional information provided by this patch we know that the
> problem occurred 0x106e after the load address of bug-i386.efi.
>
> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
> ---
>  arch/x86/cpu/i386/interrupt.c | 14 ++++++++++++++
>  1 file changed, 14 insertions(+)
>

Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Tested-by: Bin Meng <bmeng.cn@gmail.com>
Bin Meng Sept. 10, 2019, 6:27 a.m. UTC | #8
On Thu, Aug 29, 2019 at 12:46 PM Bin Meng <bmeng.cn@gmail.com> wrote:
>
> On Mon, Aug 26, 2019 at 1:55 AM Heinrich Schuchardt <xypron.glpk@gmx.de> wrote:
> >
> > If a crash occurs, show the loaded UEFI images to facilitate analysis.
> >
> > This is an example output:
> >
> > => bootefi 0x1000000
> > Found 0 disks
> > Hello world of bugs!
> > Invalid Opcode (Undefined Opcode)
> > EIP: 0010:[<06ceb06e>] EFLAGS: 00010206
> > Original EIP :[<fec9906e>]
> > EAX: 00000000 EBX: 06cec000 ECX: 00000fd0 EDX: 00000001
> > ESI: 06ced18a EDI: 07d0fe10 EBP: 07fe27a0 ESP: 07d0fde0
> >  DS: 0018 ES: 0018 FS: 0020 GS: 0018 SS: 0018
> > CR0: 00000033 CR2: 00000000 CR3: 00000000 CR4: 00000000
> > DR0: 00000000 DR1: 00000000 DR2: 00000000 DR3: 00000000
> > DR6: ffff0ff0 DR7: 00000400
> > Stack:
> >     0x07d0fde8 : 0x00000000
> >     0x07d0fde4 : 0x06ced040
> > --->0x07d0fde0 : 0x07fe27a0
> >     0x07d0fddc : 0x00010206
> >     0x07d0fdd8 : 0x00000010
> >     0x07d0fdd4 : 0x06ceb06e
> > UEFI image [0x06cea000:0x06cf0fff] pc=0x106e '/bug-i386.efi'
> > ### ERROR ### Please RESET the board ###
> >
> > With the additional information provided by this patch we know that the
> > problem occurred 0x106e after the load address of bug-i386.efi.
> >
> > Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
> > ---
> >  arch/x86/cpu/i386/interrupt.c | 14 ++++++++++++++
> >  1 file changed, 14 insertions(+)
> >
>
> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
> Tested-by: Bin Meng <bmeng.cn@gmail.com>

applied to u-boot-x86, thanks!

Patch
diff mbox series

diff --git a/arch/x86/cpu/i386/interrupt.c b/arch/x86/cpu/i386/interrupt.c
index 47df3172b7..1445204878 100644
--- a/arch/x86/cpu/i386/interrupt.c
+++ b/arch/x86/cpu/i386/interrupt.c
@@ -12,6 +12,7 @@ 

 #include <common.h>
 #include <dm.h>
+#include <efi_loader.h>
 #include <asm/control_regs.h>
 #include <asm/i8259.h>
 #include <asm/interrupt.h>
@@ -64,6 +65,18 @@  static char *exceptions[] = {
 	"Reserved"
 };

+/**
+ * show_efi_loaded_images() - show loaded UEFI images
+ *
+ * List all loaded UEFI images.
+ *
+ * @eip:	instruction pointer
+ */
+static void show_efi_loaded_images(uintptr_t eip)
+{
+	efi_print_image_infos((void *)eip);
+}
+
 static void dump_regs(struct irq_regs *regs)
 {
 	unsigned long cs, eip, eflags;
@@ -144,6 +157,7 @@  static void dump_regs(struct irq_regs *regs)
 		printf("0x%8.8lx : 0x%8.8lx\n", sp, (ulong)readl(sp));
 		sp -= 4;
 	}
+	show_efi_loaded_images(eip);
 }

 static void do_exception(struct irq_regs *regs)