On (2003/11/04 15:46), Jeff Roberson wrote:
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.
How long have you been seeing this? Are you using a usb mouse? Can you try with PS/2 if you are?
Since my last update, Fri Oct 24 17:47:22.
I am using a USB mouse, but don't have a PS/2 one. I'm also using moused, and my WM is sawfish.
The problem with all these reports is that they're scattered. It's hard to pin down exactly what the common elements are. Indeed, we may be looking at combinations of elements.
I don't have time to be more helpful, which is why I hadn't complained. I just wanted to include the datapoint that over-active mouse behaviour under load exists under SCHED_4BSD as well.
Incidentally, this is under ATA disk load. I don't really push my CPU.
Though I am not a hardcore C programmer, much less a FreeBSD contributor in any way, I do have some experience in tracking down problems like this. Used to have a lot of them on some of the more obscure platforms I've been using in the past.
My feeling is (and it might be completely wrong ofcourse) that we are dealing with atleast two completely separate issues here. The first has to do with mouse jerkiness, the second has to do with bogus mouse events.
There is a significant difference between these two, and personally I am leaning towards concluding that the first has to do with the scheduler, and the second has to do with something entirely different - interrupt handler or something else of the sorts.
The first is simply that the mouse stops for a brief moment and then continues from the point where it stopped. Perhaps this is the situation that is remedied by bypassing moused? Is moused perhaps not getting the CPU cycles it needs to process and pass on mouse messages?
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.
These two situations could at first sight be mistaken for being the same symptom, but I am pretty sure they are very different. One may influence the other, or they may by coincidence (or for some good reason) happen at the same time, but I believe the errors happen in different parts of the kernel.
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. But I guess that's better left to those who are in the know to decide ;) I have never seen it happen with the 4BSD scheduler, but that might have other reasons (hardware?).
Why don't you try with the new interrupt handler? Helped me quite a lot.. :)
/Eirik
Ciao, Sheldon.
_______________________________________________ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
