Was: More ULE bugs fixed. Is: Mouse problem?
ltning at anduin.net
Tue Nov 4 16:35:31 PST 2003
Eirik Oeverby wrote:
> Just for those interested:
> I do *not* get any messages at all from the kernel (or elsewhere) when
> my mouse goes haywire. And it's an absolute truth (just tested back and
> forth 8 times) that it *only* happens with SCHED_ULE and *only* with old
> versions (~1.50) and the very latest ones (1.75 as I'm currently
> running). 1.69 for instance did *not* show any such problems.
> I will, however, update my kernel again now, to get the latest
> sched_ule.c (if any changes have been made since 1.75) and to test with
> the new interrupt handler. I have a suspicion it might be a combination
> of SCHED_ULE and some signal/message/interrupt handling causing messages
> to get lost along the way. Because that's exactly how it feels...
Whee. Either the bump from sched_ule.c 1.75 to 1.77 changed something
back to the old status, or the new interrupt handling has had some major
All I can say is - wow. My system is now more responsive than ever, I
cannot (so far) reproduce any mouse jerkiness or bogus input or
anything, and things seem smoother.
As always I cannot guarantee that this report is not influenced by the
placebo effect, but I do feel that it's a very real improvement. The
fact that I can start VMWare, Firebird, Thunderbird, Gaim and gkrellm at
the same time without having *one* mouse hickup speaks for itself. I
couldn't even do that with ULE.
So Jeff or whoever did the interrupt stuff - what did you do?
> Morten Johansen wrote:
>> On Tue, 4 Nov 2003, Sheldon Hearn wrote:
>>> On (2003/11/04 09:29), Eirik Oeverby wrote:
>>> > The problem is two parts: The mouse tends to 'lock up' for brief
>>> > when the system is under load, in particular during heavy UI
>>> > or when doing compile jobs and such.
>>> > The second part of the problem is related, and is manifested by the
>>> > mouse actually making movements I never asked it to make.
>>> Wow, I just assumed it was a local problem. I'm also seeing unrequested
>>> mouse movement, as if the signals from movements are repeated or
>>> The thing is, I'm using 4BSD, not ULE, so I wouldn't trouble Jeff to
>>> look for a cause for that specific problem in ULE.
>> Me too. Have had this problem since I got a "Intellimouse" PS/2
>> wheel-mouse. (It worked fine with previous mice (no wheel)).
>> With any scheduler in 5-CURRENT and even more frequent in 4-STABLE,
>> IIRC. Using moused or not doesn't make a difference.
>> Get these messages on console: "psmintr: out of sync", and the mouse
>> freezes then goes wild for a few seconds.
>> Can happen under load and sometimes when closing Mozilla (not often).
>> It could be related to the psm-driver. Or maybe I have a bad mouse, I
>> don't know.
>> I will try another mouse, but it does work perfectly in Linux and
>> freebsd-current at freebsd.org mailing list
>> To unsubscribe, send any mail to
>> "freebsd-current-unsubscribe at freebsd.org"
> freebsd-current at freebsd.org mailing list
> To unsubscribe, send any mail to "freebsd-current-unsubscribe at freebsd.org"
More information about the freebsd-current