J.R. Oldroyd wrote:
> On Wed, 23 Jan 2008 08:27:58 -0700, Joe Peterson <[EMAIL PROTECTED]> wrote:
>> Also, it seems that intermittent mouse freezes happen more often when
>> I've been away from the machine for a while and return to start using
>> the mouse again, but that's not always the case. A
On Wed, 23 Jan 2008 08:27:58 -0700, Joe Peterson <[EMAIL PROTECTED]> wrote:
>
> Also, it seems that intermittent mouse freezes happen more often when
> I've been away from the machine for a while and return to start using
> the mouse again, but that's not always the case. A few short
> freezes/st
Wayne Sierke wrote:
> So it seems the only thing of interest that I"ve managed to capture so
> far pertains to glxgears - an instance of the "stutter" and a part of a
> short freeze when dragging its window. Unfortunately these frequent
> mouse disconnects make it difficult to recognise genuine fre
Doh! Now that I'm no longer using the 8 month old version of
schedgraph.py that was displaying interesting but useless graphs,
perhaps I won't continue to appear as though I'm raving like such a
lunatic about what is contained in my ktr captures.
Here follows a re-examination of the previously pos
Kris,
Latest captures (of interest) - they're not hard to come by, it seems. I
see more than a couple of these every hour at least while I'm actively
doing anything on this system, and I've witnessed up to two or three
times that many at times.
It seems my initial glee about catching Epiphany ou
Kris,
Another one, this time xorg for 2 seconds, approximately in the middle.
I'm feeling inclined to doubt the validity of this and the previous data
set, however. Looking at the tail end of each of the events in question,
there is clearly activity on other processes before the supposedly long
e
Kris,
I caught this one during what I'd class as normal usage, with a handful
of apps open, and no glxgears or other glx apps (intentionally) running.
It shows Epiphany getting cpu solidly for 2 seconds! If you crank up the
ticks per pixel and scroll to the end you can't miss it.
This typifies an
On Thu, 2008-01-17 at 20:50 +0100, Kris Kennaway wrote:
> Wayne Sierke wrote:
> > On Mon, 2008-01-14 at 21:06 +0100, Kris Kennaway wrote:
> >> Same deal as before then. It cannot be the same problem as in the
> >> previous 6.x trace (unless you are using a non-mpsafe filesystem, i.e.
> >> not UF
Kris Kennaway wrote:
> KTR_SCHED
Kris, BTW, I am curious if the traces I posted were informative. Let me
know if I did not create them correctly. The xterm test seems to vary
in usefulness depending on video card (faster cards catch up too
quickly), but the freezing still happens quite often usi
Wayne Sierke wrote:
On Mon, 2008-01-14 at 21:06 +0100, Kris Kennaway wrote:
Same deal as before then. It cannot be the same problem as in the
previous 6.x trace (unless you are using a non-mpsafe filesystem, i.e.
not UFS).
Kris
In fact I have some MSDOSFS auto-mounting from /etc/fstab, but
On Mon, 2008-01-14 at 21:06 +0100, Kris Kennaway wrote:
> Same deal as before then. It cannot be the same problem as in the
> previous 6.x trace (unless you are using a non-mpsafe filesystem, i.e.
> not UFS).
>
> Kris
In fact I have some MSDOSFS auto-mounting from /etc/fstab, but normally
not
Wayne Sierke wrote:
Just thought I'd check in in case there are any suggestions at this
point. If not I'll proceed with recompiling ports and preparing test
kernels.
Same deal as before then. It cannot be the same problem as in the
previous 6.x trace (unless you are using a non-mpsafe filesys
On Sun, 2008-01-13 at 21:09 +0100, Kris Kennaway wrote:
> Yeah, this shows things like contention between the mouse device and
> other parts of the kernel that still require the Giant lock in 6.x. It
> is not likely that these will be fixed in 6.x but most of them are in
> 7.0, so you should
13 matches
Mail list logo
