
28 April 2010
If the Matrox Millennium PCI video display adapter's 32K memory area is moved above 256 MB with MIL4P ROM rev 1.9, the system will crash during POST, requiring the NVRAM to be reset by removing and reinstalling the RTC chip. The problem does not occur if the system is downgraded to 192 MB RAM.
A downlevel ECU will attempt to move the MIL4P's 32K memory area to 256 MB, but then do it in a way which somehow conflicts with the top of system RAM. If it is manually moved, e.g. to 257 MB, there is no problem. If a sufficiently recent ECU is used, the 32K memory area will be automatically moved to around 4GB; there is no need to manually adjust the location in this case. This issue is apparently unrelated to the MIL4 ROM revision.
Flash Update disk boots and finds downlevel (1.9) microcode, but fails to update microcode to revision 2.2. The BIOS protection switch is disabled.
ERROR! Cannot program the BIOS.
Compare this to the error received when the BIOS protection switch is enabled:
- WARNING: The BIOS protection switch is currently set to PROTECTED.
MEMTEST86 run from floppy; thousands of errors detected over entire memory map during test 7 (random number sequence). All other tests run without finding any errors.
Discovered thermal creep in L2 cache RAM chips; reseated. Partial checkout in MEMTEST86 random number sequence test indicates nominal status.
Despite the exception during ECU write, configuration seems intact and correct. Subsequent executions of ECU completed normally. Noted incorrect system RAM size during initial ECU configuration. It seems this may have been the problem all along as both the EDIT.COM and OS/2 Warp 4.0 boot TRAP symptoms are gone. OS/2 Warp 3 continues to throw exception in device driver A:.
Update: MEMTEST86 continues to record errors throughout the memory map during test 7. Does not seem to be CPU, L2, PSU, RAM, or expansion card related. All indications are that there is a serious problem with the mainboard itself.
Update: This problem has been resolved by the replacement of the faulty L2 cache parts.
After selecting Advanced Installation, the installer stops.
SYS0049: The E: device is not functioning
Insert a disk into the removable media (i.e. Iomega Jaz! 2GB) drive, and retry the operation. You may have to retry more than once, before the installer continues normally. Alternately, you may select the option to return an error to the program, without first inserting removable media; you will need to do this several times before installation continues normally.
The program can be ended to access the OS/2 command interpreter, for troubleshooting purposes. An installation log is present on C:\IBMINST\LOGS\CONINST. To re-start installation, execute F:\IBMINST\CONINST.EXE where F: is the drive with the installation CD loaded.
During installation, the installer stops while copying files from disk 8.
SYS0318: message 3176
Ending the program does not allow access to the OS/2 command interpreter. The system must be rebooted and the installation restarted from the beginning.
Update: This problem has been resolved by the replacement of the faulty L2 cache parts.
Using 8x MT5LC2568-15 DIP28 chips to provide the 256 KB L2 cache expansion (for 512 KB L2 cache total) causes unpredictable memory corruption. This is evidenced by executing the random number sequence (test 7) in MEMTEST86+ and seeing massive damage throughout the memory map. The failing bits and failing locations always vary.
After replacing the PSU and processors to no avail, the problem was finally tracked down by the following methods:
The parts above all require VCC @ 5 VDC. They do not work because apparently the M54Pe supplies 3.3 VDC to VCC on the removable L2 cache.
This part requires Vcc @ 3.3 VDC, but apparently some units have partially failed. After assembling a larger population than the original eight parts which all tested bad, substituting them one at a time into a set of seven working UM61L256K-15 chips and running MEMTEST86+ test 7 for 7-10 minutes seems to have been sufficient to identify failed parts. Eight functioning MT5LC2568-15 parts were found this way, and installed. Machine now passes MEMTEST86+ test 7 (one error recorded over one full loop + 20 minutes of second loop) and appears nominally stable.
Curiously, although all prior recorded instability has been resolved, the Matrox Flash Update tool continues to fail.
BeOS R5 will reboot during detection of keyboard and mouse on M54Pe with AT keyboard port. This can be verified by holding F1 during boot to enable kernel debugging output on serial port 1 (19200, 8N1) and comparing with boot debugging output from M54Pe with PS/2 keyboard port.
The initial loader screen will complete, and the blue desktop will appear, but the system will automatically reboot before anything else appears on the screen. Safe mode boot options do not help. System will not succesfully boot from install media, nor from system installed on another machine.
Part was recovered by installing flash chip with revision 16P into M54Pe with PS/2 keyboard port, and re-flashing to revision 16A. Revision 16A works correctly on either type board.
This revision is probably for PS/2 boards only. This is speculation, however, as I have no documentation for this release.
The PS/2 and AT keyboard ports are electrically identical. A M54Pe mainboard may be converted from PS/2 to AT by removing the PS/2 connectors and soldering in an AT keyboard connector. The board retains its PS/2 mouse circuitry, but is no longer capable of attaching a PS/2 mouse.
Interestingly, the PS/2 board I have converted does not hang at boot if the ECU configures a PCI card at 256 MB like the AT board did, even using the same flash BIOS and ECU levels.
Mixing processor steppings can be hit-or-miss. MEMTEST86+ test 7 will reveal marginal configurations which might appear to work, but be subject to non-deterministic instabilities:
| primary proc. | upgrade proc. | test 7 results |
|---|---|---|
| SY022/SSS | SY028 | fail |
| SY022/SSS | SY022/SSS | pass |
BeOS R5 will reboot during kernel hardware detection if SoundBlaster 32 PnP (CT3600) is configured by the EISA Configuration Utility. Remove the card from the ECU configuration and BeOS will boot successfully, with the SB32 working normally.
Installation will panic with the message cannot assemble driver for root when loading the kernel from CD-ROM if the AHA2940UW host bus adapter is of too recent revision. This is because the older driver does not recognize the PCI ID of the newer card and fails to attach.
The elx driver only manages ~ 17 KB/sec with ftp get, although ftp put achieves normal speeds.
The iprb driver loads with most Intel 82557 ethernet cards, but fails to maintain PHY at DU8 and consequently will not send or receive packets. The driver operates correctly at DU11.
CDE 1.0.2 displays incorrect colors with Matrox Millennium driver when 24 bpp display modes are chosen. The most recent Solaris 2.5.1 x86 Recommended patch cluster corrects the defect.