SCO on Athlon- bios shadowing

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.

:-)

Comments?

More Articles by BigDumbDinosaur

Jump to Comments

Many of the products and books I review are things I purchased for my own use. Some were given to me specifically for the purpose of reviewing them. I resell or can earn commissions from the sale of some of these items. Links within these pages may be affiliate links that pay me for referring you to them. That's mostly insignificant amounts of money; whenever it is not I have made my relationship plain. I also may own stock in companies mentioned here. If you have any question, please do feel free to contact me.

Specific links that take you to pages that allow you to purchase the item I reviewed are very likely to pay me a commission. Many of the books I review were given to me by the publishers specifically for the purpose of writing a review. These gifts and referral fees do not affect my opinions; I often give bad reviews anyway.

We use Google third-party advertising companies to serve ads when you visit our website. These companies may use information (not including your name, address, email address, or telephone number) about your visits to this and other websites in order to provide advertisements about goods and services of interest to you. If you would like more information about this practice and to know your choices about not having this information used by these companies, click here.