More ULE bugs fixed.

[Eirik Oeverby]

Sheldon Hearn wrote:
> 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.