Date: 03/01/06 (Computer Geeks)    Keywords: virus, web, spyware, microsoft

Putting this out to a number of folks, in the hopes that someone can provide some insight:



Getting the following message, inconsistently:

-------------------------------------------------------------------------------------------

*** STOP: 0x000000A5 (0x00000006,0x00000000,0x00000000)
The ACPI BIOS in this system is not fully compliant with the ACPI specification. Please red the README.TXT for possible workarounds. You can also contact your system's manufacturer for an updated BIOS, or visit http://hardware-update.com to see if a new BIOS is available.

The BIOS in this system is not fully ACPI compliant. Please contact your system vendor or visit http://www.hardware-update.com for an updated BIOS. If you are unable to obtain an update BIOS or the latest BIOS supplied by your vendor is not ACPI compliant, you can turn off ACPI during text mode setup. To do this, simply press the F7 key when you are prompted to install storage drivers. The system will not notify you that the F7 key was pressed -- it will silently disable ACPI and allow you to continue your installation.

-------------------------------------------------------------------------------------------

Okay, now..

The platform is a Dell Latitude C610, about five years old, with 1024M RAM in two parallel chipsets (512M each) -- this is the max. cap. for the stock system; HDD is an 80G (nom.) Hitachi. System is set up with triple boot: 1) Ubuntu (Breezy) -- default, 2) Knoppix (also 2nd-to-last stable build), and Win2K/Pro (heavily patched with Dell and MS). I mostly use the Win, because it supports my wifi card, as well as most multimedia. I usually do a complete purge and reinstall each year; this is about two months overdue right now, so there's some evidence of Windows artifacts I'm having. (I'm not including any of those here, since I don't believe they have anything to do with this issue, and because I don't see how Windows artifacts could affect the BIOS or system startup.) The multiboot is available through a selection interface provided under grub, which was installed under Ubuntu; grub replaced lilo, which was installed under Knoppix, as Ubuntu was installed last. Grub was installed in the MBR.

The message comes up most often on startup (or reboot), but sometimes without warning during use. The system halts completely, puts the message up, and that's it. It always requires a hard boot to get past it.

The issue may repeat a number of times in a row, and downtime does not seem to make any difference. Letting the system rest overnight may or may not work, and restarting it without rest over and over eventually results in a stable session. Just by example, this current session came after multiple restarts (most of them automatic, but quite a few also called, using the hardware switch), and this cycle of errors occured after many hours of downtime.

Following the instructions, I went to Dell's website, which provides excellent support. Dell confirms that my BIOS is fully up to date, and I would be awfully surprised if anyone other than Dell had a more current version.

Possibly related, I sometimes get this error, which only occurs at startup (or reboot):

"Memory write/read failure at [ADDRESS], read [VAL1] expecting [VAL2].
Memory address line failure at [same ADDRESS], read [VAL2] expecting [some other Value]."

The ADDRESS and VALs are different from one occurrance to another. I don't know if this indicates failure in a number of registers, or if it's just hitting an error by chance as it comes through some random register. If, as I suspect, a line spike is responsible, then there may be quite a number of damaged RAM registers. However, the inconsistency of the error, together with the fact that I can't imagine why it would seek different addresses at different startups (especially with no sessions in between), seems to argue against this. It would, however, be awfully convenient if the problem could be solved just by swapping out some RAM.

Now, these problems started right after the big blizzard we had. I suspect that a power spike might have frizzled some logic or memory hardware, or possibly corrupted some firmware. (It would be possibly useful, as a troubleshooting measure, to force a BIOS rewrite, but the interface in Dell's update patch detects the current BIOS ver. and won't allow a force overwrite. Don't know if a diff. ver. exists that would allow a forced overwrite, so unable to verify that BIOS is uncorrupted.)

The problem is not Windows-related; Ubuntu also fails on some startups, before the OS can launch, and sometimes after. (I haven't tried to see if Knoppix also suffers, but I have to assume that it would.) The errors occur most often at BIOS startup, before any OS is selected and launched.

Having said that, while the memory error (which is infrequent) always hits right at the very start of startup (before Setup is available), the ACPI message may occur at seemingly any time during system startup, OS startup, or normal use, so while it may involve a BIOS corruption, it's apparently unrelated to the startup sequence itself.

Malicious ware is not indicated: The system has repeatedly passed checks for viruses, spyware, adware, and rootkits.

It may or may not be related, in part or in whole, to some file corruption: I do regular cleaning and defrag, but for reasons unclear to me, there is substantial data that cannot be defragged. Thanks to some genius at Microsoft, more recent versions of Windows no longer provide a standalone DOS, and some DOS processes (e.g., chkdsk /f) cannot be run while Windows is running. I will try to do this from outside the OS, but I don't know how much luck I'll have. It's possible to instruct it to run these processes on next startup, but this is not working for me; I suspect this may be related to the grub multiboot process, which perhaps defeats automated pre-Win startup instructions. I will also try to investigate this, and any pointers are greatly appreciated. A nice chkdsk /f never hurts.

The problem is inconsistent; sometimes -- as now, for example -- the system behaves properly, sometimes for hours, sometimes all day and night, sometimes only for a few minutes. This leads me to some other theories, such as a possible physical circuit fault inside the box (perhaps triggered by some external event, such as atmospheric changes or some kind of vibration of cabinet motion); I can't help but wonder if the battery is involved in this.

I will try some other things to see if I can run this problem down, before I get to swapping out RAM or buying a costly new battery, but in the meantime I want to put this out to see if anyone can offer any insights that might save me a lot of time and effort (and possibly money).

Source: http://community.livejournal.com/computergeeks/886615.html