Re: VS3100M76 - current

[Holm Tiffe <holm%freibergnet.de@localhost>]

David Brownlee wrote:

> On 21 May 2014 16:05, Holm Tiffe <holm%freibergnet.de@localhost> wrote:
> 
> > I've repeated this yesterday eavening one more time w/o any other things
> > than some fsck's before.
> > The -current crashes every time with this same panic, so it seems
> > something in the vm-system is going crazy here.
> > For my experiences the bug is the same on CVAX, Rigel and the NVAX,
> > since I had some ugly suprises too while installing the VS4000/90
> > but I have a somewhat running system (not used, last booted last year)
> > on this machine. At least the two VS3100's are running OpenBSD flawlessly
> > without any suprises.
> >
> > What should I do?
> > I can put the M76 aside an get the M38 to verify Ragges question about the
> > behavior of the CVAX (IMHO the very same, but I'll try again).
> >
> > I'm a good electronican and I rule my own business. Sometimes I'm
> > programming some embedded things, but debugging a VM System from a VAX is
> > beyound my possibilities, regardless of the needed time.
> > I would provide some fixes to the code, but for this it is neccessary that
> > the machines are at least able to compile some stuff.
> > That I don't know much from the internals of a VAX processor is another
> > thing..
> >
> > If I can help I'll do this as good as I can, but "fix it yourself if you
> > need it" wouldn't work here. If no one from the VAX maintainers is jumping
> > in here, I'll put that stuff aside again, maybe trying next year..
> > From my Opinion is the state of the NetBSD VAX port at least to be called
> > "desolate".
> >
> 
> I think "desolate" would be overstating. I think we would agree on "could
> be improved". It works fine on my 4000/90 and the various simh instances
> I've used to test, and I believe that is the case for several other users.

Yes,Ok. I know that was LOUD.
> 
> Clearly it doesn't work for you - on multiple instances of hardware which
> are able to run other software, so its likely there is something pervasive
> or common to your environment which is not triggering here or elsewhere,
> and it would be really good to find out.

Johnny asked above why I think it would be different to install on a 1GB
disk and on a 4GB disk. He is right, it makes no difference...theoretical.
In fact I could install the OS on the IBM0663 1Gb disk and I failed badly
to move it to the 4GB disk or install it there...

There is for sure a moving targt that spits in the soup, sometimes here and
sometimes there. Ragge may be right with the Pagemap/VM Problems, that
feels like bad memory, but bad memory on 4 different machines?

Look at this, that is from a thread last year, some infamous guy mailed
about his problems installing 6.1_RC2 on his VAXStation:

>HI,
>I've got some Vaxstations lately and today I've tried to install
>NetBSD-6.1_RC2 on a VS3100M38 with 24Mbytes of RAM.
>Disk is an IBM DCAS 34330, 4Gbyte.
>
>I can do what I want, the install.ram is crashing while labeling the disk,
>regardless if I have overwritten the disk with zeros before ot not.
>
>This is the last screen:
>
>     Status: Command ended on signal
>    Command: disklabel -w -r -f /tmp/disktab sd0 'DCAS-34330     '
>     Hit enter to continue
>--------------------------------------------------------------------------------
>uid 0, pid 7, command disklabel, on /: file system full
>
>/: write failed, file system is full
>pid 7 (disklabel): user write of 9272@0x1a2000 at 67912 failed: 28


...yes, it was me, with the very same problem.

>or this:
>
>after new booting I had to edit the mount points of the labeled partitions
>and finally this runs in the same problem.
> 
>                               | yes or no?    |
>                               |               |
>                               | a: No         |
>                               |uid 0, pid 6, command sysinst, on /: file
>system full                          +---------------+
> 
>/: wrpid 6 (sysinst): user write of 57248@0x14d000 at 1196 failed: 28
>ite failed, file system is full
>[1]   Illegal instruction     sysinst
># s: not found
># Filesystem    1K-blocks       Used      Avail %Cap Mounted on
>/dev/md0a          1551       1549          2  99% /

Curses Bug in -current ehy?

or this:

>drivedata: 0
>
>8 partitions:
>#        size    offset     fstype [fsize bsize cpg/sgs]
> a:   1842384        16     4.2BSD      0     0     1  # (Cyl.      0*-
>114*)
> b:    524288   1842400       swap                     # (Cyl.    114*-
>147*)
> c:   8250001         0     unused      0     0        # (Cyl.      0 -
>513*)
> d:   5025728   2366688     4.2BSD      0     0     1  # (Cyl.    147*-
>460*)
> e:    857504   7392416     4.2BSD      0     0     1  # (Cyl.    460*-
>513*)
>partition> W
>Label disk [n]? y
>disklabel: warning, revolutions/minute 0
>Label written
>partition> Q
>vs3138# newfs sd0a
>/dev/rsd0a: 899.6MB (1842384 sectors) block size 8192, fragment size 1024
>        using 20 cylinder groups of 44.98MB, 5758 blks, 11200 inodes.
>[1]   Segmentation fault (core dumped) newfs sd0a
>vs3138# newfs sd0d
>[1]   Illegal instruction (core dumped) newfs sd0d
>vs3138# newfs rsd0d
>[1]   Illegal instruction (core dumped) newfs rsd0d
>vs3138#

The newfs problem. Watch out the machine name: vs3138, that means at
Sat, 30 Mar 2013 22:17:34 +0100 the CVAX had the same Problem as the
Rigel (vs3176) one day before now.



> 
> Throwing out some random thoughts on what might be common (Note, I'm not
> saying "wrong", just "that NetBSD does not currently handle")
> 
> 
> In each case of newfs/tar/fsck failing :
> - are you using the same serial terminal/cable/flow control settings?

Yes, that's seyon on FreeBSD with the same cable :-)

> - are you using the same physical disk?

Yes,  Tried the IBM DCAS 34330 and the Fujitsu M2954SYU. Currently is a
working OpenBSD on the DCAS. A somewhat working NetBSD is on the IBM0663,
at least I was able to install it there, not with sysinst but by hand.

> - You're not using any odd arguments to newfs or similar - so thats out

newfs /dev/rsd1a as to be read in every terminal dump..

> - Its reproduced with netboot and cdboot, so they are excluded...

netboot .. no, I've netbooted last year, this year I've used a CROM.
But the problems are the very same. The boot itself isn't the problem.
I'm in the process of setting up the netboot environment again since
the CDROM boot is dog slow..

> 
> For OpenBSD, does it report the same details on disk attachment, does a
> read/write of a file report the same approximate speed? - eg
> dd msgfmt=human if=/dev/zero of=TMPFILE bs=1m count=10
> dd msgfmt=human if=TMPFILE of=/dev/null bs=1m

Never tried to measure some speed, I'm happe if I can pollute the
filesystems with the needed files, but the speed doesn't feel bad at all.
With NetBSD-current the extract of the base.tgz triggers the kernel to a panic.
> 
> Can you NFS export a filesystem to the vax and then boot the vax from the
> CD and manually install into the NFS filesystem? - trying to exclude the
> disk IO

Nice Idea, would try later.

> 
> Do you have any other disk controller - a VAX with an MFM/DSSI drive?

I do have some QBUS Backplane, a KA630 with 16MB ram and some UC07
Controller laying around. I'm building a enclosure for the Card Cage
currently.. will take some time, but I had that "running" on Quasjarus-0c
last year..

Searching for a KA65x, KA660 + Memory since the MVAXII is dog slow.

> 
> Does an early NetBSD/vax install (say 1.6) have the same issue?

Thell me where I can find an iso image..

> 
> So what now. Please no silence, I'll help but I don't want to be the only
> > one.
> >
> 
> Not silence. Possibly something more of a scattergun of too many questions,
> but not silence :)

Ahh.. no Problem. I've already sayd that I will do what I can.
Some of your Questions will take some time to answer.

I'll look for NetBSD 1.6 next.

Regards

Holm

-- 
      Technik Service u. Handel Tiffe, www.tsht.de, Holm Tiffe, 
     Freiberger Straße 42, 09600 Oberschöna, USt-Id: DE253710583
  www.tsht.de, info%tsht.de@localhost, Fax +49 3731 74200, Mobil: 0172 8790 741