.\" 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 "EL_INTERRUPT" "9" "09 October 2005" "" ""

.SH NAME
el_interrupt \- 
.SH SYNOPSIS
"SYNOPSIS"
.sp
\fB
.sp
irqreturn_t el_interrupt  (int \fIirq\fB, void * \fIdev_id\fB, struct pt_regs * \fIregs\fB);
\fR
.SH "ARGUMENTS"
.TP
\fB\fIirq\fB\fR
Interrupt number
.TP
\fB\fIdev_id\fB\fR
The 3c501 that burped
.TP
\fB\fIregs\fB\fR
Register data (surplus to our requirements)
.SH "DESCRIPTION"
.PP
Handle the ether interface interrupts. The 3c501 needs a lot more 
hand holding than most cards. In particular we get a transmit interrupt
with a collision error because the board firmware isnt capable of rewinding
its own transmit buffer pointers. It can however count to 16 for us.
.PP
On the receive side the card is also very dumb. It has no buffering to
speak of. We simply pull the packet out of its PIO buffer (which is slow)
and queue it for the kernel. Then we reset the card for the next packet.
.PP
We sometimes get suprise interrupts late both because the SMP IRQ delivery
is message passing and because the card sometimes seems to deliver late. I
think if it is part way through a receive and the mode is changed it carries
on receiving and sends us an interrupt. We have to band aid all these cases
to get a sensible 150kbytes/second performance. Even then you want a small
TCP window.