keir@vms.macc.wisc.edu (Rick Keir, MACC) (10/17/90)
We have a number of IIfx machines running A/UX 2.0 in our computer aided engineering facility. They are configured for nfs (if this matters); they have the 8*24 board and have NEC brand SIMMs in Bank A; non-NEC brand SIMMs in Bank B. The ones that have been installed so far share a common problem: they keep getting fuzzy bars of color on the screen, often locking up immediately after. The color bars resemble the problem that MacPaint 1.4 had on the Mac II in 256 color mode; that is, it looks like a single-bit deep video picture is being stuffed into a video board that is expecting more information. However, the bars of fuzz are longer than the old MacPaint bug had (that bug produced fuzzy squares; these are rectangles). Previously, all of these have had a Mac OS problem where moving folders in the Finder would often leave the outline of the folder behind, quickly cluttering up the screen with multiple images of old folders where they weren't. On the advice of an Apple support tech, we checked for NEC SIMMs in bank *B* of the IIfx and found them; replacing these with non-NEC memory fixed the video display problem. Note that these SIMMs in Bank A don't seem to affect the Mac OS at all; also that at all times these machines pass Apple's hardware diagnostics. Replacing the NEC SIMMs in Bank B was done purely on the advice of someone who couldn't tell us what it would fix, but that this "fixed other things before." He was right. Replacing the Bank A SIMMs is impractical (unless Apple changes its tune and takes them back) as we only got the Bank B memory replaced by swapping Bank A SIMMs from other machines. Software config: CD-ROM distribution of A/UX, installed using System 6.05 disks which were copied from shrink-wrapped Apple masters and immediately had their write-protect *permanently* glued in the open position. NFS installed immediately. No viruses detectable with Disinfectant 2.2. No non-Apple inits. Even removing Apple's inits & drivers (other than the EtherTalk and MacTCP drivers) doesn't help. *NO* user accounts - the test system we're trying to fix has as virgin a history as we can manage, and we've even (several times) blown away and reinstalled A/UX, in case progressive damage to the file system caused by lockups was confusing the issue. There are supposed to be 12 of these systems in place soon, and we can't even get the first few to work. Any information about someone seeing similar problems would help. Thanks!
keir@vms.macc.wisc.edu (Rick Keir, MACC) (10/18/90)
Thanks to those who responded. The color fuzzy lines at the top of the screen are indeed readable in 2-bit video mode. Apparently, A/UX 2.0 does not always know about color screens; in particular, when we're getting a fatal crash with i/o messages so that you can't go to the control panel and reset the video board, *then* it tends to not know about color. With the board in 256 color mode, a test run that terminated in a crash would show 2 error messages, and an indeterminate number of fuzzy line messages. With the board in 2 color mode, we got about a dozen error messages, and a fatal crash. Also, when you press the interrupt switch and enter the unix mini-debugger, you will also need to be in 2-color mode. This is true for our (still) crashing IIfx/8*24 board/RGB monitor system; your mileage may vary on other models of the Mac. Now, on to why we get crashes (it looks like it may be an SCSI problem....)