Don Williams wrote:

> Doing a fresh install of OSR 5.0.5. Tried 3 different mother boards and got
> the message "memory overlap error" during text part of initial load. Don't
> have the values reported just now but will follow up with more detail
> tomorrow.
>
> Does anyone recognize this error. Happens with SCSI and with EIDE setup.
> This is with a client CD. I may try my own CD tomorrow just to see if the
> CD is bad.
>
> Any suggestions or bootstring ideas would be appreciated.

You can get a whole lot of memory debug information out of the OSR5 boot
program by booting with:

Boot
: defbootstr mem=/v prompt

This spews a lot of output, then eventually prompts you with:

System loaded, press to start:

At that prompt, enter "v" to get even more memory information. There's
a lot of overlap between the various output. For the type of problem
you're having, the crucial details are going to be found in those areas
of overlap. Some pairs of data that _should_ be identical will be
different.

It isn't easy to capture the output I'm describing. There may be more
of it than will fit on a screen, and you have no way of printing or
saving the output on a video console except by writing it down. For
debug purposes, a better choice would be to use a serial console. To do
that, attach a serial cable to COM1 of the problem machine, and to a
port on another machine. Start up a serial comms program on the other
machine, set to 9600bps 8/N/1. Now boot the problem machine and enter:

Boot
: systty=1

You should get a boot prompt on the serial comms program. If not, check
the cable (the main problem will be null modem vs. straight through).
Once you get a prompt, turn on capture and boot with "defbootstr mem=/v
prompt"... "v".

Post the output here.

================================================== ===========================

But before that, boot an OSR507 CD on the same machine. Does it have
the same problem? If not, you might ask yourself "Why am I installing
such an archaic version?"

My guess is that 507 will be fine. If so: do the same serial console
exercise with it. Post both sets of output. That will let me see what
505 is doing wrong, and I'll probably be able to give you a bootstring
to straighten it out.

>Bela<

Terrible lapse on my part. The client had a new P4 machine and was
installing 5.0.5 which I guess is incompatible. I never even checked.

Up until today all the hardware work was done by his favorite technician,
who had no UNIX or SCSI experience.

I dropped in my developer kit 5.0.6 and it booted to the point of
serialization, which was of course at home in a safe place.

I also have a 5.0.7 kit and once I know he has a license on the way I will
install that and then we will try to find out what condition his old SCSI
drive is in. I really dread mounting that bad drive, but all his MedMgr
data is there. I have the divvy data from long ago but hope I won't have to
use it.

Thanks,

DAW
"D Williams" wrote in message
news:kNDcf.14$s14.5@newsread2.news.pas.earthlink.n et...
> Doing a fresh install of OSR 5.0.5. Tried 3 different mother boards and
> got
> the message "memory overlap error" during text part of initial load.
> Don't
> have the values reported just now but will follow up with more detail
> tomorrow.
>
> Does anyone recognize this error. Happens with SCSI and with EIDE setup.
> This is with a client CD. I may try my own CD tomorrow just to see if the
> CD is bad.
>
> Any suggestions or bootstring ideas would be appreciated.
>
> For direct reply use inmdb@earthlink-dot-net
>
> Thanks
>
> DAW
>
>

In article "SDS" writes:
$Terrible lapse on my part. The client had a new P4 machine and was
$installing 5.0.5 which I guess is incompatible. I never even checked.

Officially, it may be, but I'm sure I'm not the only person who's
had 5.0.5 running on a P4, and a couple of years ago, after I'd
mentioned having chosen a PIII system due to 5.0.5 not supporting
the P4, a helpful expert who's well known in this group emailed
me and said that in reality there shouldn't be problems running
5.0.5 on a P4. (That PIII motherboard or CPU died - never figured
out which one was responsible - and I replaced it with a P4, and
continued to run 5.0.5 for a while before upgrading to 5.0.7.)

Anyway, it sounds like you've found a solution, which is good
to know.
--
Stephen M. Dunn
>>>----------------> http://www.stevedunn.ca/ <----------------<<<
------------------------------------------------------------------
Say hi to my cat -- http://www.stevedunn.ca/photos/toby/

Stephen M. Dunn wrote:

> In article "SDS" writes:
> $Terrible lapse on my part. The client had a new P4 machine and was
> $installing 5.0.5 which I guess is incompatible. I never even checked.
>
> Officially, it may be, but I'm sure I'm not the only person who's
> had 5.0.5 running on a P4, and a couple of years ago, after I'd
> mentioned having chosen a PIII system due to 5.0.5 not supporting
> the P4, a helpful expert who's well known in this group emailed
> me and said that in reality there shouldn't be problems running
> 5.0.5 on a P4. (That PIII motherboard or CPU died - never figured
> out which one was responsible - and I replaced it with a P4, and
> continued to run 5.0.5 for a while before upgrading to 5.0.7.)

Very diplomatic. ;-}

Anyway, I think what I really said was that the chance of problems is
very small, but it's still an at-your-own-risk kind of situation.

There are probably ways that a runaway _application_ could cause a P4
CPU to overheat under OSR505. In fact it isn't clear to me that the
mods done between 506 and 507, intended to handle all the P4 thermal
problems, ever really did address runaway applications. If the P4
thermal design is really as I understood from Intel documents, I'm not
even sure it's _possible_ for an OS to protect against some situations.

The software changes demanded for thermal control were (in my opinion)
by far the worst feature of the P4 architecture family. Worse even than
the 30-40% loss of horsepower-per-MHz compared to the P3 architecture.

>Bela<