A little while ago, I followed up to a message about 1.3 not working on a
4/330.  After, a couple of patches from Jason Wright, I've got my machine
up and running, but all is not OK.  For some reason, the NCR SCSI routines
don't like the chip on the 4/330.  Under 1.2.1, I used to get :

    dma0 at obio0 addr 0xfa001000: rev 0
    esp0 at obio0 addr 0xfa000000 pri 4: ESP100A 24Mhz, target 7
    scsibus0 at esp0
    sd0 at scsibus0 targ 0 lun 0: <MICROP, 1588-15MBSUN0669, SN0C> SCSI1 0/direct fixed
    sd0: 639MB, 1632 cyl, 15 head, 53 sec, 512 bytes/sec
    sd1 at scsibus0 targ 1 lun 0: <MICROP, 1588-15MBSUN0669, SN0C> SCSI1 0/direct fixed
    sd1: 639MB, 1632 cyl, 15 head, 53 sec, 512 bytes/sec
    sd2 at scsibus0 targ 2 lun 0: <MICROP, 1588-15MBSUN0669, SN0C> SCSI1 0/direct fixed
    sd2: 639MB, 1632 cyl, 15 head, 53 sec, 512 bytes/sec
    st0 at scsibus0 targ 4 lun 0: <ARCHIVE, VIPER 150  21531, -004> SCSI1 1/sequential removable
    st0: drive empty
    ss0 at scsibus0 targ 5 lun 0: <HP, C1130A, 3614> SCSI2 3/processor fixed
    ss0: HP ScanJet 4p
    cd0 at scsibus0 targ 6 lun 0: <NEC, CD-ROM DRIVE:502, 2.0r> SCSI2 5/cdrom removable
    
Under 1.3, I get :

    dma0 at obio0 addr 0xfa001000: rev 0
    esp0 at obio0 addr 0xfa000000 pri 4: ESP100A, 24MHz, SCSI ID 7
    scsibus0 at esp0: 8 targets
    probe(esp0:0:0): max sync rate 3.90Mb/s
    sd0 at scsibus0 targ 0 lun 0: <MICROP, 1588-15MBSUN0669, SN0C> SCSI1 0/direct fixed
    sd0: 639MB, 1632 cyl, 15 head, 53 sec, 512 bytes/sect x 1309735 sectors
    probe(esp0:1:0): max sync rate 3.90Mb/s
    sd1 at scsibus0 targ 1 lun 0: <MICROP, 1588-15MBSUN0669, SN0C> SCSI1 0/direct fixed
    sd1: 639MB, 1632 cyl, 15 head, 53 sec, 512 bytes/sect x 1309735 sectors
    probe(esp0:2:0): max sync rate 3.90Mb/s
    sd2 at scsibus0 targ 2 lun 0: <MICROP, 1588-15MBSUN0669, SN0C> SCSI1 0/direct fixed
    sd2: 639MB, 1632 cyl, 15 head, 53 sec, 512 bytes/sect x 1309735 sectors
    esp0: !TC [intr 10, stat 87, step 1] prevphase 6, resid 0
    esp0: illegal command: 0x90 (state 4, phase 6, prevphase 6)
    esp0: !TC [intr 10, stat 87, step 1] prevphase 6, resid 0
    esp0: illegal command: 0x90 (state 4, phase 6, prevphase 6)
    esp0: !TC [intr 10, stat 87, step 1] prevphase 6, resid 0
    esp0: illegal command: 0x90 (state 4, phase 6, prevphase 6)
    esp0: illegal command: 0x90 (state 4, phase 6, prevphase 6)
    esp0: illegal command: 0x90 (state 4, phase 6, prevphase 6)
    esp0: illegal command: 0x90 (state 4, phase 6, prevphase 6)
    esp0: !TC [intr 10, stat 87, step 1] prevphase 6, resid 0
    esp0: illegal command: 0x90 (state 4, phase 6, prevphase 6)
    esp0: !TC [intr 10, stat 87, step 1] prevphase 6, resid 0
    esp0: illegal command: 0x90 (state 4, phase 6, prevphase 6)
    esp0: !TC [intr 10, stat 87, step 1] prevphase 6, resid 0
    esp0: illegal command: 0x90 (state 4, phase 6, prevphase 6)
    esp0: illegal command: 0x90 (state 4, phase 6, prevphase 6)
    esp0: illegal command: 0x90 (state 4, phase 6, prevphase 6)
    esp0: illegal command: 0x90 (state 4, phase 6, prevphase 6)
    probe(esp0:6:0): max sync rate 4.46Mb/s
    sd0(esp0:0:0): max sync rate 3.90Mb/s
    sd1(esp0:1:0): max sync rate 3.90Mb/s
    sd2(esp0:2:0): max sync rate 3.90Mb/s

Without Jason's esp patch, no devices probed (see previous message).

Help!  Any thoughts as to where the problem lies?  I've started looking at
the NCR routines, but could do with a pointer.  The comments in ncr53c9x.c
imply that the '!TC' message is printed when DMA is used to select a target
but I thought that the patch disabled DMA select?  Presumably not everywhere?

The patch that makes the disks visible is :

*** esp.c.dist	Mon Oct  6 12:24:29 1997
--- esp.c	Fri Jan 16 17:41:25 1998
***************
*** 217,222 ****
--- 217,223 ----
  	struct ncr53c9x_softc *sc = &esc->sc_ncr53c9x;
  	struct bootpath *bp;
  	int dmachild = strncmp(parent->dv_xname, "dma", 3) == 0;
+ 	int use_dmaselect = strncmp(parent->dv_xname, "obio", 4);
  
  	/*
  	 * Set up glue for MI code early; we use some of it here.
***************
*** 407,413 ****
  	ncr53c9x_attach(sc, &esp_switch, &esp_dev);
  
  	/* Turn on target selection using the `dma' method */
! 	ncr53c9x_dmaselect = 1;
  
  	bootpath_store(1, NULL);
  }
--- 408,417 ----
  	ncr53c9x_attach(sc, &esp_switch, &esp_dev);
  
  	/* Turn on target selection using the `dma' method */
! 	/* XXX The Sun 4/300 doesn't handle this very well, so it is */
! 	/* XXX disabled if the parent device == "obio" */
! 	/* XXX More research to do here... */
! 	ncr53c9x_dmaselect = use_dmaselect;
  
  	bootpath_store(1, NULL);
  }

Thanks,

J

PS.  Yes I do have 'st*', 'cd*' and 'ss*' in the kernel config.

PPS.  Jason also pointed out a problem that causes a 'fpu cleanup 1' panic
on the 4/330 (it doesn't affect 1.2.1 or 1.3 on an SS4).  Try running :

    #include <stdio.h>
    int
    main() {
        double f;
        char buf[] = "2.2250738585072014e-308";
    
        sscanf(buf, "%le", &f);
        sscanf(buf, "%le", &f);
        return 1;
    }

A workaround for this is :

*** fpu.c.dist	Tue Jul 29 12:40:54 1997
--- fpu.c	Tue Jan 20 08:32:42 1998
***************
*** 107,113 ****
  	switch ((fsr >> FSR_FTT_SHIFT) & FSR_FTT_MASK) {
  
  	case FSR_TT_NONE:
! 		panic("fpu_cleanup 1");	/* ??? */
  		break;
  
  	case FSR_TT_IEEE:
--- 107,120 ----
  	switch ((fsr >> FSR_FTT_SHIFT) & FSR_FTT_MASK) {
  
  	case FSR_TT_NONE:
! #if 0
! 		/* XXX I'm not sure how we get here, but ignoring the trap */
! 		/* XXX seems to work in my limited tests		   */
! 		/* XXX More research to be done =)			   */
! 		panic("fpu_cleanup 1"); /* ??? */
! #else
! 		printf("fpu_cleanup 1\n");
! #endif
  		break;
  
  	case FSR_TT_IEEE:

-- 
    1024/55A5BC19        0F 3F 62 56 18 10 8B 84  43 8F F4 94 93 37 76 AA

S.E.P.