(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 the
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_MAX
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 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
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*
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
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
'ps'
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 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
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) p
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:
(kgdb) p
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_curproc)-p_pid
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
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 itself
14 matches
Mail list logo
