[lkml]   [2008]   [Aug]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: Linux 2.6.27-rc5: System boot regression caused by commit a2bd7274b47124d2fc4dfdb8c0591f545ba749dd

    Btw, what was the original regression that commit was
    a2bd7274b47124d2fc4dfdb8c0591f545ba749dd trying to fix?

    It's not listed in that commit, even though the commit has a "Bisected-by:
    David Witbrodt <>".

    In fact, I can find it with google by searching for

    David Witbrodt bisect

    and I see that it is 3def3d6ddf43dbe20c00c3cbc38dfacc8586998f.

    I'm wondering why that commit wasn't just reverted? Because now that I see
    it, I notice that _that_ is the real bug to begin with.

    That commit really was buggy. NO WAY can you insert the code/bss/data
    resources before you've done e820 handling, because it may well be that
    some strange e820 table contains things that cross the resources.

    So that original thing was buggy, and made x86-64 do odd thigns. They were
    doubly odd, since x86-32 did it differently (and better, I think).

    Then, when actally doing the common arch/x86/kernel/setup.c, the commit
    that does so _claims_ that the common code came from the 32-bit version,
    but that doesn't seem to be true, at least wrt this thing. The current
    setup.c comes from the *broken* cleanup of setup_64.c that had been
    bisected to be broken.

    And that, in turn, happened in 41c094fd3ca54f1a71233049cf136ff94c91f4ae
    ("x86: move e820_resource_resources to e820.c") which also did "and make
    32-bit resource registration more like 64 bit.", so it got the bug into
    32-bit code that had been introduced in 64-bit code.


    So why was then that other broken commit added to paper it over, even
    though the original broken commit had been bisected and the breakage was
    known to have been due to _that_?


    Yinghai - I'm hoping that the code movement is all over and done with, but
    you need to be a _lot_ more careful here. And Ingo, this really wasn't
    very well done.


     \ /
      Last update: 2008-08-30 03:17    [W:0.022 / U:14.316 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site