Re: [9fans] Re: random moving of cursor arrow

[David Presotto <presotto@closedmind.org>]

[-- Attachment #1: Type: text/plain, Size: 1439 bytes --]

I tried a bundh of scenarios on some computers I had at work.  Nothing I
did would keep my 400 MHz system from losing characters on the serial
driver if I ran my cdrom full tilt and used > 38400 buad.  At or under
38400, turning on the fifo was enough, though I still saw one or two
overruns over the course of 15 minutes.  There's clearly something about
the cdrom driver that's staying at splhi way too long or causing back to
back interrupts that keep the serial interrupts from sneaking in.  At 9600
baud down (which is where the mouse should live), turning on the fifo
worked 100% of the time.

The serial driver (at least from interrupt to mouse stream interpretation)
is not  fundamentally different now than in the 3rd edition.  If the same
mouse hardware works with the 3rd edition and loses chars with the 4th I'm
moderately flabergasted.

For straight (non-mouse) serial ports, there is one difference: the 3rd ed
had much smaller queues and turned off RTS fairly often, effectively reducing
the port throughput to a fraction of what it was really set to.  It might be
that this was avoiding overruns.  I need to figure out a way to do the same
thing when the computer really can't keep up.  That should get rid of the
overruns for things like PPP.  Won't effect mice since I believe that they
ignore hardware flow control, at least the ones I have do.

The current aux/mouse on sources turns on the fifo.

[-- Attachment #2: Type: message/rfc822, Size: 3862 bytes --]

From: Lucio De Re <lucio@proxima.alt.za>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] Re: random moving of cursor arrow
Date: Mon, 28 Jul 2003 07:26:59 +0200
Message-ID: <20030728072659.B1666@cackle.proxima.alt.za>

On Fri, Jul 25, 2003 at 10:22:10PM -0400, David Presotto wrote:
>
> I'll bang at serial ports tomorrow and see if I can figure out what's happening.
> With modern machines, I shouldn't get overruns even without the fifo.  I used
> to avoid the fifo for mice because it made the mouse jerky.
>
Note that (in my recollection) the problem is more recent than the
switch to the new driver.  I have only recently migrated to an
Intellimouse and then only on my workstation and the impression I
get is that there has been a slowdown in the very recent past.  It
would be difficult for me to test this, but if we come up with no
other option, I can set up a test bench.

> Everything related has changed of course; uart driver, clock routine, and
> scheduler.  Any could be at fault.  I'll plug some machines back to back and
> see if I can cause overruns.  A mouse really shouldn't be able to though,
> it's only 9600 baud or less.  If we're missing, something is really
> screwed up.  We only use ps2 mice these days but I can scrounge up some
> serial ones.
>
I have only examined the actual driver.  I couldn't see anything
clearly suspicious in it.

> It is true that if the mouse is misidentified, it will cause exactly the
> behavior babic is seeing, i.e., if it guesses the wrong protocol.

Yes, but then echo i1 > /dev/eia0ctl wouldn't have any ameliorating
effect on it.

++L