Re: Was: More ULE bugs fixed. Is: Mouse problem?
On Tue, 4 Nov 2003 22:10:36 -0500 (EST), Jeff Roberson [EMAIL PROTECTED] wrote: On Wed, 5 Nov 2003, Eirik Oeverby wrote: 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 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? This is wonderful news. I fixed a few bugs over the last couple of days. I'm not sure which one caused your problem. I'm very pleased to hear your report though. This SCHED_ULE (1.78) rocks! I don't get any mouse lag anymore in the 'cd /usr/src ; make clean ; make cleandir' and the beginner of 'portupgrade -ra'. I did the hard test; I have Gnome2, Opera 7 (linux version), several gvim, several gnome-terminal tabs, pan and even use totem to watch a movie (700mb) in full screen mode ;-).. While watching the movie and it doesn't get lag that much only while unpack the large tarballs like mozilla. While the build and clean, it only has very very little lag like one to two time(s) but the rest are pretty smooth. The mouse doesn't get any lag at all. Just let you know my experience with SCHED_ULE so far. In the command line, I can tell that I can 'feel' it's faster but I don't know about the real time (ie: benchmark). It's better than SCHED_4BSD because I will get mouse lag if I do the same thing as above with SCHED_4BSD. BTW: I don't use KSE because of Nvidia driver. Cheers, Mezz Cheers, Jeff /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 -- bsdforums.org 's moderator, mezz. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Was: More ULE bugs fixed. Is: Mouse problem?
On Wed, 2003-11-05 at 17:04, Jeremy Messenger wrote: I don't get any mouse lag anymore in the 'cd /usr/src ; make clean ; make cleandir' and the beginner of 'portupgrade -ra'. I did the hard test; I have Gnome2, Opera 7 (linux version), several gvim, several gnome-terminal tabs, pan and even use totem to watch a movie (700mb) in full screen mode ;-).. While watching the movie and it doesn't get lag that much only while unpack the large tarballs like mozilla. While the build and clean, it only has very very little lag like one to two time(s) but the rest are pretty smooth. The mouse doesn't get any lag at all. Yup.. Latest SCHED_ULE commit did it for me. My system now is fast and responsive. I ran similar tests, and everything ran quite smoothly with Gnome Desktop environment. Quite drastic change, system was practically unusable before this with SCHED_ULE. However, under higher CPU usage (90%+) and load (2) the mouse starts to feel sluggish. While still responsive enough to use, it still slows down enough to be noticeable. psm0: PS/2 Mouse irq 12 on atkbdc0 psm0: model IntelliMouse, device ID 3 Dual Pentium III Intel 440BX BTW: I don't use KSE because of Nvidia driver. Confirmed. It now works just fine (so far) with KSE. signature.asc Description: This is a digitally signed message part
Re: Was: More ULE bugs fixed. Is: Mouse problem?
On Tue, Nov 04, 2003 at 11:13:26PM +0100, Morten Johansen wrote: 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... Yes, I have had this problem for a while now also. I have sent mail to current@ a while ago. Date: Thu, 2 Oct 2003 18:31:36 +0930 From: Alex Wilkinson [EMAIL PROTECTED] Subject: sec:u kernel: psmintr: out of sync To: [EMAIL PROTECTED] Hi all, I am switching between several OS's with a Cybex KVW switch. I now seem to have a problem with my mouse (after build world/kernel). FreeBSD 5.1-CURRENT #2: Wed Aug 20 13:28:54 CST 2003 I am getting these messages on the console when I move my mouse, the cursor moves in a very choppy motion (painfully slow). Oct 1 09:46:17 squirm kernel: psmintr: out of sync ( != 0008). Oct 1 09:46:17 squirm kernel: psmintr: discard a byte (1). Oct 1 09:46:17 squirm kernel: psmintr: out of sync ( != 0008). Oct 1 09:46:17 squirm kernel: psmintr: discard a byte (2). Oct 1 09:46:18 squirm kernel: psmintr: out of sync ( != 0008). Oct 1 09:46:18 squirm kernel: psmintr: discard a byte (3). Oct 1 09:46:18 squirm kernel: psmintr: out of sync ( != 0008). Oct 1 09:46:18 squirm kernel: psmintr: re-enable the mouse. Oct 1 09:46:18 squirm kernel: psm: DISABLE_DEV return code:00fa Oct 1 09:46:18 squirm kernel: psm: ENABLE_DEV return code:00fa Oct 1 09:46:20 squirm kernel: psmintr: out of sync ( != 0008). moused is running with the following: moused -p /dev/psm0 -t auto The mouse is a Microsoft IntelliMouse connected to the KVM via a USB-PS/2 adapter. If I boot the same machine into -STABLE this does *not* happen. I have tryed running moused with different protocols without any luck. Can anyone help me solve this problem ? I have to run -STABLE if I can't solve this problem, so any help would be appreciated. Thanks - aW p.s the mouse works fine with: FreeBSD -STABLE, RH Linux, Irix 6.5.20, Tru64, and WinXP. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Was: More ULE bugs fixed. Is: Mouse problem?
I've had this problem on my laptop since I bought it last year and started running -current. It's annoying, but luckily doesn't happen very often. My gut feeling here is that the psm driver isn't servicing its interrupts fast enough and characters are being dropped out of the FIFO. Maybe it's time to take the psm driver to task and figure out how to make it fast. Scott On Wed, 5 Nov 2003, Alex Wilkinson wrote: On Tue, Nov 04, 2003 at 11:13:26PM +0100, Morten Johansen wrote: 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... Yes, I have had this problem for a while now also. I have sent mail to current@ a while ago. Date: Thu, 2 Oct 2003 18:31:36 +0930 From: Alex Wilkinson [EMAIL PROTECTED] Subject: sec:u kernel: psmintr: out of sync To: [EMAIL PROTECTED] Hi all, I am switching between several OS's with a Cybex KVW switch. I now seem to have a problem with my mouse (after build world/kernel). FreeBSD 5.1-CURRENT #2: Wed Aug 20 13:28:54 CST 2003 I am getting these messages on the console when I move my mouse, the cursor moves in a very choppy motion (painfully slow). Oct 1 09:46:17 squirm kernel: psmintr: out of sync ( != 0008). Oct 1 09:46:17 squirm kernel: psmintr: discard a byte (1). Oct 1 09:46:17 squirm kernel: psmintr: out of sync ( != 0008). Oct 1 09:46:17 squirm kernel: psmintr: discard a byte (2). Oct 1 09:46:18 squirm kernel: psmintr: out of sync ( != 0008). Oct 1 09:46:18 squirm kernel: psmintr: discard a byte (3). Oct 1 09:46:18 squirm kernel: psmintr: out of sync ( != 0008). Oct 1 09:46:18 squirm kernel: psmintr: re-enable the mouse. Oct 1 09:46:18 squirm kernel: psm: DISABLE_DEV return code:00fa Oct 1 09:46:18 squirm kernel: psm: ENABLE_DEV return code:00fa Oct 1 09:46:20 squirm kernel: psmintr: out of sync ( != 0008). moused is running with the following: moused -p /dev/psm0 -t auto The mouse is a Microsoft IntelliMouse connected to the KVM via a USB-PS/2 adapter. If I boot the same machine into -STABLE this does *not* happen. I have tryed running moused with different protocols without any luck. Can anyone help me solve this problem ? I have to run -STABLE if I can't solve this problem, so any help would be appreciated. Thanks - aW p.s the mouse works fine with: FreeBSD -STABLE, RH Linux, Irix 6.5.20, Tru64, and WinXP. ___ [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]
Re: Was: More ULE bugs fixed. Is: Mouse problem?
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... 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]
Re: Was: More ULE bugs fixed. Is: Mouse problem?
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 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]
Re: Was: More ULE bugs fixed. Is: Mouse problem?
Eirik Oeverby wrote: 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 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? Oh and just to add to the goods/bads: A make -j 16 buildworld still makes the box sluggish when it gets to the crypto stuff, but not anywhere close to what it was like before. I'd say it probably matches or beats ULE now. And one *major* thing: I can now play sound again! Without clicks or pops like I've had since 5.1-RELEASE .. I can play sound for real! *meep* *meep* what a relief! This upped my QOL (quality-of-life) quite significantly, given that I haven't been able to play music (wihout being annoyed beyond what is good for me or anyone else near) since, what, spring? *phew* Thanks, to whomever of you guys made this possible... /Eirik /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] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Was: More ULE bugs fixed. Is: Mouse problem?
On Wed, Nov 05, 2003 at 12:27:04AM +0100, 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... Question: How can I find out what verion of SCHED_ULE I am running ? - aW ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Was: More ULE bugs fixed. Is: Mouse problem?
Alex Wilkinson wrote: On Wed, Nov 05, 2003 at 12:27:04AM +0100, 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... Question: How can I find out what verion of SCHED_ULE I am running ? I asked the same recently, and here's what I know: - check /usr/src/sys/kern/sched_ule.c - a page or so down there's a line with the revision - ident /boot/kernel/kernel | grep sched_ule /Eirik - aW ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Was: More ULE bugs fixed. Is: Mouse problem?
On Wed, 5 Nov 2003, Eirik Oeverby wrote: Alex Wilkinson wrote: On Wed, Nov 05, 2003 at 12:27:04AM +0100, 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... Question: How can I find out what verion of SCHED_ULE I am running ? I asked the same recently, and here's what I know: - check /usr/src/sys/kern/sched_ule.c - a page or so down there's a line with the revision - ident /boot/kernel/kernel | grep sched_ule Ident also works on source files. Cheers, Jeff /Eirik - aW ___ [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]
Re: Was: More ULE bugs fixed. Is: Mouse problem?
On Wed, 5 Nov 2003, Eirik Oeverby wrote: 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 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? This is wonderful news. I fixed a few bugs over the last couple of days. I'm not sure which one caused your problem. I'm very pleased to hear your report though. Cheers, Jeff /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] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
