[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/