On Sat, Feb 24, 2001 at 10:50:17AM +0200, Mark Murray wrote:
and now performance is very good, event with:
kern.random.sys.harvest_ethernet: 1
kern.random.sys.harvest_point_to_point: 0
kern.random.sys.harvest_interrupt: 1
You mean "even with"? If so, then I am very pleased indeed!
John Baldwin wrote:
On 22-Feb-01 Maxim Sobolev wrote:
John Baldwin wrote:
A recursive sched_lock? Erm, well, stick these options in your kernel
config:
options KTR
options KTR_EXTEND
options KTR_COMPILE=KTR_LOCK
options KTR_MASK=KTR_MASK
On Sun, Feb 25, 2001 at 10:29:42PM -0800, Kris Kennaway wrote:
This is on a UP system.
Had another one of these, under the same conditions. Both times I was
running more(1) on a stdin stream which was generated by a "find |
grep | more" operation, and I suspended the process with ^Z,
What argument are you passing to rpcinfo?
That info was from tirpc (rpcbind) and a modified nfsd(8) which
was originally ported from NetBSD and adapted to our nfsd(8):
http://home.teleport.ch/freebsd/newnfsd.c
It seems our way doing the registration was wrong (but only for
doing bindhost
On Sun, Feb 25, 2001 at 10:29:42PM -0800, Kris Kennaway wrote:
This is on a UP system.
Had another one of these, under the same conditions. Both times I was
running more(1) on a stdin stream which was generated by a "find |
grep | more" operation, and I suspended the process with ^Z,
It appears that lpd is again triggering a panic. Sources
are from 25 Feb 01 at 1039 PST. Kernel.debug, vmcore.0, kernel.0
available for the asking.
--
Steve
(kgdb) symbol-file kernel.debug
Reading symbols from kernel.debug...done.
(kgdb) exec-file /usr/tmp/kernel.0
(kgdb) core-file
On 26-Feb-01 Steve Kargl wrote:
It appears that lpd is again triggering a panic. Sources
are from 25 Feb 01 at 1039 PST. Kernel.debug, vmcore.0, kernel.0
available for the asking.
This is a different panic the dreaded 'ltr' panics everyone has been seeing,
but the enable_intr() in trap
jake2001/02/26 15:27:35 PST
Modified files:
sys/kern init_main.c kern_fork.c kern_mutex.c
Log:
Initialize native priority to PRI_MAX. It was usually 0 which made a
process's priority go through the roof when it released a (contested)
mutex. Only set
I finally realized I hadn't been running my 2xPPro box with SMP enabled for a
month or so. The top of tree, with the exception of Jake's last fix, hangs:
Mounting root from ufs:/dev/da0a
da0s1: type 0xa5, start 63, end = 8385929, size 8385867 : OK
WARNING: / was not properly dismounted
p/MsPb:i
On 26-Feb-01 Matthew Jacob wrote:
I finally realized I hadn't been running my 2xPPro box with SMP enabled for a
month or so. The top of tree, with the exception of Jake's last fix, hangs:
Mounting root from ufs:/dev/da0a
da0s1: type 0xa5, start 63, end = 8385929, size 8385867 : OK
On Mon, 26 Feb 2001, John Baldwin wrote:
On 26-Feb-01 Matthew Jacob wrote:
I finally realized I hadn't been running my 2xPPro box with SMP enabled for a
month or so. The top of tree, with the exception of Jake's last fix, hangs:
Mounting root from ufs:/dev/da0a
da0s1: type 0xa5,
11 matches
Mail list logo