[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Problem installing Slink on UDB/Multia


On Fri, 14 May 1999, Nikita Schmidt wrote:

> On Thursday, 13 May, Nathan P. Hawkins III wrote:
> > 
> > On Fri, 14 May 1999, Martin Lucina wrote:
> > > Also note that SRM/aboot IIRC will eat a lot (4.5mb?) of memory.
> > 
> > Maybe some clever person with time on their hands will do something about
> > that. Seems to me that something more like SRM would be nice. For that
> > matter, what's wrong with actually using SRM itself?
> > 
> Itself - you mean, instead of SRM/aboot?  There is no difference.  Aboot
> is just a tiny layer which does not take up any resources once the control
> is passed to the kernel.

I guess I'm not really thrilled with MILO or ARC, and SRM seems to be the
best of the lot. ARC is horrible. MILO seems excessively stripped down.
- From what I have seen in the PALcode docs, I'm inclined to say that it can
and probably should be able to do a lot more than MILO does.

> To summarise briefly:
>  * SRM is not available on all platforms, neither is MILO.

Nor ARC.

>  * SRM eats much more memory than MILO.  On my machine, it's about 1.5 Mb
>    for SRM and slightly less than 0.5 Mb for MILO.  This is probably
>    irrelevant on these modern 256 Mb machines, but still makes me a bit
>    unhappy about the wasted memory.  Just think about it: you run Linux
>    for months non-stop, and what does it preserve so carefully all this
>    time in a far corner of its high-tech semiconductor memory?  OpenVMS
>    PALcode!

Good point. But I'm trading a little memory for being a lot more confident
that it will boot up without help. ARC+MILO kept getting stuck. I had a
UDB at a remote location that rebooted itself every once in a while.
(Hardware problem.) Then, the firmware would just sit there, until I drove
down there and manually straightened it out. Ram is cheap. Outages aren't. 

>  * SRM's PALcode is generally better than the MILO's one, although in
>    most cases this is not noticeable.  Three notable differences are:
>    - interrupt processing: MILO does not pass the interrupt vector to
>      the kernel, making kernel do more work;
>    - missing wrperfmon call in MILO prevents from using performance
>      measurement tools such as Iprobe;
>    - missing wtint call in MILO does not let Linux enter low-power CPU
>      mode in the idle loop.
>    SRM can also play highly platform-specific tricks in its PALcode.
>  * When booted from SRM, the kernel has to worry about saving/restoring
>    some parts of machine state.

If someone were actively developing MILO, most of these things could be
addressed by now, don't you think? I haven't seen any sign that anyone has
done anything with it for quite a while. Not if it's home is still on


Version: 2.6.3a
Charset: noconv


Reply to: