[lkml]   [2007]   [Jun]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: 2.6.22-rc1-mm1
    Andy Whitcroft wrote:
    > Mel Gorman wrote:
    >> On Wed, 16 May 2007, H. Peter Anvin wrote:
    >>> Correction, does *this patch* do it for you?
    >> With these two patches in combination, previously failing machines
    >> elm3b6 (x86_64 on and a modern x86 built a kernel and
    >> booted correctly.
    >> elm3b132 and elm3b132 (x86 numaq on built with these
    >> patches but silently fail on boot with no output via earlyprintk.
    >> According to, this failure occurs with git-newsetup
    >> reverted so it is a separate problem.
    > Ok, I've been following up on this failure on elm3b132/3. I moved
    > forward to v2.6.22-rc2-mm1 and that also fails. I ran a bisection on
    > the git-newsetup patch in as in -mm and basically it came down to the
    > first patch, ie. any and all of this tree stops the boot.
    > I just tried reproducing git-newsetup boot failures with the latest
    > version of your tree (369f16fdd423d79640c4390915e6ab71189cb497) and that
    > also fails.
    > Fails in this context is hard boot failure after loading the kernel and
    > before anything is printed. I also added a printf to the top of main()
    > in boot/main.c and it doesn't come out, not that I really know if that
    > means it got there or not.
    > Any suggestions how to debug this puppy?

    Thanks to Peter for all his encouragement off list.

    I cannot claim to have sorted this one out, I do however understand why
    my experiences and Mels did not seem consistent. Basically I am getting
    inconsistent results with different machines.

    I started my debug on a machine where 2.6.22-rc2 which worked and
    2.6.22-rc2+newsetup which did not. I debugged the latter and managed to
    prove that it was in fact getting all the way to the kernel
    decompressor, and then crashing hard. The gzip image in memory was
    intact and yet it did not decrypt correctly, the first about 60% was
    intact, the remainder was damaged.

    Suspecting that this was an "uncompress in place" overlap problem I
    moved the compressed kernel way up out of the way and this then booted
    successfully. Experimenting I was able to get it to boot by increasing
    the overlap 'gap' from 32KB's to 64KB's. I was able to use the same
    patch to boot 2.6.22-rc2-mm1 on the same problems machines. However,
    this same overlap change did not fix another similar machine (the one in
    the TKO grid).

    I think that my debugging says that newsetup got the compressed kernel
    and decompressor into memory ok and execution passed to it normally.
    But I cannot figure out where the corruption is coming from. I tried
    annotating the gzip decompressor to see if the input and output buffers
    were overlapping at any time and that debug said no (unsure how reliable
    that is). And yet at some point the output image is munched up.

    One last piece of information. The decompressor also always seems to
    get to the end of the input stream in exactly the right place without
    reporting any kind of error, that is with exactly 8 bytes left over for
    the length and crc checks. Which given the context sensitive nature of
    the algorithm tends to imply the input stream was ok for the whole
    duration of the decompress. Yet the output stream is badly broken.

    Anyone got any wacky suggestions ...

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2007-06-01 11:53    [W:0.048 / U:1.036 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site