[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: lost interrupt?
"Michael B. Rash" wrote:
>
> Kernel 2.2.14-5.0:
>
> So I had just unsuspended my laptop, and I noticed in my syslog window a
> message popped up "hda1: lost interrupt", and my system was essentially
> unusable after that and had to be hard-rebooted. Poking around in
> drivers/block/ide.c turned up:
>
> if (hwgroup->poll_timeout != 0 || drive_is_ready(drive)) {
> if (hwgroup->poll_timeout == 0) {
> printk("%s: lost interrupt\n", drive->name);
>
> Can someone help me understand what is going on with this (I definitely a
> kernel newbie... _any_ responses would be greatly appreciated)? First of
> all, on a conceptual level what does it mean when an interrupt is "lost"?
I believe it means that the kernel has performed an operation
(say, read or write to the disk) and is expecting an interrupt
when the operation completes, but the interrupt never happens.
That would seem to indicate a hardware problem, if the driver
is a tried-and-true one (which I assume the IDE driver is).
> Second, suppose that in the first 'if' condition is made true by having
> (hwgroup->poll_timeout != 0). Then how could in the next 'if' statement
> the condition (hwgroup->poll_timeout == 0) ever be true? We just checked
> in the previous 'if' condition, and (hwgroup->poll_timeout != 0). Can it
> simply just change that quickly or something?
You're right that if the the first condition is true the way you
suggest, we will never execute the "lost interrupt" bit.
If drive_is_ready() is true, and hwgroup->poll_timeout == 0, then
we've lost an interrupt. It looks like the code we're looking at is
executing with interrupts disabled (there's a cli() a few lines
above), so nothing is going to alter poll_timeout between the
two tests.
-- Joe Knapka
-
Kernelnewbies: Help each other learn about the Linux kernel.
Archive: http://mail.nl.linux.org/
IRC Channel: irc.openprojects.net / #kernelnewbies
Web Page: http://www.surriel.com/kernelnewbies.shtml