From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <0cbd0735d6fe745e6fa6fc33e20a1ca2@plan9.bell-labs.com> From: David Presotto To: 9fans@cse.psu.edu Subject: Re: [9fans] Re: random moving of cursor arrow In-Reply-To: <20030728072659.B1666@cackle.proxima.alt.za> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="upas-xyvmgjsjsaugilhddwzdnicdme" Date: Mon, 28 Jul 2003 23:11:37 -0400 Topicbox-Message-UUID: 07d00990-eacc-11e9-9e20-41e7f4b1d025 This is a multi-part message in MIME format. --upas-xyvmgjsjsaugilhddwzdnicdme Content-Disposition: inline Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit 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. --upas-xyvmgjsjsaugilhddwzdnicdme Content-Type: message/rfc822 Content-Disposition: inline Received: from plan9.cs.bell-labs.com ([135.104.9.2]) by plan9; Mon Jul 28 01:39:30 EDT 2003 Received: from mail.cse.psu.edu ([130.203.4.6]) by plan9; Mon Jul 28 01:39:28 EDT 2003 Received: by mail.cse.psu.edu (CSE Mail Server, from userid 60001) id B734E19B8B; Mon, 28 Jul 2003 01:39:20 -0400 (EDT) Received: from psuvax1.cse.psu.edu (psuvax1.cse.psu.edu [130.203.6.6]) by mail.cse.psu.edu (CSE Mail Server) with ESMTP id 6A51719AAB; Mon, 28 Jul 2003 01:39:16 -0400 (EDT) X-Original-To: 9fans@cse.psu.edu Delivered-To: 9fans@cse.psu.edu Received: by mail.cse.psu.edu (CSE Mail Server, from userid 60001) id A9CB119B37; Mon, 28 Jul 2003 01:38:53 -0400 (EDT) Received: from cackle.proxima.alt.za (cackle.proxima.alt.za [196.30.44.141]) by mail.cse.psu.edu (CSE Mail Server) with ESMTP id 2F107199D4 for <9fans@cse.psu.edu>; Mon, 28 Jul 2003 01:38:51 -0400 (EDT) Received: from cackle.proxima.alt.za (localhost [127.0.0.1]) by cackle.proxima.alt.za (8.12.9/8.12.3) with ESMTP id h6S5R3np008850 for <9fans@cse.psu.edu>; Mon, 28 Jul 2003 07:27:04 +0200 (SAST) Received: (from lucio@localhost) by cackle.proxima.alt.za (8.12.9/8.12.3/Submit) id h6S5R0lC008849 for 9fans@cse.psu.edu; Mon, 28 Jul 2003 07:27:00 +0200 (SAST) From: Lucio De Re To: 9fans@cse.psu.edu Subject: Re: [9fans] Re: random moving of cursor arrow Message-ID: <20030728072659.B1666@cackle.proxima.alt.za> Mail-Followup-To: 9fans@cse.psu.edu References: <012c01c3528e$f861d2a0$b9844051@insultant.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.4us In-Reply-To: ; from David Presotto on Fri, Jul 25, 2003 at 10:22:10PM -0400 Organization: Proxima Research & Development Sender: 9fans-admin@cse.psu.edu Errors-To: 9fans-admin@cse.psu.edu X-BeenThere: 9fans@cse.psu.edu X-Mailman-Version: 2.0.11 Precedence: bulk Reply-To: 9fans@cse.psu.edu X-Reply-To: lucio@proxima.alt.za List-Id: Fans of the OS Plan 9 from Bell Labs <9fans.cse.psu.edu> List-Archive: Date: Mon, 28 Jul 2003 07:26:59 +0200 X-Spam-Status: No, hits=-2.5 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, REPLY_WITH_QUOTES version=2.55 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) 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 --upas-xyvmgjsjsaugilhddwzdnicdme--