aboutsummaryrefslogtreecommitdiff
path: root/sys/dev/esp
diff options
context:
space:
mode:
authorScott Long <scottl@FreeBSD.org>2005-04-22 03:37:10 +0000
committerScott Long <scottl@FreeBSD.org>2005-04-22 03:37:10 +0000
commit4bd55c43ea6e3ff5ae3f5ea340e16807ca914104 (patch)
tree61deb91169fc9481696a518039e172adf23764a1 /sys/dev/esp
parent7d60dc524baf24d04e15ec2c0f41b9257017e37f (diff)
downloadsrc-4bd55c43ea6e3ff5ae3f5ea340e16807ca914104.tar.gz
src-4bd55c43ea6e3ff5ae3f5ea340e16807ca914104.zip
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
Notes
Notes: svn path=/head/; revision=145386
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 8523a4b623ca..f9f08b4e4f74 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");
}
}
}