Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 19 Sep 2004 00:08:50 +0200
From:      "Poul-Henning Kamp" <phk@phk.freebsd.dk>
To:        John Baldwin <jhb@FreeBSD.org>
Cc:        cvs-all@FreeBSD.org
Subject:   Re: cvs commit: src/sys/boot/i386/boot2 boot2.c 
Message-ID:  <15147.1095545330@critter.freebsd.dk>
In-Reply-To: Your message of "Sat, 18 Sep 2004 16:59:48 EDT." <200409181659.48310.jhb@FreeBSD.org> 

next in thread | previous in thread | raw e-mail | index | archive | help
In message <200409181659.48310.jhb@FreeBSD.org>, John Baldwin writes:
>On Saturday 18 September 2004 03:08 am, Poul-Henning Kamp wrote:
>> In message <200409180207.i8I27044010045@repoman.freebsd.org>, John Baldwin
>> writ
>>
>> es:
>> >jhb         2004-09-18 02:07:00 UTC
>> >
>> >  FreeBSD src repository
>> >
>> >  Modified files:
>> >    sys/boot/i386/boot2  boot2.c
>> >  Log:
>> >  A long, long time ago in a CVS branch far away (specifically, HEAD prior
>> >  to 4.0 and RELENG_3), the BTX mini-kernel used paging rather than flat
>> >  mode and clients were limited to a virtual address space of 16
>> > megabytes. Because of this limitation, boot2 silently masked all physical
>> > addresses in any binaries it loaded so that they were always loaded into
>> > the first 16 Meg.  Since BTX no longer has this limitation (and hasn't
>> > for a long time), remove the masking from boot2.  This allows boot2 to
>> > load kernels larger than about 12 to 14 meg (12 for non-PAE, 14 for PAE).
>>
>> Does this also give us better space for isa_dma bounce buffers ?
>
>Err, I don't see how it could.  This only affects how boot2 handles addresses 
>in the executables it loads, it doesn't affect how the kernel manages memory 
>at all.

it was the "so that they were always loaded into the first 16 Meg" that
triggered a neuron here.

We're seeing isa-dma bounce buffers getting hard to get hold of these
days.

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk@FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?15147.1095545330>