Subject: Snapshot report - 5 March tar_files
To: None <current-users@sun-lamp.cs.berkeley.edu>
From: Alistair G. Crooks <agc@uts.amdahl.com>
List: current-users
Date: 03/08/1994 08:23:23
Snapshot report.
================

Me: agc@uts.amdahl.com (Alistair G. Crooks)

Source: tar_files, 05th March 1994, from agate.berkeley.edu

Base version of NetBSD: 0.9.

Upgrade from previous -current: yes, 26 Feb tar_files from
agate.berkeley.edu

Machine specifics: 486DX2/66, 16MB RAM, 340 MB IDE (Conner), VGA card

Other software: Havard Eidnes' shared XFree86 2.0, from 9 February 1994.

Tar files integrity: good.

Additional things to do during upgrade:

Any warnings during compilation: various, not noted

Any problems during make: see below.

Observations:

Changes from 26 Feb tar_files:
(This is taken from the CHANGES file on agate - last update on 06 Mar 94,
so I'm not exactly sure what made it into the Mar 05 sources.)

        update telnet and telnetd from latest sources on ftp.cray.com. (cgd)
        slightly disambiguate setuid() man page. (cgd)
        fix the way apropos et al. deal with underscores in names. (cgd)
        fix reset's tabset file problems, based on a fix sent in by
                Frank van der Linden <vdlinden@fwi.uva.nl> (cgd)
        fix bsd.dep.make to clean .depend files only only on cleandir.
                Pointed out by michaelv@iastate.edu. (cgd)
        add 3Com 3c501 driver by Matt Kimmel <kimmel@cs.umass.edu>. (hpeyerl)
        when restoring from multi-volume dump, check the correct tape header
                volume number, from thomas@mathematik.uni-Bremen.de. (cgd)
        fix to 'primes' to deal properly with large numbers,
                from Arne Juul <arnej@dsl.unit.no>. (cgd)
        fix rarpd to put necessary fields in network byte order,
                from Christos Zoulas <christos@deshaw.com>. (cgd)
        fix sed to do the right thing with empty regex matches. (cgd)
        fix from Christos Zoulas <christos@deshaw.com> to keep tftpd
                from dumping core when invoked with no arguments. (cgd)
        fix from Christos Zoulas <christos@deshaw.com> to keep vi
                from trying to use its controlling tty when it doesn't
                really have one. (cgd)
        mods to msdos filesystem code so it works on big-endian machines.
                (paulus)
        fix i386 disklabel routines so that when creating a new label, they
                fill in the info for the appropriate partition. (cgd)
        various fixes and improvements to make(1) supplied
                by Christos Zoulas <christos@deshaw.com>. (cgd)
        sparc: support lkm/tun/vn, SYSVSHM, SYSVMSG (deraadt)
        fix serious YP bug in gethostbyname() functions (deraadt)
        ar had a file descriptor leak, fix from Robert Crowe
                <bob@speakez.com> (deraadt)
        i386: integrate new Bustek driver which works on many more
                models of the card. Fixed by Michael VanLoon
                <michaelv@iastate.edu> (deraadt)
        sparc: various fixes and changes torek sent me ages ago (deraadt)
        fairly simple SUNOS_COMPAT sysconf() function (deraadt)
        netstat core dump fix from Chuck Cranor <chuck@maria.wustl.edu>
                (deraadt)

[Sorry it's so long this week, but there are a few quotes that
needed to go in, and I've got to get my gushing thanks in again somehow]

Notes:

0.  If people are reporting problems with any piece of code, could
they please give the version number of the code they're using?  It
makes it so much easier to see if it's a known/fixed problem.

1.  There's a new version of wd.c in -current.  It's much improved. 
Thanks to Charles Hannum for this.  Jason Thorpe still thinks the
driver's a bit broken, but gave no version number for the driver.  Tom
Crockett reports that the March 3 wd.c/wdreg.h fixed his fsck problems
with 2 IDE drives.  I can confirm that the March 5 version (1.60)
works fine for me.  The first of many quotes from Charles says:

"It turns out that this (lost interrupt messages when doing
multisector writes) is due to semi-flaky hardware.  If I try to write
bytes to the IDE controller too fast, it just occasionally drops one
(actually, two).  By reconfiguring my C&T chipset (using the BIOS
utilities) and adding wait states (specifically, increasing `*-BIT AT
BUS WAIT STATES' to 2, but this will vary depending on the machine), I
was able to completely fix the problem.  Interestingly enough,
single-sector writes don't seem to ever tickle this; the probability
of losing on a given write approaches 100% as the size of the transfer
approaches somewhere around 16k or 32k.

I've also occasionally (like once every three or four months) seen a
strange lossage mode with my NE2000 where if_ed will start spewing
`remote DMA not completed' messages until I reboot.  It's possible
that this problem is related."

- and - 

"Just so nobody is confused, I'll add that the infinite loop of timeouts
that a couple of people have reports in last night's sources (rev 1.56)
is a different problem than what I mentioned happening on my machine.
The former should be fixed by the current version of wd.c (rev 1.59),
but the latter is still a hardware problem."

2.  Michael VanLoon's bt742a.c driver was integrated into -current last week,
which gives me a marvellous opportunity to post the SCSI table again.

aha1542b isa                 aha1542.c       mycroft@gnu.ai.mit.edu
aha1542c/cf isa              aha1542.c       hpeyerl@novatel.ca
aha1742 eisa                 aha1742.c       cgd@postgres.berkeley.edu  
aha1742 eisa                 aha1742.c       mycroft@gnu.ai.mit.edu
bt445   vlb                  bt742a.c        dhess@cs.stanford.edu
bt542   isa (mod'd driver)   aha1542.c       tim@introl.introl.com
bt545   isa (old ones only)  aha1542.c       tim@introl.introl.com
bt742   eisa                 bt742a.c        deraadt@fsa.ca
bt747   eisa 		     bt742a.c        michaelv@iastate.edu
ultra34f vlb		     ultra14f.c	     jkreska@hpmail2.fwrdc.rtsg.mot.com
ultra14f isa                 ultra14f.c      mycroft@gnu.ai.mit.edu

[The Adaptec 2742 is not supported, and may not be in future due to
Adaptec's refusal to release "proprietary information" about the board.]

If anyone has any more to add to this list, please drop me a line.

(There was some discussion over the best SCSI board to purchase. 
General reasoning was that Adaptec support wasn't good for non-DOS
problems, and re the 2742 issue.  The Ultrastore has jumpers for
everything, which can be a pain.  The Bustek boards have had
favourable reports.  Please note that I'm just condensing other
people's opinions here, all you lawyers out there.)

3.  There is absolutely no excuse for me to print the Ethernet card
table again, so here it is.

3c501                   isa     if_el                     (kimmel@cs.umass.edu)
3c503 (and probably 3C507, but I can't actually test it)  (mycroft)
3c509  			isa	if_ep   bnc/aui/utp.      (tdr)
3c579			eisa		doesn't work yet. (tdr)
WD 8390-based cards 	isa	if_ed			  (mycroft)
SMC 8390-based cards 	isa	if_ed			  (mycroft)
NE1000, NE2000    	isa	if_ed			  (mycroft)
NE2100			isa	if_is			  (mycroft)
AT&T StarLAN (82586-based cards)			  (mycroft)
BICC Isolan				 		  (mycroft)

If anyone has any more to add to this list, please contact me.

4.  Charles Hannum yet again picked up the pccons.c bull by the horns,
and, at least for me, it has worked a treat.  My Caps Lock key will
now do the right thing both in normal mode and in X, and the LEDs work
correctly too.  Some people are still reporting problems, but for me
version 1.58 of pccons.c works well. To quote from Charles' article:

"I just looked into why this causes problems.  Below is an abbreviated
explanation.

The keyboard (or the i8042; it's not clear which) has this strange idea
of `scancode translation tables'.  Each keyboard/i8042 has a set of such
translation tables, a command to select one, and a default, which
determine what scancodes are queued in the keyboard buffer when a key is
pressed or released.

Normally, the BIOS magically divines which table number has the old XT
codes in it and selects that, to avoid compatibility problems with old
software.  How it figures this out is a mystery to me; my Vectra docs
seem to think it's table 1, but my Superwave 386 seems to think it's
table 0.

pccons, and I think all of the various *BSD console drivers, require the
old XT codes.  They haven't the foggiest idea how to translate the new
codes, or even recognize an AT-style break code.  But some keyboards
when reset default to a different translation table.

Now here's the catch.  We could set the translation table after the
reset, except that there's no good algorithm that I can think of for
determining which table we should select!

So, basically, the code is screwed.

I've added the appropriate code to select table 0 in pccons, but turned
off the entire section of code by default.  If you feel daring, try
removing the `#if 0' around the reset code and let me know what happens
on your machine!  It works on mine, but that's doesn't mean much."

- and -

"I believe that I just fixed this completely.  It turns out that some
keyboards send a second ack byte after the reset, and this was not being
removed from the buffer.  Thus, the buffer was never empty, the
interrupt line didn't go low, and further keyboard actions would not
generate a new interrupt.  (Don't you love edge-triggered interrupts?)

Thanks to Holger Veit for cluing me in that there seemed to be something  
wedged in his keyboard buffer after the reset."

5. The latest version of Matt Kimmel's 3c501 driver is available in
-current, or by ftp at varese.cs.umass.edu:

6. Are silo overflows a thing of the past? A Mr. Hannum writes:

"For the record, I am right now dumping large quantities of junk at 19200
baud (lacking anything faster that I can trust to connect to) to a 16450
on my krsuty 386-20, and I'm not getting *any* silo overflows.

This is not to say the com driver doesn't have problems, but the biggest
problem that affect{ed,s} it, namely interrupt latency, has largely been
fixed at this point.

Clearly a faster CPU and/or buffered ports can handle several of these
at once with no problems."

7.  If you're new to -current, or are looking for an answer to what
you may think is a FAQ, check the mailing list archive on
agate.berkeley.edu:pub/NetBSD/mailing-lists/current-users.

8.  I compiled libc with both -pipe and using intermediate files.  I
had *NO* spontaneous reboots from this.  None.  I'm not saying they're
gone completely, just saying I had none.

9.  A Mr. Demetriou of Berkeley, CA, has updated the binary snapshot
of the i386 -current files.  It's on agate.berkeley.edu:pub/NetBSD/arch/i386

10.  A reminder that there's a NetBSD repository of ported software on
alpha.gnu.ai.mit - look there before hacking, someone may already have
done the hard work.

11. Peter Galbavy says:

"I don't know enough about PC LAN software, but there is a LAN Manager or
netbios of whatever server thingy available, at least from:

        ftp.wonderland.org:/networking/netbios/...      or
        ftp.demon.co.uk:/pub/networking/netbios/..."


General verdict: I had absolutely ZERO problems this week either
compiling or installing the -current tar_files.  There was no
spontaneous reboot, either when compiling libc with -pipe or without. 
The pccons.c sucessfully sets CAPS LOCK, and gets the LEDs right.  The
IDE drive is/was rock solid for me (my wd.c is version 1.60).  Many,
many thanks to all concerned.

And the usual afterthoughts:

1.  Could someone recompile the day to include 25 hours, please?
Or is this the USL way, to make it non-standard for everyone else?

And now for some *speculation*:

I've seen some questions about when the next version of NetBSD will be
"released".  The core team say "when it's ready".  I think I've got a
pretty damn good system at the moment (-current), which has all I want
and more.  There's a binary snapshot for people moving up from 0.9 who
don't want the hassle of bootstrapping a new shared-library
environment.  And so I'm very glad that the core team don't want to
rush to a new release.  I would also speculate that 4.4 lite would
precede any new release of NetBSD.  Once again, thank you to everyone
involved in NetBSD, for working very hard to give me a very fine OS.

And, following that speculation, I'll modify my disclaimer:
[These are only my opinions, and certainly not those of the NetBSD core team.]

All flames to /dev/null. All money to:

Alistair
--
Alistair G. Crooks (agc@uts.amdahl.com)                      +44 252 346377
Amdahl European HQ, Dogmersfield Park, Hartley Wintney, Hants RG27 8TE, UK.
[These are only my opinions, and certainly not those of Amdahl Corporation]

------------------------------------------------------------------------------