From owner-freebsd-current@FreeBSD.ORG Wed Nov 5 09:52:58 2003 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B08ED16A4CE for ; Wed, 5 Nov 2003 09:52:58 -0800 (PST) Received: from regina.plastikos.com (216-107-106-250.wan.networktel.net [216.107.106.250]) by mx1.FreeBSD.org (Postfix) with ESMTP id 82F8844001 for ; Wed, 5 Nov 2003 09:52:57 -0800 (PST) (envelope-from fullermd@over-yonder.net) Received: from mortis.over-yonder.net (adsl-212-172-144.jan.bellsouth.net [68.212.172.144]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by regina.plastikos.com (Postfix) with ESMTP id 5FC866EEB9 for ; Wed, 5 Nov 2003 12:52:56 -0500 (EST) Received: by mortis.over-yonder.net (Postfix, from userid 100) id E8C6220F2F; Wed, 5 Nov 2003 11:52:53 -0600 (CST) Date: Wed, 5 Nov 2003 11:52:53 -0600 From: "Matthew D. Fuller" To: Eirik Oeverby Message-ID: <20031105175253.GJ12248@over-yonder.net> References: <20031104153820.GB73736@starjuice.net> <20031104154618.E10222-100000@mail.chesapeake.net> <20031105091007.GJ73736@starjuice.net> <3FA8D0E2.5060507@anduin.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3FA8D0E2.5060507@anduin.net> User-Agent: Mutt/1.4.1i-fullermd.1 X-Editor: vi X-OS: FreeBSD cc: Jeff Roberson cc: current@freebsd.org Subject: Re: More ULE bugs fixed. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Nov 2003 17:52:58 -0000 On Wed, Nov 05, 2003 at 11:28:50AM +0100 I heard the voice of Eirik Oeverby, and lo! it spake thus: > > The second is that mouse messages are actually *lost*, or bogus ones are > being generated. I guess it's the first, making moused or X misinterpret > the messages it gets. Where along the chain it fails I obviously have no > clue. The consequence of this is that when the mouse stops (like in #1) > but then resumes from an entirely different point - be it 10 pixels away > or at the other end of the screen - possibly even generating a button > push (but not necessarily the corresponding button release) message. Note that I've had this to a greater or lesser extent for as long as I can remember (certainly back to 3.0-CURRENT). It corresponds with syslog'd messages on my xconsole along the lines of: Nov 3 12:46:13 mortis kernel: psmintr: out of sync (00c0 != 0000). Nov 3 12:46:13 mortis kernel: psmintr: discard a byte (12). It's certainly a lot more common (by orders of magnitude) on 5.x in the past... oh, I dunno, year-ish, than it was previously. I lose mouse function for maybe a second, then it squirms itself off somewhere on the screen and sends some button press events. I'm currently running 5.1-R, the traditional scheduler, a PS/2 mouse with no moused. And since I got them (much more rarely) with earlier 5-CURRENT's, and with 4-CURRENT's, etc, I can't see how it's scheduler related. > When you say you get the bogus mouse events (which I believe you are > saying atleast ;) only during load, I'm immediately thinking that yes, > that might make sense. I don't get it only under load; sometimes from flat idle. However, it's usually when I first move the mouse, after it sitting still for a while (where 'while' can vary from a few seconds to a few days, of course); it hardly ever happens in mid-move. -- Matthew Fuller (MF4839) | fullermd@over-yonder.net Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ "The only reason I'm burning my candle at both ends, is because I haven't figured out how to light the middle yet"