From: Rodrigo Amestica <ramestic@nrao.edu>
To: Sergey Vlasov <vsu@altlinux.ru>
Cc: Rodrigo Amestica <ramestic@nrao.edu>,
linux-kernel@vger.kernel.org, Patrick P Murphy <pmurphy@nrao.edu>
Subject: Re: vmalloc kernel parameter
Date: Thu, 29 Jun 2006 09:08:31 -0400 [thread overview]
Message-ID: <44A3D0CF.8050608@nrao.edu> (raw)
In-Reply-To: <44A29E85.9000902@nrao.edu>
Hi Sergey,
the uppermem workaround for grub did not work well for me when I tried to add
the mem+memmap parameters to the kernel. My machine has 2GB of ram and trying to
set mem beyond the 1GB limit made the machine unable to boot. Setting mem to a
value below 1GB allowed the machine to boot but VmallocTotal reported unexpected
values.
I have switched now to lilo and things seems to work just fine. The following
lilo config
image=/boot/vmlinuz
label=vmalloc
initrd=/boot/initrd.img
read-only
append="root=LABEL=/ vmalloc=256M mem=1899M memmap=128M#1899M"
let's the machine boot just fine reporting the following values in /proc/meminfo
MemTotal: 1925632 kB
VmallocTotal: 245752 kB
Rodrigo
Rodrigo Amestica wrote:
> Hi Sergey, many thanks for the reply.
>
> I saw those links before but I did not get their full meaning.
>
> By setting uppermem to 512M it does actually work. However, now I'm
> trying to reserve RAM for DMA sake. For that I use mem=1899M; where 1899
> comes from the total memory reported under normal booting less 128M,
> which are the Megs that I'm trying to reserve.
>
> It seems that by adding mem to the boot line goes into conflicting with
> the uppermem+vmalloc arrangement.
>
> Without providing more details on what's actually happening can you tell
> that there is something wrong on what I'm trying to do?
>
> Would switching to lilo help any?
>
> thanks,
> Rodrigo
>
> Sergey Vlasov wrote:
>>
>> This is a known problem with GRUB: it tries to put initrd at the highest
>> possible address in memory, and assumes the standard vmalloc area size.
>> You need to trick GRUB into thinking that your machine has less memory
>> by using "uppermem 524288" (512M) or even lower - then the initrd data
>> will still be accessible for the kernel even with larger vmalloc area.
>>
>> http://lkml.org/lkml/2005/4/4/283
>> http://lists.linbit.com/pipermail/drbd-user/2005-April/002890.html
>>
>>> ps: my kernel version is 2.6.15.2, and my machine is a dual opteron
>>> with 2GB of ram
>>>
>>> title with vmalloc
>>> root (hd0,0)
>>
>> Add "uppermem 524288" here.
>>
>>> kernel /boot/vmlinuz ro root=LABEL=/ vmalloc=256M
>>> initrd /boot/initrd.img
next prev parent reply other threads:[~2006-06-29 13:08 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-06-28 12:15 vmalloc kernel parameter Rodrigo Amestica
2006-06-28 12:33 ` Sergey Vlasov
2006-06-28 15:21 ` Rodrigo Amestica
2006-06-29 13:08 ` Rodrigo Amestica [this message]
2006-06-29 2:07 ` H. Peter Anvin
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=44A3D0CF.8050608@nrao.edu \
--to=ramestic@nrao.edu \
--cc=linux-kernel@vger.kernel.org \
--cc=pmurphy@nrao.edu \
--cc=vsu@altlinux.ru \
/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.