Dear vs3100 people,
   I may have located the problem with the vax 3100 having trouble after
6/25.  On 6/25 ncr.c was changed to have:
===== ncr.c line 152 =====
        /*
         * DMA area mapin.
         * On VS3100, split the 128K block between the two devices.
         * On VS2000, don't care for now.
         */
#define DMASIZE (64*1024)
        if (va->va_paddr & 0x100) { /* Secondary SCSI controller */
                sc->ncr_off = DMASIZE;
                sc->onlyscsi = 1;
        }
        sc->ncr_addr = (caddr_t)va->va_dmaaddr;
        ncr_dmasize = min(va->va_dmasize, MAXPHYS);
====================
If I take the 6/26 sources I have the problem of newfs failing with 
read only disk.
If I comment out the line:
               sc->ncr_off = DMASIZE
and rebuild the kernel the newfs seems to be happy.

The value va->va_dmasize is 0x0000fc00
Both scsi drives are on the second scsi controler.  The tkxx drive is on
the first scsi controler but has no tape in it.

I'm rebuilding a ALPHA2 kernel with the ncr_off setting line commented out
to see if the ALPHA2 sources work with that mod.

Where do we get docs to find out how the DMA on the 3100 should really
work.

johnh...

On Thu, 28 Sep 2000, John Hayward wrote:

> Date: Thu, 28 Sep 2000 18:43:27 -0500 (CDT)
> From: John Hayward <johnh@ImapStu.wheaton.edu>
> To: Andrew Gillham <gillham@vaultron.com>
> Cc: Matthias Buelow <token@cip.informatik.uni-wuerzburg.de>,
>      port-vax@netbsd.org
> Subject: Re: 1.5_ALPHA2 on VS3100/m30 and external SCSI
> 
> I verified that if I update sys sources to 6/25 I don't have the problem
> while if I update to 6/26 I observe the problem.
> I noted that I needed to do a make depend not just make because at least
> one header file had changed it's name (something like from vm_prot.h to
> uvm_prot.h)
> 
> I'll look to see if I can find out what changed over that period of time.
> johnh...
> On Thu, 28 Sep 2000, John Hayward wrote:
> 
> > Date: Thu, 28 Sep 2000 08:26:08 -0500 (CDT)
> > From: John Hayward <johnh@ImapStu.wheaton.edu>
> > To: Andrew Gillham <gillham@vaultron.com>
> > Cc: Matthias Buelow <token@cip.informatik.uni-wuerzburg.de>,
> >      port-vax@netbsd.org
> > Subject: Re: 1.5_ALPHA2 on VS3100/m30 and external SCSI
> > 
> > I noted the same problem and have been working on pinning down the exact
> > date of when things broke.
> > I have been using cvs to obtain sources on various dates.
> > Last night I built a kernel with 6/25 which did not have this problem.
> > I thought I had built a kernel with 6/26 which did have problems.
> > I'm going to try to verify this today.
> > It does take a while to build a kernel on these machines when running
> > things via nfs.
> > My impression is that the problem might be related to reading/writing to
> > kernel space rather than user space.  This probably could be
> > verified/disproved by writing a userland program to read/write/verify
> > various things to the disk with varying buffer sizes - might be an issue
> > of size of dma buffer.
> > 
> > I'll post when I find out something more useful.
> > johnh...
> > On Thu, 28 Sep 2000, Andrew Gillham wrote:
> > 
> > > Date: Thu, 28 Sep 2000 00:00:47 -0400 (EDT)
> > > From: Andrew Gillham <gillham@vaultron.com>
> > > To: Matthias Buelow <token@cip.informatik.uni-wuerzburg.de>
> > > Cc: port-vax@netbsd.org
> > > Subject: Re: 1.5_ALPHA2 on VS3100/m30 and external SCSI
> > > 
> > > Matthias Buelow writes:
> > > > Hi,
> > > > 
> > > > does anybody know of problems using an external SCSI disk with a
> > > > VAXstation 3100/m30 with 1.5_ALPHA2?
> > > > I have attached a 4GB disk on the external port and the kernel
> > > > recognizes it as sd1:
> > > > 
> > > > sd1 at scsibus1 target 1 lun 0: <QUANTUM, XP34301, 1071> SCSI2 0/direct fixed
> > > > sd1: 4106 MB, 4076 cyl, 20 head, 103 sec, 512 bytes/sect x 8410200 sectors
> > > > 
> > > > However, the disk doesn't seem to be able to hold a disklabel, once
> > > > written to it it always seems to "disappear" after a few moments.
> > > 
> > > This is the exact problem I have.  I have been whining about it for several
> > > weeks, but I haven't collected enough information to file a PR on it.
> > > :-)
> > > 
> > > I have a kernel from June 29 that does not have the problem.  Any kernel
> > > after that (actually after the vsbus.c rototillage) is broken.
> > > 
> > > Unfortunately the build was broken from about June 30 to July 30 so I am
> > > having trouble isolating the changes via CVS binary search. :-)
> > > 
> > > Anyway, I am very glad to hear someone else has this problem.  It shows
> > > I'm not going crazy. (at least on this issue)
> > > 
> > > I guess a PR should be filed anyway, but I was trying to isolate the dates
> > > involved better.
> > > 
> > > -Andrew
> > > 
> > 
> > 
> 
>