Re: SCSI Kernel Problem - BAD

Simon Shapiro (Shimon@i-connect.net)
Mon, 11 Mar 1996 16:25:46 -0600 (CST)

Hi "Leonard N. Zubkoff"; On 10-Mar-96 you wrote:
> > Date: Sat, 9 Mar 96 00:27 EST
> From: eric@aib.com (Eric Youngdale)
>
> The only way I have ever been able to exercise this is by
> using the scsi-debug fake host adapter, and by then running all of the
> scsi code in user mode under gdb. Crude, but before I was able to do
> something like this, the abort/reset code was completely useless.
>
> That certainly explains a few things. I can't claim to really understand all
> the permutations of reset/abort handling that code attempts. I am going to
> attempt to prototype some changes to scsi.c togerther with my BusLogic driver
> along the lines I discussed in the long message I sent recently. Hopefully, I
> will be able to come up with a 100% stable solution. I'm rather leery of
> making wholesale changes to code I don't really understand completely right
> before a release. Once there is *a* solution, we can try to figure out how
> best to generalize it and where the boundary between the mid level code and
> driver code ought to be.

Thanx for the interest and help (moral support so far :-). More input on the
problem:

I disabled the calls to scsi_reset in scsi.c and enabled TIMEOUT_DEBUG. I get
a LOT of timeout reports, but the disks do not lock up now.
As I said in another reply, tapes really aggravate the situation. Tape speed
is not important. Use a tape and suddenly a good disk times out all the time.

there is a nasty race condition here. Leonard, i am able to produce and
re-produce this problem at will. i also have 5 wide/differential HP drives
hooked up to a PCI Wide SCSI BusLogic. Can test any patch you want in
minutes. Let me know.

Sincerely Yours,
(Sent on 03/11/96, 16:25:46)
Simon Shapiro i-Connect.Net, a Division of iConnect Corp.
Shimon@i-Connect.Net 13455 SW Allen Blvd., Suite 140 Beaverton OR 97008