Andi Kleen <[EMAIL PROTECTED]> writes:
> [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 th
BTW, the checks after line 153 in linux/arch/i386/boot/tools/build.c
reflect all those limitations.
- Werner
--
_
/ Werner Almesberger, ICA, EPFL, CH [EMAIL PROTECTED] /
/_IN_N_032__Tel_+41_21_693_6621__Fax_+41
On Sun, Nov 12, 2000 at 12:20:19PM -0700, Eric W. Biederman wrote:
> 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.
> [..] Only the boot/compressed/head.S did and that
On Sun, Nov 12, 2000 at 11:57:15AM -0700, Eric W. Biederman wrote:
> 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 e
[This is quite a bizarre discussion, but I'll answer anyways. I am not exactly
sure what your point is]
On Sun, Nov 12, 2000 at 11:57:15AM -0700, Eric W. Biederman wrote:
>
> > > I can tell you don't have real hardware. The non obviousness
>
> I need to retract this a bit. You are still build
Andrea Arcangeli <[EMAIL PROTECTED]> writes:
> On Sun, Nov 12, 2000 at 06:14:36AM -0700, Eric W. Biederman wrote:
> > 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
Andrea Arcangeli <[EMAIL PROTECTED]> writes:
> On Sun, Nov 12, 2000 at 06:14:36AM -0700, Eric W. Biederman wrote:
> > 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
On Sun, Nov 12, 2000 at 04:44:17PM +0100, Andi Kleen wrote:
> 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
On Sat, Nov 11, 2000 at 12:09:41PM -0800, H. Peter Anvin wrote:
> 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]
Plea
On Sun, Nov 12, 2000 at 04:37:05PM +0100, Andrea Arcangeli wrote:
> > 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
>
On Sun, Nov 12, 2000 at 06:14:36AM -0700, Eric W. Biederman wrote:
> 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
Andrea Arcangeli <[EMAIL PROTECTED]> writes:
> On Sat, Nov 11, 2000 at 12:35:46PM -0700, Eric W. Biederman wrote:
> > 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 p
On Sat, Nov 11, 2000 at 12:35:46PM -0700, Eric W. Biederman wrote:
> 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 lea
On Sat, Nov 11, 2000 at 10:57:20AM -0800, Robert Lynch wrote:
> Andi Kleen wrote:
> >
> > On Sat, Nov 11, 2000 at 10:03:35AM -0800, Robert Lynch wrote:
> > > sys_nfsservctl 80 1060 980 +1225.0
> > > dump_extended_fpu8 84 76 +950.00
> >
Tigran Aivazian <[EMAIL PROTECTED]> writes:
> On Sat, 11 Nov 2000, Andrea Arcangeli wrote:
>
> > On Sat, Nov 11, 2000 at 02:51:21PM +, Tigran Aivazian wrote:
> > > Yes, Andrea, I know that paging is disabled at the point of loading the
> > > image but I was talking about the inability to boo
Tigran Aivazian wrote:
>
> On Fri, 10 Nov 2000, H. Peter Anvin wrote:
> > >
> > > 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
Max Inux wrote:
>
> >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?)
>
b is "big". They are both gzip compres
Andi Kleen wrote:
>
> On Sat, Nov 11, 2000 at 10:03:35AM -0800, Robert Lynch wrote:
> > sys_nfsservctl 80 1060 980 +1225.0
> > dump_extended_fpu8 84 76 +950.00
> > get_fpregs 36 372 336 +933.33
> > sc
On Sat, Nov 11, 2000 at 04:46:09PM +, Tigran Aivazian wrote:
> 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
On Sat, Nov 11, 2000 at 10:03:35AM -0800, Robert Lynch wrote:
> sys_nfsservctl 80 1060 980 +1225.0
> dump_extended_fpu8 84 76 +950.00
> get_fpregs 36 372 336 +933.33
> schedule_tail
Peter Samuelson wrote:
> [Robert Lynch] wrote:
> > I've been regularly building kernels in the testXX series, and
> > they have been coming out ~ 600K; test10-final and test11-pre1:
> >
> > -rw-r--r--1 root root 610503 Oct 31 18:39 vmlinuz-t10
> > -rw-r--r--1 root root
Andrzej Krzysztofowicz wrote:
> 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
On Sat, 11 Nov 2000, Andrea Arcangeli wrote:
> On Sat, Nov 11, 2000 at 02:51:21PM +, Tigran Aivazian wrote:
> > 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 st
On Sat, Nov 11, 2000 at 02:51:21PM +, Tigran Aivazian wrote:
> 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
> Max Inux wrote:
> > 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
On Sat, Nov 11, 2000 at 03:30:36PM +0100,
Andi Kleen <[EMAIL PROTECTED]> wrote:
>
> On Fri, Nov 10, 2000 at 11:47:50PM -0600, Peter Samuelson wrote:
> > 2b) If yes, write a perl script to compute symbol sizes from each
> > System.map file. (Symbol size == address of next symbol minus
> >
On Sat, 11 Nov 2000, Andrea Arcangeli wrote:
> On Sat, Nov 11, 2000 at 11:36:00AM +, Tigran Aivazian wrote:
> > 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 th
On Sat, Nov 11, 2000 at 11:36:00AM +, Tigran Aivazian wrote:
> 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]
On Fri, Nov 10, 2000 at 11:47:50PM -0600, Peter Samuelson wrote:
> 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
On Sat, 11 Nov 2000, Max Inux wrote:
> >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?)
Neither. They are both c
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
On Sat, 11 Nov 2000, Tigran Aivazian wrote:
> On Fri, 10 Nov 2000, H. Peter Anvin wrote:
> > >
> > > 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 fi
On Fri, 10 Nov 2000, H. Peter Anvin wrote:
> >
> > 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 pag
On Sat, Nov 11, 2000 at 03:27:36AM -0800, Max Inux wrote:
> >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?)
IMH
Mike Harris corrected me, which puts life back where it started reading
other replies. bzimage = Big zImage removing the 640K limitation. I
have not upgraded to 2.4.0-test11-pre2 from test10, when I do I will see
if I get simmilar results.
Sorry,
William Tiemann
<[EMAIL PROTECTED]>
http://www.O
>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?)
>> On x86 machines there is a size limitation on booting. Though I tho
[Robert Lynch]
> I've been regularly building kernels in the testXX series, and
> they have been coming out ~ 600K; test10-final and test11-pre1:
>
> -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
>
>
"H. Peter Anvin" <[EMAIL PROTECTED]> writes:
> > 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
Max Inux wrote:
>
> On 10 Nov 2000, H. Peter Anvin wrote:
> >Different compile options?
> >
> >Why is a 900K kernel unusable?
> >
> > -hpa
>
> My guess would be it not actually bzipping the kernel. Id run make
> bzImage again and making sure it is bzipping it.
>
gzip, actually. I can
On 10 Nov 2000, H. Peter Anvin wrote:
>Different compile options?
>
>Why is a 900K kernel unusable?
>
> -hpa
My guess would be it not actually bzipping the kernel. Id run make
bzImage again and making sure it is bzipping it.
On x86 machines there is a size limitation on booting. Though
Followup to: <[EMAIL PROTECTED]>
By author:Robert Lynch <[EMAIL PROTECTED]>
In newsgroup: linux.dev.kernel
>
> I've been regularly building kernels in the testXX series, and
> they have been coming out ~ 600K; test10-final and test11-pre1:
>
> -rw-r--r--1 root root 610503 Oct 3
I've been regularly building kernels in the testXX series, and
they have been coming out ~ 600K; test10-final and test11-pre1:
-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:
42 matches
Mail list logo
