Hi Finn,
Thanks for testing. "No regressions over v1" means "no regressions", right? Well, what would I compare the driver performance to? With your patches to sort out locking races, the driver is more stable than I've ever seen it in years. That's a definite win. Big improvement over the driver in its current state in m68k and mainstream (which locks up quite reliably with even moderate concurrent IDE and SCSI I/O for me). No regression over v1 or patches that you sent for me to test off-list. On the other hand, I've seen warnings about lost bytes (stuck in the DMA fifo) for the first time _ever_ with the new driver - we've discussed that at length, and it is still unclear why these happen. This is a known NCR5380 issue, and pretty much anything could have precipitated that. Must have happened for other Falcon users before in the past, because the interrupt handler explicitly checks for this condition.
I went back and checked test logs from driver tests before any of your patches - no regressions over vanilla 3.17 or 3.16. The 'lost bytes' error is rare enough that it would not have shown in those tests. Vanilla kernels run into the ST-DMA locking race at about 7% of the total test set. The last kernel that performed with a similar stability as with your patches was 2.4.30 or thereabouts. 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
