.\" This manpage has been automatically generated by docbook2man 
.\" from a DocBook document.  This tool can be found at:
.\" <http://shell.ipoline.com/~elmert/comp/docbook2X/> 
.\" Please send any bug reports, improvements, comments, patches, 
.\" etc. to Steve Cheng <steve@ggi-project.org>.
.TH "UNEXPECTED_INTR" "" "06 October 2005" "" ""

.SH NAME
unexpected_intr \- handle an unexpected IDE interrupt
.SH SYNOPSIS
"SYNOPSIS"
.sp
\fB
.sp
void unexpected_intr  (int \fIirq\fB, ide_hwgroup_t * \fIhwgroup\fB);
\fR
.SH "ARGUMENTS"
.TP
\fB\fIirq\fB\fR
interrupt line
.TP
\fB\fIhwgroup\fB\fR
hwgroup being processed
.SH "DESCRIPTION"
.PP
There's nothing really useful we can do with an unexpected interrupt,
other than reading the status register (to clear it), and logging it.
There should be no way that an irq can happen before we're ready for it,
so we needn't worry much about losing an ``important'' interrupt here.
.PP
On laptops (and ``green'' PCs), an unexpected interrupt occurs whenever
the drive enters ``idle'', ``standby'', or ``sleep'' mode, so if the status
looks ``good'', we just ignore the interrupt completely.
.PP
This routine assumes \fB__cli\fR is in effect when called.
.PP
If an unexpected interrupt happens on irq15 while we are handling irq14
and if the two interfaces are ``serialized'' (CMD640), then it looks like
we could screw up by interfering with a new request being set up for 
irq15.
.PP
In reality, this is a non-issue.  The new command is not sent unless 
the drive is ready to accept one, in which case we know the drive is
not trying to interrupt us.  And \fBide_set_handler\fR is always invoked
before completing the issuance of any new drive command, so we will not
be accidentally invoked as a result of any valid command completion
interrupt.
.PP
Note that we must walk the entire hwgroup here. We know which hwif
is doing the current command, but we don't know which hwif burped
mysteriously.