From: "Bora Şahin" <borasah@netone.com.tr>
To: <linux-kernel@vger.kernel.org>
Subject: Q: parse_cmdline_early()
Date: Sun, 2 Mar 2003 11:35:20 +0200 [thread overview]
Message-ID: <00a201c2e09f$0bab6900$0100a8c0@bora> (raw)
Hi,
I have two problems with the parse_cmdline_early().
My first problem is related to mem options.
...
/*
* "mem=nopentium" disables the 4MB page tables.
* "mem=XXX[kKmM]" defines a memory region from HIGH_MEM
* to <mem>, overriding the bios size.
* "mem=XXX[KkmM]@XXX[KkmM]" defines a memory region from
* <start> to <start>+<mem>, overriding the bios size.
*/
I think this comment would be expressed better. Of the comments are
understood like
"start_at@mem_size". But actually "mem_size@start_at"
if (!memcmp(from, "mem=", 4)) {
if (to != command_line)
to--;
// ok
if (!memcmp(from+4, "nopentium", 9)) {
from += 9+4;
clear_bit(X86_FEATURE_PSE, &boot_cpu_data.x86_capability);
}
// ok
else if (!memcmp(from+4, "exactmap", 8)) {
from += 8+4;
e820.nr_map = 0;
userdef = 1;
}
// This is the problem
else {
/* If the user specifies memory size, we
* limit the BIOS-provided memory map to
* that size. exactmap can be used to specify
* the exact map. mem=number can be used to
* trim the existing memory map.
*/
unsigned long long start_at, mem_size;
mem_size = memparse(from+4, &from);
if (*from == '@') {
start_at = memparse(from+1, &from);
add_memory_region(start_at, mem_size, E820_RAM);
}
else {
limit_regions(mem_size);
userdef=1;
}
}
}
...
If I supply the parameter in a old fashion, that is, mem=xxx[kmg] It's OK,
limit_regions is called and It works as usual. But If I supply the parameter
in a new way, that is mem=128m@1m, the kernel hangs on. Only prints the
screen "uncompressing Linux... Ok, booting the kernel" msg. If I understand
the function correctly, there are two case:
1) mem=xx[kmg]. It works.
2) mem=exactmap and mem=xxx[kmg]@xxx[kmg] are supplied together because as
if function was configured having been thought this. For example this way
userdef is set. But If I supply the mem=exactmap and mem=x@x, Lilo complains
and refuse it: "Invalid number".
If I supply only mem=xxx[kmg]@xxx[kmg], kernel can be crashed.
Because (One of the reasons) I have got 256 Mb RAM and this will overlaps
the BIOS provided results. (sanitize function is not called after the
parse_cmdline_early()) But this isnt and as I said the above, It crashes
early-bootup phase.
These means, doesnt Lilo support mem=x@x? Version: 21.4-4 or are my
assumptions true?
My second problem is in fact trivial. According to the function, If an
option is omitted from command_line It seems It should be done a check.
*to = command_line
...
/* among mem options */
if (to != command_line)
to--;
This means an unnecessary space isnt added to 'to' variable. (If It is first
option in the command_line, then there is no extra space) But there is an
exception.
else if (!memcmp(from, "highmem=", 8))
highmem_pages = memparse(from+8, &from) >> PAGE_SHIFT;
Here, highmem_pages is parsed and omitted but there is no check like the
above. This way, an extra space is added to 'to'. I think functions which
parse command_line later is prepared but It seems there are inconsistencies.
Kernel Version: 2.4.19
Thanks in advance...
Sory for my bad English...
Regards
Bora Sahin
reply other threads:[~2003-03-02 9:25 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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='00a201c2e09f$0bab6900$0100a8c0@bora' \
--to=borasah@netone.com.tr \
--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.