summaryrefslogtreecommitdiffstats
path: root/sys/dev/esp
diff options
context:
space:
mode:
authorscottl <scottl@FreeBSD.org>2005-04-22 03:37:10 +0000
committerscottl <scottl@FreeBSD.org>2005-04-22 03:37:10 +0000
commit92c02688a62def0d758581d08857d9580dfa1900 (patch)
tree61deb91169fc9481696a518039e172adf23764a1 /sys/dev/esp
parent31cfb7f24206d3a671772a4a3cd12167a7eb8543 (diff)
downloadFreeBSD-src-92c02688a62def0d758581d08857d9580dfa1900.zip
FreeBSD-src-92c02688a62def0d758581d08857d9580dfa1900.tar.gz
If we get interrupted during a data phase and the DMA engine is still
pumping data despite our scsi data counters being at 0, something has gone massively wrong. The consequence of happily ignoring this is more DMA phase errors and a disk full of spammed sectors. Instead, panic on the first occurance to hopefully limit the damage. MFC After: 3 days
Diffstat (limited to 'sys/dev/esp')
-rw-r--r--sys/dev/esp/ncr53c9x.c6
1 files changed, 6 insertions, 0 deletions
diff --git a/sys/dev/esp/ncr53c9x.c b/sys/dev/esp/ncr53c9x.c
index 8523a4b..f9f08b4 100644
--- a/sys/dev/esp/ncr53c9x.c
+++ b/sys/dev/esp/ncr53c9x.c
@@ -2228,6 +2228,11 @@ again:
* a DATA transfer. Print a diagnostic
* if the DMA counter and TC bit
* appear to be out of sync.
+ *
+ * XXX This is fatal and usually means that
+ * the DMA engine is hopelessly out of
+ * sync with reality. A disk is likely
+ * getting spammed at this point.
*/
device_printf(sc->sc_dev, "!TC on DATA XFER"
" [intr %x, stat %x, step %d]"
@@ -2237,6 +2242,7 @@ again:
sc->sc_espstep,
sc->sc_prevphase,
ecb ? ecb->dleft : -1);
+ panic("esp: unrecoverable DMA error");
}
}
}
OpenPOWER on IntegriCloud