wesw@ozvax.WV.TEK.COM (Wes Whitnah) (06/08/89)
My AT-compatible is loosing its CMOS ram quite regularly now (after EVERY power-up) and new batteries have not helped. I recall that someone in netland mentioned a particular batch of faulty chips (Motorolla...?) that many foreign-made systems had installed which caused this type of failure. I believe this is the cause of my system's troubles as it fits this description. Could someone who has this info please mail it to me so I can get this thing fixed? Thanks. Wes Whitnah wesw@ozvax.WV.TEK.COM
mlord@bnr-public.uucp (Mark Lord) (06/09/89)
In article <1724@ozvax.WV.TEK.COM> wesw@ozvax.WV.TEK.COM (Wes Whitnah) writes: > > My AT-compatible is loosing its CMOS ram quite regularly now > (after EVERY power-up) and new batteries have not helped. Funny thing. My AT clone has exactly the same problem. I have even replaced the (socketed) Real Time clock chip but to no avail. Next on the list is to replace the CMOS ram chip if I can figure out which one it is. If anyone else has any ideas, I'd sure love to hear them. My email address is given below. Thanks -Mark utgpu!bnr-vpa!bnr-fos!mlord%bnr-public
karl@ddsw1.MCS.COM (Karl Denninger) (06/11/89)
>----- >Response 1 of 1 (3685) by mlord at bnr-public.uucp on Sat 10 Jun 89 18:05 >[Mark Lord] > >In article <1724@ozvax.WV.TEK.COM> wesw@ozvax.WV.TEK.COM (Wes Whitnah) writes: >> >> My AT-compatible is loosing its CMOS ram quite regularly now >> (after EVERY power-up) and new batteries have not helped. > >Funny thing. My AT clone has exactly the same problem. I have even replaced Hmmm... you guys wouldn't have Tatung machines by any chance, would you? There is a known problme with these. I have had promises from Comark in Glendale Hts (which sold the ones we have seen that have the problem), but nothing more. No prints, no instructions, no part number on the defective chip! I can handle desoldering the buggers, but it's a little much to ask me to get out data books and ID everything in sight that looks like it might be involved! They claim they know what the problem is, and how to fix it. Then again, I am sure the chip isn't socketed. I've already tried replacing every socketed chip on the board with no effect. -- Karl Denninger (karl@ddsw1.MCS.COM, <well-connected>!ddsw1!karl) Public Access Data Line: [+1 312 566-8911], Voice: [+1 312 566-8910] Macro Computer Solutions, Inc. "Quality Solutions at a Fair Price"
hollen@eta.megatek.uucp (Dion Hollenbeck) (06/12/89)
From article <562@bnr-fos.UUCP>, by mlord@bnr-public.uucp (Mark Lord): > In article <1724@ozvax.WV.TEK.COM> wesw@ozvax.WV.TEK.COM (Wes Whitnah) writes: >> >> My AT-compatible is loosing its CMOS ram quite regularly now >> (after EVERY power-up) and new batteries have not helped. > > Funny thing. My AT clone has exactly the same problem. I have even replaced > the (socketed) Real Time clock chip but to no avail. Next on the list is to > replace the CMOS ram chip if I can figure out which one it is. If anyone else > has any ideas, I'd sure love to hear them. My email address is given below. > I had this problem, only more intermittently. I had upgraded my XT to an AT by replacing the motherboard with a 'baby' size AT motherboard. I kept the original XT power supply. About one time in ten, the CMOS would be trashed when I did a power-on. I found out that this was because the XT power supply was spiking the CMOS when turned on. I replaced the power supply with a 'baby' AT supply (200 watt AT in an XT size case) and have not had any problems since. There is a set of programs which I have heard about out there in Netland which capture the contents of CMOS to a file and write the contents of the file back to CMOS. I have asked for anyone to post these before and I ask again, please post!! These programs could help by automatically writing the CMOS from a file which has the correct data each time a boot is done and then re-booting. This will only help, of course, it this problem is intermittent, or only occurs at power-up. If it happens every time, power-up or ALT-CTL-DEL, then I don't see much hope of help from these programs. Dion Hollenbeck (619) 455-5590 x2814 Megatek Corporation, 9645 Scranton Road, San Diego, CA 92121 seismo!s3sun!megatek!hollen ames!scubed/
mlord@bnr-public.uucp (Mark Lord) (06/12/89)
>>> My AT-compatible is loosing its CMOS ram quite regularly now >>> (after EVERY power-up) and new batteries have not helped. >> >>Funny thing. My AT clone has exactly the same problem. I have even replaced > >Hmmm... you guys wouldn't have Tatung machines by any chance, would you? I don't think so.. it's an ancient SAM VIP something or another.. no fancy chipsets etc.. The real time clock keeps on ticking just fine between powerups but the CMOS ram forgets everything any time a hardware reset is issued (such as on a powerup or when I hit the big red button). CTL-ALT-DEL is just fine. I suspected a virus maybe, but booting from original write-protected-since-day-1 DOS diskettes (from MicroSoft) makes no difference. Something strange is going on somewhere. -Mark
jack@focsys.UUCP (Jack Houde) (06/20/89)
In article <562@bnr-fos.UUCP> mlord@bnr-public.UUCP (Mark Lord) writes: >In article <1724@ozvax.WV.TEK.COM> wesw@ozvax.WV.TEK.COM (Wes Whitnah) writes: >> >> My AT-compatible is loosing its CMOS ram quite regularly now >> (after EVERY power-up) and new batteries have not helped. > >Funny thing. My AT clone has exactly the same problem. I have even replaced >the (socketed) Real Time clock chip but to no avail. Next on the list is to >replace the CMOS ram chip if I can figure out which one it is. If anyone else >has any ideas, I'd sure love to hear them. My email address is given below. > >Thanks > >-Mark utgpu!bnr-vpa!bnr-fos!mlord%bnr-public Maybe this will help but, maybe not. We had a similar problem with some of our systems loosing (or showing up as corrupted) CMOS data upon powerup. After lenthy testing, it was discovered that the power supply was at fault. From what I gathered, the power supply was asserting the POWER GOOD line before the power was stable which in turn caused sporadic corruption of the data. We changed the offending power supplies and gone was the problem.