Re: PSA: Clock drift and pkgin

["Maciej W. Rozycki" <macro%orcam.me.uk@localhost>]

On Tue, 19 Dec 2023, Johnny Billquist wrote:

> >   The DS1287 is an example source of the timer interrupt with some systems
> > where a high-resolution timer has to provided separately, just as with the
> > 4000/60.  By no means I find the DS1287 itself a high-resolution timer.
> 
> Ok. Then we agree, and I'll drop that. :)
> 
> I would still think that if you have the full ICCS and ICR register in the
> VAX, it is better than such a chip, or probably any chip.

 Full ICCS/ICR isn't necessarily better than a having a truly free-running 
counter of a suitable width available, such as with the KA60, because such 
a counter is immune to missed timer interrupts.

> > > Did anyone actually report results running on a 4000/60?
> > 
> >   Me, earlier on in this thread.
> 
> Great. Sorry that I didn't remember. How did the clock behave for you?

 See my first message in this thread, in reply to one of yours actually.

> >   I do have a 4000/90 too, but it suffers from an issue I yet need to debug
> > where it ever boots NetBSD 9 from local storage only once.  Then the OS
> > corrupts itself somehow in storage such that any subsequent attempt to
> > boot causes the firmware to fail:
> 
> Weird. I have a 4000/90, and have never observed such issues. But now it's a
> few months since I last spun it up. I plan to test it out with the current
> updates after christmas.

 I don't know what could be causing it.  I made the installation with my 
4000/60 using the NetBSD installer while at my lab where it was more 
convenient to me and I had time available to experiment (it was during a 
COVID-19 pandemic lockdown), dd'ed the resulting disk contents to another, 
identical disk (and thankfully to a backup file too) and placed the latter 
disk in my 4000/90 which I keep at a different site across Europe.

 Maybe it is not the canonical way to install the OS, but I can see no 
reason for this to fail as the KA90 mainboard is a drop-in upgrade for the 
KA60, so the console ABI of both is the same.  Besides, it does boot once, 
so it's not that there is an issue with the pristine installation itself 
being incompatible with the 4000/90, but rather the OS writing something 
to storage while running that corrupts the bootloader or suchlike.

 Besides, there is an issue with netbooting my 4000/90, i.e. the NetBSD 
bootloader loads, but then fails to proceed, so I couldn't have installed 
the system the proper way anyway:

>>> boot EZA0

-EZA0
>> NetBSD/vax boot [1.12 (Fri Feb 14 00:06:28 UTC 2020)] <<
>> Press any key to abort autoboot 0
SGEC: Ethernet address 08:00:2b:30:96:d8
Trying BOOTP
Using IP address: x.x.x.x
myip: xxx.xxx.xxx.xxx (x.x.x.x)
root addr=y.y.y.y path=/scratch
3882276read section: Unknown error: code 60
> boot netbsd
SGEC: Ethernet address 08:00:2b:30:96:d8
open netbsd: No such file or directory
netbsd: boot failed: No such file or directory
> boot netbsd.gz
[...]

and on the boot host:

$ ls -laL /scratch/netbsd.vax
-r--r--r-- 1 root root 3883124 Feb 14  2020 /scratch/netbsd.vax
$ readelf -l /scratch/netbsd.vax

Elf file type is EXEC (Executable file)
Entry point 0x80000578
There is 1 program header, starting at offset 52

Program Headers:
  Type           Offset   VirtAddr   PhysAddr   FileSiz MemSiz  Flg Align
  LOAD           0x000080 0x80000000 0x80000000 0x3b3d24 0x3d45c8 RWE 0x40

 Section to Segment mapping:
  Segment Sections...
   00     .text .rodata link_set_evcnts link_set_sysctl_funcs link_set_modules link_set_domains link_set_dkwedge_methods link_set_prop_linkpools .data .bss
$

so all seems right (3882276 reported by the bootloader above is 0x3b3d24 
hex reported as the file size of the sole loadable segment).  This would 
have to be debugged too.  I can't remember if I could figure out what 
"read section: Unknown error: code 60" boils down to, probably not.

 For the disk bootloader things work:

>>> boot DKA200

-DKA200
>> NetBSD/vax boot [1.12 (Fri Feb 14 00:06:28 UTC 2020)] <<
>> Press any key to abort autoboot 0
nfs_open: must mount first.
open netbsd.vax: Device not configured
> boot netbsd
3293856+205208 [238480+226939]=0x3c821c
[   1.0000000] Copyright (c) 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005,
[   1.0000000]     2006, 2007, 2008, 2009, 2010, 2011, 2012, 2013, 2014, 2015, 2016, 2017,
[   1.0000000]     2018, 2019, 2020 The NetBSD Foundation, Inc.  All rights reserved.
[   1.0000000] Copyright (c) 1982, 1986, 1989, 1991, 1993
[   1.0000000]     The Regents of the University of California.  All rights reserved.

[   1.0000000] NetBSD 9.0 (GENERIC) #0: Fri Feb 14 00:06:28 UTC 2020
[   1.0000000]  mkrepro%mkrepro.NetBSD.org@localhost:/usr/src/sys/arch/vax/compile/GENERIC
[   1.0000000] MicroVAX 4000/{90,90A,96}
[   1.0000000] total memory = 127 MB
[   1.0000000] avail memory = 119 MB
[   1.0000000] mainbus0 (root)
[   1.0000000] cpu0 at mainbus0: KA49, NVAX, 10KB L1 cache, 256KB L2 cache
[...]
Starting local daemons:.
Updating motd.
Starting ntpd.
Starting sshd.
Starting inetd.
Starting cron.
The following components reported failures:
    /etc/rc.d/ntpdate
See /var/run/rc.log for more information.
Wed Jan  1 01:02:19 CET 2070

NetBSD/vax (xxx.xxx.xxx.xxx) (constty)

login: 

but as I say once only (ignore the NTP failure/odd date reported; it's due 
to wrong IP addressing for the 4000/90 vs the 4000/60 the image has come 
from).  Given that the machine fails to netboot too, there's no feasible 
way for me to use it with NetBSD until these issues have been debugged and 
fixed.

> >   NB I worked with Mike Uhler (the lead designer of the NVAX in case you
> > didn't know), who was the manager of our group at MIPS UK back in early
> > 2000s, and knowing his absolute technical insight I'd have no doubt he
> > wouldn't let such an important architectural feature out of the NVAX
> > microarchitecture.
> 
> Very cool/nice. But as observed, the NVAX don't have it built in as such. So
> it might, or might not exist on a specific machine, depending on external
> bits. The NVAX itself only guarantees that the ICCS exists, and can generate
> 10ms interval interrupts, which is the basic requirement for any VAX. The
> documentation for the NVAX chip is on bitsavers.

 NVAX/NMC/NCA was the standard chipset configuration and I don't think the 
NVAX CPU itself was ever used in any other way.  Therefore I gather it was 
a deliberate design decision to put the ICR in the peripheral bus bridge 
component rather than the CPU itself, perhaps to fit in the silicon space 
available for the CPU component.

 Conversely the NVAX+ CPU was designed to interface Alpha CPU chipset 
components, which do not provide for any VAX architectural features, and 
therefore the ICR was placed in the Cbox unit of the NVAX+ CPU itself.  
Observe that for the NVAX CPU numerous IPRs are implemented in the other 
chipset components while for the NVAX+ they are all internal to the CPU.

 Nowadays I guess the NVAX/NMC/NCA combo would have been implemented as a 
single chip, but there was no technology available to do so back in 1990s, 
and the three chips were rather huge each by the contemporary standards.

  Maciej