Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

OSR504 boot STOPS after "Loading kernel ... .text"

59 views
Skip to first unread message

Carol Saah

unread,
Jul 16, 2003, 10:51:50 AM7/16/03
to
Hi,

I replaced an Intel P4 D845PESV motherboard
with an Intel P4 D865PERL motherboard -- as a
result of lightning that ended up going through
a working APC Smart-UPS 700 and knocking out the
motherboard/memory.

I had SCO OSR504 installed in that machine on an
Adaptec 29160 with 2 Seagate LVDs, which were
NOT affected by the hit.

/dev/boot is on hd0a and
/dev/root is on /dev/hd24. (Another HD off the 50-pin
port on the 29160 had been installed BEFORE the 2nd
LVD drive - so that's why OSR504 root is on /dev/hd24.)

I am using the ad160 driver that is for
OSR505 since there was none for OSR504 and it worked on OSR504. The system
was bootable both
from floppies and the hard disk with the Intel P4
D845PESV motherboard before the hit.

Solaris 9 is installed on the same hd as OSR504 root
and boots just fine with the new motherboard.
Microsoft Small Business Server is also on the 1st hd and
it also boots just fine.

Now, I cannot boot OSR504 from hd(40)unix nor from
fd(60)unix. I have tried 2 SCO OSR504 boot/root
floppies and here are the results:

When booting with fd(60)unix, boot consistently STOPS
at the 1st dot after the line:

Loading kernel fd(60)unix.Z .text
. [stops here]

If I boot from the floppy but use the following bootstring
hd(40)unix swap=hd(161) dump=hd(161) root=hd(162),
then boot stops with 1 complete line of dots and about
half-way through the next line of dots after the following
line:

Loading kernel hd(40)unix.Z .text

If I boot from the hard disk, boot consistently stops after
4 complete lines of dots plus half of the 5th line.

If I try to BOOT ONLY from an SCO OSR505 boot
floppy withOUT the ad160 driver and with an OSR505
kernel from a Pentium 100 PC, the boot completes to
the root filesystem diskette request. I do NOT go any
further since the controller driver is NOT ad160 on the
OSR505 system and it isn't the same OS version.

If I disable cache in the bootstring, boot still stops
after the "Loading... .text" msg.

When I remove the Adaptec 29160 and the 2 LVD
drives and hook to a new Dell P4 Dimension 8250,
I have no problem booting/rooting from the hard drives.

The D865PERL motherboard is running with:

DDR333 -> single channel dynamic paging mode

Memory is 512 Mb (DDR400) single channel (setup)

Two serial-ATA ports are also available on this
motherboard, but not being used.

If I try to change the ATA/IDE config to legacy mode --
up to 2 IDE devices max, booting from the hd stops
sooner after the "Loading... .text" line.

Under chipset configuration, the following is set on the
Intel motherboard:

ISA Enable Bit - Enable
PCI Latency Timer 32
Extended config:
SDRAM Frequency Auto
CPC Override Auto
SDRAM Timing Control AUTO
SDRAM RAS Act. to Pre. 7
SDRAM CAS# LATENCY 2.5
SDRAM RAS# to CAS# delay 3
SDRAM RAS# Precharge 3

On the OSR504 system, I have many patches and
rs504c: oss470a,oss485a,oss471f and
oss469d,oss496a,oss621b,oss644b,oss642a,
oss480a,oss601a,oss472a,oss475a,oss459b,oss473a,
oss481a,oss605a,oss644b

If there is anything I can do to change the kernel (while
the disks are hooked to the Dell machine) or a bootstring
option to boot the SCO OSR504 on the new motherboard, please let me know.

I would prefer to work on the P4 rather than the Pentium
100.

I understand that I need to upgrade to OSR507 and
maybe that would solve my problem, but I need an
interim solution if possible.

Thanks in advance.

Carol Saah


Bela Lubkin

unread,
Jul 16, 2003, 3:26:35 PM7/16/03
to post article to comp.unix.sco.misc, Carol Saah
Carol Saah wrote:

Thanks for the complete report.

The boot stage at which your system is hanging happens long before the
differences between OSR504 and OSR507 (or between straight OSR504 and
OSR504 + 17 patches) would make any difference. It's also before the
use of a BTLD should make any real difference; and and before the
location of the root filesystem would make any difference. The only
thing you're accessing is the /stand (boot) filesystem, or the boot
floppy.

/boot reads a hard disk boot filesystem using BIOS hard disk read
functions; it reads floppy and CD-ROM filesystems using BIOS floppy disk
read functions (i.e. the same function, different "drive number"). The
action is very simple. BIOS is called to read a sector, then a
different BIOS call is done to copy the resulting data up into high
memory; repeat. If it hangs, one of those function calls must be
failing in an odd manner.

From what you've already tried, the next thing I would want to try is do
exactly the same things on a different D865PERL motherboard (with
different CPU & RAM -- all components different) -- to see if it's a
generic problem with OSR5 vs. that motherboard. Of course you probably
only have one unit, so you can't do that. I guess my next attempt would
be: try booting removing all hardware not needed to boot the floppy,
then try booting one of the floppies that hangs. That is, primarly,
remove the ad160 hardware. If the kernel loads then you can tell
there's something going on between /boot and the ad160 BIOS or hardware.
Of course the kernel won't do anything useful if it can't access the
disks; this is just a probe.

Regarding the detailed BIOS settings (SDRAM timing etc.) -- are those
default values assigned by the BIOS? Most BIOSes successfully
initialize themselves to conservative values that work consistently. If
those are tuned values, reset to BIOS defaults and see if things are any
better -- then if you need to tune, change one thing at a time until you
find the culprit, and don't change that!

I haven't seen a D865PERL yet. I'm using an i875P-based motherboard
(not Intel brand) without problems, and the 865 and 875 chipsets are
very closely related. That doesn't prove anything about your situation,
just that OSR5 isn't inherently allergic to that chipset family.

>Bela<

Bob Bailin

unread,
Jul 17, 2003, 12:21:49 AM7/17/03
to

"Carol Saah" <cs...@cox.net> wrote in message
news:LDdRa.1842$MK4.263@lakeread07...

Are you using one of the newer P4 processors (3.04GHz) that supports
hyperthreading?
If so, make sure hyperthreading is disabled in the BIOS.


Carol Saah

unread,
Jul 17, 2003, 9:30:23 AM7/17/03
to

"Bob Bailin" <72027...@compuserve.com> wrote in message
news:bf58gc$59a$1...@ngspool-d02.news.aol.com...

>
> Are you using one of the newer P4 processors (3.04GHz) that supports
> hyperthreading?
> If so, make sure hyperthreading is disabled in the BIOS.
>

My processor is 2.53 GHz and the motherboard
manual indicates that that processor does not fall
into the processor category that features Hyper-
Threading.

I do not see a setting to disable hyper-threading in setup,
though. Maybe that is automatic depending on the
processor.

Thank you for your response.

Carol Saah


Carol Saah

unread,
Jul 17, 2003, 9:30:38 AM7/17/03
to
Bela,

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.

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.

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.

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?

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

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?

Again, thanks for the leads and I hope this posting will help better
than the last one.

Carol Saah

"Bela Lubkin" <be...@sco.com> wrote in message
news:20030716192...@sco.com...


> Carol Saah wrote:
>
> > I replaced an Intel P4 D845PESV motherboard
> > with an Intel P4 D865PERL motherboard -- as a

[removed lines]

Carol Saah

unread,
Jul 17, 2003, 6:48:47 PM7/17/03
to
Bela,

I just tried to boot my OSR504 and OSR505 boot diskettes in an
D875PBZLK machine. In both cases, the diskette was accessed
briefly and boot control passed to the next device in the boot
sequence.

I also want to mention that the Dell Dimension 8250 which I could
boot OSR504 both from OSR504 boot/root floppies and from the HD
off the Adaptec 29160 had problems with "doscp" and "dosdir".
The floppy drive is a 1.44 Mb drive. When I tried to use doscp, the result
was:

# doscp -r filename a:filename
# killed

# dosdir a:
# killed

# dosdir /dev/fd0135ds18
# killed

I am not planning on loading OSR504 in the Dell so I did not report
this earlier.

The Dell Dimension 8250 has:
bus speed 533 MHz
processor P4 2.40 GHz
and Dual channel memory: 2 RIMM_1 of 256 Mb each (setup)
Processor ID: F27 (I don't know what this means.)

Carol Saah

"Carol Saah" <cs...@cox.net> wrote in message

news:DxxRa.4185$MK4.2059@lakeread07...

Bela Lubkin

unread,
Jul 18, 2003, 3:04:08 AM7/18/03
to sco...@xenitec.ca
Carol Saah wrote:

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<

Bela Lubkin

unread,
Jul 18, 2003, 3:13:18 AM7/18/03
to sco...@xenitec.ca
Carol Saah wrote:

> I just tried to boot my OSR504 and OSR505 boot diskettes in an
> D875PBZLK machine. In both cases, the diskette was accessed
> briefly and boot control passed to the next device in the boot
> sequence.

Again, it looks like this is due to the BIOS enforcing the floppy boot
signature of 0x55 0xAA at address 0x1FE of a diskette. No other modern
BIOS that I am aware of does this.

I will send you private email with a possible fix for this.

> I also want to mention that the Dell Dimension 8250 which I could
> boot OSR504 both from OSR504 boot/root floppies and from the HD
> off the Adaptec 29160 had problems with "doscp" and "dosdir".
> The floppy drive is a 1.44 Mb drive. When I tried to use doscp, the result
> was:
>
> # doscp -r filename a:filename
> # killed
>
> # dosdir a:
> # killed
>
> # dosdir /dev/fd0135ds18
> # killed
>
> I am not planning on loading OSR504 in the Dell so I did not report
> this earlier.

Those messages make it look like your `doscp` and `dosdir` binaries are
corrupt. Has nothing to do with the floppy drive. If you run:

# dosdir
# dosdir c:

you'll see the same message. This is so abnormal as to make me think
there is something much more fundamentally wrong with the install.

> The Dell Dimension 8250 has:
> bus speed 533 MHz
> processor P4 2.40 GHz
> and Dual channel memory: 2 RIMM_1 of 256 Mb each (setup)
> Processor ID: F27 (I don't know what this means.)

Those are the three digits "family, model, stepping" returned from one
of the subfunctions of the `CPUID' instruction. Family 'F' is the
signature of the Pentium 4 family of processors. F27 is the right
signature for a Pentium 4 "Northwood" 478-pin 0.18 micron 533MHz FSB
CPU. (I _think_ those are the right code name and line size, but those
are just from memory...)

Basically, that's all fine _except_ that you're using OSR504 on a
Pentium 4, which is unsupported and expected to have trouble. The
various boot symptoms you're having do not appear to be CPU-related. I
am much less certain about the `doscp` problem. I think it very well
_could_ be related to running OSR504 on a CPU that shipped 5 years after
the OS.

>Bela<

0 new messages