Memory Trouble in Stormville

Posted on April 18, 2020 by Michal Necasek

The OS/2 Museum recently acquired a genuine Intel DX79SR (Stormville) board. Together with its close siblings DX79SI (Siler) and DX79TO (Thorsby), these were the last “great” Intel motherboards, supporting the big LGA 2011 socket for the Sandy Bridge E platform—but not Ivy Bridge, because Intel treated buyers of its final boards rather poorly and refused to update the board firmware to support Ivy Bridge E CPUs.

The DX79SR is extremely similar to the older DX79SI which it replaced in Intel’s lineup. The only noteworthy differences are that the Stormville adds two additional rear USB 3.0 ports and two internal 6Gbps SATA ports (through an onboard Marvell SATA controller).

A detail shot (voltage regulator heatsink) of an Intel DX79SR destkop board, 2012.
Intel DX79SR board detail

At $299 (price at May 2012 introduction), the DX79SR was a rather pricey board for rather pricey CPUs. Why would anyone want one? Because it was the only way to get a desktop board (from Intel) supporting an Intel CPU with more than four cores and with support for more than 32GB RAM. All “standard” desktop boards for Sandy Bridge and Ivy Bridge platforms (and even for Haswell in fact) were limited to four cores and 32GB RAM.

It is also noteworthy that the board supports not only Sandy Bridge E but also Sandy Bridge EP processors, and can thus run with not just the six-core i7-branded CPUs but also 6-core or even 8-core LGA2011 Xeons, such as the beefy eight-core E5-2687W.

In my testing, the DX79SR coupled with an i7-3930K is an impressive performer, albeit a real power guzzler. The six-core CPU is rated at 3.2 GHz base frequency and 3.8 GHz turbo, but it easily overclocks to 4.6 GHz turbo with air cooling. In multi-threaded workloads, the old Sandy Bridge E can still easily keep up with today’s quad-core CPUs.

That’s all well and good. Unfortunately, getting more than 32 GB (or at first even 32GB) going in the Stormville board turned out to be quite difficult.

Continue reading →
Posted in Bugs, Intel, PC hardware, PC history | 14 Comments

386 Cache Coherency

Posted on April 8, 2020 by Michal Necasek

I’ve been slowly chewing my way through U.S. Patent 5,724,549, titled Cache Coherency without Bus Arbitration Signals, initially filed by Cyrix Corporation in 1992 and published in 1998 (when it was utterly irrelevant, but such is the life of patents).

When Intel designed the 386, it was already well known that an internal (L1) cache is one of the most effective ways to increase processor performance. But given the manufacturing process available at the time, Intel could only squeeze about 512 bytes of cache onto the complex chip, and that was not enough to be effective.

The 386 was designed with external cache (sometimes called L2, although in the case of a 386 there was no L1 cache) in mind and Intel produced its own cache controller for use with a 386, the 82385 (although much like the 80387, the 82385 became available significantly later than the 386 itself).

A classic Cyrix Cx486DLC upgrade processor for the 386 socket, circa 1993.
Cyrix Cx386DLC, 33 MHz

When Cyrix designed the 486DLC upgrade processors for the 386 socket, it was not a problem to put 1K of internal cache on a 386-socket chip, or later even 8K in the case of Texas Instruments 486SXL processors. But keeping the cache coherent was a problem. There were in fact two sources of trouble: External bus masters and our old friend (frenemy?), the A20 gate.

Continue reading →
Posted in 386, Cyrix, PC architecture, PC history | 18 Comments

Linux 2.4 APIC Hang

Posted on March 16, 2020 by Michal Necasek

The other day I set out to install SuSE Linux 7.3 (Linux 2.4.10 kernel) in a virtual machine, primarily with the goal of evaluating if the included MARS_NWE NetWare emulator is any good.

But I couldn’t get anywhere–the boot floppy (or bootable DVD) would just hang. And since SuSE defaults to a graphical boot up, the boot disk would hang with a black screen and absolutely no information.

Soon enough I found out that disabling local APIC support through a Linux kernel argument ‘(disableapic’) gets rid of the hang. And when it did hang, in text mode I could at least see how far it (Linux kernel 2.4.10-4GB) got:

Linux 2.4 hanging on APIC initialization

The “host bus clock speed” is actually the APIC timer frequency. And obviously 0.0 MHz is not right, even though the CPU clock speed is spot on. So how did Linux arrive at the nonsensical number?

Continue reading →
Posted in Bugs, Linux, PC hardware | 16 Comments

OS/2 1.3 on a “Large” Disk

Posted on March 6, 2020 by Michal Necasek

In response to a reader question, I started wondering how difficult it actually is to install OS/2 1.3 on a “big” hard disk, where “big” is defined as more than about 500 MB. In an attempt to reduce the number of potential problems, I skipped IDE and went straight for a SCSI setup, using an (emulated) BusLogic SCSI HBA with a 6 GB hard disk.

The short story is that it can be done, but it’s not entirely trivial:

OS/2 1.3 managing a 6 GB disk

MS OS/2 1.3 does not include a driver for the BusLogic HBA, but BusLogic provided one. The driver can be had for example from here, or from the vendor here (the “vendor” now being Broadcom, where BusLogic ended up after a string of acquisitions (BusLogic to Mylex to LSI Logic to Avago/Broadcom).

Installing the driver is easy enough; the file SPARE001.SYS needs to be copied from the archive to the OS/2 boot floppy. The virtual disk created by the OS/2 installer can be used for file exchange. I used the Installation Diskette B, but I believe Diskette A could have been used just as easily. Note that after the OS is installed, the driver has to be manually copied to the root directory of the boot drive, otherwise the installed OS cannot boot.

Continue reading →
Posted in BusLogic, OS/2, PC history, Storage | 16 Comments

EMM386 and VDS: Not Quite Working

Posted on February 26, 2020 by Michal Necasek

The other day I set out to solve a seemingly simple problem: With a DOS extended application, lock down memory buffers using DPMI and use them for bus-mastering (BusLogic SCSI HBA, though the exact device model isn’t really relevant to the problem).

Now, DPMI does not allow querying the physical address of a memory region, although it does have provisions for mapping a given physical memory area. But that doesn’t help here–mapping physical memory is useful for framebuffers where a device memory needs to be mapped so that an application can access it. In my case, I needed the opposite, allowing a bus-mastering device to use already-allocated system memory.

As many readers probably know, VDS (Virtual DMA Services) should solve this problem through the “Scatter/Gather Lock Region” VDS function. The function is presented with a linear address and buffer size, and returns one or more physically contiguous regions together with their physical addresses.

I already had VDS working for low (DOS) memory, but I just could not get it working for “normal” extended memory. It did not matter if I used statically allocated variables placed in the executable, C runtime malloc(), or direct DPMI memory allocation functions. The VDS call succeeded and filled the result buffer with the same address I passed in, indicating a 1:1 linear:physical mapping, except the memory definitely was not mapped 1:1. So bus-mastering couldn’t work, because the addresses I programmed into the adapter were bogus. But why was this happening?

Continue reading →
Posted in Bugs, Development, DOS Extenders | 2 Comments

A Brief Visit to Disk Geometry Hell

Posted on February 20, 2020 by Michal Necasek

Several weeks ago I thought I’d install NetWare 3.12 in a virtual machine using the BusLogic SCSI controller emulation. While configuring a 1.5 GB virtual drive, I thought I should be safe and not run into any trouble with a “too big” disk.

But I was wrong. The NetWare 3.12 installer created the DOS partition and launched the NetWare OS, but trying to create a NetWare partition resulted in the following error:

NetWare 3.12 reporting an error when attempting to create a NetWare partition, caused by a geometry mismatch between the BIOS and driver.
NetWare 3.12 upset by a geometry mismatch

This error is naturally not specific to virtualization and happens on real systems as well. But why? The geometry of a SCSI disk is entirely fictional, so why is it a problem?

Continue reading →
Posted in BusLogic, IBM, NetWare, PC architecture, Storage | 32 Comments

Emulating EtherLink

Posted on January 31, 2020 by Michal Necasek

Spurred by the discovery of a pre-release OS/2 NetWare Requester from early 1988 with a very thin selection of drivers, several months ago I decided to write emulation of the classic 3Com 10Mbps Ethernet 3C501 card, also known as EtherLink. The developer documentation from 3Com was available, and didn’t look all that terrifying, just a couple of pages.

A 3Com 3C501 Etherlink adapter.
A non-emulated 3C501 EtherLink adapter manufactured in 1986.

The 3C501 is known for the comments made about it by Donald Becker, the author of many Linux networking drivers in the mid-1990s: “Don’t purchase this card, even as a joke.” The comments were not unjustified when they were made; the 3C501 was already an obsolete design in 1992 or so. The problem was that the card has a tiny buffer, only big enough for one packet, and three mutually exclusive modes: Send, receive, and buffer access by the host (obviously no full-duplex Ethernet there). Once a packet is received, further reception stops until the packet buffer is emptied by the host and receive re-started again. That leads to many dropped packets and very poor performance in busy networks, particularly networks with a lot of broadcast or multicast traffic.

Fortunately, the virtual switch in a hypervisor has the ability to buffer packets, and packet loss is far less of a problem in a VM. Which is not to say the emulated EtherLink is some kind of a great performer, but it can certainly handle much more than 10Mbps.

Continue reading →
Posted in 3Com, Networking, PC hardware, PC history, Virtualization | 33 Comments

1987 Networking: ELS NetWare 286 Level I 2.0a

Posted on January 24, 2020 by Michal Necasek

A rare find recently turned up: NetWare from 1987, specifically the low-end ELS variant of NetWare 286 version 2.0a (ELS may be claimed to mean Entry Level System or maybe Entry Level Server, but at least originally it stood for Entry Level Solution). NetWare v2.0 was released in 1985, followed by v2.0a in 1986. In November 1987, NetWare v2.1 was to become available, but in September of that year Novell released the low-end ELS product with support for 4 users (really 4 concurrent connections) and without some of the perks of Advanced NetWare. The ELS package was based on the about-to-be obsoleted v2.0a version of NetWare 286.

Screenshot of non-dedicated ELS NetWare 2.0a booting up.
Is it DOS? Is it NetWare? It’s both!

The original ELS I product was later updated with NetWare v2.12 as its basis. In early 1988, Novell added an ELS II package with support for 8 users. The ELS II variant was initially based on NetWare v2.1 and later updated to v2.11, v2.12, and finally v2.15. In 1991, Novell consolidated all the low-end versions into NetWare 2.2 (sold alongside NetWare 3.11 and released more or less at the same time as 3.11).

A print ad for ELS (Entry Level Solution) NetWare, published in PC Magazine in December 1987. "To get the power of NetWare, you'll have to pay a small price", $595. Via Google Books.
A NetWare ELS print ad (PC Magazine, December 1987)

For whatever reason, even though NetWare versions for PCs existed since the early 1980s, it is nearly impossible to find any NetWare server software from before 1990; presumably in large part because NetWare actually sold in rather small numbers before 1990 and with funny stuff like hardware locks in the early versions, the software wasn’t very useful once the hardware died. Whatever the reason, NetWare from 1987 is exceedingly rare, and in fact any PC networking software from 1987 or earlier is surprisingly difficult to find.

Continue reading →
Posted in 286, 3Com, Kryoflux, NetWare, Networking | 29 Comments

Another Strange 286 Board

Posted on January 20, 2020 by Michal Necasek

The OS/2 Museum sometimes seems to have a knack for acquiring hardware so obscure that it cannot be even identified. One of the more recent arrivals was a seemingly typical Baby AT 286 board with an 8 MHz CPU. The board was in remarkably good condition for its age, having been produced in 1986; the date code on the PCB could be read as 15-98 or as 86-51, but there’s no question which of the two interpretations is correct. A significant contributing factor to the good shape of the board was no doubt the fact that it uses a CR2032 lithium coin battery and not one of those horrible leaky NiMh rechargeables.

A Maxware/Fujitech Baby AT 286 motherboard.
A Baby-AT 286 clone board of ostensibly Japanese manufacture

The board claims to have been made in Japan by a company named Fujitech, or maybe Maxware. Interestingly, a very similar Fujitech XT board was seen with a sticker on it referencing Octek, a Taiwanese company. This would not be the first board supposedly Made in Japan that was really manufactured in Taiwan or China, but at least this “AT-BABY” uses almost exclusively Japanese components, whether it was actually assembled in Japan or not.

Continue reading →
Posted in 286, PC hardware, PC history | 27 Comments

More Fun with ISA DMA

Posted on January 13, 2020 by Michal Necasek

A reader comment on a previous post on ISA DMA pointed out that UMBPCI (or rather the DMACHK utility distributed with it) does something unusual with regard to ISA DMA. There was a suspicion of somehow accomplishing the mythical memory-to-memory DMA transfers; that proved to be unfounded, at least in the UMBPCI case, but what the utility does is nevertheless quite interesting.

Dual NEC D8237AC-% DMA controllers in a PC/AT clone board.
Classic cascaded 8237A DMA controller chips in a PC/AT clone

First some background about what DMACHK does and why it exists in the first place. UMBs are generally prone to causing difficulty with DMA, and UMBPCI is no exception. The way UMBPCI works is that it enables memory between 640KB to 1MB for use with UMBs. Such memory is normally only intended for ROM shadowing and in some chipsets, it is not accessible via DMA (whereas EMM386/QEMM/386MAX use paging to remap normal memory into the UMB range, causing physical addresses to differ from linear ones).

Continue reading →
Posted in PC architecture, PC hardware, Software Hacks | 8 Comments