| >> 3) The SPD for V6.2-1H3 states that VMS doesn't support dumping more
>> than 4GB of memory. Does this mean that there is a 4GB memory
>> limit for V6.2-1H3 or is this just for Full Dumps.
>
> That's indeed what the SPD says, but I don't know why.
Yes indeed, and ehere's the reason:
BUGCHECK uses the bootdriver to perform its I/O. Bootdrivers use a data
structure that defines the virtual address and size of the buffer,,
plus the physical address and size (typeically a page!) of each
fragment of the buffer.
Now the size of each field in this structure is a longword, so
addresses and sizes can't exceed 4GB. Sizes aren't a problem, since
I/Os are done by BUGCHECK in 128-block segments.
The VA is never a problem either, as BUGCHECK has some PTEs reserved at
boot time that give it addresses in S0/S1 space. It's just the PA that
hurts.
Now different bootdrivers use different parts of this data structure.
CNBTDRIVER (the most common) uses the VA, so 4GB is not a problem
there. KDMBTDRIVER uses the PA, so your dump isn't going to be much
use.
When those words were put into the SPD, it was late in the day for
V6.2, and all I knew was that dumps over 4GB were broken. I didn't then
know exactly which combinations of full vs selective and bootdriver
gave or avoided the problem. For safety's sake, we simply said none
were supported (but like many things we say aren't supported, YMMV).
In V7.1, I changed BUGCHECK to handle systems over 4GB by copying all
data to a buffer that I knew was below 4GB and writing it from there.
Later in the V7.1 development cycle, as DOSD was being designed, we
were able to define the exact combination of dumps and drivers that hit
the problem, hence today I can sound like I know what I'm talking
about.
In a future release, the bootdrivers will be changed to pass 64 bits of
address around, since new platforms with discontiguous memory could
exist with *no* memory below 4GB. At that time, BUGCHECK will take
advantage of those changes.
Richard Bishop
OpenVMS Alpha BUGCHECK/SDA maintainer
ps: I don't normally frequent this conference (Steve H. forwarded the
base note to me.) So if my answer raises more questions, someone will
need to alert me. :-)
|