[ On Friday, September 27, 2002 at 16:15:04 (+0900), Takeshi Nakayama wrote: ]
> Subject: Re: netbsd-1.6 sparc64 installed OK on SunFire V100
>
> >>> woods@weird.com (Greg A. Woods) wrote
> 
> > The only other major problem is that NetBSD seems to be unable to
> > properly read the real-time clock on this machine.  It gets everything
> > right but the year, which ends up being 1970.
> 
> I think pulling up the rev 1.50 of sys/arch/sparc64/sparc64/clock.c
> to netbsd-1-6 branch solves this prolrem.
> 
> | RCS file: /cvsroot/syssrc/sys/arch/sparc64/sparc64/clock.c,v
> | Working file: clock.c
> | head: 1.50
> (snip)
> | revision 1.50
> | date: 2002/06/11 23:33:27;  author: eeh;  state: Exp;  lines: +20 -20
> | Fixes for the rtc clock on Netra X1 machines from PRs 15611 and 16816

Yes I can confirm this patch, when applied against the 1.6 release
branch, also fixes the clock for the SunFire V100:

	No counter-timer -- using %tick at 500MHz as system clock.
	Kernelized RAIDframe activated
	root on wd0a dumps on wd0b
	rtc_gettime: read c 14/20 y 2/2 m 9/9 wd 5 d 1b/27 h 11/17 m 36/54 s 21/33
	root file system type: ffs
	Fri Sep 27 13:54:35 EDT 2002

I will note though that I had to reboot three times to get the system
back to normal and stop the warnings, even though the system time was
correct when I halted the release kernel.  On first boot the system time
zoomed forward to the year 2034:

	Kernelized RAIDframe activated
	root on wd0a dumps on wd0b
	rtc_gettime: read c 14/20 y 22/34 m 9/9 wd 5 d 1b/27 h 11/17 m 33/51 s a/10
	WARNING: clock gained 11688 days -- CHECK AND RESET THE DATE!
	root file system type: ffs
	Wed Sep 27 13:51:12 EDT 2034

after which I reset the system time manually and halted the patched
kernel.  After rebooting for the second time the system time remained
correct, but there was a warning about the clock jumping backwards
(since of course it did, having been way ahead in 2034 for a wee bit).
Full console logs are available on request).

I don't expect anything sane can be done about this to automatically
compensate safely, but it might be a good idea to put a note about it in
the release notes for 1.6.1.  Of course if the upgraded machine is
running rdate or ntpdate or other corrective measures on boot (as one
would have to do if one were running the un-patched kernel) then things
will work themselves out anyway.

BTW, these V100's are no screaming deamons.  A plain GENERIC kernel
build on a machine with 512MB RAM from NFS-mounted sources to local
disk, with 10baseT half-duplex switched access to the NFS server and no
special compiler options (i.e. no -pipe, and nothing done to make it use
mfs:/tmp instead of /var/tmp) and of course using the stock ST340016A
drive for / and /var, the build to 28 minutes.  The CPU was flat out
most of the time according to occasional peeks I took with sysstat (and
make's output was directed to a file, _not_ the 9600bps console).  It
would make a great firewall I suppose, but as a server for anything else
it's extremely limited given that it's almost totally unexpandable, and
as such it's also extremely over-priced (even with all the fancy LOM
7x24 stuff).  If you'd never need more than 34GB of not-so-fast disk
then I suppose the twin internal drives could be mirrored and will
hopefully run very reliably for a long time, but mirroring on that
IDE/ATA controller won't likely be very fast.  Apple's Xserve really
does blow it away price/performance wise, even just as a pure hardware
platform for NetBSD (i.e. ignoring the hidden costs for the vendor OS
you won't be using).

-- 
								Greg A. Woods

+1 416 218-0098;            <g.a.woods@ieee.org>;           <woods@robohack.ca>
Planix, Inc. <woods@planix.com>; VE3TCP; Secrets of the Weird <woods@weird.com>