I was impressed by how fast 2.6.18-rc3-mm2 is under memory pressure,
until I noticed that my "mem=512M" boot option was doing nothing. The
two fixes below got it working, but I wonder how many other early_param
"option=" args are wrong (e.g. "memmap=" in the same file): x86_64
shows many such, i386 shows only one, I've not followed it up further.
Hugh
--- 2.6.18-rc3-mm2/arch/x86_64/kernel/e820.c 2006-08-06 12:25:35.000000000 +0100
+++ linux/arch/x86_64/kernel/e820.c 2006-08-06 18:05:33.000000000 +0100
@@ -646,11 +646,11 @@ static int __init parse_memopt(char *p)
{
if (!p)
return -EINVAL;
- end_user_pfn = memparse(p, NULL);
+ end_user_pfn = memparse(p, &p);
end_user_pfn >>= PAGE_SHIFT;
return 0;
}
-early_param("mem=", parse_memopt);
+early_param("mem", parse_memopt);
static int userdef __initdata;
On Sun, 6 Aug 2006, Hugh Dickins wrote:
> I was impressed by how fast 2.6.18-rc3-mm2 is under memory pressure,
> until I noticed that my "mem=512M" boot option was doing nothing. The
> two fixes below got it working, but I wonder how many other early_param
> "option=" args are wrong (e.g. "memmap=" in the same file): x86_64
> shows many such, i386 shows only one, I've not followed it up further.
Oh, and that's not enough for it to show up in x86_64's /proc/cmdline.
Hugh
On Sun, 6 Aug 2006 18:22:04 +0100 (BST)
Hugh Dickins <[email protected]> wrote:
> I was impressed by how fast 2.6.18-rc3-mm2 is under memory pressure,
> until I noticed that my "mem=512M" boot option was doing nothing. The
> two fixes below got it working, but I wonder how many other early_param
> "option=" args are wrong (e.g. "memmap=" in the same file): x86_64
> shows many such, i386 shows only one, I've not followed it up further.
Thanks again.
Andi, it sounds like so many fixes will be needed there that it's worth
dropping, pending rev #2.
On Sunday 06 August 2006 21:15, Andrew Morton wrote:
> On Sun, 6 Aug 2006 18:22:04 +0100 (BST)
> Hugh Dickins <[email protected]> wrote:
>
> > I was impressed by how fast 2.6.18-rc3-mm2 is under memory pressure,
> > until I noticed that my "mem=512M" boot option was doing nothing. The
> > two fixes below got it working, but I wonder how many other early_param
> > "option=" args are wrong (e.g. "memmap=" in the same file): x86_64
> > shows many such, i386 shows only one, I've not followed it up further.
>
> Thanks again.
>
> Andi, it sounds like so many fixes will be needed there that it's worth
> dropping, pending rev #2.
Yes, it looks like it. Now I remember why I dropped this a long time
ago already ;-)
After fixing Hugh's issue with all parameters
(there were some more with this) the kernel goes into an endless loop
at boot when you have one which is a full prefix of another.
-Andi
On Sun, 2006-08-06 at 18:22 +0100, Hugh Dickins wrote:
> but I wonder how many other early_param
> "option=" args are wrong (e.g. "memmap=" in the same file): x86_64
> shows many such, i386 shows only one, I've not followed it up further.
Thanks Hugh.
Andrew, here's that i386 fix:
Subject: Fix acpi_sci early_param
Unlike __setup which just does prefix matching, early_param does actual
command-line parsing (as module_param), so no "=" is needed or desired.
Signed-off-by: Rusty Russell <[email protected]>
--- linux-2.6.18-rc3-mm2/arch/i386/kernel/acpi/boot.c.~1~ 2006-08-07 12:40:14.000000000 +1000
+++ linux-2.6.18-rc3-mm2/arch/i386/kernel/acpi/boot.c 2006-08-07 12:49:42.000000000 +1000
@@ -1292,4 +1292,4 @@
return -EINVAL;
return 0;
}
-early_param("acpi_sci=", setup_acpi_sci);
+early_param("acpi_sci", setup_acpi_sci);
--
Help! Save Australia from the worst of the DMCA: http://linux.org.au/law
On Monday 07 August 2006 04:54, Rusty Russell wrote:
> On Sun, 2006-08-06 at 18:22 +0100, Hugh Dickins wrote:
> > but I wonder how many other early_param
> > "option=" args are wrong (e.g. "memmap=" in the same file): x86_64
> > shows many such, i386 shows only one, I've not followed it up further.
>
> Thanks Hugh.
>
> Andrew, here's that i386 fix:
I had already fixed that one and the x86-64 ones.
But it still doesn't boot on x86-64 - gets into an endless loop
at boot. I'm suspecting the code can't deal with duplicated
prefixes.
-Andi
On Mon, 2006-08-07 at 04:55 +0200, Andi Kleen wrote:
> On Monday 07 August 2006 04:54, Rusty Russell wrote:
> > On Sun, 2006-08-06 at 18:22 +0100, Hugh Dickins wrote:
> > > but I wonder how many other early_param
> > > "option=" args are wrong (e.g. "memmap=" in the same file): x86_64
> > > shows many such, i386 shows only one, I've not followed it up further.
> >
> > Thanks Hugh.
> >
> > Andrew, here's that i386 fix:
>
> I had already fixed that one and the x86-64 ones.
>
> But it still doesn't boot on x86-64 - gets into an endless loop
> at boot. I'm suspecting the code can't deal with duplicated
> prefixes.
Works fine here:
early_param("param", early_param1);
early_param("param2", early_param2);
I'm building an x86_64 kernel, and hoping it runs under qemu. If so,
I'll find the problem...
Thanks,
Rusty.
--
Help! Save Australia from the worst of the DMCA: http://linux.org.au/law
On Monday 07 August 2006 05:08, Rusty Russell wrote:
> On Mon, 2006-08-07 at 04:55 +0200, Andi Kleen wrote:
> > On Monday 07 August 2006 04:54, Rusty Russell wrote:
> > > On Sun, 2006-08-06 at 18:22 +0100, Hugh Dickins wrote:
> > > > but I wonder how many other early_param
> > > > "option=" args are wrong (e.g. "memmap=" in the same file): x86_64
> > > > shows many such, i386 shows only one, I've not followed it up further.
> > >
> > > Thanks Hugh.
> > >
> > > Andrew, here's that i386 fix:
> >
> > I had already fixed that one and the x86-64 ones.
> >
> > But it still doesn't boot on x86-64 - gets into an endless loop
> > at boot. I'm suspecting the code can't deal with duplicated
> > prefixes.
>
> Works fine here:
32bit works for me too, but x86-64 does. Strangely it seems to somehow
reenter head64 copy_boot_data. Perhaps stack gets smashed somehow?
It goes into an endless loop of:
Bootdata ok (command line is ip=dhcp nfsroot=10.23.204.1:/home/nfsroot/gaston root=/dev/nfs debug vga=0x0f07 rw pci=noacpi earlyprintk=serial,ttyS0,115200 console=ttyS0,115200 earlyprintk=serial,ttyS0,115200 console=tty0 BOOT_IMAGE=bzImage )
Bootdata ok (command line is ip=dhcp nfsroot=10.23.204.1:/home/nfsroot/gaston root=/dev/nfs debug vga=0x0f07 rw pci=noacpi earlyprintk=serial,ttyS0,115200 console=ttyS0,115200 earlyprintk=serial,ttyS0,115200 console=tty0 BOOT_IMAGE=bzImage )
Bootdata ok (command line is ip=dhcp nfsroot=10.23.204.1:/home/nfsroot/gaston root=/dev/nfs debug vga=0x0f07 rw pci=noacpi earlyprintk=serial,ttyS0,115200 console=ttyS0,115200 earlyprintk=serial,ttyS0,115200 console=tty0 BOOT_IMAGE=bzImage )
etc.
That is with all =s removed in early_params (i got that wrong in a lot of cases
-- the only option I tested was apic which didn't have it)
-Andi
>
Hugh Dickins wrote:
> On Sun, 6 Aug 2006, Hugh Dickins wrote:
>> I was impressed by how fast 2.6.18-rc3-mm2 is under memory pressure,
>> until I noticed that my "mem=512M" boot option was doing nothing. The
>> two fixes below got it working, but I wonder how many other early_param
>> "option=" args are wrong (e.g. "memmap=" in the same file): x86_64
>> shows many such, i386 shows only one, I've not followed it up further.
>
> Oh, and that's not enough for it to show up in x86_64's /proc/cmdline.
Thats one I've been chasing and is caused by this same patch. We've
lost the separation between command_line and saved_command_line and the
user visible line gets trunc'd. Andi has a later version which has this
part fixed as far as I can tell. I'm posting a dirty patch in response
to my report of this to at least get past this bit as our test system
relies on the commmand line being maintained to user space.
-apw
Hugh Dickins <[email protected]> writes:
> On Sun, 6 Aug 2006, Hugh Dickins wrote:
>> I was impressed by how fast 2.6.18-rc3-mm2 is under memory pressure,
>> until I noticed that my "mem=512M" boot option was doing nothing. The
>> two fixes below got it working, but I wonder how many other early_param
>> "option=" args are wrong (e.g. "memmap=" in the same file): x86_64
>> shows many such, i386 shows only one, I've not followed it up further.
>
> Oh, and that's not enough for it to show up in x86_64's /proc/cmdline.
The /proc/cmdline part is easy.
Someone deleted the copy from saved_command_line to command_line.
Since kernel/params.c:parse_args called in init/main.c is destructive
if we don't do this we will never see a reasonable command line in /proc,
and /init implementations that parse /proc/command_line will choke horribly.
Signed-off-by: Eric W. Biederman <[email protected]>
diff --git a/arch/x86_64/kernel/setup.c b/arch/x86_64/kernel/setup.c
index 3bc1ff4..37206a4 100644
--- a/arch/x86_64/kernel/setup.c
+++ b/arch/x86_64/kernel/setup.c
@@ -378,7 +378,8 @@ #endif
early_identify_cpu(&boot_cpu_data);
parse_early_param();
- *cmdline_p = saved_command_line;
+ memcpy(command_line, saved_command_line, COMMAND_LINE_SIZE);
+ *cmdline_p = command_line;
finish_e820_parsing();
On 8/7/06, Eric W. Biederman <[email protected]> wrote:
> Hugh Dickins <[email protected]> writes:
>
> > On Sun, 6 Aug 2006, Hugh Dickins wrote:
> >> I was impressed by how fast 2.6.18-rc3-mm2 is under memory pressure,
> >> until I noticed that my "mem=512M" boot option was doing nothing. The
> >> two fixes below got it working, but I wonder how many other early_param
> >> "option=" args are wrong (e.g. "memmap=" in the same file): x86_64
> >> shows many such, i386 shows only one, I've not followed it up further.
> >
> > Oh, and that's not enough for it to show up in x86_64's /proc/cmdline.
>
> The /proc/cmdline part is easy.
>
> Someone deleted the copy from saved_command_line to command_line.
> Since kernel/params.c:parse_args called in init/main.c is destructive
> if we don't do this we will never see a reasonable command line in /proc,
> and /init implementations that parse /proc/command_line will choke horribly.
>
> Signed-off-by: Eric W. Biederman <[email protected]>
>
> diff --git a/arch/x86_64/kernel/setup.c b/arch/x86_64/kernel/setup.c
> index 3bc1ff4..37206a4 100644
> --- a/arch/x86_64/kernel/setup.c
> +++ b/arch/x86_64/kernel/setup.c
> @@ -378,7 +378,8 @@ #endif
> early_identify_cpu(&boot_cpu_data);
>
> parse_early_param();
> - *cmdline_p = saved_command_line;
> + memcpy(command_line, saved_command_line, COMMAND_LINE_SIZE);
> + *cmdline_p = command_line;
>
> finish_e820_parsing();
Ok this helped keep the cmdline around but the early_param is still
busted with 2.6.18-rc3-mm2 (I don't have cmdline problem with non -mm
2.6.18-rc3).
I am booting with numa=hotadd=100 on x86_64. The parameter
hotadd_percent is not getting setup right. Printk tells me that
numa_setup is not called during boot.
if I change
early_param("numa=", numa_setup);
to
early_param("numa", numa_setup);
The parameter hotadd_percent is setup right but there is a
"Malformed early option 'numa'" message.
Is there some other patch that I missed to fix this?
Also it seems like the earlyconsole isn't getting setup right.... It
seems to take forever to start (say about 20-30 seconds) This pause in
the boot is caused by the reserve hot-add patch but early console
should start before the pause.
command line is root=/dev/sda3
ip=9.47.66.153:9.47.66.169:9.47.66.1:255.255.255.0 resume=/dev/sda2
showopts earlyprintk=ttyS0,115200 console=ttyS0,115200 console=tty0
debug numa=hotadd=100
Again thing work as expected with 2.6.18-rc3.
Thanks,
Keith
>
> Again thing work as expected with 2.6.18-rc3.
Everything I knew of is fixed in the latest version of the patch, just -mm* still
has the old one.
It's useless to report any more bugs against the -mm* version.
-Andi
On Tue, 2006-08-08 at 17:10 -0700, Keith Mannthey wrote:
> The parameter hotadd_percent is setup right but there is a
> "Malformed early option 'numa'" message.
For the record: this happens when the function registered with
early_param() returns non-zero. __setup() functions return 1 if OK,
module_param() and early_param() return 0 or a -ve error code.
Hope that clarifies,
Rusty.
--
Help! Save Australia from the worst of the DMCA: http://linux.org.au/law