Messages in this thread | | | Date | Mon, 11 Mar 1996 16:25:46 -0600 (CST) | From | Simon Shapiro <> | Subject | Re: SCSI Kernel Problem - BAD |
| |
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
| |