bugGNU GRUB - Bugs: bug #47711, EFI boot hang when driver...

 
 

You are not allowed to post comments on this tracker with your current authentication level.

bug #47711: EFI boot hang when driver allocates more than 1.5GB RAM above 4GB

Submitted by:  B Cran <bcran>
Submitted on:  Fri 15 Apr 2016 09:06:32 PM UTC  
 
Category: BootingSeverity: Major
Priority: 5 - NormalItem Group: Software Error
Status: InvalidPrivacy: Public
Assigned to: NoneOriginator Name: B Cran
Open/Closed: ClosedRelease: 
Release: Git masterReproducibility: Every Time
Planned Release: None

Sun 17 Apr 2016 04:32:52 AM UTC, comment #4:

If driver calls AllocatePages after ExitBootServices was called (and completed successfully), driver violates UEFI specification and there is little we can do here. Anyway, closing as per comment #2.

Andrei Borzenkov <arvidjaar>
Project Member
Sun 17 Apr 2016 01:53:29 AM UTC, comment #3:

Sorry, I meant b->exit_boot_services.

B Cran <bcran>
Sun 17 Apr 2016 01:52:37 AM UTC, comment #2:

With help from people on the edk2-devel ML, I booted Linux directly from Qemu and in the process found that it's not actually a problem with GRUB after all. Linux gets some way through booting before hanging.

B Cran <bcran>
Sat 16 Apr 2016 04:54:05 PM UTC, comment #1:

b->grub_efi_finish_boot_services does not exist. There is grub_efi_finish_boot_services() which calls b->exit_boot_services. Could you clarify what exactly you mean?

Andrei Borzenkov <arvidjaar>
Project Member
Fri 15 Apr 2016 09:06:32 PM UTC, original submission:

I have a UEFI driver that, when sufficient memory is available, uses lots of it for its work, for example routinely allocating 3-4GB. In an attempt to avoid problems with other drivers, applications or bootloaders, allocations start from the top of RAM and work towards the bottom.

GRUB master (abf9beb7d667d3604774753cf698c439c6fbc736) hangs sometime after calling `b->grub_efi_finish_boot_services` in grub_linux_boot() (grub-core/loader/i386/linux.c) when the following EFI code is run in a driver:

```
EFI_PHYSICAL_ADDRESS addr = 0x180000000;
EFI_STATUS status = gBS->AllocatePages(AllocateAddress, EfiBootServicesData, 0x80000, &addr);
```

For simplicity of replicating the problem this doesn't figure out where the top of memory is, but instead just chooses to allocate at 6GB.

I'm running OVMF from edk2 master under qemu 2.5.50 with:

qemu-system-x86_64 -name uefi -M pc -m size=20G -cpu host -drive unit=0,if=pflash,format=raw,file=OVMF.fd -nodefaults -realtime mlock=off -enable-kvm -S -s -rtc base=utc -monitor stdio -drive file=uefi3.img,if=ide,media=disk,format=raw -vga std -vnc :0 -device vfio-pci,host=02:00.0,id=pcidev,romfile=allocmem.rom

I've tried debugging this further by using gdb, but so far haven't managed to get a build that has full symbols.

B Cran <bcran>

 

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -unavailable- added by arvidjaar (Posted a comment)
  • -unavailable- added by bcran (Submitted the item)
  •  

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.

     

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    Follow 2 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Sun 17 Apr 2016 04:32:52 AM UTCarvidjaarStatusNone=>Invalid
      Open/ClosedOpen=>Closed

    Back to the top


    Powered by Savane 3.1-cleanup1