|
s i s t e m a o p e r a c i o n a l m a g n u x l i n u x | ~/ · documentação · suporte · sobre |
15. Upgrading Older Machines15.1. Older Memory TypesThe last-generation memory package was a SIMM (Single In-Line Memory Module). We include some information on these here for people upgrading old systems. SIMMs have 9 bits wide (8 bits of data, one for parity) and either 1, 4, or 16 megabytes in size. The 16s are slightly cheaper per megabyte. There are two physical SIMM sizes; 30-pin and 72-pin. The 30-pin size is long obsolete; most SIMM-using motherboards have exclusively 72-pin sockets. Also, your memory may or may not have on-board parity check bits. Memory with parity is specified as ``x36'' (4 check bits per word); memory without is ``x32''. Some motherboards require parity memory; some (including those based on the Neptune chipset) can use parity if present; some (including those based on the Triton chipset) cannot use it. Parity memory is a good idea for Unix machines, which stress the hardware more than other OSs. You'll hear a lot about ``EDO'' (Extended Data Out) RAM. This stuff is 5%-10% more expensive, but that pays for a significant performance boost in ``burst mode'' (that is, when fetching large contiguous sections of memory into the cache). Most current motherboards (including those based on the Triton chipset) can use EDO but don't require it. You do not want to buy 1MB SIMMs any more, unless you're filling out memory in an existing system configured with 1MB SIMMs. The trouble with these (besides the fact that four of them are more expensive than a 4MB chip) is that, due to interleaving constraints, you'll probably have to throw them away if you ever add more memory. These interleaving constraints differ from motherboard to motherboard. Typically, memory sockets are set up in banks of either 2 or 4, with a requirement that you fill all sockets of each bank with the same size of chip. Also, if you mix chip sizes in the banks, the sizes have to decrease smoothly (so there won't be gaps in the memory address space). So your possible configurations look like the following table. All of these are possible on 4-bank, 16-slot boards; only the asterisked ones are possible on 2-bank, 8-slot boards. All the capacities above 64MB require that the board accept 16MB SIMMs. All current 2x8 boards accept these.
As you can see from the table, most configurations with 1MB chips in them can't be upgraded without throwing away chips. Here's some more about memory packaging.
There are also adapter cards that will accept 30-pin SIMM modules and plug into a 72-pin socket; make sure you've the room for these if you intend to try them, as they protrude quite a bit above the board. There are also companies that will, for modest fees, desolder the memory chips from 30-pin SIMMs and wave solder them onto 72-pin boards. (Thanks to Dave Ihnat for the glossary.) 15.2. If You Must Buy a 486There were a bunch of early 386 boards that tanked Unix badly, due to timing problems or botched cache design (one of these mistakes actually sank a major vendor, Everex, when it got a piece of a big federal-government Unix contract and then couldn't perform because its motherboards wouldn't run Unix reliably!). Incompatibilities that gross are pretty much history now, unless some low-ball vendor slips you a fossil from his back shelf. A good, tricky way to avoid this is to specify a motherboard that can take 4 or 16MB SIMMs (as opposed to just the older 1MB kind). You want to do this anyhow for functional reasons. Beware the infamous FP exception bug! Some motherboards fail to handle floating point exceptions correctly; instead of generating a SIGFPE they lock up. The following fragment of C code will reproduce the problem:
John R. Levine <johnl@iecc.cambridge.ma.us> explains: "The difficulty stems from the fact that there are two ways to handle floating exceptions on a 486, the right way and the PC way. What the 486 wants to do is to generate an interrupt 16 when there is a floating point error, all entirely internal to the CPU. This has been the native way to handle floating point interrupts since the 286/287. The 286/287 and 386/387 each have a dedicated ERROR pin that the FPU uses to tell the CPU that it's time for an error interrupt. Unfortunately, the 8086/8087 handled interrupts differently. The error pin on the 8087 was wired to the 8259A interrupt controller, the same interrupt controller that handled keyboard, disk, clock, etc. interrupts. The PC/AT enshrined IRQ 13 as the one for floating interrupts. (The details of this are a little hazy to me, since the XT didn't have IRQ 13 tied to an 8259A, so the AT must have at least changed the interrupt number.) PC designs have generally wired the 287 or 387 ERROR pin to the 8259A, not to the ERROR pin on the CPU, or at best had some poorly documented way to switch between the two interrupt methods. In the interest of backward compatibility, the 486 has a mode bit that says not to handle FP exceptions automatically, but rather to freeze the FPU and send a signal on the FERR pin, which is usually tied to an 8259A which then feeds the interrupt back as IRQ 13. There is some extra complication involved here because the FPU has to stay frozen until the interrupt is accepted so the CPU can go back and look at the FPU's state. Early 386/25 chips had a bug that would sometimes freeze up on a floating point interrupt and you had to get a kludge socket with a PAL that fixed the timing glitch that provoked the bug. So as likely as not, the motherboard hardware that runs FERR out and back isn't working correctly. It's not surprising, few DOS users take floating point seriously enough to notice whether the interrupts are working right." When you specify a system, make clear to your vendor that the motherboard must handle float exceptions properly. Test your motherboard's handling of divide-by-zero; if it doesn't work, press your vendor to replace it and send me email! Only by publishing a list of boards known to be bad can we protect ourselves and pressure vendors to fix this problem. Norbert Juffa <s_juffa@iravcl.ira.uka.de> adds: Actually, the IBM PC, PC/XT and most compatible use the NMI (non-maskable interrupt) to report coprocessor errors. They don't go through the interrupt controller. Only a few not quite compatible machines did use the 8259 PIC and one needed special startup code for Microsoft-C for example to ensure correct handling of coprocessor interrupts in programs. The PC/AT and compatibles do use the 8259, and the coprocessor interrupt comes in as INT 75h (IRQs from second [slave] 8259 are mapped to INT 70h-77h) to the CPU. On the PC/XT it comes in as INT 2 (NMI). The problem with using the NMI was that NMI is also used for other purposes (e.g. parity error reporting) and that the service routine has to figure out what really caused the interrupt. The reason not to use the 8259 on the PC might have been that not enough IRQs were available. The AT has two cascaded 8259 chips and therefore has more IRQs available. Bill Reynolds <bill@goshawk.lanl.gov> recommends that, if you're buying an EISA motherboard, you check with the vendor to make sure it does not use the `Hint' chipset. It isn't true EISA. A note in the back of the Hint manual admits that the Hint's DMA, interrupts and timers aren't ISA-compatible (however, Linux will run on it). Caveat emptor. 15.3. Cache Engineering on 486 MachinesThe 8K primary cache (L1) on the 486 is write-through, four-way set-associative with a four-deep write posting buffer. It's been argued that the 486 is more limited by that shallow write-posting buffer than by cache miss overhead. The 486's 8K internal primary cache is typically supplemented with an external caching system (L2) using SRAM to reduce the cost of an internal cache miss; in November 1994, 20ns SRAM is typical. What varies between motherboards is the design of this secondary cache. 486 External Caches are Usually Direct-Mapped Given the realities of the clone market, where buyers have been trained to assume that a bigger number is always better, it is also easier to simply advertise the 128K of direct mapped cache. Because the 486 has write-posting buffers, a write-through external cache is OK. Remember that the i486 already has a 4-deep write-buffer. Writes are done when there is little bus activity (most common case) or when the buffer is full. The write-buffer will write out its contents while the i486 CPU is still crunching away from the internal cache. Thus, a write-through has little negative impact on write performance. If the buffer was usually full, then the i486 would be stalling while the write is done (and you would then want a write-back cache OR a better choice would be another external write buffer). Also, recall that one of the goals of the secondary cache is to have very high effective bandwidth to the i486 processor. Any associativity greater than direct-mapped measurably increases the lookup time in the secondary cache and increases the time to service an internal cache miss, and thus reduces the effective bandwidth to the i486. Thus, direct-mapped secondary caches provide a lower $$ cost AND increase the performance in the common case of a secondary cache hit, even though the hit rate has been slightly reduced by not adding the associativity. |
|||||||||
Andrew Comech's The Cheap /Linux/ Box page is a useful guide to building with current hardware that is updated every two weeks. Andrew also maintains a short-cut version.
The Caveat Emptor guide has an especially good section on evaluating monitor specifications.
Dick Perron has a PC Hardware Links page. There is lots and lots of good technical stuff linked to here. Power On Self Test codes, manufacturer address lists, common fixes, hard disk interface primer, etc.
Anthony Olszewski's Assembling A PC is an excellent guide to the perplexed. Not Linux-specific. If you're specifically changing a motherboard, see the Installing a Motherboard page. This one even has a Linux note.
Tom's Hardware Guide covers many hardware issues exhaustively. It is especially good about CPU chips and motherboards. Full of ads and slow-loading graphics, though.
The System Optimization Site has many links to other worthwhile sites for hardware buyers.
Christopher B. Browne has a page on Linux VARs that build systems. He also recommends the Linux VAR HOWTO.
Jeff Moe has a Build Your Own PC page. It's more oriented towards building from parts than this one. Less technical depth in most areas, but better coverage of some including RAM, soundcards and motherboard installation. Features nifty and helpful graphics, one of the better graphics-intensive pages I've seen. However, the hardware-selection advice is out of date.
The Linux Hardware Database provides, among other things (e.g., drivers, specs, links, etc.), user ratings for specific hardware components for use under Linux. Our ratings take a lot of the guess work out of choosing which hardware to buy for a Linux box. The site also provides several product-specific resources (i.e., drivers, workarounds, how-to) that help users get hardware working after they have made a purchase.