Wayne Sierke wrote:
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
Kris Kennaway wrote:
sysctl debug.mutex.prof.enable=1
... trigger hang ...
sysctl debug.mutex.prof.enable=0
and send me the output of
sysctl debug.mutex.prof.stats
The output is here:
http://www.raad.tartu.ee/~toomas/mutex_stats.txt
--
Toomas Aas
... Whoever decided to cut taglines at 57
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
Wayne Sierke wrote:
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
Toomas Aas wrote:
Kris Kennaway wrote:
sysctl debug.mutex.prof.enable=1
... trigger hang ...
sysctl debug.mutex.prof.enable=0
and send me the output of
sysctl debug.mutex.prof.stats
The output is here:
http://www.raad.tartu.ee/~toomas/mutex_stats.txt
This one also shows giant contention
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
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 MPROF_BUFFERS=1536
options MPROF_HASH_SIZE=1543
And set debug.mutex.prof.enable=1
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 MPROF_BUFFERS=1536
options MPROF_HASH_SIZE=1543
And set
Kris Kennaway wrote:
OK, you may need to set up hwpmc or LOCK_PROFILING to figure out what
your system is doing at that moment.
While experimenting with pmcstat I found that my problem seems to be
mouse-related. I did several tests - booted, logged in with xdm, started
an xterm and left
Toomas Aas wrote:
Kris Kennaway wrote:
OK, you may need to set up hwpmc or LOCK_PROFILING to figure out what
your system is doing at that moment.
While experimenting with pmcstat I found that my problem seems to be
mouse-related. I did several tests - booted, logged in with xdm, started
an
Kris Kennaway wrote:
Toomas Aas wrote:
# grep psm /var/run/dmesg.boot
psm0: PS/2 Mouse irq 12 on atkbdc0
psm0: [GIANT-LOCKED]
psm0: model IntelliMouse, device ID 3
There was another report of problems with psm. Can you try with
sysmouse instead? If that works around the issue then we
Toomas Aas wrote:
Kris Kennaway wrote:
Toomas Aas wrote:
# grep psm /var/run/dmesg.boot
psm0: PS/2 Mouse irq 12 on atkbdc0
psm0: [GIANT-LOCKED]
psm0: model IntelliMouse, device ID 3
There was another report of problems with psm. Can you try with
sysmouse instead? If that works around
Toomas Aas wrote:
Kris Kennaway wrote:
I mean use /dev/sysmouse in X instead of /dev/psm0 directly.
That's how my xorg has always been configured:
Section InputDevice
Identifier Mouse0
Driver mouse
Option Protocol auto
Option Device
Kris Kennaway wrote:
I mean use /dev/sysmouse in X instead of /dev/psm0 directly.
That's how my xorg has always been configured:
Section InputDevice
Identifier Mouse0
Driver mouse
Option Protocol auto
Option Device /dev/sysmouse
Option
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
By running glxgears the problem is easily witnessed, also by maintaining
To save others hunting sources which have migrated between FreeBSD releasess:
FreeBSD/releases/4.11-RELEASE/ports
x11/XFree86-4-clients/pkg-plist:bin/glxgears
x11/xorg-clients/pkg-plist:bin/glxgears
Wayne Sierke wrote:
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 -
Toomas Aas wrote:
Wayne Sierke wrote:
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
Kris Kennaway wrote:
Toomas Aas wrote:
I have a 6.3-PRERELEASE system (last cvsupped Dec 12), which
always freezes *once* a few minutes after booting up.
This is usually when your system accesses swap because you ran out of
free RAM.
Hmm, I thought that 768 MB RAM (minus 16 for
Toomas Aas wrote:
Kris Kennaway wrote:
Toomas Aas wrote:
I have a 6.3-PRERELEASE system (last cvsupped Dec 12), which always
freezes *once* a few minutes after booting up.
This is usually when your system accesses swap because you ran out of
free RAM.
Hmm, I thought that 768 MB RAM
Kris Kennaway wrote:
Toomas Aas wrote:
Kris Kennaway wrote:
Toomas Aas wrote:
I have a 6.3-PRERELEASE system (last cvsupped Dec 12), which always
freezes *once* a few minutes after booting up.
This is usually when your system accesses swap because you ran out of
free RAM.
last pid:
Toomas Aas wrote:
Kris Kennaway wrote:
Toomas Aas wrote:
Kris Kennaway wrote:
Toomas Aas wrote:
I have a 6.3-PRERELEASE system (last cvsupped Dec 12), which always
freezes *once* a few minutes after booting up.
This is usually when your system accesses swap because you ran out
of
Toomas Aas wrote:
Kris Kennaway wrote:
OK, you may need to set up hwpmc or LOCK_PROFILING to figure out what
your system is doing at that moment.
I set up a kernel with hwpmc support, but am feeling a bit (to put it
mildly) lost, since I haven't really done anything with hwpmc ever
before.
24 matches
Mail list logo
