Messages in this thread | | | Date | Fri, 1 Oct 1999 20:50:20 -0700 | From | "Leonard N. Zubkoff" <> | Subject | Re: FlashPoint card hanging system (BT-950) |
| |
Date: Wed, 29 Sep 1999 11:33:56 -0500 (CDT) From: welash@xnet.com (William Lash)
[snip]
Anyway, I find that the interrupt is entered due to a BUSFREE indication in the interrupt status register. The ISR goes down, and calls phaseBusFree(), presumably to handle that condition, but the bit never seems to get cleared in the interrupt status register.
Of course, the interesting question is, "Why does this only show up with a faster processor?". There seem to be 2 possibilities, either the faster processor causes the original BUSFREE interrupt to occur in such a way that the normal BUSFREE handling can't clear it, or that the faster processor makes it so that the code that is supposed to clear the BUSFREE condition doesn't work correctly.
Anyway, attached below are the patch that I used to gather data, and the logged results from mounting the CD several times. The patch contains code to detect other conditions in the ISR that I thought might cause problems as well. Any ideas about what to try would be appreciated. I will forward a copy of this to mylex tech support as well. It looks like the FlashPoint.c file is basically some code from their development kit.
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.
(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.
Leonard
- 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/
| |