On Thu, Apr 12, 2001 at 14:05:52 +0200, Paul Kranenburg wrote:

> > For /virtual-memory
> > 
> > existing                 00000000 00000000 80000000 
> >                          00000000 80000000 80000000 
> > 
> > available                00000000 fffff000 00001000 
> >                          00000000 00000000 f0000000 
> >                          00000000 f0040000 0ffa3000
> 
> Well, that's just dumb!  But.. is there anything in the boot programs
> that could have provoked the PROM to do this?
> 
> To quote from:
> 18 August, 1994 IEEE Draft Std P1275.1/D14a User interface extensions  
> 
> "5.2.6. Virtual address space and memory allocation 
> 
>  When a client program begins execution, an Open Firmware implementations use
>  of any virtual address space outside of the ranges 0xffd0.0000-0xffef.ffff
>  and 0xfe00.0000-0xfeff.ffff shall have ceased, except for the virtual
>  address space and associated memory that is allocated for the client
>  programs code and data, as specified in the client program header.
>  Subsequently, the Open Firmware implementation shall not allocate virtual
>  address space outside those ranges, except as needed for the execution of
>  subsequent client programs or as explicitly requested by a client program.
> "

Yes, I read that passage too.  However, the properties above are from
a "clean" box, freshly reset.  Anyway, its OF entry point (%o3 passed
on boot) is 0xf003.381c and that's way out of the range you quote from
the sparc supplement and is, obviously, an OF choice, not some side
effect from a client program.

All in all, JS1 seems to be a "transient" machine, so quirks like this
are not that surprising.  I have couple of Krups (JS10) but admins
scavenged memory from them and I can't find compatible DIMMs to check
what their OpenFirmware has.

SY, Uwe
-- 
uwe@ptc.spbu.ru                         |       Zu Grunde kommen
http://www.ptc.spbu.ru/~uwe/            |       Ist zu Grunde gehen