Re: [Issue] EFI runtime-wrapper is broken

Re: [Issue] EFI runtime-wrapper is broken

[Ard Biesheuvel]

On Fri, 28 Oct 2022 at 11:10, Gavin Shan <gshan@redhat.com> wrote:
>
> Hi Ard,
>
> I ran into the following crash with v6.1.rc2. I'm not sure if it's known
> issue. Last good version is v6.0.rc6/rc7. The kernel configuration is attached.
>

Hello Gavin,

This is probably related to the patch below. It means the firmware is
buggy, and does not work as it should if the firmware never calls
SetVirtualAddressMap() [and doing so is explicitly described as
OPTIONAL by the EFI specification].

The problem here is that other EFI implementations (primarily the
Qualcomm ones used on Windows-on-ARM laptops) are buggy too, and don't
tolerate SetVirtualAddressMap().

Can you try whether reverting the patch below helps?




commit d3549a938b73f203ef522562ae9f2d38aa43d234
Author: Ard Biesheuvel <ardb@kernel.org>
Date:   Fri Sep 16 11:48:30 2022 +0200

    efi/arm64: libstub: avoid SetVirtualAddressMap() when possible

    EFI's SetVirtualAddressMap() runtime service is a horrid hack that we'd
    like to avoid using, if possible. For 64-bit architectures such as
    arm64, the user and kernel mappings are entirely disjoint, and given
    that we use the user region for mapping the UEFI runtime regions when
    running under the OS, we don't rely on SetVirtualAddressMap() in the
    conventional way, i.e., to permit kernel mappings of the OS to coexist
    with kernel region mappings of the firmware regions. This means that, in
    principle, we should be able to avoid SetVirtualAddressMap() altogether,
    and simply use the 1:1 mapping that UEFI uses at boot time. (Note that
    omitting SetVirtualAddressMap() is explicitly permitted by the UEFI
    spec).

    However, there is a corner case on arm64, which, if configured for
    3-level paging (or 2-level paging when using 64k pages), may not be able
    to cover the entire range of firmware mappings (which might contain both
    memory and MMIO peripheral mappings).

    So let's avoid SetVirtualAddressMap() on arm64, but only if the VA space
    is guaranteed to be of sufficient size.

    Signed-off-by: Ard Biesheuvel <ardb@kernel.org>



> [   71.281677] Unable to handle kernel paging request at virtual address 00000000a934da68
> [   71.289593] Mem abort info:
> [   71.292375]   ESR = 0x0000000096000006
> [   71.296111]   EC = 0x25: DABT (current EL), IL = 32 bits
> [   71.301411]   SET = 0, FnV = 0
> [   71.304453]   EA = 0, S1PTW = 0
> [   71.307581]   FSC = 0x06: level 2 translation fault
> [   71.312446] Data abort info:
> [   71.315315]   ISV = 0, ISS = 0x00000006
> [   71.319138]   CM = 0, WnR = 0
> [   71.322094] user pgtable: 4k pages, 48-bit VAs, pgdp=0000080046ad6000
> [   71.328522] [00000000a934da68] pgd=0000000000000000, p4d=0000000000000000
> [   71.335299] Internal error: Oops: 0000000096000006 [#1] SMP
> [   71.340860] Modules linked in: bridge stp llc qrtr rfkill sunrpc vfat fat mlx5_ib ib_uverbs cdc_ether usbnet mii ib_core acpi_ipmi ipmi_ssif arm_spe_pmu ipmi_devintf ipmi_msghandler arm_cmn arm_dmc620_pmu arm_dsu_pmu cppc_cpufreq xfs libcrc32c ast drm_vram_helper drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops drm_ttm_helper ttm mlx5_core crct10dif_ce ghash_ce sha2_ce sha256_arm64 sha1_ce drm sbsa_gwdt mlxfw tls nvme igb nvme_core psample nvme_common i2c_algo_bit pci_hyperv_intf i2c_designware_platform i2c_designware_core xgene_hwmon dm_mirror dm_region_hash dm_log dm_mod fuse
> [   71.393089] CPU: 94 PID: 1563 Comm: kworker/u320:3 Not tainted 6.1.0-rc2-gavin+ #6
> [   71.400646] Hardware name: FOXCONN Mt. Collins/Mt. Collins, BIOS 0ACOC017 (SCP: 1.08.20210825) 10/22/2021
> [   71.410200] Workqueue: efi_rts_wq efi_call_rts
> [   71.414636] pstate: 204000c9 (nzCv daIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
> [   71.421585] pc : 0xb7ec7ae4
> [   71.424367] lr : 0xb7ec8668
> [   71.427149] sp : ffff80002f0e37e0
> [   71.430452] x29: ffff80002f0e37e0 x28: ffffa4efa13bb0d0 x27: ffffa4efa0e32a18
> [   71.437575] x26: ffff3fff93ce2d74 x25: ffff3fff90793805 x24: 0000000000000000
> [   71.444698] x23: 0000000000000000 x22: 0000000000000000 x21: ffffa4efa06f0750
> [   71.451821] x20: ffff8000279fbcc8 x19: ffffa4efa1df2a80 x18: 0000000000000000
> [   71.458944] x17: 0000000000000000 x16: 0000000000000000 x15: 0000aaab19a5fb90
> [   71.466067] x14: 0000000000000000 x13: 0000000000000010 x12: 0101010101010101
> [   71.473190] x11: 7f7f7f7f7f7f7f7f x10: fefefefefeff7076 x9 : ffffa4ef9f5f7570
> [   71.480313] x8 : 00000000b7cc05b8 x7 : ffff80002f0e3b60 x6 : ffff80002f0e3c00
> [   71.487436] x5 : ffff80002f0e3b58 x4 : 00000000b7e81358 x3 : 00000000b7ec8600
> [   71.494559] x2 : 0000000001000000 x1 : 0000000001000000 x0 : 00000000a934da60
> [   71.501682] Call trace:
> [   71.504116]  0xb7ec7ae4
> [   71.506551]  0xb7ec8668
> [   71.508985]  0xb7ec6e08
> [   71.511419]  0xb7ec68ec
> [   71.513853]  0xb7ec3824
> [   71.516287]  0xb7ec05a8
> [   71.518721]  0xb7ec12a0
> [   71.521155]  0xb7e53524
> [   71.523590]  0xb7e53670
> [   71.526024]  0xb7e582f0
> [   71.528458]  0xb7e5909c
> [   71.530892]  0xb7e5a014
> [   71.533326]  0xb7e508a8
> [   71.535760]  0xb7cc3328
> [   71.538195]  0xb7cc0674
> [   71.540629]  __efi_rt_asm_wrapper+0x2c/0x48
> [   71.544802]  efi_call_rts+0x2a8/0x440
> [   71.548454]  process_one_work+0x1e4/0x460
> [   71.552452]  worker_thread+0x74/0x414
> [   71.556103]  kthread+0xf0/0xf4
> [   71.559147]  ret_from_fork+0x10/0x20
> [   71.562712] Code: 90000000 912c2000 f9400000 f9400000 (f9400401)
> [   71.568794] ---[ end trace 0000000000000000 ]---
> [   71.573401] Kernel panic - not syncing: Oops: Fatal exception in interrupt
> [   71.580263] SMP: stopping secondary CPUs
> [   71.584932] Kernel Offset: 0x24ef975e0000 from 0xffff800008000000
> [   71.591012] PHYS_OFFSET: 0x80000000
> [   71.594488] CPU features: 0x00000,001700a4,6601720b
> [   71.599353] Memory Limit: none
> [   71.602395] ---[ end Kernel panic - not syncing: Oops: Fatal exception in interrupt ]---
>
> Thanks,
> Gavin
>

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [Issue] EFI runtime-wrapper is broken

[Gavin Shan]

Hi Ard,

On 10/28/22 5:21 PM, Ard Biesheuvel wrote:
> On Fri, 28 Oct 2022 at 11:10, Gavin Shan <gshan@redhat.com> wrote:
>> I ran into the following crash with v6.1.rc2. I'm not sure if it's known
>> issue. Last good version is v6.0.rc6/rc7. The kernel configuration is attached.
> 
> This is probably related to the patch below. It means the firmware is
> buggy, and does not work as it should if the firmware never calls
> SetVirtualAddressMap() [and doing so is explicitly described as
> OPTIONAL by the EFI specification].
> 
> The problem here is that other EFI implementations (primarily the
> Qualcomm ones used on Windows-on-ARM laptops) are buggy too, and don't
> tolerate SetVirtualAddressMap().
> 
> Can you try whether reverting the patch below helps?
> 

I ran into the issue on server, equipped with Ampere CPUs. With d3549a938b73
reverted, the crash disappeared.

Thanks,
Gavin
  
> 
> commit d3549a938b73f203ef522562ae9f2d38aa43d234
> Author: Ard Biesheuvel <ardb@kernel.org>
> Date:   Fri Sep 16 11:48:30 2022 +0200
> 
>      efi/arm64: libstub: avoid SetVirtualAddressMap() when possible
> 
>      EFI's SetVirtualAddressMap() runtime service is a horrid hack that we'd
>      like to avoid using, if possible. For 64-bit architectures such as
>      arm64, the user and kernel mappings are entirely disjoint, and given
>      that we use the user region for mapping the UEFI runtime regions when
>      running under the OS, we don't rely on SetVirtualAddressMap() in the
>      conventional way, i.e., to permit kernel mappings of the OS to coexist
>      with kernel region mappings of the firmware regions. This means that, in
>      principle, we should be able to avoid SetVirtualAddressMap() altogether,
>      and simply use the 1:1 mapping that UEFI uses at boot time. (Note that
>      omitting SetVirtualAddressMap() is explicitly permitted by the UEFI
>      spec).
> 
>      However, there is a corner case on arm64, which, if configured for
>      3-level paging (or 2-level paging when using 64k pages), may not be able
>      to cover the entire range of firmware mappings (which might contain both
>      memory and MMIO peripheral mappings).
> 
>      So let's avoid SetVirtualAddressMap() on arm64, but only if the VA space
>      is guaranteed to be of sufficient size.
> 
>      Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
> 
> 
> 
>> [   71.281677] Unable to handle kernel paging request at virtual address 00000000a934da68
>> [   71.289593] Mem abort info:
>> [   71.292375]   ESR = 0x0000000096000006
>> [   71.296111]   EC = 0x25: DABT (current EL), IL = 32 bits
>> [   71.301411]   SET = 0, FnV = 0
>> [   71.304453]   EA = 0, S1PTW = 0
>> [   71.307581]   FSC = 0x06: level 2 translation fault
>> [   71.312446] Data abort info:
>> [   71.315315]   ISV = 0, ISS = 0x00000006
>> [   71.319138]   CM = 0, WnR = 0
>> [   71.322094] user pgtable: 4k pages, 48-bit VAs, pgdp=0000080046ad6000
>> [   71.328522] [00000000a934da68] pgd=0000000000000000, p4d=0000000000000000
>> [   71.335299] Internal error: Oops: 0000000096000006 [#1] SMP
>> [   71.340860] Modules linked in: bridge stp llc qrtr rfkill sunrpc vfat fat mlx5_ib ib_uverbs cdc_ether usbnet mii ib_core acpi_ipmi ipmi_ssif arm_spe_pmu ipmi_devintf ipmi_msghandler arm_cmn arm_dmc620_pmu arm_dsu_pmu cppc_cpufreq xfs libcrc32c ast drm_vram_helper drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops drm_ttm_helper ttm mlx5_core crct10dif_ce ghash_ce sha2_ce sha256_arm64 sha1_ce drm sbsa_gwdt mlxfw tls nvme igb nvme_core psample nvme_common i2c_algo_bit pci_hyperv_intf i2c_designware_platform i2c_designware_core xgene_hwmon dm_mirror dm_region_hash dm_log dm_mod fuse
>> [   71.393089] CPU: 94 PID: 1563 Comm: kworker/u320:3 Not tainted 6.1.0-rc2-gavin+ #6
>> [   71.400646] Hardware name: FOXCONN Mt. Collins/Mt. Collins, BIOS 0ACOC017 (SCP: 1.08.20210825) 10/22/2021
>> [   71.410200] Workqueue: efi_rts_wq efi_call_rts
>> [   71.414636] pstate: 204000c9 (nzCv daIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
>> [   71.421585] pc : 0xb7ec7ae4
>> [   71.424367] lr : 0xb7ec8668
>> [   71.427149] sp : ffff80002f0e37e0
>> [   71.430452] x29: ffff80002f0e37e0 x28: ffffa4efa13bb0d0 x27: ffffa4efa0e32a18
>> [   71.437575] x26: ffff3fff93ce2d74 x25: ffff3fff90793805 x24: 0000000000000000
>> [   71.444698] x23: 0000000000000000 x22: 0000000000000000 x21: ffffa4efa06f0750
>> [   71.451821] x20: ffff8000279fbcc8 x19: ffffa4efa1df2a80 x18: 0000000000000000
>> [   71.458944] x17: 0000000000000000 x16: 0000000000000000 x15: 0000aaab19a5fb90
>> [   71.466067] x14: 0000000000000000 x13: 0000000000000010 x12: 0101010101010101
>> [   71.473190] x11: 7f7f7f7f7f7f7f7f x10: fefefefefeff7076 x9 : ffffa4ef9f5f7570
>> [   71.480313] x8 : 00000000b7cc05b8 x7 : ffff80002f0e3b60 x6 : ffff80002f0e3c00
>> [   71.487436] x5 : ffff80002f0e3b58 x4 : 00000000b7e81358 x3 : 00000000b7ec8600
>> [   71.494559] x2 : 0000000001000000 x1 : 0000000001000000 x0 : 00000000a934da60
>> [   71.501682] Call trace:
>> [   71.504116]  0xb7ec7ae4
>> [   71.506551]  0xb7ec8668
>> [   71.508985]  0xb7ec6e08
>> [   71.511419]  0xb7ec68ec
>> [   71.513853]  0xb7ec3824
>> [   71.516287]  0xb7ec05a8
>> [   71.518721]  0xb7ec12a0
>> [   71.521155]  0xb7e53524
>> [   71.523590]  0xb7e53670
>> [   71.526024]  0xb7e582f0
>> [   71.528458]  0xb7e5909c
>> [   71.530892]  0xb7e5a014
>> [   71.533326]  0xb7e508a8
>> [   71.535760]  0xb7cc3328
>> [   71.538195]  0xb7cc0674
>> [   71.540629]  __efi_rt_asm_wrapper+0x2c/0x48
>> [   71.544802]  efi_call_rts+0x2a8/0x440
>> [   71.548454]  process_one_work+0x1e4/0x460
>> [   71.552452]  worker_thread+0x74/0x414
>> [   71.556103]  kthread+0xf0/0xf4
>> [   71.559147]  ret_from_fork+0x10/0x20
>> [   71.562712] Code: 90000000 912c2000 f9400000 f9400000 (f9400401)
>> [   71.568794] ---[ end trace 0000000000000000 ]---
>> [   71.573401] Kernel panic - not syncing: Oops: Fatal exception in interrupt
>> [   71.580263] SMP: stopping secondary CPUs
>> [   71.584932] Kernel Offset: 0x24ef975e0000 from 0xffff800008000000
>> [   71.591012] PHYS_OFFSET: 0x80000000
>> [   71.594488] CPU features: 0x00000,001700a4,6601720b
>> [   71.599353] Memory Limit: none
>> [   71.602395] ---[ end Kernel panic - not syncing: Oops: Fatal exception in interrupt ]---
>>
>> Thanks,
>> Gavin
>>
> 


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [Issue] EFI runtime-wrapper is broken

[Ard Biesheuvel]

On Fri, 28 Oct 2022 at 11:38, Gavin Shan <gshan@redhat.com> wrote:
>
> Hi Ard,
>
> On 10/28/22 5:21 PM, Ard Biesheuvel wrote:
> > On Fri, 28 Oct 2022 at 11:10, Gavin Shan <gshan@redhat.com> wrote:
> >> I ran into the following crash with v6.1.rc2. I'm not sure if it's known
> >> issue. Last good version is v6.0.rc6/rc7. The kernel configuration is attached.
> >
> > This is probably related to the patch below. It means the firmware is
> > buggy, and does not work as it should if the firmware never calls
> > SetVirtualAddressMap() [and doing so is explicitly described as
> > OPTIONAL by the EFI specification].
> >
> > The problem here is that other EFI implementations (primarily the
> > Qualcomm ones used on Windows-on-ARM laptops) are buggy too, and don't
> > tolerate SetVirtualAddressMap().
> >
> > Can you try whether reverting the patch below helps?
> >
>
> I ran into the issue on server, equipped with Ampere CPUs. With d3549a938b73
> reverted, the crash disappeared.
>

Thanks for confirming

Can you please share the complete boot log and the DMI/SMBIOS data? Thanks.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [Issue] EFI runtime-wrapper is broken

[Ard Biesheuvel]

(cc Nhi Pham and Quan Nguyen)

On Fri, 28 Oct 2022 at 11:21, Ard Biesheuvel <ardb@kernel.org> wrote:
>
> On Fri, 28 Oct 2022 at 11:10, Gavin Shan <gshan@redhat.com> wrote:
> >
> > Hi Ard,
> >
> > I ran into the following crash with v6.1.rc2. I'm not sure if it's known
> > issue. Last good version is v6.0.rc6/rc7. The kernel configuration is attached.
> >
>
> Hello Gavin,
>
> This is probably related to the patch below. It means the firmware is
> buggy, and does not work as it should if the firmware never calls
> SetVirtualAddressMap() [and doing so is explicitly described as
> OPTIONAL by the EFI specification].
>
> The problem here is that other EFI implementations (primarily the
> Qualcomm ones used on Windows-on-ARM laptops) are buggy too, and don't
> tolerate SetVirtualAddressMap().
>
> Can you try whether reverting the patch below helps?
>
>
>
>
> commit d3549a938b73f203ef522562ae9f2d38aa43d234
> Author: Ard Biesheuvel <ardb@kernel.org>
> Date:   Fri Sep 16 11:48:30 2022 +0200
>
>     efi/arm64: libstub: avoid SetVirtualAddressMap() when possible
>
>     EFI's SetVirtualAddressMap() runtime service is a horrid hack that we'd
>     like to avoid using, if possible. For 64-bit architectures such as
>     arm64, the user and kernel mappings are entirely disjoint, and given
>     that we use the user region for mapping the UEFI runtime regions when
>     running under the OS, we don't rely on SetVirtualAddressMap() in the
>     conventional way, i.e., to permit kernel mappings of the OS to coexist
>     with kernel region mappings of the firmware regions. This means that, in
>     principle, we should be able to avoid SetVirtualAddressMap() altogether,
>     and simply use the 1:1 mapping that UEFI uses at boot time. (Note that
>     omitting SetVirtualAddressMap() is explicitly permitted by the UEFI
>     spec).
>
>     However, there is a corner case on arm64, which, if configured for
>     3-level paging (or 2-level paging when using 64k pages), may not be able
>     to cover the entire range of firmware mappings (which might contain both
>     memory and MMIO peripheral mappings).
>
>     So let's avoid SetVirtualAddressMap() on arm64, but only if the VA space
>     is guaranteed to be of sufficient size.
>
>     Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
>
>
>
> > [   71.281677] Unable to handle kernel paging request at virtual address 00000000a934da68
> > [   71.289593] Mem abort info:
> > [   71.292375]   ESR = 0x0000000096000006
> > [   71.296111]   EC = 0x25: DABT (current EL), IL = 32 bits
> > [   71.301411]   SET = 0, FnV = 0
> > [   71.304453]   EA = 0, S1PTW = 0
> > [   71.307581]   FSC = 0x06: level 2 translation fault
> > [   71.312446] Data abort info:
> > [   71.315315]   ISV = 0, ISS = 0x00000006
> > [   71.319138]   CM = 0, WnR = 0
> > [   71.322094] user pgtable: 4k pages, 48-bit VAs, pgdp=0000080046ad6000
> > [   71.328522] [00000000a934da68] pgd=0000000000000000, p4d=0000000000000000
> > [   71.335299] Internal error: Oops: 0000000096000006 [#1] SMP
> > [   71.340860] Modules linked in: bridge stp llc qrtr rfkill sunrpc vfat fat mlx5_ib ib_uverbs cdc_ether usbnet mii ib_core acpi_ipmi ipmi_ssif arm_spe_pmu ipmi_devintf ipmi_msghandler arm_cmn arm_dmc620_pmu arm_dsu_pmu cppc_cpufreq xfs libcrc32c ast drm_vram_helper drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops drm_ttm_helper ttm mlx5_core crct10dif_ce ghash_ce sha2_ce sha256_arm64 sha1_ce drm sbsa_gwdt mlxfw tls nvme igb nvme_core psample nvme_common i2c_algo_bit pci_hyperv_intf i2c_designware_platform i2c_designware_core xgene_hwmon dm_mirror dm_region_hash dm_log dm_mod fuse
> > [   71.393089] CPU: 94 PID: 1563 Comm: kworker/u320:3 Not tainted 6.1.0-rc2-gavin+ #6
> > [   71.400646] Hardware name: FOXCONN Mt. Collins/Mt. Collins, BIOS 0ACOC017 (SCP: 1.08.20210825) 10/22/2021
> > [   71.410200] Workqueue: efi_rts_wq efi_call_rts
> > [   71.414636] pstate: 204000c9 (nzCv daIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
> > [   71.421585] pc : 0xb7ec7ae4
> > [   71.424367] lr : 0xb7ec8668
> > [   71.427149] sp : ffff80002f0e37e0
> > [   71.430452] x29: ffff80002f0e37e0 x28: ffffa4efa13bb0d0 x27: ffffa4efa0e32a18
> > [   71.437575] x26: ffff3fff93ce2d74 x25: ffff3fff90793805 x24: 0000000000000000
> > [   71.444698] x23: 0000000000000000 x22: 0000000000000000 x21: ffffa4efa06f0750
> > [   71.451821] x20: ffff8000279fbcc8 x19: ffffa4efa1df2a80 x18: 0000000000000000
> > [   71.458944] x17: 0000000000000000 x16: 0000000000000000 x15: 0000aaab19a5fb90
> > [   71.466067] x14: 0000000000000000 x13: 0000000000000010 x12: 0101010101010101
> > [   71.473190] x11: 7f7f7f7f7f7f7f7f x10: fefefefefeff7076 x9 : ffffa4ef9f5f7570
> > [   71.480313] x8 : 00000000b7cc05b8 x7 : ffff80002f0e3b60 x6 : ffff80002f0e3c00
> > [   71.487436] x5 : ffff80002f0e3b58 x4 : 00000000b7e81358 x3 : 00000000b7ec8600
> > [   71.494559] x2 : 0000000001000000 x1 : 0000000001000000 x0 : 00000000a934da60
> > [   71.501682] Call trace:
> > [   71.504116]  0xb7ec7ae4
> > [   71.506551]  0xb7ec8668
> > [   71.508985]  0xb7ec6e08
> > [   71.511419]  0xb7ec68ec
> > [   71.513853]  0xb7ec3824
> > [   71.516287]  0xb7ec05a8
> > [   71.518721]  0xb7ec12a0
> > [   71.521155]  0xb7e53524
> > [   71.523590]  0xb7e53670
> > [   71.526024]  0xb7e582f0
> > [   71.528458]  0xb7e5909c
> > [   71.530892]  0xb7e5a014
> > [   71.533326]  0xb7e508a8
> > [   71.535760]  0xb7cc3328
> > [   71.538195]  0xb7cc0674
> > [   71.540629]  __efi_rt_asm_wrapper+0x2c/0x48
> > [   71.544802]  efi_call_rts+0x2a8/0x440
> > [   71.548454]  process_one_work+0x1e4/0x460
> > [   71.552452]  worker_thread+0x74/0x414
> > [   71.556103]  kthread+0xf0/0xf4
> > [   71.559147]  ret_from_fork+0x10/0x20
> > [   71.562712] Code: 90000000 912c2000 f9400000 f9400000 (f9400401)
> > [   71.568794] ---[ end trace 0000000000000000 ]---
> > [   71.573401] Kernel panic - not syncing: Oops: Fatal exception in interrupt
> > [   71.580263] SMP: stopping secondary CPUs
> > [   71.584932] Kernel Offset: 0x24ef975e0000 from 0xffff800008000000
> > [   71.591012] PHYS_OFFSET: 0x80000000
> > [   71.594488] CPU features: 0x00000,001700a4,6601720b
> > [   71.599353] Memory Limit: none
> > [   71.602395] ---[ end Kernel panic - not syncing: Oops: Fatal exception in interrupt ]---
> >
> > Thanks,
> > Gavin
> >

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [Issue] EFI runtime-wrapper is broken #forregzbot

[Thorsten Leemhuis]

[Note: this mail is primarily send for documentation purposes and/or for
regzbot, my Linux kernel regression tracking bot. That's why I removed
most or all folks from the list of recipients, but left any that looked
like a mailing lists. These mails usually contain '#forregzbot' in the
subject, to make them easy to spot and filter out.]

[TLDR: I'm adding this regression report to the list of tracked
regressions; all text from me you find below is based on a few templates
paragraphs you might have encountered already already in similar form.]

Hi, this is your Linux kernel regression tracker.

On 28.10.22 11:21, Ard Biesheuvel wrote:
> On Fri, 28 Oct 2022 at 11:10, Gavin Shan <gshan@redhat.com> wrote:
>>
>> Hi Ard,
>>
>> I ran into the following crash with v6.1.rc2. I'm not sure if it's known
>> issue. Last good version is v6.0.rc6/rc7. The kernel configuration is attached.

Thanks for the report. To be sure below issue doesn't fall through the
cracks unnoticed, I'm adding it to regzbot, my Linux kernel regression
tracking bot:

#regzbot ^introduced d3549a938b73f203e
#regzbot title: efi: crashes due to broken runtime-wrapper
#regzbot from: Gavin Shan <gshan@redhat.com>
#regzbot ignore-activity

This isn't a regression? This issue or a fix for it are already
discussed somewhere else? It was fixed already? You want to clarify when
the regression started to happen? Or point out I got the title or
something else totally wrong? Then just reply -- ideally with also
telling regzbot about it, as explained here:
https://linux-regtracking.leemhuis.info/tracked-regression/

Reminder for developers: When fixing the issue, add 'Link:' tags
pointing to the report (the mail this one replies to), as explained for
in the Linux kernel's documentation; above webpage explains why this is
important for tracked regressions.

Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat)

P.S.: As the Linux kernel's regression tracker I deal with a lot of
reports and sometimes miss something important when writing mails like
this. If that's the case here, don't hesitate to tell me in a public
reply, it's in everyone's interest to set the public record straight.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [Issue] EFI runtime-wrapper is broken

[Thorsten Leemhuis]

Hi, this is your Linux kernel regression tracker. CCing the regression
mailing list, as it should be in the loop for all regressions, as
explained here:
https://www.kernel.org/doc/html/latest/admin-guide/reporting-issues.html

On 28.10.22 11:39, Ard Biesheuvel wrote:
> On Fri, 28 Oct 2022 at 11:38, Gavin Shan <gshan@redhat.com> wrote:
>> On 10/28/22 5:21 PM, Ard Biesheuvel wrote:
>>> On Fri, 28 Oct 2022 at 11:10, Gavin Shan <gshan@redhat.com> wrote:
>>>> I ran into the following crash with v6.1.rc2. I'm not sure if it's known
>>>> issue. Last good version is v6.0.rc6/rc7. The kernel configuration is attached.
>>>
>>> This is probably related to the patch below. It means the firmware is
>>> buggy, and does not work as it should if the firmware never calls
>>> SetVirtualAddressMap() [and doing so is explicitly described as
>>> OPTIONAL by the EFI specification].
>>>
>>> The problem here is that other EFI implementations (primarily the
>>> Qualcomm ones used on Windows-on-ARM laptops) are buggy too, and don't
>>> tolerate SetVirtualAddressMap().
>>>
>>> Can you try whether reverting the patch below helps?
>>
>> I ran into the issue on server, equipped with Ampere CPUs. With d3549a938b73
>> reverted, the crash disappeared.
> 
> Thanks for confirming
> 
> Can you please share the complete boot log and the DMI/SMBIOS data? Thanks.

Gavin, did you ever send this?

Or Ard, was there any progress to get the issue fixed?

I ask because I have this on the list of tracked regression -- and I
noticed there is another report about problems caused by d3549a938b73
now from Alexandru Elisei:
https://lore.kernel.org/lkml/Y2lAB508TrrjpDPi@monolith.localdoman/

Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat)

P.S.: As the Linux kernel's regression tracker I deal with a lot of
reports and sometimes miss something important when writing mails like
this. If that's the case here, don't hesitate to tell me in a public
reply, it's in everyone's interest to set the public record straight.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [Issue] EFI runtime-wrapper is broken

[Ard Biesheuvel]

On Tue, 8 Nov 2022 at 13:26, Thorsten Leemhuis
<regressions@leemhuis.info> wrote:
>
> Hi, this is your Linux kernel regression tracker. CCing the regression
> mailing list, as it should be in the loop for all regressions, as
> explained here:
> https://www.kernel.org/doc/html/latest/admin-guide/reporting-issues.html
>
> On 28.10.22 11:39, Ard Biesheuvel wrote:
> > On Fri, 28 Oct 2022 at 11:38, Gavin Shan <gshan@redhat.com> wrote:
> >> On 10/28/22 5:21 PM, Ard Biesheuvel wrote:
> >>> On Fri, 28 Oct 2022 at 11:10, Gavin Shan <gshan@redhat.com> wrote:
> >>>> I ran into the following crash with v6.1.rc2. I'm not sure if it's known
> >>>> issue. Last good version is v6.0.rc6/rc7. The kernel configuration is attached.
> >>>
> >>> This is probably related to the patch below. It means the firmware is
> >>> buggy, and does not work as it should if the firmware never calls
> >>> SetVirtualAddressMap() [and doing so is explicitly described as
> >>> OPTIONAL by the EFI specification].
> >>>
> >>> The problem here is that other EFI implementations (primarily the
> >>> Qualcomm ones used on Windows-on-ARM laptops) are buggy too, and don't
> >>> tolerate SetVirtualAddressMap().
> >>>
> >>> Can you try whether reverting the patch below helps?
> >>
> >> I ran into the issue on server, equipped with Ampere CPUs. With d3549a938b73
> >> reverted, the crash disappeared.
> >
> > Thanks for confirming
> >
> > Can you please share the complete boot log and the DMI/SMBIOS data? Thanks.
>
> Gavin, did you ever send this?
>
> Or Ard, was there any progress to get the issue fixed?
>
> I ask because I have this on the list of tracked regression -- and I
> noticed there is another report about problems caused by d3549a938b73
> now from Alexandru Elisei:
> https://lore.kernel.org/lkml/Y2lAB508TrrjpDPi@monolith.localdoman/
>

Yes, this is essentially the exact same problem, only on a different
type of Ampere hardware

I have an idea how to fix this more comprehensively - I'll work with
Alexandru to converge on a fix and get it queued up.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [Issue] EFI runtime-wrapper is broken #forregzbot

[Thorsten Leemhuis]

[Note: this mail is primarily send for documentation purposes and/or for
regzbot, my Linux kernel regression tracking bot. That's why I removed
most or all folks from the list of recipients, but left any that looked
like a mailing lists. These mails usually contain '#forregzbot' in the
subject, to make them easy to spot and filter out.]

On 08.11.22 14:57, Ard Biesheuvel wrote:
>> I ask because I have this on the list of tracked regression -- and I
>> noticed there is another report about problems caused by d3549a938b73
>> now from Alexandru Elisei:
>> https://lore.kernel.org/lkml/Y2lAB508TrrjpDPi@monolith.localdoman/
> Yes, this is essentially the exact same problem, only on a different
> type of Ampere hardware
> 
> I have an idea how to fix this more comprehensively - I'll work with
> Alexandru to converge on a fix and get it queued up.

In that case:

#regzbot dup-of:
https://lore.kernel.org/lkml/Y2lAB508TrrjpDPi@monolith.localdoman/


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [Issue] EFI runtime-wrapper is broken #forregzbot

[Thorsten Leemhuis]

[Note: this mail is primarily send for documentation purposes and/or for
regzbot, my Linux kernel regression tracking bot. That's why I removed
most or all folks from the list of recipients, but left any that looked
like a mailing lists. These mails usually contain '#forregzbot' in the
subject, to make them easy to spot and filter out.]

On 08.11.22 13:26, Thorsten Leemhuis wrote:
> Hi, this is your Linux kernel regression tracker. CCing the regression
> mailing list, as it should be in the loop for all regressions, as
> explained here:
> https://www.kernel.org/doc/html/latest/admin-guide/reporting-issues.html
> 
> On 28.10.22 11:39, Ard Biesheuvel wrote:
>> On Fri, 28 Oct 2022 at 11:38, Gavin Shan <gshan@redhat.com> wrote:
>>> On 10/28/22 5:21 PM, Ard Biesheuvel wrote:
>>>> On Fri, 28 Oct 2022 at 11:10, Gavin Shan <gshan@redhat.com> wrote:
>>>>> I ran into the following crash with v6.1.rc2. I'm not sure if it's known
>>>>> issue. Last good version is v6.0.rc6/rc7. The kernel configuration is attached.
>>>>
>>>> This is probably related to the patch below. It means the firmware is
>>>> buggy, and does not work as it should if the firmware never calls
>>>> SetVirtualAddressMap() [and doing so is explicitly described as
>>>> OPTIONAL by the EFI specification].
>>>>
>>>> The problem here is that other EFI implementations (primarily the
>>>> Qualcomm ones used on Windows-on-ARM laptops) are buggy too, and don't
>>>> tolerate SetVirtualAddressMap().
>>>>
>>>> Can you try whether reverting the patch below helps?
>>>
>>> I ran into the issue on server, equipped with Ampere CPUs. With d3549a938b73
>>> reverted, the crash disappeared.
>>
>> Thanks for confirming
>>
>> Can you please share the complete boot log and the DMI/SMBIOS data? Thanks.
> 
> Gavin, did you ever send this?
> 
> Or Ard, was there any progress to get the issue fixed?
> 
> I ask because I have this on the list of tracked regression -- and I
> noticed there is another report about problems caused by d3549a938b73
> now from Alexandru Elisei:
> https://lore.kernel.org/lkml/Y2lAB508TrrjpDPi@monolith.localdoman/

#regzbot fixed-by: 550b33cfd445296



_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel