On Wed, 2008-10-01 at 16:36 -0400, Stephen Clark wrote:
Robert Watson wrote:
On Wed, 1 Oct 2008, Gary Palmer wrote:
ps alxw may be of interest in addition to ps auxw as it displays
what the processes are waiting on. It could conceivably be a problem
of some kind at the filesystem
On Tue, 2008-08-05 at 20:30 -0700, Jeremy Chadwick wrote:
This looks like the issue I've been tracking for months now. I'm sorry
the document isn't complete; it's an issue of time...
http://wiki.freebsd.org/JeremyChadwick/ATA_issues_and_troubleshooting
My experiences with disk timeouts on
Curiouser and curiouser...
Synopsis: attaching either or both of two Logitech MX500 mice directly
to the (fixed) rear USB ports on this system results in frequent
disconnections (disconnect/reconnects) of the mice (ums0/ums1). The
frequency of the disconnections apparently increases under
On Fri, 2008-01-25 at 01:59 +1030, Wayne Sierke wrote:
I'm getting a lot of USB mouse disconnects on RELENG_7. I wondered
whether they might have been due to running with a KTR-enabled kernel
but in just the last 7 hours I've been running on stock GENERIC and
they're still happening.
I get
On Fri, 2008-02-01 at 07:17 -0800, Jeremy Chadwick wrote:
On Fri, Feb 01, 2008 at 10:00:11PM +1030, Wayne Sierke wrote:
- I've also just noticed that I'm getting these messages on startup
under 7.x:
kernel: Starting devd.
kernel: Starting ums0 moused:
kernel
On Fri, 2008-02-01 at 12:26 -0700, Joe Peterson wrote:
Wayne Sierke wrote:
On Fri, 2008-01-25 at 01:59 +1030, Wayne Sierke wrote:
I'm getting a lot of USB mouse disconnects on RELENG_7. I wondered
whether they might have been due to running with a KTR-enabled kernel
but in just the last
I'm getting a lot of USB mouse disconnects on RELENG_7. I wondered
whether they might have been due to running with a KTR-enabled kernel
but in just the last 7 hours I've been running on stock GENERIC and
they're still happening.
I get this set of messages for each disconnect:
Jan 24 15:40:13
In an attempt to obtain a ktrdump from one of these lengthy (1-2s)
freezes I'm seeing when moving an active window running glxgears, I
configured a kernel with a 512k ktr buffer size.
I still couldn't catch any significant part of the event because of the
high rate of context-switching with
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
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
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
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
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 UFS
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 in
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
On Sun, 2008-01-13 at 12:39 +0100, Kris Kennaway wrote:
MUTEX_PROFILING changes the kernel ABI so modules that are not compiled
with that option will not work. If you use make buildkernel to build
your kernel + modules together then it uses the kernel config file for
both so they are
On Thu, 2008-01-10 at 21:27 +0100, Kris Kennaway wrote:
Toomas Aas wrote:
Kris Kennaway wrote:
OK. Can you obtain a lock profiling dump?
I'm trying, but not succeeding so far. I added the following to the
kernel config:
options MUTEX_PROFILING
options
On Sun, 2008-01-13 at 03:24 +1030, Wayne Sierke wrote:
I added options MUTEX_PROFILING and options HWPMC_HOOKS but the system
hangs when going multi-user after printing: Entropy harvesting:
interrupts ethernet point_to_point. ^t shows it stuck in dd, ^c brings
out to sysctl [null] but I
FreeBSD 6.3-PRERELEASE #5: Sat Dec 29 19:25:43 CST 2007 i386
I've noticed that this system is freezing periodically, for anywhere
from around a fraction of a second up to perhaps 1.5 seconds, and
occurring on average about twice a minute, but with no particular
pattern - i.e. it could happen
On Wed, 2006-12-13 at 12:27 -0600, Wayne M. Barnes wrote:
Dear FreeBSD,
Did something happen to the location for the pkg-descr so
that ports can't find it? The following happens to me a lot,
for many packages:
=== Installing for gmake-3.81_1
=== Generating temporary packing list
On Sun, 2006-10-01 at 02:45 -0700, Jeremy Chadwick wrote:
On Sun, Oct 01, 2006 at 02:17:17PM +0930, Wayne Sierke wrote:
If you run fsck (fsck -n is sufficient) without specifying a file
system so that it reads the list of which file systems to check from
fstab, does it check all those
On Fri, 2006-09-29 at 15:58 +0100, Josef Karthauser wrote:
On Fri, Sep 29, 2006 at 09:44:07AM -0500, Brooks Davis wrote:
On my laptop running 6.2-PRERELEASE the drives always mount dirty, which
suggests that they are not being shutdown clean; however the machine
always syncs the disks
On Fri, 2006-09-15 at 02:09 +0200, Karol Kwiatkowski wrote:
On 15/09/2006 01:37, Benjamin Lutz wrote:
On Friday 15 September 2006 01:15, Kris Kennaway wrote:
Anyone who is confused but doesn't attempt to enlighten themselves by
reading the provided documentation deserves to stay confused :)
On Sun, 2006-06-04 at 21:29 +1200, Kaiwai Gardiner wrote:
One would ask as to why xorg has failed to compile, and it appears no
one else here has experienced the same issue; hence the reason I
suggested a clean removal of installed ports and a vanilla compile of
it.
I've updated my ports
24 matches
Mail list logo
