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 influence.
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?
/Eirik
Greetings, /Eirik
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 moments
> when the system is under load, in particular during heavy UI operations
> 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 amplified.
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 Windogs...
mj
_______________________________________________
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
_______________________________________________ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
_______________________________________________ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
