Re: efi_random_alloc() returning EFI_NOT_FOUND

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

 



On Wed, 12 Mar 2025 at 20:05, Ben Schneider <ben@xxxxxxxxx> wrote:
>
> On Wednesday, March 12th, 2025 at 4:24 AM, Ilias Apalodimas <ilias.apalodimas@xxxxxxxxxx> wrote:
> >
> > Can you please apply[...]to make
> > sure the map doesn't change from the time the slots were calculated.
>
> It doesn't seem like they do. This is the output:
>
> 7 0-4000000
> 0 4000000-4200000
> 7 4200000-4400000
> 0 4400000-5400000
> 7 5400000-3daef000
> 1 3daef000-3e2d5000
> 7 3e2d5000-3ea78000
> 2 3ea78000-3ea7b000
> 1 3ea7b000-3eaa1000
> 4 3eaa1000-3eaa7000
> 2 3eaa7000-3eaba000
> 4 3eaba000-3eabb000
> 2 3eabb000-3eabd000
> 4 3eabd000-3eabe000
> 9 3eabe000-3eac5000
> 4 3eac5000-3eac9000
> 6 3eac9000-3eaca000
> 4 3eaca000-3eacb000
> 6 3eacb000-3eaed000
> 4 3eaed000-3eaf6000
> 3 3eaf6000-3fb92000
> 6 3fb92000-3fb93000
> 3 3fb93000-3ff00000
> 5 3ff00000-3ff10000
> 3 3ff10000-40000000
>
> Inside get_entry_num_slots() it skips everything that's not
> conventional which just leaves these four entries:
>
> 7 0-4000000
> 7 4200000-4400000
> 7 5400000-3daef000
> 7 3e2d5000-3ea78000
>
> As a reminder, size is 18087936.

This is a decimal right ?

>
> For the first entry, I am seeing region_end = 67108863, first_slot
> = 0, last_slot = 48234496 so the function returns 24. This is the
> entry that is then subsequently used in the efi_allocate_pages()
> call that returns EFI_NOT_FOUND.
>
> For the second entry, first_slot > last_slot so we return 0.
>
> For the third entry, I am seeing region_end = 1034874879,
> first_slot = 88080384, last_slot = 1015021568 so the function
> returns 443. This is the entry that, when used by allocate pages
> by ignoring the first EFI_NOT_FOUND, returns EFI_SUCCESS and we
> continue to boot.
>
> For the fourth entry, first_slot > last_slot so we return 0.

Ok this helps. I don't think there's anything wrong in the kernel.
U-Boot has 64mb available and you are requesting to allocate ~17mb which fails.
On top of that, if you skip the failed allocation, the kernel tries
the next available slot starting at 0x5400000 which corresponds to the
correct memory map.

Since this seems a U-Boot issue, I'll send a patch over to the other
thread and we can continue from there

Thanks
/Ilias
>
> Ben




[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