APLawrence.com -  Resources for Unix and Linux Systems, Bloggers and the self-employed

SCO on Athlon- bios shadowing

© December 2004 BigDumbDinosaur

Date: Thu, 17 Jan 2002
From: Bill Brier
Subject: SCO on Athlon

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.

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.

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.

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:

defbootstr apm.no32pm=disable nbuf=500 link=""

Incidentally, the above will not work if the machine is booted from the OS5 CD-ROM.

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.

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.


Got something to add? Send me email.

(OLDER)    <- More Stuff -> (NEWER)    (NEWEST)   

Printer Friendly Version

-> SCO on Athlon- bios shadowing ––>SCO on Athlon

Inexpensive and informative Apple related e-books:

Digital Sharing Crash Course

Take Control of Preview

Take Control of Apple Mail, Third Edition

El Capitan: A Take Control Crash Course

Take Control of Numbers

More Articles by © BigDumbDinosaur

Printer Friendly Version

Have you tried Searching this site?

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.

Contact us

Printer Friendly Version

In C++ it's harder to shoot yourself in the foot, but when you do, you blow off your whole leg. (Bjarne Stroustrup)

Linux posts

Troubleshooting posts

This post tagged:




Unix/Linux Consultants

Skills Tests

Unix/Linux Book Reviews

My Unix/Linux Troubleshooting Book

This site runs on Linode

SCO Unix Sales, Support, & Service

Phone:  707-SCO-UNIX (707-726-8649Toll Free: 833-SCO-UNIX (833-726-8649)