lkml.org 
[lkml]   [2013]   [Nov]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH 0/3] Early use of boot service memory
    On Thu, Nov 14, 2013 at 10:24:17AM +0200, Pekka Enberg wrote:
    > Hi Jerry,
    >
    > On Thu, Nov 14, 2013 at 1:57 AM, <jerry.hoemann@hp.com> wrote:
    > > I will still point out that as currently used, efi_reserve_boot_services
    > > is wrong. A work around for firmware bugs on one platform shouldn't be
    > > breaking platforms that don't have that bug. Its just much less likely
    > > to cause problems with higher crash kernel allocation.
    >
    > Wrong in what way exactly?


    efi_reserve_boot_services can cause reserve_crashkernel to fail.
    This breaks kump.

    Prior to 3.9, the area for crash dump had to be reserved below 896M.
    crash kernel is in one physically contiguous space.

    This is still the default way crash kernel is allocated post 3.9.

    The size of crash kernel is based upon size of system (memory, cpus, IO)
    and can get large. On one of our new servers we need to allocate crash
    kernels of 512MB or larger. efi_reserve_boot_services reserve boot
    service code/data and prevents it from being available to reserve_crashkernel.
    When this reservation fragments memory below 896 MB, it breaks the
    allocation for reserve_crashkernel. It breaks kdump.

    Distros based upon pre 3.9 kernels and w/ efi_reserve_boot_services
    are subject to failure.


    Customers who buy large servers want to be supported. They want to
    be able to take crash dumps and have bugs fixed. This issue makes
    crash dump more difficult or impossible dependent upon configuration
    and kernel version.




    > We need efi_reserve_boot_services on _some_ platforms and it's only practical
    > to do it on all platforms to be able to boot a generic kernel. Likewise, it


    disagree.

    efi_reserve_boot_services is necessary on some platforms, but
    it should have been applied as a quirk as its a workaround for
    broken firmware.

    there are numerous examples in linux of other platform defects being
    worked around as quirks.



    > would be more practical to fix crashkernel on all platforms instead of adding a
    > new code path in the kernel that won't receive as much testing coverage (we
    > need to reserve boot services by default).

    disagree.

    The fix for this issue will have to be back ported across multiple releases
    and distros. A large change will be difficult to back port and debug.
    There are kernel/tools rev locks in top of tree crash paths, these
    will likely have to be back ported also.

    Making this issue a quirk will be a lot more practical. Its a small, focused
    change whose implications are limited and more easily understood.

    BTW, we test the crash path a lot.


    >
    > And frankly, I don't understand why 'violating the UEFI specification' is even


    Its background material to understand why the code is the way it is.
    Its the reason that efi_reserve_boot_services was added to the kernel.
    Its why we can't just drop efi_reserve_boot_services.


    > brought up. It's shipped firmware that matters here no matter how broken it
    > is. As long as there's a reasonable solution for crashkernel that works on all
    > platforms, we should go for it instead of special-casing for 'proper firmware'
    > because it makes testing the kernel more difficult.
    >
    > Pekka

    --

    ----------------------------------------------------------------------------
    Jerry Hoemann Software Engineer Hewlett-Packard

    3404 E Harmony Rd. MS 57 phone: (970) 898-1022
    Ft. Collins, CO 80528 FAX: (970) 898-XXXX
    email: jerry.hoemann@hp.com
    ----------------------------------------------------------------------------



    \
     
     \ /
      Last update: 2013-11-14 19:41    [W:4.332 / U:0.016 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site