Subject: Eek! Didn't think of this!
To: None <port-sparc@NetBSD.ORG>
From: Jason Thorpe <thorpej@xenotropic.com>
List: port-sparc
Date: 01/04/1996 01:17:31
[ Cc'd to port-sun3 because this might be a problem there, too... ]
So, I had the occasion to want a crash dump (so I could keep the process
table around to debug something else) on my 4/260 today, which has been
running the new si driver (which I committed the other day) for a long
time...
The reason for the panic was along the lines of "kernel fault" (sorry, no
crash dump... :-/), and all was going fine until the si driver attempted
to kdvma_mapin() the buffer, which only made matters worse. Needless to
say, my poor Sun 4 was quite confused and I couldn't get a crash dump.
This is clearly a bug in the si driver, so I went poking around and
discovered that there's not really a way to tell a SCSI driver to _not_
use DMA (or DVMA, in this case) during a crash dump. A mechanism to
specify polling (rather than interrupts) exists and is used properly.
(This doesn't appear to be a problem with the esp driver? I guess it's
DVMA resources are pre-allocated? Am I missing something? I'll admit I
haven't really gone through that driver thoroughly in a Long Time :-)
So, I thought perhaps that adding a global in machdep.c and setting it
to true in dumpsys() would work. This could be checked before the driver
does its call to kdvma_mapin(), and revert to PIO if true. Well, it
works, but it seems kind of icky...Thoughts?
(Oh yeah .. patch below...)
------------------------------------------------------------------------------
Jason R. Thorpe thorpej@Xenotropic.COM
Just me and my collection of obsolete computer gear(s).
Index: sparc/machdep.c
===================================================================
RCS file: /usr/og/devsrc/netbsd/src/sys/arch/sparc/sparc/machdep.c,v
retrieving revision 1.1.1.1
diff -c -r1.1.1.1 machdep.c
*** machdep.c 1995/12/19 17:27:01 1.1.1.1
--- machdep.c 1996/01/04 09:11:33
***************
*** 716,721 ****
--- 716,723 ----
return (p + BYTES_PER_DUMP);
}
+ int dump_in_progress = 0; /* XXX so SCSI won't try to use DVMA */
+
/*
* Write a crash dump.
*/
***************
*** 729,734 ****
--- 731,742 ----
register int nmem;
extern struct memarr pmemarr[];
extern int npmemarr;
+
+ /*
+ * XXX Ick.
+ * Make sure SCSI/other code doesn't do something it shouldn't.
+ */
+ dump_in_progress = 1;
/* copy registers to memory */
snapshot(cpcb);
Index: dev/si.c
===================================================================
RCS file: /usr/og/devsrc/netbsd/src/sys/arch/sparc/dev/si.c,v
retrieving revision 1.5
diff -c -r1.5 si.c
*** si.c 1996/01/01 21:51:45 1.5
--- si.c 1996/01/04 09:12:16
***************
*** 624,629 ****
--- 624,630 ----
struct si_dma_handle *dh;
int i, xlen;
u_long addr;
+ extern int dump_in_progress; /* XXX */
#ifdef DIAGNOSTIC
if (sr->sr_dma_hand != NULL)
***************
*** 635,640 ****
--- 636,648 ----
if ((sc->sc_options & SI_ENABLE_DMA) == 0)
return;
#endif
+
+ /*
+ * If we're the doer-of-a-crash-dump, we shouldn't try to
+ * use DVMA, because we might only make things worse.
+ */
+ if (dump_in_progress)
+ return;
addr = (u_long) ncr_sc->sc_dataptr;
xlen = ncr_sc->sc_datalen;