If this isn't exactly what you wanted, please try our Search (there's a LOT of techy and non-techy stuff here about Linux, Unix, Mac OS X and just computers in general!):
Date: Thu, 17 Jan 2002 17:41:42 +0000
From: Bill Brier <steggy@bcstechnology.net>
Subject: SCO on Athlon
<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
Hiya!
<p>You may recall that some time ago, I described an instability issue
related to running SCO OpenServer 5.0.6 on AMD Athlon systems using DDR
memory. The problem was that the system would "go to sleep" when
activity was light, causing such things as uptime to be incorrect and cron
jobs to not run when scheduled. We thought at first that this issue
was somehow related to the presence of DDR memory and the 266 MHz front
side bus, as it would not occur on older Athlon boards using PC100 or PC133
SDRAM.
<p>It turns out we were correct in surmising a relationship with DDR.
However, it appears that the real issue is related to the fact that BIOS
shadowing on many DDR Athlon boards cannot be disabled in the BIOS setup
itself. This led me to conclude that during the installation of OS5,
BIOS shadowing was "poisoning" some areas of memory and that the overall
installation was fatally flawed.
<p>My approach to fixing this was to try to reduce the memory footprint
used during initial load by reducing the number of buffers allocated at
boot time. I did this by experimenting with different boot strings
when starting a load (a very laborious process, as it turned out, since
I had to format the drive after each failed installation). Also,
in testing this idea I accidentally discovered a bug specific to the use
of Equinox SuperSerial (SST) hardware on an Athlon DDR system.
<p>Anyhow, the solution turned out to be relative simple (aren't they always?).
Using the SCO boot floppy to start the OS installation, I entered the following
response to the boot prompt:
<p><tt>defbootstr apm.no32pm=disable nbuf=500 link="<package>"</tt>
<p>Incidentally, the above will not work if the machine is booted from
the OS5 CD-ROM.
<p>After completing a system load with the above boot string, along with
installing a NIC and attaching the box to our shop network, stable operation
was achieved. In fact, I let the machine run for nearly a week, all
the while monitoring uptime and the execution of some contrived cron jobs.
<p>Everything was fine until I installed an SST board and linked in the
driver. Doing so caused the instability to return: uptime was way
off and cron jobs weren't being run at the right time (or at all).
I experimented with placing the SST board into different slots, with no
change. However, as soon as I unlinked the driver from the kernel
stability returned. One interesting thing about SST hardware is that
it uses no IRQ's -- all serial processing is confined to the board itself
and the CPU is pretty much kept out of the picture. Equinox has been
contacted on this and right now their hardware engineers are working with
a test box I sent them so they can resolve this issue. I'll advise
as soon as they respond.
<p>:-)</html>
Enter your email address for automatic notification of new posts here
(be sure to whitelist 'feedburner.com' if you use spam filtering)
| Views for this page | ||||
|---|---|---|---|---|
| Today | This Week | This Month | This Year | Overall |
| 1 | 2 | 9 | 158 | 997 |
/Bofcusm/1412.html copyright 1997-2004 (various authors) All Rights Reserved
Have you tried Searching this site?
Unix/Linux/Mac OS X support by phone, email or on-site: Support Rates
This is a Unix/Linux resource website. It contains technical articles about Unix, Linux and general computing related subjects, opinion, news, help files, how-to's, tutorials and more. We appreciate comments and article submissions.
Add your comments