lkml.org 
[lkml]   [2009]   [Jan]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: 2.6.28-rc9 panics with crashkernel=256M while booting
    From
    Date
    On Thu, 2009-01-08 at 15:59 +0530, Chandru wrote:
    > @@ -898,9 +899,17 @@ static void mark_reserved_regions_for_ni
    > * if reserved region extends past active region
    > * then trim size to active region
    > */
    > - if (end_pfn > node_ar.end_pfn)
    > + if (end_pfn > node_ar.end_pfn) {
    > reserve_size = (node_ar.end_pfn << PAGE_SHIFT)
    > - (start_pfn << PAGE_SHIFT);
    > + /*
    > + * resize it further if the reservation could
    > + * cross the last page in this node
    > + */
    > + if (PFN_UP(physbase+reserve_size) >
    > + node_end_pfn)
    > + reserve_size -= PAGE_SIZE;
    > + }
    > /*

    Now I'm even more confused. Could you please send a fully changelogged
    patch that describes the problem, and how this fixes it? This just
    seems like an off-by-one error, which isn't what I thought we had before
    at all.

    I'm also horribly confused why PFN_UP is needed here. Is 'physbase' not
    page aligned? reserve_size looks like it *has* to be. 'end_pfn' is
    always (as far as I have ever seen in the kernel) the pfn of the page
    after the area we are interested in and we treat it as such in that
    function. In the case of an unaligned physbase, that wouldn't be true.

    Think of the case where we have a 1-byte reservation. start_pfn will
    equal end_pfn and we won't go into that while loop at *all* and won't
    reserve anything.

    Does 'end_pfn' need fixing?

    -- Dave



    \
     
     \ /
      Last update: 2009-01-08 21:05    [W:0.038 / U:0.036 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site