While debugging what I thought was the ttyflags hang problem on my q840av I
have discovered that the real problem is somewhat different.  I guess I owe
Dr. Bill an apology for casting aspersions on the quality of his zstty code.

The last thing before setting tty flags is the fsck of disks.  If the
machine prints fscking sd3a before sd2d then the machine always hangs.  If
the machine prints fscking sd2d before sd3a then the machine always goes on
to complete a normal boot (barring the usual collection of other possible
disasters that is).

The machine is a Q840av running a slightly customized version 1.3.2 (as
described in ftp://macbsd.jpl.nasa.gov/pub/users/hotz).  sd0 and sd2 are
internal.  sd1 and sd3 are in an old Sun "shoebox."

The relevant portion from dmesg:

esp0 at obio0: address 0x89f000: NCR53C96, 25MHz, SCSI ID 7
scsibus0 at esp0: 8 targets
sd0 at scsibus0 targ 0 lun 0: <QUANTUM, LP240S GM240S01X, 6.3> SCSI2
0/direct fixed
sd0: 234MB, 1818 cyl, 4 head, 65 sec, 512 bytes/sect x 479350 sectors
sd1 at scsibus0 targ 1 lun 0: <QUANTUM, LP80S  980809404, 2.9> SCSI2
0/direct fixed
sd1: 80MB, 921 cyl, 4 head, 44 sec, 512 bytes/sect x 164139 sectors
cd0 at scsibus0 targ 3 lun 0: <SONY, CD-ROM CDU-8003A, 1.9a> SCSI2 5/cdrom
removable
sd2 at scsibus0 targ 4 lun 0: <SEAGATE, ST3600N, 9422> SCSI1 0/direct fixed
sd2: 500MB, 1872 cyl, 7 head, 78 sec, 512 bytes/sect x 1025920 sectors
sd3 at scsibus0 targ 5 lun 0: <MICROP, 1588-15MBSUN0669, SN0C> SCSI1
0/direct fixed
sd3: 639MB, 1632 cyl, 15 head, 53 sec, 512 bytes/sect x 1309735 sectors

My (current, working) /etc/fstab:

/dev/sd0a       /               ffs     rw 1 1
/dev/sd1b       none            swap    sw 0 0
/dev/sd2d       /users          ffs     rw 1 2
/dev/sd3a       /mirror         ffs     rw 1 0
/dev/sd3b       /usr/vice       ffs     rw 0 0
/dev/cd0a       /cd0            cd9660  ro 0 0
kern            /kern           kernfs  rw 0 0
proc            /proc           procfs  rw 0 0

At this point I have rebooted the machine five times and not had it hang
during boot since I removed sd3 from the boot fsck sequence.  The
statistics are starting to look convincing.

I guess I'll need to modify some rc files to get some sequencing to the
non-root fsck's, since I don't want to skip fsck on sd3 altogether.  I'm
going to hold off on a PR since this could be an obscure hardware and not a
software problem.

Signature failed Preliminary Design Review.
Feasibility of a new signature is currently being evaluated.
h.b.hotz@jpl.nasa.gov, or hbhotz@oxy.edu