Hi Finn,
>> Leaves the current instability - I did some work on the CT60 accelerator
>> (reflashed the firmware so I can use the CTPCI board). This might have
>> caused the system to become more unstable. Needs more investigation.
>
> I gather from the emails we've exchanged that the "current" instability
> (data corruption) dates back to March or thereabouts, so it is unrelated
> to this patch series.
Absolutely right - meant to add that but got interrupted in that train
of thought :-(
> The lockups have been resolved, which leaves only the ST DMA FIFO issue,
> which seems to be an old problem. From the comments in atari_scsi, it
> doesn't look like this was ever resolved.
>
> /* If the DMA was active, but now bit 1 is not clear, it is some
> * other 5380 interrupt that finishes the DMA transfer. We have to
> * calculate the number of residual bytes and give a warning if
> * bytes are stuck in the ST-DMA fifo (there's no way to reach them!)
> */
> if (atari_dma_active && (dma_stat & 0x02)) {
> unsigned long transferred;
>
> transferred = SCSI_DMA_GETADR() - atari_dma_startaddr;
> /* The ST-DMA address is incremented in 2-byte steps, but the
> * data are written only in 16-byte chunks. If the number of
> * transferred bytes is not divisible by 16, the remainder is
> * lost somewhere in outer space.
> */
> if (transferred & 15)
> printk(KERN_ERR "SCSI DMA error: %ld bytes lost in "
> "ST-DMA fifo\n", transferred & 15);
>
> Presuming that this is an old issue (apparently timing sensitive), we can
> conclude that no regressions were observed in your tests. I'm content with
> this presumption. I gather that you are too, or you would not have sent a
> "tested-by" tag. Which seems to put the ball in Geert's court?
Right again - though it's probably not Geert but James who needs to
give the go-ahead.
Cheers,
Michael
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
