Subject: Eek! Didn't think of this!
To: None <port-sparc@NetBSD.ORG>
From: Jason Thorpe <thorpej@xenotropic.com>
List: port-sun3
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;