> Date: Mon, 15 Sep 2003 11:51:26 -0700 (PDT)
> From: Doug White <[EMAIL PROTECTED]>
> Sender: [EMAIL PROTECTED]
>
> On Mon, 15 Sep 2003, Irvine Short wrote:
>
> > Thanks for the definitive reply!
>
> You're quite welcome.
>
> > > > This is relevant to the work we're doing - some of my users ac
> However we have a situation where if I set MAXDSIZ to 2048 or above then
> things break, so FreeBSD right now has an effectivce limit of 2GB per
> process.
>
> Is this to be considered a bug or a feature?
It orta work above 2Gb, and has been known to work to about 3Gb. The fact that
tcsh is r
On Sun, 14 Sep 2003, Doug White wrote:
> > However we have a situation where if I set MAXDSIZ to 2048 or above then
> > things break, so FreeBSD right now has an effectivce limit of 2GB per
> > process.
> >
> > Is this to be considered a bug or a feature?
>
> I'd have to say feature. The kernel pl
On Mon, 15 Sep 2003, Irvine Short wrote:
> Yes, I understand that. What I am saying is, is that the general story out
> there is that with a 32 bit operatng system no process can address more
> than 4GB of RAM. Fine. David said that in FreeBSD I cannot in practicality
> address more than about 3GB
On Sun, 14 Sep 2003, Alex de Kruijff wrote:
> On Sat, Sep 13, 2003 at 03:48:21AM -0700, David G. Lawrence wrote:
> > > David Lawrence said:
> > > > Sorry, due to design issues, it isn't possible to have virtual sizes
> > > >larger than about 3GB on FreeBSD. This is because the kernel is mapped i
On Sat, Sep 13, 2003 at 03:48:21AM -0700, David G. Lawrence wrote:
> > David Lawrence said:
> > > Sorry, due to design issues, it isn't possible to have virtual sizes
> > >larger than about 3GB on FreeBSD. This is because the kernel is mapped in
> > >the upper part of the virtual address space. O
