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 [EMAIL PROTECTED]
