Subject: Re: memory, booting, etc..
To: None <firstname.lastname@example.org.Hawaii.Edu>
From: Niklas Hallqvist <email@example.com>
Date: 03/11/1994 10:26:45
>>>>> "Tim" == newsham <firstname.lastname@example.org.Hawaii.Edu> writes:
Tim> I have NetBSD running on a system with 5megs of 32 wide ram and
Tim> 4 megs of 16 wide ram. My machine does alot of swapping since in
Tim> BSD it can only use 5 megs and I've decided since no one else is
Tim> working at getting BSD to use non-contiguous memory I'd give it a
A couple of days ago Chris stated that "everyone" is waiting for a
new pmap module from the hp300 guys. Maybe they address this problem.
Chris, where do these guys keep their discussions? On a m68k-list?
On a hp300-list? I haven't seen anything on current-users...
If your 16-bit memory is autoconfig, and you remove 1MB it ought to
be possible to use mergemem to get 8MB of contiguous memory, thus
diminishing the demand for non-contigous mem-support. But, if you
really want to do something to the pmap module, please go ahead.
It's fun being a kernel hacker...
Tim> When I was using just 16 bit ram there was a bug that came up
Tim> while using gcc that was attributed to the 16 bit ram. More
Tim> recently I remember some discussion about certain operations on
Tim> 16-bit ram on GVP devices across page boundaries or at odd
Tim> byte-addresses. Has this problem been resolved yet? I suppose
Tim> there is little use in using 16-bit ram if its going to start
Tim> breaking things.
You did not state if you were using a GVP accelerator, but I guess
you are as you've seen the bug. I don't know of any generic 16-bit
memory bug, but only of the GVP accelerator-induced one. All programs
that does 24-bit wide bit-field handling on odd adresses suffers from
this. For the moment I know only of two: "as" and "emacs". I've run
quite a lot with merged memory the last week in order to find out what
the problem is, and so far, these two programs are the only ones that
fail. There's rumours from Chris Hooper and Russ Miranda that it's
a broken GVP PAL on early GVP DPRC-equipped accelerators which bite
AMIX-users, which makes sense when I look at my results. AmigaDOS
never pagefaults and almost never use '030 bitfield ops. AMIX does
and NetBSD does. The rumour said that GVP offered PAL upgrades for
a nominal fee. I'm investigating this now with the swedish dealer.
I'll get back, and will report what I find out.
I'll leave your other questions for someone better suitable to
answer such questions. I'm not totally ignorant of the issues
but then again, I'm definitely not good enough to provide you
with full (or even fully correct) information.
PS. Noone has answered how I in trap() can make a memory
reference to a page mapped in user-space (i.e. I know
the user-space VA, but I guess the data is mapped elsewhere,
or not at all, in the traphandler). Anyone?