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.

Bob