On 11 November 2015 at 01:20, Vladimir Olovyannikov <volov...@broadcom.com> wrote: > Hello, > > I am not sure this is the right forum to ask this question, so I am sorry in > advance if this is an offtopic here (please point me to the proper one). > > I brought up UEFI on the device and am trying to load linux from the SD card > (loading from the network using GRUB is a topic for another message). > > Linux kernel starts and shortly after that (as soon as local_async is > enabled which is simple “MSR DAIfclr,4”) there is a kernel crash with > > “Bad mode in Error handler detected, code 0xbf000000 -- SError” > Here is the log: > > > > The default boot selection will start in 10 seconds >
Unrelated note: *please* get rid of the ARM BDS and use the Intel BDS instead. The ARM BDS violates the UEFI spec, (i.e., you cannot boot installer images from it without a lot of hassle) and does not allow you to enable UEFI secure boot. Look at the development history of ArmVExpress-FVP-AArch64.dsc for hints how to do this. > [1] Linux Kernel from SD Card > > - SD(0x0)/HD(1,MBR,0x00000000,0x89,0x3A9F77)/Image > > - Arguments: dtb=ns2-svk.dtb initrd=initrd console=ttyS0,115200n8 > earlycon=uart8250,mmio32,0x66130000,maxcpus=1 > > [2] GRUB > > - MAC(001019D0B2A4,0x1)/IPv4(10.136.12.136)/grub.efi > > - Arguments: > > [3] Shell > > [4] Boot Manager > > Start: 1 > > InstallProtocolInterface: CE345171-BA0B-11D2-8E4F-00A0C969723B BEDB9DA0 > > BlockSize : 512 > > LastBlock : 3A9FFF > > InstallProtocolInterface: 09576E91-6D3F-11D2-8E39-00A0C969723B BEDB9798 > > InstallProtocolInterface: 964E5B21-6459-11D2-8E39-00A0C969723B BEDB9670 > > InstallProtocolInterface: CE345171-BA0B-11D2-8E4F-00A0C969723B BEDB95A0 > > InstallProtocolInterface: 964E5B22-6459-11D2-8E39-00A0C969723B BEDAF030 > > InstallProtocolInterface: 5B1B31A1-9562-11D2-8E3F-00A0C969723B BE2E6040 > > Loading driver at 0x000B8C0C000 EntryPoint=0x000B9297440 > > Loading driver at 0x000B8C0C000 EntryPoint=0x000B9297440 > > InstallProtocolInterface: BC62157E-3E33-4FEC-9920-2D3B36D750DF BEDB0718 > > EFI stub: Booting Linux Kernel... > > ConvertPages: Incompatible memory types > > EFI stub: Using DTB from command line > > EFI stub: Exiting boot services and installing virtual address map... > > MmcHost: ExitBootServicesEvent+ > > Marked card brcm-SDIO1 as removed > > Resetting Card brcm-SDIO1 > > brcm-SDIO1 Card reset done. > > MmcHost: ExitBootServicesEvent- > > MmcHost: ExitBootServicesEvent+ > > Marked card brcm-SDIO0 as removed > > Resetting Card brcm-SDIO0 > > brcm-SDIO0 Card reset done. > > MmcHost: ExitBootServicesEvent- > > [ 0.000000] Booting Linux on physical CPU 0x0 > > [ 0.000000] Initializing cgroup subsys cpu > > [ 0.000000] Linux version 4.2.0+ (volovyan@LBRMN-LNXUB114) (gcc version > 4.9.2 20140904 (prerelease) (crosstool-NG linaro-1.13.1-4.9-2014.09 - Linaro > GCC 4.9-2014.09) ) #1 SMP PREEMPT Tue Oct 13 11:33:09 PDT 2015 > > [ 0.000000] CPU: AArch64 Processor [411fd073] revision 3 > > [ 0.000000] Detected PIPT I-cache on CPU0 > > [ 0.000000] earlycon: Early serial console at MMIO32 0x66130000 (options > 'maxcpus=1') > > [ 0.000000] bootconsole [uart0] enabled > > [ 0.000000] Bad mode in Error handler detected, code 0xbf000000 -- SError > > [ 0.000000] CPU: 0 PID: 0 Comm: swapper Not tainted 4.2.0+ #1 > > [ 0.000000] Hardware name: SVK proto (DT) > > [ 0.000000] task: ffffffc0007584b0 ti: ffffffc00074c000 task.ti: > ffffffc00074c000 > > [ 0.000000] PC is at setup_arch+0x260/0x5b4 > > [ 0.000000] LR is at setup_arch+0x25c/0x5b4 > > [ 0.000000] pc : [<ffffffc000709708>] lr : [<ffffffc000709704>] pstate: > 000002c5 > > [ 0.000000] sp : ffffffc00074ff20 > > [ 0.000000] x29: ffffffc00074ff20 x28: 0000000000000000 > > [ 0.000000] x27: ffffffc000081198 x26: 00000000807cd000 > > [ 0.000000] x25: 00000000807ca000 x24: 0000000080000000 > > [ 0.000000] x23: 0000000000000000 x22: ffffffc000752000 > > [ 0.000000] x21: ffffffc000752610 x20: ffffffbffa800000 > > [ 0.000000] x19: ffffffc000080000 x18: 0000000000000000 > > [ 0.000000] x17: 00000000000005e3 x16: 0000000000001000 > > [ 0.000000] x15: 0000000000001c00 x14: 0ffffffffffffffe > > [ 0.000000] x13: 0000000000000020 x12: 0000000000000028 > > [ 0.000000] x11: 0000000000000007 x10: 0101010101010101 > > [ 0.000000] x9 : fffffffffffffffb x8 : 0000000000000008 > > [ 0.000000] x7 : 0000000000000003 x6 : 0000000000800000 > > [ 0.000000] x5 : 000000000000005f x4 : 0000000000000000 > > [ 0.000000] x3 : 0000000000000000 x2 : 0000000000000065 > > [ 0.000000] x1 : 0000000000000000 x0 : 0000000000000001 > > [ 0.000000] > > [ 0.000000] Internal error: Oops - bad mode: 0 [#1] PREEMPT SMP > > [ 0.000000] Modules linked in: > > [ 0.000000] CPU: 0 PID: 0 Comm: swapper Not tainted 4.2.0+ #1 > > [ 0.000000] Hardware name: SVK proto (DT) > > [ 0.000000] task: ffffffc0007584b0 ti: ffffffc00074c000 task.ti: > ffffffc00074c000 > > [ 0.000000] PC is at setup_arch+0x260/0x5b4 > > [ 0.000000] LR is at setup_arch+0x25c/0x5b4 > > [ 0.000000] pc : [<ffffffc000709708>] lr : [<ffffffc000709704>] pstate: > 000002c5 > > [ 0.000000] sp : ffffffc00074ff20 > > [ 0.000000] x29: ffffffc00074ff20 x28: 0000000000000000 > > [ 0.000000] x27: ffffffc000081198 x26: 00000000807cd000 > > [ 0.000000] x25: 00000000807ca000 x24: 0000000080000000 > > [ 0.000000] x23: 0000000000000000 x22: ffffffc000752000 > > [ 0.000000] x21: ffffffc000752610 x20: ffffffbffa800000 > > [ 0.000000] x19: ffffffc000080000 x18: 0000000000000000 > > [ 0.000000] x17: 00000000000005e3 x16: 0000000000001000 > > [ 0.000000] x15: 0000000000001c00 x14: 0ffffffffffffffe > > [ 0.000000] x13: 0000000000000020 x12: 0000000000000028 > > [ 0.000000] x11: 0000000000000007 x10: 0101010101010101 > > [ 0.000000] x9 : fffffffffffffffb x8 : 0000000000000008 > > [ 0.000000] x7 : 0000000000000003 x6 : 0000000000800000 > > [ 0.000000] x5 : 000000000000005f x4 : 0000000000000000 > > [ 0.000000] x3 : 0000000000000000 x2 : 0000000000000065 > > [ 0.000000] x1 : 0000000000000000 x0 : 0000000000000001 > > [ 0.000000] > > [ 0.000000] Process swapper (pid: 0, stack limit = 0xffffffc00074c020) > > [ 0.000000] Stack: (0xffffffc00074ff20 to 0xffffffc000750000) > > [ 0.000000] ff20: 0074ffa0 ffffffc0 00707688 ffffffc0 00733fa8 ffffffc0 > 0079d000 ffffffc0 > > [ 0.000000] ff40: 0079d000 ffffffc0 00752000 ffffffc0 00000000 00000000 > 80000000 00000000 > > [ 0.000000] ff60: 807ca000 00000000 807cd000 00000000 00000001 00000000 > 9f400000 00000000 > > [ 0.000000] ff80: ffffffff ffffffff 00000000 00000000 00000080 00000000 > fefefefe fefefefe > > [ 0.000000] ffa0: 00000000 00000000 8053e000 00000000 befe0018 00000000 > 00000e12 00000000 > > [ 0.000000] ffc0: 9f400000 00000000 00000000 00000000 00000000 00000000 > 80000000 00000000 > > [ 0.000000] ffe0: 00000000 00000000 00733fa8 ffffffc0 00000000 00000000 > 00000000 00000000 > > [ 0.000000] Call trace: > > [ 0.000000] [<ffffffc000709708>] setup_arch+0x260/0x5b4 > > [ 0.000000] [<ffffffc000707684>] start_kernel+0xa4/0x3ac > > [ 0.000000] Code: 91316000 94001ac2 97fff7a3 d50344ff (9400069a) > > [ 0.000000] ---[ end trace cb88537fdc8fa200 ]--- > > [ 0.000000] Kernel panic - not syncing: Attempted to kill the idle task! > > [ 0.000000] ---[ end Kernel panic - not syncing: Attempted to kill the > idle task! > > > > Searching for this issue on the Internet yielded several discussions, but it > looks like they do not apply to my case. > > Thus, I have tried to set the EFI_RT_VIRTUAL_BASE to some high value to > catch if anything from the UEFI tries to dereference memory while mapping is > being done, > to no avail – no errors. > If anything like that is going on, I would expect the fault to be reported synchronously. > > > Has anybody faced this issue? Or have any idea on how to catch where it > happens? > > The problem here is that obviously something happens way BEFORE aborts are > enabled, but inspecting GIC distributor etc. does not show any trace of an > abort. > This is a firmware problem, not a kernel problem. The kernel is entered with an pending asynchronous external abort, which may have several causes. You need to instrument the firmware (i.e., unmask the aborts earlier and run in the debugger) to get a feeling for what is going on there. It could be something like speculative accesses to unassigned physical ranges that are mapped cacheable inadvertently, but it could be lots of other things as well. -- Ard. _______________________________________________ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
