Matthew D. Fuller wrote:
On Wed, Nov 05, 2003 at 11:28:50AM +0100 I heard the voice of
Eirik Oeverby, and lo! it spake thus:
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. Wher
On Wed, Nov 05, 2003 at 11:28:50AM +0100 I heard the voice of
Eirik Oeverby, and lo! it spake thus:
>
> 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 chai
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
On Wed, 5 Nov 2003, 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? C
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 la
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 updat
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 trut
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 SCHE
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 a
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* happe
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)
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 (
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 la
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'
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
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
ti
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-S
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
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
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
Jeff Roberson wrote:
On Mon, 3 Nov 2003, Eirik Oeverby wrote:
Hi,
Just recompiled yesterday, running sched_ule.c 1.75. It seems to have
re-introduced the bogus mouse events I talked about earlier, after a
period of having no problems with it. The change happened between 1.69
and 1.75, and there'
On Mon, 3 Nov 2003, Eirik Oeverby wrote:
> Hi,
>
> Just recompiled yesterday, running sched_ule.c 1.75. It seems to have
> re-introduced the bogus mouse events I talked about earlier, after a
> period of having no problems with it. The change happened between 1.69
> and 1.75, and there's also the
On Tue, 4 Nov 2003, Bruce Evans wrote:
> On Sun, 2 Nov 2003, Jeff Roberson wrote:
>
> > You commented on the nice cutoff before. What do you believe the correct
> > behavior is? In ULE I went to great lengths to be certain that I emulated
> > the old behavior of denying nice +20 processes cpu t
On Tue, Nov 04, 2003 at 12:33:48AM +1100, Bruce Evans wrote:
> I think the existence of rtprio and a non-broken idprio makes infinite
> deprioritization using niceness unnecessary. (idprio is still broken
> (not available to users) in -current, but it doesn't need to be if
> priority propagation i
On Sun, 2 Nov 2003, Jeff Roberson wrote:
> On Sat, 1 Nov 2003, Bruce Evans wrote:
> > My simple make benchmark now takes infinitely longer with ULE under SMP,
> > since make -j 16 with ULE under SMP now hangs nfs after about a minute.
> > 4BSD works better. However, some networking bugs have dev
Hi,
Just recompiled yesterday, running sched_ule.c 1.75. It seems to have
re-introduced the bogus mouse events I talked about earlier, after a
period of having no problems with it. The change happened between 1.69
and 1.75, and there's also the occational glitch in keyboard input.
If you need
Jeff Roberson <[EMAIL PROTECTED]> wrote:
> On Fri, 31 Oct 2003, Bruno Van Den Bossche wrote:
[...]
> > I recently had to complete a little piece of software in a course on
> > parallel computing. I've put it online[1] (we only had to write the
> > pract2.cpp file). It calculates the inverse of a
On Fri, 31 Oct 2003, Sam Leffler wrote:
> On Friday 31 October 2003 09:04 am, Bruce Evans wrote:
>
> > My simple make benchmark now takes infinitely longer with ULE under SMP,
> > since make -j 16 with ULE under SMP now hangs nfs after about a minute.
> > 4BSD works better. However, some networki
On Sat, 1 Nov 2003, Bruce Evans wrote:
> On Fri, 31 Oct 2003, Jeff Roberson wrote:
>
> > I have commited my SMP fixes. I would appreciate it if you could post
> > update results. ULE now outperforms 4BSD in a single threaded kernel
> > compile and performs almost identically in a 16 way make. I
On Fri, 31 Oct 2003, Bruno Van Den Bossche wrote:
> Jeff Roberson <[EMAIL PROTECTED]> wrote:
>
> > On Wed, 29 Oct 2003, Jeff Roberson wrote:
> >
> > > On Thu, 30 Oct 2003, Bruce Evans wrote:
> > >
> > > > > Test for scheduling buildworlds:
> > > > >
> > > > > cd /usr/src/usr.bin
> > > > >
On Friday 31 October 2003 09:04 am, Bruce Evans wrote:
> My simple make benchmark now takes infinitely longer with ULE under SMP,
> since make -j 16 with ULE under SMP now hangs nfs after about a minute.
> 4BSD works better. However, some networking bugs have developed in the
> last few days. On
On Fri, 31 Oct 2003, Jeff Roberson wrote:
> I have commited my SMP fixes. I would appreciate it if you could post
> update results. ULE now outperforms 4BSD in a single threaded kernel
> compile and performs almost identically in a 16 way make. I still have a
> few more things that I can do to
Jeff Roberson <[EMAIL PROTECTED]> wrote:
> On Wed, 29 Oct 2003, Jeff Roberson wrote:
>
> > On Thu, 30 Oct 2003, Bruce Evans wrote:
> >
> > > > Test for scheduling buildworlds:
> > > >
> > > > cd /usr/src/usr.bin
> > > > for i in obj depend all
> > > > do
> > > >
On Wed, 29 Oct 2003, Jeff Roberson wrote:
> On Thu, 30 Oct 2003, Bruce Evans wrote:
>
> > > Test for scheduling buildworlds:
> > >
> > > cd /usr/src/usr.bin
> > > for i in obj depend all
> > > do
> > > MAKEOBJDIRPREFIX=/somewhere/obj time make -s -j16 $i
> > > done >/tmp/zqz 2>&1
On Thu, 30 Oct 2003, Bruce Evans wrote:
> > Test for scheduling buildworlds:
> >
> > cd /usr/src/usr.bin
> > for i in obj depend all
> > do
> > MAKEOBJDIRPREFIX=/somewhere/obj time make -s -j16 $i
> > done >/tmp/zqz 2>&1
> >
> > (Run this with an empty /somewhere/obj.
> Test for scheduling buildworlds:
>
> cd /usr/src/usr.bin
> for i in obj depend all
> do
> MAKEOBJDIRPREFIX=/somewhere/obj time make -s -j16 $i
> done >/tmp/zqz 2>&1
>
> (Run this with an empty /somewhere/obj. The all stage doesn't quite
> finish.) On an ABI
Bruce Evans [EMAIL PROTECTED] wrote :
> On Sun, 26 Oct 2003, Jon Mini wrote:
>
> > Jeff Roberson [EMAIL PROTECTED] wrote :
> >
> > > On Fri, 17 Oct 2003, Bruce Evans wrote:
> > >
> > > How would one test if it was an improvement on the 4BSD scheduler? It
> > > is not even competitive in my simpl
On Sun, 26 Oct 2003, Jon Mini wrote:
> Jeff Roberson [EMAIL PROTECTED] wrote :
>
> > On Fri, 17 Oct 2003, Bruce Evans wrote:
> >
> > How would one test if it was an improvement on the 4BSD scheduler? It
> > is not even competitive in my simple tests.
>
> What were your simple tests?
Er, they wer
Jeff Roberson [EMAIL PROTECTED] wrote :
> On Fri, 17 Oct 2003, Bruce Evans wrote:
>
> How would one test if it was an improvement on the 4BSD scheduler? It
> is not even competitive in my simple tests.
What were your simple tests?
--
Jonathan Mini <[EMAIL PROTECTED]>
http://www.freebsd.org/
_
On Fri, 17 Oct 2003, Bruce Evans wrote:
> On Fri, 17 Oct 2003, Jeff Roberson wrote:
>
> > On Fri, 17 Oct 2003, Bruce Evans wrote:
> >
> > > How would one test if it was an improvement on the 4BSD scheduler? It
> > > is not even competitive in my simple tests.
> > > ...
> >
> > At one point ULE wa
Thanks.
I should have known =)
/Eirik
Maxime Henrion wrote:
Eirik Oeverby wrote:
As a side note/question:
Is there any way to figure out which ULE version I'm running in a
precompiled kernel? I just nuked my src tree by accident, and am not
sure if i'm on 1.65 or something older..
If there is
On Fri, 17 Oct 2003, Jeff Roberson wrote:
> On Fri, 17 Oct 2003, Bruce Evans wrote:
>
> > How would one test if it was an improvement on the 4BSD scheduler? It
> > is not even competitive in my simple tests.
> > ...
>
> At one point ULE was at least as fast as 4BSD and in most cases faster.
> Thi
Eirik Oeverby wrote:
> As a side note/question:
> Is there any way to figure out which ULE version I'm running in a
> precompiled kernel? I just nuked my src tree by accident, and am not
> sure if i'm on 1.65 or something older..
>
> If there is no way, is this perhaps an idea?
Try "ident /boot
As a side note/question:
Is there any way to figure out which ULE version I'm running in a
precompiled kernel? I just nuked my src tree by accident, and am not
sure if i'm on 1.65 or something older..
If there is no way, is this perhaps an idea?
Thanks,
/Eirik
Jeff Roberson wrote:
On Fri, 17 Oc
> The commit to src/sys/kern/kern_switch.c:1.62, would it fix the
> following crash (can't find my kernel with debugging symbols):
Hrm, nope. This is from a kernel from tonight at 9pm PST. -sc
#0 doadump () at /usr/src/sys/kern/kern_shutdown.c:240
#1 0xc052f579 in boot (howto=256) at /usr/src
> > > > I think you cvsup'd at a bad time. I fixed a bug that would have
> > > > caused the system to lock up in this case late last night. On my
> > > > system it freezes for a few seconds and then returns. I can stop
> > > > that by turning down the interactivity threshold.
> > >
> > > Hrm, I
Il Mer, 2003-10-15 alle 09:51, Jeff Roberson ha scritto:
> I fixed two bugs that were exposed due to more of the kernel running
> outside of Giant. ULE had some issues with priority propagation that
> stopped it from working very well.
>
> Things should be much improved.
On my Athlon XP 2000+ t
> > > I think you cvsup'd at a bad time. I fixed a bug that would have
> > > caused the system to lock up in this case late last night. On my
> > > system it freezes for a few seconds and then returns. I can stop
> > > that by turning down the interactivity threshold.
> >
> > Hrm, I must concur
On Fri, 17 Oct 2003, Sean Chittenden wrote:
> > I think you cvsup'd at a bad time. I fixed a bug that would have
> > caused the system to lock up in this case late last night. On my
> > system it freezes for a few seconds and then returns. I can stop
> > that by turning down the interactivity
> I think you cvsup'd at a bad time. I fixed a bug that would have
> caused the system to lock up in this case late last night. On my
> system it freezes for a few seconds and then returns. I can stop
> that by turning down the interactivity threshold.
Hrm, I must concur that while ULE seems a
On Fri, 17 Oct 2003, Bruce Evans wrote:
> On Fri, 17 Oct 2003, Jeff Roberson wrote:
>
> > On Fri, 17 Oct 2003, Bruce Evans wrote:
> >
> > > How would one test if it was an improvement on the 4BSD scheduler? It
> > > is not even competitive in my simple tests.
> > > ...
> >
> > At one point ULE w
On Fri, 17 Oct 2003, Bruce Evans wrote:
> How would one test if it was an improvement on the 4BSD scheduler? It
> is not even competitive in my simple tests.
[scripts results deleted]
>
> Summary: SCHED_ULE was more than twice as slow as SCHED_4BSD for the
> obj and depend stages. These stages
On Wed, 15 Oct 2003, Jeff Roberson wrote:
> I fixed two bugs that were exposed due to more of the kernel running
> outside of Giant. ULE had some issues with priority propagation that
> stopped it from working very well.
>
> Things should be much improved. Feedback, as always, is welcome. I'd
>
Jeff Roberson wrote:
On Thu, 16 Oct 2003, Eirik Oeverby wrote:
Jeff Roberson wrote:
On Wed, 15 Oct 2003, Eirik Oeverby wrote:
Eirik Oeverby wrote:
Jeff Roberson wrote:
I fixed two bugs that were exposed due to more of the kernel running
outside of Giant. ULE had some issues with priorit
Hi !
> Things should be much improved. Feedback, as always, is welcome.
Wow ! Smoothly working under a load of approx. 4.
Running gnome2, mozilla, evolution, mplayer and kpdf.
Running portsdb -Uu and a kernel build.
No stuttering mouse, no irritating delays, fast rendering.
That's definitely bet
On Thu, 16 Oct 2003, Eirik Oeverby wrote:
> Jeff Roberson wrote:
> > On Wed, 15 Oct 2003, Eirik Oeverby wrote:
> >
> >
> >>Eirik Oeverby wrote:
> >>
> >>>Jeff Roberson wrote:
> >>>
> >>>
> I fixed two bugs that were exposed due to more of the kernel running
> outside of Giant. ULE had som
Jeff Roberson wrote:
On Wed, 15 Oct 2003, Eirik Oeverby wrote:
Eirik Oeverby wrote:
Jeff Roberson wrote:
I fixed two bugs that were exposed due to more of the kernel running
outside of Giant. ULE had some issues with priority propagation that
stopped it from working very well.
Things should b
On Wed, 15 Oct 2003, Daniel Eischen wrote:
> On Wed, 15 Oct 2003, Jeff Roberson wrote:
>
> > I fixed two bugs that were exposed due to more of the kernel running
> > outside of Giant. ULE had some issues with priority propagation that
> > stopped it from working very well.
> >
> > Things shou
On Wed, 15 Oct 2003, Jeff Roberson wrote:
> On Wed, 15 Oct 2003, Daniel Eischen wrote:
>
> > On Wed, 15 Oct 2003, Jeff Roberson wrote:
> >
> > > I fixed two bugs that were exposed due to more of the kernel running
> > > outside of Giant. ULE had some issues with priority propagation that
> > > s
On Wed, 15 Oct 2003, Daniel Eischen wrote:
> On Wed, 15 Oct 2003, Jeff Roberson wrote:
>
> > I fixed two bugs that were exposed due to more of the kernel running
> > outside of Giant. ULE had some issues with priority propagation that
> > stopped it from working very well.
> >
> > Things should b
On Wed, 15 Oct 2003, Eirik Oeverby wrote:
> Eirik Oeverby wrote:
> > Jeff Roberson wrote:
> >
> >> I fixed two bugs that were exposed due to more of the kernel running
> >> outside of Giant. ULE had some issues with priority propagation that
> >> stopped it from working very well.
> >>
> >> Thing
On Wed, 15 Oct 2003, Jeff Roberson wrote:
> I fixed two bugs that were exposed due to more of the kernel running
> outside of Giant. ULE had some issues with priority propagation that
> stopped it from working very well.
>
> Things should be much improved. Feedback, as always, is welcome. I'd
Eirik Oeverby wrote:
Jeff Roberson wrote:
I fixed two bugs that were exposed due to more of the kernel running
outside of Giant. ULE had some issues with priority propagation that
stopped it from working very well.
Things should be much improved. Feedback, as always, is welcome. I'd
like to loo
Jeff Roberson wrote:
I fixed two bugs that were exposed due to more of the kernel running
outside of Giant. ULE had some issues with priority propagation that
stopped it from working very well.
Things should be much improved. Feedback, as always, is welcome. I'd
like to look into making this the
I fixed two bugs that were exposed due to more of the kernel running
outside of Giant. ULE had some issues with priority propagation that
stopped it from working very well.
Things should be much improved. Feedback, as always, is welcome. I'd
like to look into making this the default scheduler f
65 matches
Mail list logo
