>>> netbsd: ms0: input error (0x3447)
>> 0x47 has ZSRR1_FE but not ZSRR1_PE set; the host is seeing a framing
>> error from the mouse.  [...]
>> Have you tried a different mouse?  If you can, that's one of the
>> first things I'd try.
> I have tried another optical mouse and it was the same.

That does seem to eliminate the cable...though the mouse cable is not
the only relevant piece of wire.  With anything later than a type-2,
the mouse plugs into the keyboard - have you tried another keyboard
and/or keybaord cable?

> Heat/warm up was a false alarm also as it's still happening hours
> later.

That's a bit reassuring; I was having trouble thinking of a failure
mode that would explain that.

> I'll try this code as a patch and rebuild my kernel.
> I think this is what you are suggesting yes?

No; the code I quoted was taken directly from the source, and if it
doesn't match your ms_zs.c, you should make sure you understand what it
would change before you try dropping it in.  (I also have no reason to
think it has a fix for anything.)

Does the mouse work even approximately, or is it completely unusable?
If it works at all - especially, if the buttons work - then the
baudrate is at least close to correct.

If you want to change the baudrate, well, I don't see anything saying
which OS version you're using, but the source I have at hand has
several places you could change that.  sys/dev/sun/ms_zs.c sets the
speed with

        (void) zs_set_speed(cs, ms_zs_bps);

where ms_zs_bps is defined with

int     ms_zs_bps = MS_BPS;

MS_BPS comes from msvar.h:

#ifdef  SUN_MS_BPS
#define MS_BPS  SUN_MS_BPS
#else
#define MS_BPS  1200
#endif

Thus, you might be able to just add a line

options SUN_MS_BPS=4800

(or whatever baudrate you want) to your kernel config, reconfig,
rebuild, and go.  You could also change the default in msvar.h, change
the initialization in ms_zs.c, or change the zs_set_speed call.  Or you
could patch ms_zs_bps in your kernel binary with gdb.

I wonder if the baud-rate crystal in the host has drifted far enough
that it's no longer running at an accurate 1200 baud.  You should be
able to get baudrates of 1172, 1181, 1190, 1209, 1219, 1228, etc, if
you ask for them.  (Where did I get those?  See sys/dev/ic/z8530reg.h,
the BPS_TO_TCONST and TCONST_TO_BPS macros, with f being 307200, that
being 1/16 of the PCLK value from sys/arch/sparc/dev/zs.c.  Feeding
1200 to BPS_TO_TCONST gives 126; those other baudrates I gave
correspond to TCONST_TO_BPS applied to 129, 128, 127, 125, 124, 123.)

However, a byte value of 0x34, that being the data value portion of the
0x3447 you quoted...that's an unusual byte to see coming from the
mouse.  Even shifting it one way or the other doesn't help much.
Unless the mouse works part of the time, I'd say the baudrate's wrong -
and maybe even then; I haven't tried running a mouse at the wrong
baudrate, so I don't know.  I suspect it might sort-of work.

Do you get these errors only occasionally (say, no more than every few
seconds when moving the mouse) or does touching the mouse at all
generate a flood of them?

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       mouse@rodents.montreal.qc.ca
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B