All of lore.kernel.org
 help / color / mirror / Atom feed
From: Nigel Kukard <nkukard@lbsd.net>
To: "H. Peter Anvin" <hpa@zytor.com>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [BUG] kernel 2.6.33-rc4 OOPS's with large initramfs
Date: Sat, 20 Mar 2010 22:26:41 +0000	[thread overview]
Message-ID: <4BA54BA1.6020304@lbsd.net> (raw)
In-Reply-To: <4BA54012.2080106@zytor.com>


>>>>> How much RAM are you giving your VM?  The default for Qemu is 128 MB,
>>>>> and if you have a 110 MB initramfs it's hardly surprising that you get
>>>>> an out of memory error.
>>>>>       
>>>>>           
>>>> The kernel now boots where it booted for my 64bit box.
>>>>
>>>> The main problem though is the instant reboots for bzip2 and lzma
>>>> compressed initramfs images. The change for printf to /usr/bin/printf
>>>> both render the sane end result when run with the same commandline being
>>>> run in the makefile, so this isn't the issue.
>>>>
>>>>     
>>>>         
>>> Oh, you have *that* problem.
>>>
>>> What printf is being used?
>>>       
>> coreutils 8.4 and 7.5 and bash all give me the same result for the
>> commandline being run. This was just one of the things I tried and it
>> didn't fix the problem.
>>
>> Here is what is run from the buildlog...
>>   (cat arch/x86/boot/compressed/vmlinux.bin | lzma -9 && printf
>> \\150\\111\\241\\007) > arch/x86/boot/compressed/vmlinux.bin.lzma || (rm
>> -f arch/x86/boot/compressed/vmlinux.bin.lzma ; false)
>>
>> I tested printf out...
>> # printf \\150\\111\\241\\007 | xxd
>> 0000000: 6849 a107                                hI..
>>
>> coreutils 7.5
>> # /usr/bin/printf \\150\\111\\241\\007 | xxd
>> 0000000: 6849 a107                                hI..
>>
>> coreutils 8.4
>> # /usr/bin/printf \\150\\111\\241\\007 | xxd
>> 0000000: 6849 a107                                hI..
>>
>>
>> That confirms it? its not the b0rked printf issue afaics :)
>>
>>     
> Okay, so why the f*ck did you mention that instead of answering the
> question I asked?  *How much memory does your VM have?*

Sorry, had 128M , now has 2G. The tests now render the same results
between qemu and plain hardware.

The reason I mentioned the printf issue is it causes this exact problem,
I just wanted you to know that I've already touched that base to rule it
out. Sorry.




      reply	other threads:[~2010-03-20 22:32 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-01-16 11:12 [BUG] kernel 2.6.33-rc4 OOPS's with large initramfs Nigel Kukard
2010-01-24 23:26 ` H. Peter Anvin
2010-03-20 18:12   ` Nigel Kukard
2010-03-20 18:56     ` H. Peter Anvin
2010-03-20 20:09       ` Nigel Kukard
2010-03-20 20:16         ` H. Peter Anvin
2010-03-20 20:22           ` Nigel Kukard
2010-03-20 21:37             ` H. Peter Anvin
2010-03-20 22:26               ` Nigel Kukard [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4BA54BA1.6020304@lbsd.net \
    --to=nkukard@lbsd.net \
    --cc=hpa@zytor.com \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.