advice i can give .. 1) it is possible the controller is faulty. i had a BRAND new drive die within hours/days when connected to a faulty controller. 2) get a diagnostics program for the drive/controller, unfortunately such programs do not come cheap, i suggest Microscope, availlable at www.micro2000.com 3) purchase a drive that has a diagnostics program for it, IBM has *EXCELLENT* diagnostics for their drives(their software is on their site) and maxtor also has a diagnostics programs(they forced me to run it before they would issue me an RMA#) that way you can at least tell for sure if the drive is faulty, kernel errors are a good sign but its usually not a sure thing until you start suffering data loss. 4) also never never ever do a bios low level format on an ide drive unless the program comes from the maker of the drive, low level formatting an IDE drive has about a 99% chance of destorying the drive, for good. Really old IDE drives (say 420MB and smaller) didn't have a problem with low level formats, but newer drives do. I can't explain why it destorys an IDE drive(when it is actually reccomended and sometimes required on a SCSI drive), i've seen it happen many many times and read countless people reccomend against it.
hope this helps, if you have more questions lemme know . nate On Sun, 2 Jan 2000, Damon Muller wrote: dm-deb >Hi folks, and happy new year! dm-deb > dm-deb >We have seen people posting about the kernel error message of dm-deb >Lost_Interupt (or something similar) reasonably regularly, and then dm-deb >people usually post back saying 'your HD is about to die, replace it', dm-deb >and everyone then goes back on with their lives. dm-deb > dm-deb >I too have had this error, and assumed that the HD was just going bad dm-deb >(which was confirmed by doing a BIOS low-level format). No-one likes it dm-deb >when a HD dies, but everything has a useful life-span. dm-deb > dm-deb >However, I recently installed debian onto a machine, where this error dm-deb >again showed up, twice, on different drives (on oldish, one brand new, dm-deb >both from different manifacturers). The larger, newer drive was the dm-deb >first to go - the drive made weird noises, spouted the error lots of dm-deb >times. When I got around to running a fsck on the drive, most of the dm-deb >contents had ended up in lost+found, and I basically had to write the dm-deb >installation off. dm-deb > dm-deb >I tried to convice the owner of said computer that it might have been a dm-deb >faulty drive (there is an identical one running in a Mandrake 6.1 dm-deb >machine which has had no problems). I then got the smaller, older drive dm-deb >in the same machine, and reinstalled onto that (I have been using this dm-deb >smaller drive as the root drive, with /home and /var on the larger, dm-deb >newer drive). After a few hours of reinstalling everything (the machine dm-deb >had not yet gone into production, so there was no backup), and dm-deb >installing the latest kernel (2.2.13, 2.2.12 had been running when the dm-deb >drive died), everything seems h?ppy. dm-deb > dm-deb >I get back from my new-years camping trip, and about an hour later I get dm-deb >a call to say that the machine has died again, this time with the other dm-deb >(older drive). Same symptoms - the owner turned off the computer when dm-deb >the drive went nuts (those who had heard it know it's not a pretty sound dm-deb >to hear from a delicate piece of electronics!), and although I have yet dm-deb >to see it in person, I'm not going to surprised if this drive is cactus dm-deb >as well (this time we have a backup). dm-deb > dm-deb >So, what do we have. Two drives - different sizes, different ages, dm-deb >different manifacturers, one the primary master, the other the secondary dm-deb >master. Two different kernels, both with CONFIG_IDEDMA_AUTO=n (which dm-deb >some have suggested might help), both with all the various IDE chipset dm-deb >workarounds enabled. An extremely vanilla installation of debian 2.1 dm-deb >(with all the latest official add-ons, and non of the non-offical ones). dm-deb >We have an identical drive working flawlessly in both other linux and dm-deb >windows NT machines. The same machine (with same drives) also ran with dm-deb >no problems with an NT installation). In both cases, the problem dm-deb >manifested after the machines had been running 24/7 for a few weeks (not dm-deb >sure exacly how long, but at least 14 days). dm-deb > dm-deb >It is *possible* that both drives were faulty and about to die anyway, dm-deb >but it looks very unlikely to me that they would both die in the same dm-deb >machine in the same way. dm-deb > dm-deb >Unfortunately I don't have the make and model of the motherboard with dm-deb >me, but it was running a Cyrix 266 chip in a fairly generic motherboard, dm-deb >the same combination we run in other machines with no problems that I am dm-deb >aware of. If I had to guess, I'd say that maybe the kernel didn't like dm-deb >the IDE controller (don't know make/model again), but it sounds like a dm-deb >pretty lame excuse when other OSs didn't have any problem with it. dm-deb > dm-deb >This machine was to be our new main server, running mail, dns, web, ppp, dm-deb >firewall, all the mod cons. I managed to successfully argue running dm-deb >debian, because if I was administering it, I wanted something I knew dm-deb >well. Of course, since we have never had a problem with any of our other dm-deb >RedHat or Mandrake boxes, Debian is being singled out as the culprate. dm-deb >I'm being told I should install RedHat, and forget debian, as it's the dm-deb >cause of all the woes in the world. I'd be very suprised if anything dm-deb >partiular in debian was the problem, more likely to be a kernel issue, I dm-deb >would think, which means it's distribution independent. But if I don't dm-deb >come up with a solution soon, it's going to be back to redhat (or worse dm-deb >still, NT)... dm-deb > dm-deb >Switch MBs/Machines might be a solution, but the sad fact is that if I dm-deb >have to use a new MB, I'm going to be going back to a P100 or something, dm-deb >which is not an accpetable solution, as far as I'm concerned. dm-deb > dm-deb >I *know* this issue has come up before, and I'm pretty sure no-one has dm-deb >suggested a plausible solution other than 'dump the hardware'. Should I dm-deb >just swap motherboards, go back to an underpowered machine (yes, it's dm-deb >all relative, I know, but I've had to fight to get good hardware for the dm-deb >linux servers)? Is there a chance it's debian related? dm-deb > dm-deb >Any suggestions will be greatly appreciated. dm-deb > dm-deb >cheers, dm-deb > dm-deb >damon dm-deb > dm-deb >-- dm-deb >Damon Muller ([EMAIL PROTECTED]) / It's not a sense of humor. dm-deb >* Criminologist / It's a sense of irony dm-deb >* Webmeister / disguised as one. dm-deb >* Linux Geek / - Bruce Sterling dm-deb > dm-deb > dm-deb >-- dm-deb >Unsubscribe? mail -s unsubscribe [EMAIL PROTECTED] < /dev/null dm-deb > ----------------------------------------[mailto:[EMAIL PROTECTED] ]-- Vice President Network Operations http://www.firetrail.com/ Firetrail Internet Services Limited http://www.aphroland.org/ Everett, WA 425-348-7336 http://www.linuxpowered.net/ Powered By: http://comedy.aphroland.org/ Debian 2.1 Linux 2.0.36 SMP http://yahoo.aphroland.org/ -----------------------------------------[mailto:[EMAIL PROTECTED] ]-- 11:11pm up 135 days, 11:07, 4 users, load average: 1.88, 1.76, 1.66
