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 please
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
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,
triggerin
> 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 ^
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 /usr/tmp/v
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 k
> 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. Onl
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
> > da0s
11 matches
Mail list logo