From: becker@super.org (Donald J. Becker) Subject: Re: Theory of IRQs ? Date: Fri, 12 Feb 1993 18:41:24 GMT
In article <1lb2ru$8q3@sixgun.East.Sun.COM> tgendron@caneel.East.Sun.COM writes:
>Etherlink II card now conflicts with my HD controller it appears.
>
>I have finally correctly compiled into my SLS .99p2 Kernel the EL2 driver code.
>Upon boot up it sees the card at 0x300 and echos the physical address.
>Shortly after that I get zilloins of HD controller reset still busy... IRQ 5
>messages. I have tried re-jummpering the board but no change.
>
>The kernel HD use to work fine just no networking.
>
>Any suggestions would be appreciated. Do I re-compile with a #define set
>appropriatly? If so which file to I change?
This is a problem with 3c503 driver IRQ selection code. The IRQ line
the 3c503 uses is software selectable from the set {5, 9/2, 3, 4}.
The ethercard driver finds the first IRQ line from that set (in that
order) without a handler and assumes that it is unused. The driver
then programs the 3c503 to use that IRQ line. In this case your SCSI
controller must be using IRQ 5, but the SCSI devices aren't
initialized when the ethercard probe is run.
The easy solution to this problem is to define EI8390_IRQ to '5' and
build a new kernel. To do this, edit 'net/tcp/GNUmakefile' to change
-DEI8390_IRQ=0 (the "autoIRQ" setting) to -DEI8390_IRQ=5.
There are several ways I might be able to fix this problem and retain
the autoIRQ. I welcome comments and suggestions about any of them.
"Twinkle" the selected IRQ line, and use my autoIRQ code to
see if an interrupt actually occured.
Before programming the IRQ line, find out which IRQ lines are
at a '0' level and therefore already in use (even if there
isn't a handler for them yet). Anyone know how to do this?
Defer setting the programming IRQ line until the device is
opened, and provide an ioctl() to change the IRQ. Until
the ioctl is in place you could use a gdb script ;->.
Getting rid of the autoprobe and autoIRQ code is out of the question.
They make setting up the system _much_ easier for first-time users
and my experimental network boot disk can't work without them.
-- Donald Becker becker@super.org Supercomputing Research Center 17100 Science Drive, Bowie MD 21114 301-805-7482