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-m68k" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
