[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: hda:lost interrupt!!!

Owen Heisler wrote:
On Mon, 2007-04-30 at 08:48 -0700, Andrew Sackville-West wrote:
On Mon, Apr 30, 2007 at 05:26:13PM +0530, shyam narayanan wrote:
hi all,
I had a perfect debian installation and as i boot up i am getting the
error messsage
hda:lost interrupt
hda:DMA interrupt recovery
hda:dma_timer_expiry:dma status == 0x24
these three messages are coming in loop each taking some time :(
mine is an intel pentium D processor and HDD is a 40gb seagate of
model ST340810A
I'd look for potential hardware failure of that hd.

Yeah, prepare for that drive to completely melt down soon, so you aren't
taken by surprise if it actually does.

I had a system with a chipset fan that would die intermittently,
allowing the chipset to overheat.  By the time I figured out what was
happening and got the fan replaced, the chipset had been damaged.  I got
DMA errors (like yours) a lot on the second IDE controller.  Other than
that, I didn't have any problems.

I would suggest also doing some tests (memtest86) and disabling DMA on
that drive.

Also, perhaps a bad cable could cause that...?  Unlikely I suppose.

I've had 'lost interrupt' problems on a couple of machines, but not related to hard disks (at least for the second system).

I recently purchased an HP AMD64 laptop, planning to install Debian's 64 bit version. During install, all was OK, but on booting the new system I got intermittent hangs. Googling came up with several possible work arounds. The one that works, in my case, is to boot with the kernel option 'noapic' ;(

Now, I get errors about IRQ 7, nobody cared, and the system disables it. According to KDE info center, int7 is related to the USB ehci controller. This disabling happens whether or not there's anything connected to the USB ports.

Since the system doesn't stay up for long if booted without that option, I cannot determine if this IRQ would get disabled in any case, or if it's because of the option.

In any case, it would seem to me that possible bugs in the relevant kernel drivers or IRQ routines could contribute, as well as buggy or otherwise broken APIC chips.

It would be nice to know if there are any diagnostic tools that could be used to help isolate the problem. I don't know much about memtest86, but the name would imply it may not be helpful in this case.


Attachment: smime.p7s
Description: S/MIME Cryptographic Signature

Reply to: