Hi,
On Tue, 19 Sep 2000 [EMAIL PROTECTED] wrote:
...
> This looks like you've hit the limit for the FFS node memory type.
BINGO!
>FFS node262144 65536K 65536K 65536K 20244600 6 256
So the symptom is clear. But the cause?
With pre SMPng I had the default kmem sizes (which is 12MB
On Tue, 19 Sep 2000 [EMAIL PROTECTED] wrote:
...
> This looks like you've hit the limit for the FFS node memory type.
>
> vmstat -m will indicate if this is correct.
>
...
> Increasing the kmem_map size (by setting a loader variable
> (kern.vm.kmem.size) or defining VM_KMEM_SIZE and VM_KMEM_SIZE
> (kgdb) ps
> pidprocaddruid pri ppid pgrp flag stat comm wchan
>37 c7874a00 c96650000 32 636 004086 3 tar piperd c9663f20
>36 c7874bc0 c960a0000 32 636 004006 3 tar FFS node
>c02f4220
This looks like you've hit
On Sun, 17 Sep 2000, John Baldwin wrote:
...
> Hmm, could it be lockmgr() related?
How can I proof?
Bye!
Michael Reifenberger
^.*Plaut.*$, IT, R/3 Basis, GPS
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Greg Lehey wrote:
> On Monday, 18 September 2000 at 1:29:34 +0200, Michael Reifenberger wrote:
> > On Mon, 18 Sep 2000, Greg Lehey wrote:
> > ...
> >> Oops, that's what comes of typing hurriedly early in the morning.
> >>
> >> p ((struct proc *)gd_curproc)->p_comm
> >> p ((struct proc *)gd_cu
On Monday, 18 September 2000 at 1:29:34 +0200, Michael Reifenberger wrote:
> On Mon, 18 Sep 2000, Greg Lehey wrote:
> ...
>> Oops, that's what comes of typing hurriedly early in the morning.
>>
>> p ((struct proc *)gd_curproc)->p_comm
>> p ((struct proc *)gd_curproc)->p_pid
> Works better:
>
On Mon, 18 Sep 2000, Greg Lehey wrote:
...
> Oops, that's what comes of typing hurriedly early in the morning.
>
> p ((struct proc *)gd_curproc)->p_comm
> p ((struct proc *)gd_curproc)->p_pid
Works better:
(kgdb) p ((struct proc *)gd_curproc)->p_comm
$6 = "irq1: atkbd0\000\000\000\000"
(kgdb)
On Monday, 18 September 2000 at 1:23:30 +0200, Michael Reifenberger wrote:
> On Mon, 18 Sep 2000, Greg Lehey wrote:
> ...
>> You could also show the content of p->p_pid. If you don't have a p
>> pointer in the frame you're looking at, use ((struct
>> *proc)gd_curproc)->p_pid and ((struct *proc)g
On Mon, 18 Sep 2000, Greg Lehey wrote:
...
> You could also show the content of p->p_pid. If you don't have a p
> pointer in the frame you're looking at, use ((struct
> *proc)gd_curproc)->p_pid and ((struct *proc)gd_curproc)->p_comm. We
> need to know what is hanging.
Sorry doesn't seem to work:
On Sunday, 17 September 2000 at 16:29:41 +0200, Michael Reifenberger wrote:
> Hi,
> ...
>> The frames above are what the system went to as the result of your
>> debugger request. I'd also be interested to see the output of the
>> 'icnt' macro (if this is UP machine) or 'icnt1' (if it's SMP), and
Hi,
if the order of the ps macro is correct, here the backtraces of the procs 35,36,37:
Copyright (c) 1992-2000 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
The Regents of the University of California. All rights reserved.
FreeBSD 5.0-CURRE
Hi,
...
> The frames above are what the system went to as the result of your
> debugger request. I'd also be interested to see the output of the
> 'icnt' macro (if this is UP machine) or 'icnt1' (if it's SMP), and
> 'ps' (the macro I promised above).
(kgdb) icnt
1215544*566*0 0*
On Sunday, 17 September 2000 at 0:32:01 +0200, Michael Reifenberger wrote:
> Hi,
> -current hangs reliable (as described in another mail) for me.
> For short:
> "tar cf /dev/null /usr/ports&; tar cf - /usr/ports | tar tf -"
> locks the system solid after a few minutes.
> The first tar itsel
Hi,
-current hangs reliable (as described in another mail) for me.
For short:
"tar cf /dev/null /usr/ports&; tar cf - /usr/ports | tar tf -"
locks the system solid after a few minutes.
The first tar itself seems to need some time longer before hang.
This is verified to occure with 2 diff
14 matches
Mail list logo
