1.5_ALPHA2 on VS3100/m30 and external SCSI
Matthias Buelow
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.
I wrote the kernel generated label to the disk using:
disklabel sd1 >sd1label
disklabel -R -r sd1 sd1label
which seems to work, although it spits out "sd1: no disk label";
at least "disklabel -r sd1" now displays the label.
However, after a few seconds, a second "disklabel -r sd1" fails
with:
sd1: no disk label
disklabel: no disklabel
and "disklabel sd1" displays the incore-label followed by
disklabel: boot block size 0
disklabel: super block size 0
Having done this for quite some time now, I also managed to
create a partition once and newfs it, but after writing the
superblock backups, newfs failed with, iirc, "wtfs: read-only
filesystem" and then the label was gone again.
The disk itself is known to work. Anyone got some hints or
suggestions?
TIA
--mkb
Andrew Gillham
> 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
John Hayward
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 <gil...@vaultron.com>
> To: Matthias Buelow <to...@cip.informatik.uni-wuerzburg.de>
> Cc: port...@netbsd.org
> Subject: Re: 1.5_ALPHA2 on VS3100/m30 and external SCSI
John Hayward
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 <jo...@ImapStu.wheaton.edu>
> To: Andrew Gillham <gil...@vaultron.com>
> Cc: Matthias Buelow <to...@cip.informatik.uni-wuerzburg.de>,
John Hayward
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)
John Hayward
> sc->ncr_off = DMASIZE
in ncr.c removed.
I am able to label the disk and do a newfs without the label disappearing
or claiming the disk is read only.
My machine is a VS3100/M10 as far as I can determine.
I'd like to know if this is particular to the fix works with other models
of VS3100.
I'd like to know if this works with machines which have a working tkxx
drive on the other scsi bus.
I'd like to know pointers to documentation to understand how the DMA works
on the VS3100 to get this correct.
Ideally changes could be done before 1.5 is released.
johnh...
Andrew Gillham
> I have built an ALPHA2 source kernel with the one line
> > sc->ncr_off = DMASIZE
> in ncr.c removed.
> I am able to label the disk and do a newfs without the label disappearing
> or claiming the disk is read only.
>
> My machine is a VS3100/M10 as far as I can determine.
>
> I'd like to know if this is particular to the fix works with other models
> of VS3100.
I'll try to test mine tomorrow. Thanks!
-Andrew
John Hayward
Use his patch rather than my patch (unless you want to corrupt your drives
on the internal bus).
johnh...
On Sun, 1 Oct 2000, Andrew Gillham wrote:
> Date: Sun, 1 Oct 2000 02:43:45 -0400 (EDT)
> From: Andrew Gillham <gil...@vaultron.com>
> To: John Hayward <John.C....@wheaton.edu>
> Cc: Andrew Gillham <gil...@vaultron.com>,
> Matthias Buelow <to...@cip.informatik.uni-wuerzburg.de>,
> port...@netbsd.org
> Subject: Re: 1.5_ALPHA2 on VS3100/m30 and external SCSI
>
Andrew Gillham
> Ragge has resolved the problem with a better patch. It is in the cvs now.
> Use his patch rather than my patch (unless you want to corrupt your drives
> on the internal bus).
> johnh...
I will get it from CVS. Good thing I haven't had time to mess with my
VAX at all, or I would have hosed disks. :-)
-Andrew