[7643] in linux-scsi channel archive
RE: Linux SCSI seagate (TMC-950) driver help
daemon@ATHENA.MIT.EDU (Egbert Eich)
Mon Dec 6 20:37:33 1999
From: Egbert Eich <eich@hilbert.ikp.physik.tu-darmstadt.de>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <14412.25512.69687.753407@hilbert.ikp.physik.tu-darmstadt.de>
Date: Tue, 7 Dec 1999 02:32:24 +0100 (MET)
To: "Christian Jullien" <eligis@wanadoo.fr>
Cc: "Marc SCHAEFER" <schaefer@alphanet.ch>,
<linux-scsi@vger.rutgers.edu>
In-Reply-To: eligis@wanadoo.fr wrote on Monday, 6 December 1999 at 21:41:20 +0100
Christian Jullien writes:
> > I second the other guy who said that maybe you are not at all getting any
> > interrupts. I looked quickly through seagate.c and the only case
> > I see the
> > interrupt routine called is for reselection.
>
> So, if I understand well, every times I send a request, I'm busy waiting for
> the response while, when I allow disconnect I should be waken up by an IRQ ?
> right ?
Yes, that's how it works.
>
> > Try really hard to change interrupts, etc. Disabling disconnection seems
> > like a remedy for the wrong problem.
>
> Now I agree with you.
>
> I'm confused, what wrong ? I assumes that my IRQ (5 in my case) is well
> configured (it's the same IRQ 5, MEM 0x140, base 0xCA000 on my NT box). What
> can I do if linux can't send me a request via IRQ 5 ? How I can track that
> (i.e. trace IRQ ?) is there a tool to show possible conflicts ? Should I
> give up ?
No, I don't think so. You should try some more.
Bach in the early days of Linux (0.96 or so) I had problems with
the seagate, too. It took me month to find out that the kernel
tack was overflowing do to the recursive nature of disconnect/reconnect
handling that the driver was using then. When I posted this I learned
that somebody else (I don't recall who it was) just had a patch for that.
Regards,
Egbert.
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@vger.rutgers.edu
