It's emblematic of how far we haven't come: signalling computer system problems with beeps instead of intelligible messages.Yes, I know the excuse - no UI, compatibility with older hardware, and so on. But consider this brief story.
Take a Windows XP machine with Intel D865GBF motherboard. Running fine since 2006. The plan is to convert the boot disk to RAID 1. An existing controller already running in the machine was suitable for the task. Its firmware was out of date and incompatible with the Windows-based "PAM" management tool for the controller. The firmware was updated, the PAM applications and Windows driver to accompany moving from JBOD to RAID 1. The drives were updated to RAID 1 and files restored to it preliminary to making it the boot disk.
Windows booted fine from the old boot disk. After about two minutes, a repeated low - high beep pattern began - using a perfect fourth or fifth. No POST codes matched this symptom. The Intel desktop tools showed nothing out of the ordinary with power levels, temperature or fan settings. The pattern was ceaseless. Some POST codes seemed somewhat plausible, suggesting that the CPU detected a problem with itself, but under light test the O.S. behaved well except for the beeping. The system was rebooted and memory tests run for an hour. No errors were detected.
After much investigation and fruitless web searches, the culprit, if it can be called that, turned out to be the presence of the Promise TX2300 controller, which had been in the system for years. When it was removed, the beeping stopped. The ultimate cause is unclear - possibly there was an indirect consequence of changing to RAID 1, but there were no messages anywhere, not in the event log or in the directory where the Promise driver was installed.
The absurdity of troubleshooting beeps with the full Windows UI present should not be lost on anyone.
No comments:
Post a Comment