bzImage ~ 900K with i386 test11-pre2

Quoted 5 lines · Max Inux

Quoted 2 lines
gzip, actually. I can verify here "make bzImage" does the expected thing and it looks normal-sized to me.
I believe there is zImage (gzip) and bzImage (bzip2). (Or is it compress vs gzip, but then why bzImage vs gzImage?)

IMHO bzImage means something like 'big zImage', it uses the same compression but a different loader. IIRC bzImage became necessary when the (uncompressed) kernel grew above 1MB.

Jan

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

Tigran Aivazian

2000-11-11 11:35 UTC #9 lore raw

Quoted 7 lines · H. Peter Anvin

Quoted 4 lines
On x86 machines there is a size limitation on booting. Though I thought it was 1024K as the max, 900K should be fine.
No, there isn't. There used to be, but it has been fixed.

Are you sure? I thought the fix was to build 2 page tables for 0-8M instead of 1 page table for 0-4M. So, we still cannot boot a bzImage more than 2.5M which roughly corresponds to 8M. Is this incorrect? Are you saying I should be able to boot a bzImage corresponding to an ELF object vmlinux of 4G or more?

I tried it and it failed (a few weeks ago) so at least reasonably recently what you are saying was not true. I will now check if it suddenly became true now.

Regards,
Tigran

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

Tigran Aivazian

2000-11-11 11:37 UTC #10 lore raw

Quoted 15 lines · Tigran Aivazian

Quoted 7 lines · H. Peter Anvin
Quoted 4 lines
On x86 machines there is a size limitation on booting. Though I thought it was 1024K as the max, 900K should be fine.
No, there isn't. There used to be, but it has been fixed.
Are you sure? I thought the fix was to build 2 page tables for 0-8M instead of 1 page table for 0-4M. So, we still cannot boot a bzImage more than 2.5M which roughly corresponds to 8M. Is this incorrect? Are you saying I should be able to boot a bzImage corresponding to an ELF object vmlinux of 4G or more?

Quoted 3 lines

I tried it and it failed (a few weeks ago) so at least reasonably recently what you are saying was not true. I will now check if it suddenly became true now.

Just to clarify -- I always eat words on the first round -- of course I know that there is no limit at 1M, that is obvious -- what I do _not_ know if there is no limit at 2.5M -- this is non-obvious and requires proof.

Regards,
Tigran

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

Max Inux

2000-11-11 11:42 UTC #11 lore raw

May I recomend a read of Documentation/i386/boot.txt, it explains exactly what is done

Protocol 2.02: (Kernel 2.4.0-test3-pre3) New command line protocol.
Lower the conventional memory ceiling. No overwrite of the traditional setup area, thus making booting safe for systems which use the EBDA from SMM or 32-bit BIOS entry points. zImage deprecated but still supported.

2.01 may have had the issue you speak of, looks like this fixes it.

William Tiemann
<[email protected]>
http://www.OpenPGP.Net

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

H. Peter Anvin

2000-11-11 20:10 UTC #12 lore raw

Quoted 16 lines · Tigran Aivazian

Quoted 7 lines · H. Peter Anvin
Quoted 4 lines
On x86 machines there is a size limitation on booting. Though I thought it was 1024K as the max, 900K should be fine.
No, there isn't. There used to be, but it has been fixed.
Are you sure? I thought the fix was to build 2 page tables for 0-8M instead of 1 page table for 0-4M. So, we still cannot boot a bzImage more than 2.5M which roughly corresponds to 8M. Is this incorrect? Are you saying I should be able to boot a bzImage corresponding to an ELF object vmlinux of 4G or more?

Quoted 4 lines

I tried it and it failed (a few weeks ago) so at least reasonably recently what you are saying was not true. I will now check if it suddenly became true now.

That wasn't the fix in question (there was a 1 MB *compressed* limit for a while), but you're right, for now the limit is 8 MB *uncompressed.*

-hpa

Signature · 7 lines

<[email protected]> at work, <[email protected]> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

Andrea Arcangeli

2000-11-12 16:22 UTC #13 lore raw

Quoted 1 line · H. Peter Anvin

a while), but you're right, for now the limit is 8 MB *uncompressed.*

s/8/7/ (kernel starts at 1M)

Andrea
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

Andrea Arcangeli

2000-11-11 14:42 UTC #14 lore raw

In reply to Andrea Arcangeli

Quoted 1 line · Tigran Aivazian

Are you sure? I thought the fix was to build 2 page tables for 0-8M

Paging is disabled at that point.

Andrea
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

Tigran Aivazian

2000-11-11 14:51 UTC #15 lore raw

Quoted 5 lines · Andrea Arcangeli

Quoted 1 line · Tigran Aivazian
Are you sure? I thought the fix was to build 2 page tables for 0-8M
Paging is disabled at that point.

Yes, Andrea, I know that paging is disabled at the point of loading the image but I was talking about the inability to boot (boot == complete booting, i.e. at least reach start_kernel()) a kernel with very large .data or .bss segments because of various reasons -- one of which, probably,is the inadequacy of those pg0 and pg1 page tables set up in head.S

So, what is still a bit unclear is -- if the only way to create a huge bzImage is by having huge .text or .data or .bss, what is the combination of the limits? I.e. which limit do we hit first -- the one on bzImage (which Peter says is infinite?) or the ones on .text/.data/.bss (and what exactly are they?)? See my question now?

Regards,
Tigran

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

Andrea Arcangeli

2000-11-11 16:26 UTC #16 lore raw

Quoted 6 lines · Tigran Aivazian

Yes, Andrea, I know that paging is disabled at the point of loading the image but I was talking about the inability to boot (boot == complete booting, i.e. at least reach start_kernel()) a kernel with very large .data or .bss segments because of various reasons -- one of which, probably,is the inadequacy of those pg0 and pg1 page tables set up in head.S

Ah ok, I thought you were talking about bootloader.

About the initial pagetable setup on i386 port there's certainly a 3M limit on the size of the kernel image, but it's trivial to enlarge it. BTW, exactly for that kernel size limit reasons in x86-64 I defined a 40Mbyte mapping where we currently have a 4M mapping and that's even simpler to enlarge since they're 2M PAE like pagetables.

Basically as far as the kernel can get loaded in memory correctly we have no problem :)

Quoted 2 lines

(which Peter says is infinite?) or the ones on .text/.data/.bss (and what exactly are they?)? See my question now?

We sure hit the 3M limit on the .bss clearing right now.

Andrea
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

Tigran Aivazian

2000-11-11 16:46 UTC #17 lore raw

Quoted 16 lines · Andrea Arcangeli

Quoted 6 lines · Tigran Aivazian
Yes, Andrea, I know that paging is disabled at the point of loading the image but I was talking about the inability to boot (boot == complete booting, i.e. at least reach start_kernel()) a kernel with very large .data or .bss segments because of various reasons -- one of which, probably,is the inadequacy of those pg0 and pg1 page tables set up in head.S
Ah ok, I thought you were talking about bootloader.
About the initial pagetable setup on i386 port there's certainly a 3M limit on the size of the kernel image, but it's trivial to enlarge it. BTW, exactly for that kernel size limit reasons in x86-64 I defined a 40Mbyte mapping where we currently have a 4M mapping and that's even simpler to enlarge since they're 2M PAE like pagetables.

Quoted 8 lines

Basically as far as the kernel can get loaded in memory correctly we have no problem :)
Quoted 2 lines
(which Peter says is infinite?) or the ones on .text/.data/.bss (and what exactly are they?)? See my question now?
We sure hit the 3M limit on the .bss clearing right now.

I understand and agree with what you say except the number 4M. It is not 4M but 8M, imho. See arch/i386/kernel/head.S

/*
* The page tables are initialized to only 8MB here - the final page
* tables are set up later depending on memory size.
*/
.org 0x2000
ENTRY(pg0)

.org 0x3000
ENTRY(pg1)

/*
* empty_zero_page must immediately follow the page tables ! (The
* initialization loop counts until empty_zero_page)
*/

.org 0x4000
ENTRY(empty_zero_page)

(the comment next to pg0 in asm/pgtable.h is misleading, whilst the comment above paging_init() is plain wrong -- I sent a patch to Linus yesterday but perhaps "wrong comment" is not a critical 2.4 issue :)

Regards,
Tigran

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

Eric W. Biederman

2000-11-11 20:19 UTC #18 lore raw

Quoted 12 lines · Tigran Aivazian

Quoted 10 lines · Andrea Arcangeli
Quoted 6 lines · Tigran Aivazian
Yes, Andrea, I know that paging is disabled at the point of loading the image but I was talking about the inability to boot (boot == complete booting, i.e. at least reach start_kernel()) a kernel with very large .data or .bss segments because of various reasons -- one of which, probably,is the inadequacy of those pg0 and pg1 page tables set up in head.S
Ah ok, I thought you were talking about bootloader.

Quoted 19 lines

Quoted 3 lines
About the initial pagetable setup on i386 port there's certainly a 3M limit on
the size of the kernel image, but it's trivial to enlarge it. BTW, exactly
for
Quoted 2 lines
that kernel size limit reasons in x86-64 I defined a 40Mbyte mapping where we currently have a 4M mapping and that's even simpler to enlarge since they're
2M
Quoted 10 lines
PAE like pagetables.
Basically as far as the kernel can get loaded in memory correctly we have no problem :)
Quoted 2 lines
(which Peter says is infinite?) or the ones on .text/.data/.bss (and what exactly are they?)? See my question now?
We sure hit the 3M limit on the .bss clearing right now.

With respect to .bss issues we should clear it before we set up page tables. That way we have no hardlimit short of 4GB which.

We also do stupid things like set segment registers before setting up a GDT. Yes we set them in setup.S but it is still a stupid non-obvious dependency. We we can do it in setup.S

Eric
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

Andrea Arcangeli

2000-11-12 11:30 UTC #19 lore raw

Quoted 1 line · Eric W. Biederman

With respect to .bss issues we should clear it before we set up page tables.

We could sure do that but that's a minor win since we still need a large mapping (more than 1 pagetable) for the bootmem allocator. (and we need at least 1 pagetable setup as ident mapping at 0x100000 for the instruction where we enable paging)

Quoted 2 lines

We also do stupid things like set segment registers before setting up a GDT. Yes we set them in setup.S but it is still a stupid non-obvious

		     ^^^^

I think you meant: we set "it" (gdt_48) up.

Quoted 1 line

dependency. We we can do it in setup.S

I removed that dependency in x86-64.

Andrea
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

Eric W. Biederman

2000-11-12 13:23 UTC #20 lore raw

Quoted 8 lines · Andrea Arcangeli

Quoted 1 line · Eric W. Biederman
With respect to .bss issues we should clear it before we set up page tables.
We could sure do that but that's a minor win since we still need a large mapping (more than 1 pagetable) for the bootmem allocator. (and we need at least 1 pagetable setup as ident mapping at 0x100000 for the instruction where we enable paging)

Quoted 4 lines

Quoted 2 lines
We also do stupid things like set segment registers before setting up a GDT. Yes we set them in setup.S but it is still a stupid non-obvious
		     ^^^^
I think you meant: we set "it" (gdt_48) up.

I was thinking segment descriptors.

Quoted 4 lines

Quoted 2 lines
dependency. We we can do it in setup.S
I removed that dependency in x86-64.

Maniacal cackle....

x86-64 doesn't load the segment registers at all before use. This is BAD BAD BAD!!!!!!!
I can tell you don't have real hardware. The non obviousness of correct operation tripped you up as well.

So while you load the gdt before you set a segment register later, which is good the more important part was still missed.

O.k. on monday I'll dig up my patch and that clears this up.

Eric

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

Andrea Arcangeli

2000-11-12 15:37 UTC #21 lore raw

Quoted 1 line · Eric W. Biederman

x86-64 doesn't load the segment registers at all before use.

Yes, before switching to 64bit long mode we never do any data access. We do a stack access to clear eflags only while we still run in legacy mode with paging disabled and so we only rely on ss to be valid when the bootloader jumps at 0x100000 for executing the head.S code (and not anymore on the gdt_48 layout).

Quoted 1 line

I can tell you don't have real hardware. The non obviousness

Current code definitely works fine on the simnow simulator so if current code shouldn't work because it's buggy then at least the simulator is sure buggy as well (and that isn't going to be the case as its behaviour is in full sync with the specs as far I can see).

Quoted 2 lines

So while you load the gdt before you set a segment register later, which is good the more important part was still missed.

Sorry but I don't see the missing part. Are you sure you're not missing this part of the x86-64 specs?

Data and Stack Segments:

In 64-bit mode, the contents of the ES, DS, and SS segment registers are ignored. All fields (base, limit, and attribute) in the corresponding segment descriptor registers (hidden part) are also ignored.

Address calculations in 64-bit mode that reference the ES, DS, or SS segments, are treated as if the segment base is zero. Rather than perform limit checks, the processor instead checks that all virtual-address references are in canonical form.

You'll find the above at the top of page 42 of the specs.

Basically in 64bit long mode only CS matters and basically only to specify CS.L=1 and CS.D=0.

The only subtle case is during iret where we need a valid data segment for some subtle reason (but that's unrelated to head.S that instead only needs to switch to 64bit mode and jump into head64.c where we do the rest of the work like clearing bss in C). Infact we need only 1 32bit compatibility mode data segment in the gdt.

Quoted 1 line

O.k. on monday I'll dig up my patch and that clears this up.

Sure, go ahead if you weren't missing that basic part of the long mode specs. Thanks.

Andrea
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

Andi Kleen

2000-11-12 15:56 UTC #22 lore raw

Quoted 6 lines · Andrea Arcangeli

Quoted 1 line
I can tell you don't have real hardware. The non obviousness
Current code definitely works fine on the simnow simulator so if current code shouldn't work because it's buggy then at least the simulator is sure buggy as well (and that isn't going to be the case as its behaviour is in full sync with the specs as far I can see).

The current simulator seems to be buggy in that it checks the SS,DS segments that were pushed as part of the interrupt stack on iretd (which it IMHO shouldn't according to the spec). We currently need to have a valid kernel DS to make the interrupts work.

-Andi

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

Andrea Arcangeli

2000-11-12 16:33 UTC #23 lore raw

Quoted 2 lines · Andi Kleen

The current simulator seems to be buggy in that it checks the SS,DS segments that were pushed as part of the interrupt stack on iretd [..]

That's the first thing I thought too indeed 8), but it maybe because at iret time the CPU doesn't know if it will have to return to compatibility mode or not. If we feed the ss/ds with a 32bit compatibility mode data segment all should work right as well (this should be verified on the simulator though).

Andrea
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

Eric W. Biederman

2000-11-12 19:05 UTC #24 lore raw

Quoted 7 lines · Andrea Arcangeli

Quoted 1 line · Eric W. Biederman
x86-64 doesn't load the segment registers at all before use.
Yes, before switching to 64bit long mode we never do any data access. We do a stack access to clear eflags only while we still run in legacy mode with paging disabled and so we only rely on ss to be valid when the bootloader jumps at 0x100000 for executing the head.S code (and not anymore on the gdt_48 layout).

Nope you rely on cs & ds as well. cs is just a duh the codes running so it must be valid. But ds is needed for lgdt.

Quoted 1 line

Quoted 1 line
I can tell you don't have real hardware. The non obviousness

I need to retract this a bit. You are still building a compressed image, and the code in the boot/compressed/head.S remains unchanged and loads segment registers, so it works by luck. If you didn't build a compressed image you would be in trouble.

Quoted 4 lines

Current code definitely works fine on the simnow simulator so if current code shouldn't work because it's buggy then at least the simulator is sure buggy as well (and that isn't going to be the case as its behaviour is in full sync with the specs as far I can see).

Add a target for a noncompressed image and then build. It should be interesting to watch.

Quoted 6 lines

Quoted 3 lines
So while you load the gdt before you set a segment register later, which is good the more important part was still missed.
Sorry but I don't see the missing part. Are you sure you're not missing this part of the x86-64 specs?

Nope because what I was complaining about is in 32 bit mode. :)

Quoted 6 lines

Data and Stack Segments:
In 64-bit mode, the contents of the ES, DS, and SS segment registers are ignored. All fields (base, limit, and attribute) in the corresponding segment descriptor registers (hidden part) are also ignored.

Hmm. I'll have to look and see if FS & GS are also ignored.

Quoted 4 lines

Address calculations in 64-bit mode that reference the ES, DS, or SS segments, are treated as if the segment base is zero. Rather than perform limit checks, the processor instead checks that all virtual-address references are in canonical form.

Cool I like this bit. The segments are finally dead.

Quoted 4 lines

Quoted 1 line
O.k. on monday I'll dig up my patch and that clears this up.
Sure, go ahead if you weren't missing that basic part of the long mode specs. Thanks.

Nope. Though I suspect we should do the switch to 64bit mode in setup.S and not have these issues pollute head.S at all.

Eric

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

Eric W. Biederman

2000-11-12 19:28 UTC #25 lore raw

Quoted 7 lines · Andrea Arcangeli

Quoted 1 line · Eric W. Biederman
x86-64 doesn't load the segment registers at all before use.
Yes, before switching to 64bit long mode we never do any data access. We do a stack access to clear eflags only while we still run in legacy mode with paging disabled and so we only rely on ss to be valid when the bootloader jumps at 0x100000 for executing the head.S code (and not anymore on the gdt_48 layout).

Actually it just occurred to me that this stack assess is buggy. You haven't set up a stack yet so. Only the boot/compressed/head.S did and that location isn't safe to use.

Eric
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

Andi Kleen

2000-11-12 19:34 UTC #26 lore raw

[This is quite a bizarre discussion, but I'll answer anyways. I am not exactly sure what your point is]

Quoted 7 lines · Eric W. Biederman

Quoted 2 lines
Quoted 2 lines
I can tell you don't have real hardware. The non obviousness
I need to retract this a bit. You are still building a compressed image, and the code in the boot/compressed/head.S remains unchanged and loads segment registers, so it works by luck. If you didn't build a compressed image you would be in trouble.

boot/compressed/head.S does run in 32bit legacy mode, where you of course need segment registers. After you got into long mode segments are only needed to jump between 32/64bit code segments and and for a the data segment of the 32bit emulation (+ the iretd bug currently which I hope will be fixed in final hardware)

Also note that boot/compressed/* currently does not even link, because the x86-64 toolchain cannot generate relocated 32bit code ATM (the linker chokes on the 32bit relocations) The tests we did so far used a precompiled relocated binary compressed/{head,misc}.o from a IA32 build.

Quoted 6 lines

Quoted 4 lines
In 64-bit mode, the contents of the ES, DS, and SS segment registers are ignored. All fields (base, limit, and attribute) in the corresponding segment descriptor registers (hidden part) are also ignored.
Hmm. I'll have to look and see if FS & GS are also ignored.

They are not, you to fully use them you need privileged MSRs. Their limit is ignored.

Quoted 5 lines

Quoted 2 lines
Sure, go ahead if you weren't missing that basic part of the long mode specs. Thanks.
Nope. Though I suspect we should do the switch to 64bit mode in setup.S and not have these issues pollute head.S at all.

I see no advantage in doing it there instead of in head.S

-Andi
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

Andrea Arcangeli

2000-11-12 22:31 UTC #27 lore raw

Quoted 2 lines · Eric W. Biederman

Nope you rely on cs & ds as well. cs is just a duh the codes running so it must be valid. But ds is needed for lgdt.

Right. The ds just needs to be valid as cs and ss needs to be valid as well (for obvious reasons I didn't even mentioned cs needs to be valid). i386 instead has the dependency to have the selectors in desc.h to be the same as used by the decompression code, we only need valid ones instead. I think relying on the decompression code to provide sane segment selectors isn't as ugly as being dependent on its own private gdt layout.

If I don't want to rely on the ds to be valid to do the lgdt, then I need to rely on even more stuff dependent on the decompression as i386 does infact, see? I just prefer to require the decompression code to provide a sane ds/ss (and cs). I know decompression code returns valid ds/ss and I think current requirement is the cleaner one and I don't see any problem in doing that.

Quoted 1 line

I need to retract this a bit. You are still building a compressed image,

Sure, not compressed images aren't supported (not sure it even worth to support uncompressed images in the long run as those machines will have _enough_ memory to decompress the kernel, even my dragonball based PDA has btw :). And anyways at this point in time what we really care is that a bzImage boots from floppy at the moment and that works just fine (definitely not by luck).

Quoted 2 lines

Nope. Though I suspect we should do the switch to 64bit mode in setup.S and not have these issues pollute head.S at all.

Only point of head.S is to switch to 64bit with minimal pagetable setup in place and then to jump in kernel virtual address space to run 64bit C code.

If we do the switch to 64bit in setup.S then we have to change the decompression code and then the decompression code wouldn't work anymore with other x86 bootloaders that are not been changed in their "setup.S". So I'd cosndier it a very bad thing.

Also current head.S has much less pollution than the i386 one IMHO as it's been rewritten to do only the minimal stuff in asm and a new head64.c is been created to fixup all the rest in C so that's readable and maintainable and I hope you enjoy this too ;).

Andrea
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

Andrea Arcangeli

2000-11-12 23:03 UTC #28 lore raw

Quoted 2 lines · Eric W. Biederman

Actually it just occurred to me that this stack assess is buggy. You haven't set up a stack yet so. [..]

Yes, ss and esp are inherit from the decompression code right now.

Quoted 2 lines

[..] Only the boot/compressed/head.S did and that location isn't safe to use.

It's 0x90000 here and that's safe. However I see it should been something like 0x1037a0 instead and it would overwrite 4 bytes of decompressed image, not sure why it happens to be safe right now hmm.

About ss I'd still depend on the decompression code to give back the sane segmented environment.

Andrea
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

Eric W. Biederman

2000-11-16 20:01 UTC #29 lore raw

In reply to Andrea Arcangeli

Quoted 2 lines · Andi Kleen

[This is quite a bizarre discussion, but I'll answer anyways. I am not exactly sure what your point is]

Let me step aside a second and explain where I'm coming from. As a spin off of the work of the linuxBIOS project I have implemented a system call that implements exec functionality at the kernel level. Essentially allowing you to warm boot linux from linux. To get this to work no bios calls are involved, so I'm not using setup.S. This also has the interesting side effect of allowing a boot loader to be written that will work on all linux platforms. (I have currently just begun my port to alpha).

In the process of the above I have learned quite a bit about how the current boot loader works. And want eventually to convert linux to not need wrapper code to use my bootloader.

Booting vmlinux is fun :)

Quoted 19 lines · Eric W. Biederman

Quoted 7 lines
Quoted 2 lines
Quoted 2 lines
I can tell you don't have real hardware. The non obviousness
I need to retract this a bit. You are still building a compressed image, and the code in the boot/compressed/head.S remains unchanged and loads segment registers, so it works by luck. If you didn't build a compressed image you would be in trouble.
boot/compressed/head.S does run in 32bit legacy mode, where you of course need segment registers. After you got into long mode segments are only needed to jump between 32/64bit code segments and and for a the data segment of the 32bit emulation (+ the iretd bug currently which I hope will be fixed in final hardware)
Also note that boot/compressed/* currently does not even link, because the x86-64 toolchain cannot generate relocated 32bit code ATM (the linker chokes on the 32bit relocations) The tests we did so far used a precompiled relocated binary compressed/{head,misc}.o from a IA32 build.

...

Quoted 9 lines

Quoted 1 line
Quoted 1 line
Sure, go ahead if you weren't missing that basic part of the long mode
specs.
Quoted 4 lines
Quoted 1 line
Thanks.
Nope. Though I suspect we should do the switch to 64bit mode in setup.S and not have these issues pollute head.S at all.
I see no advantage in doing it there instead of in head.S

After reading through the long mode specs I now agree. If you could be in long mode with the mmu disabled that would be a different story but you can't and it isn't.

I was thinking of symmetry with the x86 and how much easier everything is if you only use one processor mode for the initial boot strap. No need for super assemblers etc. Oh well.

On x86 there are some real advantages to moving the segment loads into setup.S from the various head.S's and they still apply (although to a lesser extent) to x86-64. This causes less code confusion.

For my kexec stuff I now need to think really hard how I want to handle x86-64. What I was thinking would work well in general is to start the processor it's native/optimal mode with the mmu disabled. With x86-64 I can't do this unfortunately :(

Eric
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

Andrea Arcangeli

2000-11-11 18:49 UTC #30 lore raw

Quoted 2 lines · Tigran Aivazian

I understand and agree with what you say except the number 4M. It is not 4M but 8M, imho. See arch/i386/kernel/head.S

You're reading 2.4.x, I was reading 2.2.x.

Andrea
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

Andrzej Krzysztofowicz

2000-11-11 16:12 UTC #31 lore raw

Quoted 7 lines

Quoted 2 lines · Max Inux
On x86 machines there is a size limitation on booting. Though I thought it was 1024K as the max, 900K should be fine.
No, there isn't. There used to be, but it has been fixed.
-hpa

Except the simple boot loader. You cannot boot kernel >=1024KB directly from floppy...

Andrzej
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

Jeff Garzik

2000-11-11 17:28 UTC #32 lore raw

Quoted 2 lines · Andrzej Krzysztofowicz

Except the simple boot loader. You cannot boot kernel >=1024KB directly from floppy...

That doesn't really matter much though... You have proceded beyond the 'simple' case. :)

You can always use a tiny bootloader like hpa's syslinux. I am currently typing on a kernel booted from a standard 3 1/2" floppy:

Quoted 7 lines

[jgarzik@rum linux_2_4]$ make bzImage
[...]
System is 1612 kB
[jgarzik@rum g]$ dmesg|less
[...]
Memory: 124388k/131060k available (2876k kernel code, 6284k reserved, 367k data, 448k init, 0k highmem)

(...with /dev/fd0u1722, 1.44M floppies becomes 1.722M floppies...)

Signature · 7 lines

Jeff Garzik             |
Building 1024           | Would you like a Twinkie?
MandrakeSoft            |
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

Werner Almesberger

2000-11-14 14:33 UTC #33 lore raw

BTW, the checks after line 153 in linux/arch/i386/boot/tools/build.c reflect all those limitations.

- Werner

Signature · 7 lines

  _________________________________________________________________________
 / Werner Almesberger, ICA, EPFL, CH           [email protected] /
/_IN_N_032__Tel_+41_21_693_6621__Fax_+41_21_693_6610_____________________/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

Chmouel Boudjnah

2000-11-11 05:29 UTC #34 lore raw

In reply to Max Inux

Quoted 3 lines · H. Peter Anvin

Quoted 2 lines
On x86 machines there is a size limitation on booting. Though I thought it was 1024K as the max, 900K should be fine.
No, there isn't. There used to be, but it has been fixed.

the main problem is for us distribution if we want to fit this on a disk with a couple of modules for our installation process.

Signature · 6 lines

MandrakeSoft Inc                     http://www.chmouel.org
                      --Chmouel
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

Peter Samuelson

2000-11-11 05:48 UTC #35 lore raw

[Robert Lynch]

Quoted 9 lines

I've been regularly building kernels in the testXX series, and they have been coming out ~ 600K; test10-final and test11-pre1:
(quoted diff) +0 -2
-rw-r--r--    1 root     root       610503 Oct 31 18:39 vmlinuz-t10
-rw-r--r--    1 root     root       610568 Nov  7 20:26 vmlinuz-t11p01
test11-pre2 comes out ~ 900K:
-rw-r--r-- 1 root root 926345 Nov 10 10:16 vmlinuz-t11p02

Track it down yourself:

1) The sizes of your two 'vmlinux' files: do they differ wildly as well?

2a) If no, check the make logs between the vmlinux link line and bzImage
creation. Compare the two and note any significant differences.

2b) If yes, write a perl script to compute symbol sizes from each
System.map file. (Symbol size == address of next symbol minus address of this symbol.) Sort numerically, then compare old vs new for symbols that have grown a lot, or large new symbols.

Peter
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

Andi Kleen

2000-11-11 14:30 UTC #36 lore raw

Quoted 4 lines · Peter Samuelson

2b) If yes, write a perl script to compute symbol sizes from each
System.map file. (Symbol size == address of next symbol minus address of this symbol.) Sort numerically, then compare old vs new for symbols that have grown a lot, or large new symbols.

No need to write one: ftp.firstfloor.org:/pub/ak/perl/bloat-o-meter

-Andi
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

Thomas K�hler

2000-11-11 15:46 UTC #37 lore raw

Quoted 8 lines · Andi Kleen

Quoted 4 lines · Peter Samuelson
2b) If yes, write a perl script to compute symbol sizes from each
System.map file. (Symbol size == address of next symbol minus address of this symbol.) Sort numerically, then compare old vs new for symbols that have grown a lot, or large new symbols.
No need to write one: ftp.firstfloor.org:/pub/ak/perl/bloat-o-meter

Would be good if you added a notice under which licence you put all these nice perl scripts... Are they GPL'ed? Under a BSD-style licence? Something else?

Quoted 1 line

-Andi

CU,
Thomas

Signature · 4 lines

 Thomas Köhler Email:   [email protected]     | LCARS - Linux
     <><        WWW:     http://jeanluc-picard.de      | for Computers
                IRC:             jeanluc               | on All Real
               PGP public key available from Homepage! | Starships

Robert Lynch

author

2000-11-11 18:06 UTC #38 lore raw

Quoted 7 lines · Peter Samuelson

Quoted 6 lines · [Robert Lynch]
I've been regularly building kernels in the testXX series, and they have been coming out ~ 600K; test10-final and test11-pre1:
(quoted diff) +0 -2
-rw-r--r--    1 root     root       610503 Oct 31 18:39 vmlinuz-t10
-rw-r--r--    1 root     root       610568 Nov  7 20:26 vmlinuz-t11p01

Quoted 7 lines

Quoted 3 lines
test11-pre2 comes out ~ 900K:
-rw-r--r-- 1 root root 926345 Nov 10 10:16 vmlinuz-t11p02
Track it down yourself:
1) The sizes of your two 'vmlinux' files: do they differ wildly as well?

Wildly; compare test11-pre1 and testll-pre2 sizes:

-rwxr-xr-x 1 root root 1789457 Nov 7 20:26
vmlinux-t11p01
-rwxr-xr-x 1 root root 2625016 Nov 10 10:15
vmlinux-t11p02

Quoted 9 lines

2a) If no, check the make logs between the vmlinux link line and bzImage
creation. Compare the two and note any significant differences.
2b) If yes, write a perl script to compute symbol sizes from each
System.map file. (Symbol size == address of next symbol minus address of this symbol.) Sort numerically, then compare old vs new for symbols that have grown a lot, or large new symbols.
Peter

Whence Andi Kleen chipped in:

Quoted 3 lines

No need to write one: ftp.firstfloor.org:/pub/ak/perl/bloat-o-meter
-Andi

Running:

perl bloat-o-meter /boot/vmlinux-t11p01 /boot/vmlinux-t11p02 > /tmp/bloat.out

looking at the output, the large positive changes seem to be (doing it by eye, might have skipped and/or missed something):

Symbol Old size New size Delta Change (%)

slabinfo_write_proc                  8      340     332  +4150.0
show_buffers                        24      368     344  +1433.3
sys_nfsservctl                      80     1060     980  +1225.0
dump_extended_fpu                    8       84      76  +950.00
get_fpregs                          36      372     336  +933.33
schedule_tail                       16      144     128  +800.00 
set_fpregs                          36      272     236  +655.56
tty_release                         16      108      92  +575.00
ext2_write_inode                    20      108      88  +440.00

...

I have surpressed my momentary urge to post the whole thing, so as not to arouse the legendary ire of this list. :)

Bob L.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

Andi Kleen

2000-11-11 18:30 UTC #39 lore raw

Quoted 11 lines · Robert Lynch

sys_nfsservctl                      80     1060     980  +1225.0
dump_extended_fpu                    8       84      76  +950.00
get_fpregs                          36      372     336  +933.33
schedule_tail                       16      144     128  +800.00 
set_fpregs                          36      272     236  +655.56
tty_release                         16      108      92  +575.00
ext2_write_inode                    20      108      88  +440.00

...

I have surpressed my momentary urge to post the whole thing, so as not to arouse the legendary ire of this list. :)

Ordering by byte delta is more useful than by Change to get the real pigs, because Change gives high values even for relatively small changes (like 8 -> 84)

Also note that some of the output is bogus due to inaccurate nm output (bloat-o-meter relies on nm)

-Andi
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

Robert Lynch

author

2000-11-11 18:58 UTC #40 lore raw

Quoted 14 lines · Andi Kleen

Quoted 11 lines · Robert Lynch

sys_nfsservctl                      80     1060     980  +1225.0
dump_extended_fpu                    8       84      76  +950.00
get_fpregs                          36      372     336  +933.33
schedule_tail                       16      144     128  +800.00
set_fpregs                          36      272     236  +655.56
tty_release                         16      108      92  +575.00
ext2_write_inode                    20      108      88  +440.00

...

I have surpressed my momentary urge to post the whole thing, so as not to arouse the legendary ire of this list. :)

Quoted 8 lines

Ordering by byte delta is more useful than by Change to get the real pigs, because Change gives high values even for relatively small changes (like 8 -> 84)
Also note that some of the output is bogus due to inaccurate nm output (bloat-o-meter relies on nm)
-Andi

Yer right, here's a biggie I missed:

stext_lock 4344 29395 25051 +576.68

Bob L.

Signature · 5 lines

Robert Lynch-Berkeley CA [email protected]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

Andi Kleen

2000-11-11 20:36 UTC #41 lore raw