>> I got to testing the fifo overrun problem a little, and there is no
>> problem at 19.2, but there is at 38400.  I'd like to try values in
>> between, but tcsetattr won't permit them.  Is there a reason why it
>> has to be this way?

Yes, unfortunately.  What it amounts to is, the chip can give you a
baud rate only if it can be obtained by dividing down its clock by some
integer.  This is what the BPS_TO_TCONST and TCONST_TO_BPS macros are
all about - the "other" argument they take is the frequency of the
clock.  The frequency argument is getting passed 307200; for this
frequency, the following divisors and corresponding baudrates are
available, where I've marked three notable ones:

	tconst	bps
	0	76800
	1	51200
	2 ----- 38400
	3	30720
	4	25600
	5	21942.857142857142857142etc
	6 ----- 19200
	7	17066.666etc
	8	15360
	9	13963.636363etc
	10	12800
	11	11815.384615384615384615etc
	12	10971.428571428571428571etc
	13	10240
	14 ----  9600
	...etc

>>   Seems like 28.8 and 33.whatever should be allowed too.

33.6, it is.  Unfortunately, the hardware simply isn't capable of it.

Well, almost.  The chip is being set to divide the crystal clock by 16
before using it.  If it were set to divide it by 1 instead, an
additional factor of 16 would be gained, but at the price of more
flakiness because it's harder to sample bits in the middle of their bit
times.

If this is done, then here's what I find:

	tconst	bps
	 62	38400
	 71	33665.75342465753424etc
	 72	33210.810810810etc
	 83	28912.94117647058823etc
	 84	28576.74418604651162etc
	126	19200

Note that 28800 and 33600 are still not available, though depending on
the hardware you're talking to (and such things as crystal frequency
drift) you might get away with one of the approximations above.

If you want to try using a X1 clock, just go into
sys/arch/sparc/dev/zs.c and change

                cs->cs_brg_clk = PCLK / 16;

to

                cs->cs_brg_clk = PCLK;

Also edit the fifth line of the initializer for zs_init_reg[] to change
the ZSWR4_CLK_X16 part to ZSWR4_CLK_X1.  Rebuild your kernel and boot
the new kernel.  You will lose the low end of the available speeds,
since there is a largest possible TCONST value, but even at X1 that
value (65535) corresponds to about 37.5 baud (at X16, 2.3437+ baud), so
you are unlikely to lose anything you care about there.  The inevitable
clock jitter between sender and receiver, and the sampling inaccuracy
it implies, will be a bigger downside.  You may find it works well
enough for you that you don't care....

> I would suggest, since this is likely to be encounterd by users,
> rather than just by programmers, that pppd be changed so that it will
> catch invalid speeds in options, or the command line, and generate a
> helpful error message.

Unfortunately, without knowing the underlying hardware's restrictions,
pppd _can't_ catch invalid speeds before trying them.  The most it can
do is, when it gets this error, try the same settings only with the
speed set to whatever it found there, and if that works report that the
requested speed is unavailable.

Of course, if you're willing to switch crystals, you can get anything
you want (though there are probably limits on how high a crystal
frequency you can use - check with the 8530 data sheets - and depending
on the hardware, that crystal may drive other things too and hence
can't be casually changed).  And of course if you're doing that sort of
thing, you will _need_ a custom kernel with a zs driver hacked to know
about the new crystal frequency.

					der Mouse

			       mouse@rodents.montreal.qc.ca
		     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B