Re: FlashPoint card hanging system (BT-950)

William Lash (welash@xnet.com)
Sun, 3 Oct 1999 00:48:13 -0500 (CDT)

>
> Mylex's FlashPoint code is overly sensitive to timing issues in my experience.
> At one point in time I attempted to get their code working with memory mapped
> access rather than I/O mapped access, and the code became quite flakey in ways
> similar to what you describe. My best guess was that the code depended on the
> slowness of the I/O instructions to operate reliably without voiolating the
> SCSI specification. Since they never released a memory mapped driver
> themselves, it didn't appear that the code had been thoroughly tested.
>
> Operation of the FlashPoint host adapters has also been problematic with
> non-Intel chipsets, and this may well be due to similar timing issues. I would
> suggest a couple of additional experiments to try to track this down further:
>
> (1) Add a short delay at the beginning of the ISR to see if the register value
> is somehow being read too soon and has the wrong value. udelay(10) would
> probably be sufficient.

I tried this, and it didn't seem to have any effect on the problem

>
> (2) Redefine the OS_ input/output macros to introduce a short delay (udelay(1)
> perhaps) before the actual input/output instruction to see if the changed
> timing corrects the problem. Higher speed I/O access may be sampling a SCSI
> signal too soon.

This, however, seems to have done the trick for me. I have not seen any
of the errors that I was seeing before when doing my old trick of repeatedly
mounting and unmounting a cd in my SCSI CDRW Drive. I was also able to
burn a CD in the drive, which used to cause the problem as well.

I am still leaving in the code that detects more than 50 iterations
through the outher while loop in the interrupt, just to prevent a
total freeze if this problem raises it's ugly head again. Since I
don't have anything really important on the SCSI bus right now, I am
not very concerned about resetting the adapter. About the worst thing
that could happen to me in this instance would be screwing up a CDR disc.
If I had SCSI hard disks, I might be less likely to leave it in, but in
the end I think it might be a good addition to the driver to try to
detect if a "stuck in the interrupt handler" condition happens, and
try to recover from the situation.

Below is a patch to the FlashPoint.c file that just changes the OS_*
macros to add a delay. I have applied this on top of the old patch
I was using to do the "stuck in interrupt" detection.

Bill Lash
welash@xnet.com

--- orig.FlashPoint.c Sat Oct 2 23:48:26 1999
+++ FlashPoint.c Sat Oct 2 21:41:39 1999
@@ -28,12 +28,12 @@
#undef BUSTYPE_PCI


-#define OS_InPortByte(port) inb(port)
-#define OS_InPortWord(port) inw(port)
-#define OS_InPortLong(port) inl(port)
-#define OS_OutPortByte(port, value) outb(value, port)
-#define OS_OutPortWord(port, value) outw(value, port)
-#define OS_OutPortLong(port, value) outl(value, port)
+#define OS_InPortByte(port) (udelay(1),inb(port))
+#define OS_InPortWord(port) (udelay(1),inw(port))
+#define OS_InPortLong(port) (udelay(1),inl(port))
+#define OS_OutPortByte(port, value) (udelay(1),outb(value, port))
+#define OS_OutPortWord(port, value) (udelay(1),outw(value, port))
+#define OS_OutPortLong(port, value) (udelay(1),outl(value, port))
#define OS_Lock(x)
#define OS_UnLock(x)

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/