Carol Saah wrote:

> Thank you VERY, VERY, VERY much for your comments
> and suggestion to take the ad160 out of the machine. There is
> a problem with the D865PERL bios booting off SCO OSR504 and
> SCO OSR505 boot diskettes. At boot, a brief access to
> SCO's boot diskette is made and THEN control is passed on to
> boot the next device in the boot sequence. A DOS 5.0 diskette can be
> booted.
>
> I am really embarrassed because I knew the BIOS was not
> transferring control to the diskette yesterday and I even mentioned the
> fact to the dealer from whom I purchased the motherboard and
> told him how I had to get the diskette to boot: press "a" at the
> Ranish Boot Manager (www.ranish.com/part/) screen. So, in my
> tests, the BIOS was transferring boot control to the next boot device
> in the sequence -- the hard drive.
>
> I know this is a direct contradiction to what I posted. Somehow the
> crucial WAY I was booting from floppies totalling escaped my mind when
> I was writing the original posting. Unbelievable except that I have been
> troubleshooting a lot of electrical failures resulting from that lightning
> hit
> and so it is difficult to really concentrate on one thing. And I NEED MY
> SCO OSR504 so I didn't want to wait to post.
>
> I had also forgotten that from my research to figure out how to use Ranish
> Boot manager to boot SCO OSR504, I could NOT use the "a" method
> to boot OSR504. period.
>
> But, please note that I WAS ABLE to boot SCO OSR505's boot
> floppy to completion via pressing "a" at the Ranish boot manager.
> I didn't have the SCO OSR505 machine in February when I did my
> Ranish tests.

I don't know anything about Ranish boot manager (and have not looked at
the web site as I write this). I'm confused about the implications of
what you're saying. Are you saying that you already had Ranish
installed on the machine when these problems started, and the above is
an explanation (meaningful to someone who is familiar with Ranish) of
how you had to change its configuration to allow booting an OSR5 floppy?

Or, are you saying that you had these problems and brought Ranish in as
a possible cure?

My advice in either case would be quite different. If you had Ranish
Boot Manager on the machines in the first place, I would say: well, try
with it completely absent.

If you brought it in as a cure, I would draw an entirely different
conclusion. The original IBM PC BIOS, back in 1981, required a specific
"bootable floppy" signature -- values 0x55 0xAA in the last two bytes of
the boot sector. Almost no later PC enforces this, because some early
clones forgot to check for it, some OS vendors shipped disks which
hadn't been tested on "real" IBM PCs and didn't have the signature, so
then real PCs had to be modified to ignore the signature. OSR5's floppy
boot code does not have the signature. My guess would then be that the
D865PERL and D875PBZLK BIOSes _do_ check for the signature. Ranish,
which presumably makes it its business to boot every kind of OS
imaginable, would perforce _not_ check the signature.

If I'm right, then I would expect Intel to be under pressure to modify
their BIOS to stop checking the signature. You should check their web
site for BIOS updates. Presumably the most common OSes (various flavors
of Windows and Linux) do have the right signatures, so they didn't catch
this during testing. On the other hand, I strongly doubt OSR5 is the
_only_ OS to leave out the signature.

> On a different note....
> I wonder if this also means that SCO's OSR505 COULD be
> booted from Ranish's Partition Manager!!!!! If it can, I will be
> very, very appreciative because a SCO upgrade would save me a lot
> of trouble I have been going through until now to boot SCO OSR504.
>
> In Ranish boot manager, I can either choose to boot with the Ranish boot
> manager or the "standard IPL". So, if the Ranish boot manager is the
> boot manager, I either have to boot with SCO OSR504 boot/root floppies
> and type in the bootstring (which is what I have been doing recently), or
> I have to boot to the Ranish boot manager, make sure that SCO's boot
> partition is active and set the boot manager to boot with the "standard
> IPL". Then, I can reboot into SCO, but then the Ranish boot manager is
> unavailable until I boot with a DOS diskette and run part243, to boot and
> activate the Ranish boot manager again. And, then, I can run Solaris or
> SBS until the next time I need to run SCO OSR504 without the boot/root
> floppies. Then, the same boot manager change is needed. (It is too
> complicated, I guess.)
>
> I would love it if SCO's new OS would come out with a boot
> manager that can boot OS's from the 2nd disk. Then, I would be
> set.

Well, as you can see it's complicated, there are no really easy answers.
The OpenServer boot manager does enough for many purposes. Extending it
further would put us in the business of writing really complex boot
managers, which is a tangent that we shouldn't really be following.

OpenServer 5.0.7 has one change to make it more tolerant of being booted
_by_ a boot manager. The default locations of the various standard
divisions (boot, swap, root) are the same device numbers as before: 1,40
through 1,42; and those still stand for "0th drive, active partition,
divisions 0..2". But the exact meaning of "active" has changed. Prior
releases take it to literally mean the partition marked as active in the
partition table. OSR507 takes it to mean one of the following (in
order):

- the partition marked as active in the partition table, if it is a
Unix partition

- else the lowest numbered Unix partition (according to Unix partition
numbering)

- else, if there are no Unix partitions, any partition marked as
active in the partition table

As a result, if you have an OSR507 partition and some other partitions,
and a boot manager that will load the OSR507 partition boot sector while
its partition is not marked "active" in the partition table, OSR5 should
still boot.

This still does not address booting OSR5 from a second disk; nor is
there any change in the OSR5 boot manager to allow it to provoke booting
of a different OS from a second disk.

> By the way, the chipset configuraton I gave in the original
> posting are at the default settings. I would not have the slightest
> idea what to change there without more research.

Ok, understood. My question was again due to not understanding your
intent. I couldn't tell if you were just showing what was there, or if
you meant to imply that you had actually _configured_ the settings that
way and wanted confirmation that they were good settings. Most readers,
including me, have no idea whether those are good settings...

> My motherboard dealer says that for a few more bucks, he
> can exchange the D865PERL motherboard for a D875PBZLK
> if I can tell him that it will work with my operating system.
>
> If SCO OSR5 does not support Multi-Threading, then it looks
> as though I'll need to change my memory, too, if I upgrade to
> D875PBZLK. Does SCO OSR5 support Multi-Threading in the 875i?

First, terminology. "Multithreading" refers to a whole bunch of
different technologies, some of which are possible under OSR5 (various
threads libraries exist). I think you're referring to "HyperThreading"
(or "HT"), which is Intel's implementation of multiple virtual CPU cores
on a single x86 die.

HT is only available on Intel Pentium 4 family CPUs. The only
OpenServer releases which officially support _any_ P4 family CPU are:
OSR506 _with_ supplements rs506a + oss648a; and OSR507. OSR504 and 505
are officially not supported on P4, and problems _are_ expected (though
not the early-boot problems you're seeing).

Regarding HT itself: neither 506 nor 507 have any explicit HT support.
_Some_ motherboards provide descriptions of the HT virtual processors in
Intel MPS tables, in which case OSR5 can recognize and use the
processors. However, there are a couple of big negatives. One is that,
since the OS has no idea that these are not "real" processors, you must
have an expensive SCO SMP license for each added virtual processor.
Another is that the process scheduler knows nothing about scheduling
processes onto different physical CPU cores. If you had two physical
CPUs (thus 4 virtual CPUs), you would need 3 SMP licenses. Then the
scheduler might schedule the only two running processes onto the two
virtual CPUs of one physical CPU, leaving the other physical CPU
completely idle.

The upcoming OSR507UP1 (Update Pack 1 -- the first deliverable in the
SCO Update program for OSR5) includes preliminary HT support. The
kernel learns to require SMP licenses only for additional physical CPUs.
It learns to schedule processes to take better advantage of HT.

Finally, _none_ of this has anything to do with memory types.

> My processor is 2.53 GHz with a system bus speed of 533 MHz,
> which does not have the Multi-Threading technology.

Correct. HT didn't arrive in "regular" (not-Xeon) Pentium 4's until the
3.06GHz/533MHz FSB, and then all the 800MHz FSB chips (2.4GHz through
3.2GHz, so far).

> I have one DIMM of 512 Mb (DDR400) to run in Single Channel
> Memory Mode. Is there a version of SCO OSR5 that supports dual
> channel memory mode?

The operating system doesn't know anything about the number of DDR
memory channels in use. That is purely between the CPU, FSB (frontside
bus), and motherboard memory design. At most, the OS might be able to
detect a small performance difference (improvement) with two channels in
use. Of course the OS has no way to cause you to add and remove memory
channels in order to benchmark the difference, and whatever difference
there is on one motherboard could easily be overwhelmed by good (or bad)
memory subsystem design from one motherboard to another.

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

This is all getting rather far afield. We have that the BIOSes won't
boot OSR5 boot floppies due to missing signature bytes. We also have
(completely unrelated, but similar symptoms) that the BIOSes won't boot
OSR5 from the hard disk, due to hanging along the way.

It's hard to diagnose this stuff from afar. Even harder when we're
going every direction at once.

My opinion: you should forget about floppies for the moment, concentrate
on figuring out why it hangs during hard disk boot. Next step: check
Intel web site for updated versions of D865PERL, D875PBZLK BIOSes.

For reference, I am using an ABIT IC7 motherboard, based on the same
i875P chipset as the D875PBZLK. It boots OSR5 CD-ROMs (which use a
floppy image), and hard disks, with no trouble. I'm not sure if I've
ever tried booting a OSR5 _floppy_ on the machine.

>Bela<