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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox