Subject: Re: 1.5_ALPHA2, newfs and rz56
To: Andrew Gillham <firstname.lastname@example.org>
From: John Hayward <John.C.Hayward@wheaton.edu>
Date: 09/19/2000 11:24:52
I have just confirmed that if I take the generic kernel from the 1.5_ALPHA
snap dated June-22 running on a 1.5_ALPHA2 sytem I can at least newfs my
rz56 on MicroVax 3100. I had been unable to do so running 1.5_ALPHA2
Tom G. Christensen <email@example.com> indicated he had not had
problems with doing this on a 4000 with the 1.5_ALPHA2 kernel.
It appears there were some changes:
Diff for /syssrc/sys/arch/vax/vsa/ncr.c between version 1.31 and 220.127.116.11
between 6/19 and 6/28 - though Andrew indicates he has been happy with a
I may try an earlier version of ncr file with the ALPHA2 sources to see if
that is the source of problems.
On Thu, 14 Sep 2000, Andrew Gillham wrote:
> Date: Thu, 14 Sep 2000 01:52:51 -0400 (EDT)
> From: Andrew Gillham <firstname.lastname@example.org>
> To: John Hayward <John.C.Hayward@wheaton.edu>
> Cc: email@example.com
> Subject: Re: 1.5_ALPHA2, newfs and rz56
> John Hayward writes:
> > After I label the disk and in the process of doing a newfs it proceeds
> > to print the backup super blocks then stops with the following error
> > message:
> > write error: 0
> > wtfs: Read-only file system
> > Follwing that the disk label is messed up.
> > Mike Dowden suggested a low level format and I found that test 75 on the
> > 3100 console provided for formatting a scsi drive. This was performed
> > successfully - so I believe the hardware is ok.
> > Is anyone else seeing these kind of problems?
> Yes! With my Vaxstation 3100/M38 and an external IBM 1GB drive.
> With a kernel compiled on June 29 it works, with a new kernel it reports
> no label and data read from the drive is "goofy" and the drive can't be
> I think some is "Bad Wrong(TM)" somewhere. I guess I need to do a
> binary search on it. I pretty much know the kernel built on June 29 works
> and a kernel around August 3 does not. Time to search. :(
> > I note that 1632*15*53 = 1297440 where the dmesg indicates 1299174
> > I don't know if that is because of bad sector forwarding or different
> > number of sectors per track over the disk or something else.
> I see something like this also. I have 4119*5*99 = 2038905 while the
> dmesg reports 2055035. I used 2038905 to create a 'sd3e' partition.
> This has been working great ever since the SCSI was fixed and DMA was
> added, etc. In the July timeframe something seems to have broken.
> I'll start looking at the CVS logs and try to checkout a specific date
> and build a kernel.