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

Submitter:  B Cran <bcran>
Submitted:  Fri 15 Apr 2016 09:06:32 PM UTC
   
 
Category:  Booting Severity:  Major
Priority:  5 - Normal Item Group:  Software Error
Status:  Invalid Privacy:  Public
Assigned to:  None Originator Name:  B Cran
Open/Closed:  Closed Release:  Git master
Release:  Reproducibility:  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>
Group 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>
Group 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>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

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

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

     

    Follow 2 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2016-04-17 arvidjaar StatusNone Invalid
        Open/ClosedOpen Closed

    Back to the top

    Powered by Savane 3.13-caa5.
    Corresponding source code