Re: "sleeping without queue" ?
On Tue, 22 Jul 2008, Mikhail Teterin wrote: Kris Kennaway ???(??): Mikhail Teterin wrote: Kris Kennaway ???(??): Well, I mean kernel backtrace. Can I obtain that remotely and without restarting/panicking the box? Thanks, kgdb on /dev/mem or procstat [EMAIL PROTECTED]:~ (107) kgdb /boot/kernel/kernel /dev/mem [...] (kgdb) bt #0 0x in ?? () Error accessing memory address 0x0: Bad address. Even less luck with procstat: [EMAIL PROTECTED]:~ (108) locate procstat [EMAIL PROTECTED]:~ (109) procstat procstat: ???. [EMAIL PROTECTED]:~ (110) man procstat No manual entry for procstat I'm sorry, but you'll need to be more specific. What should I type? Thanks, Assuming you're using 7.0 or an older 7-STABLE: procstat(1) appeared after 7.0 was released, but should be there if you slide forward on 7-STABLE. You can use "procstat -k pid" to see kernel stack traces for kernel threads working on behalf of the process. Depending on the level of detail you require, you can use -kk to also list function offsets inside the kernel, but the results are a bit harder to read. Robert N M Watson Computer Laboratory University of Cambridge ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: "sleeping without queue" ?
On Wed, Jul 23, 2008 at 04:15:47PM -0400, Mikhail Teterin wrote: > John Baldwin написав(ла): > >I think this case is still a lingering bug in the sleep queue code since > >the thread lock stuff went in. There have been several reports of it but > >I have been unable to figure out how the wakeup is being missed. > > > Is there anything I can still do for the investigation, or can I (try > to) kill this thingie and restart my build of OpenOffice? Yours, I think I would not gather any additional information from this case for now. You can reboot/restart the system. pgpwrQRInYXkj.pgp Description: PGP signature
Re: "sleeping without queue" ?
John Baldwin написав(ла): I think this case is still a lingering bug in the sleep queue code since the thread lock stuff went in. There have been several reports of it but I have been unable to figure out how the wakeup is being missed. Is there anything I can still do for the investigation, or can I (try to) kill this thingie and restart my build of OpenOffice? Yours, -mi P.S. NVidia on amd64? ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: "sleeping without queue" ?
On Wednesday 23 July 2008 08:03:48 am Kostik Belousov wrote:
> On Tue, Jul 22, 2008 at 03:59:57PM -0400, Mikhail Teterin wrote:
> > Kostik Belousov написав(ла):
> > >On Tue, Jul 22, 2008 at 03:26:29PM -0400, Mikhail Teterin wrote:
> > >>Kostik Belousov написав(ла):
> > >>>Did you switched to the process before doing backtrace (using the proc
> > >>>
> > >>>command)?
> > >>Ok, thanks. Did not know about this one. Here:
> > >>...
> > >>(kgdb) proc 79759
> > >>(kgdb) bt
> > >>#0 sched_switch (td=0xff01286dc000, newtd=0xff00010ce000,
> > >>flags=2) at /var/src/sys/kern/sched_4bsd.c:928
> > >>#1 0x in ?? ()
> > >>#2 0x802f1108 in mi_switch (flags=678281216, newtd=0x2) at
> > >>/var/src/sys/kern/kern_synch.c:442
> > >>#3 0x80318513 in sleepq_check_timeout () at
> > >>/var/src/sys/kern/subr_sleepqueue.c:519
> > >>#4 0x80318c85 in sleepq_timedwait (wchan=0x80688408) at
> > >>/var/src/sys/kern/subr_sleepqueue.c:597
> > >>#5 0x802f16a2 in _sleep (ident=0x80688408, lock=0x0,
> > >>priority=0, wmesg=0x804f3059 "vmo_de", timo=1) at
> > >>/var/src/sys/kern/kern_synch.c:224
> > >>#6 0x8043036b in vm_object_deallocate
> > >>(object=0xff0053024a90) at /var/src/sys/vm/vm_object.c:509
> > >From this frame, please, print the object (like p *object) and
> > >likewise, print the object that is at the head of the object->shadow_head
> > >list.
> > kgdb /usr/obj/var/src/sys/SILVER-SMP/kernel.debug /dev/mem
> > [GDB will not be able to debug user-mode threads:
> > /usr/lib/libthread_db.so: Undefined symbol "ps_pglobal_lookup"]
> > GNU gdb 6.1.1 [FreeBSD]
> > Copyright 2004 Free Software Foundation, Inc.
> > GDB is free software, covered by the GNU General Public License, and you
are
> > welcome to change it and/or distribute copies of it under certain
> > conditions.
> > Type "show copying" to see the conditions.
> > There is absolutely no warranty for GDB. Type "show warranty" for
details.
> > This GDB was configured as "amd64-marcel-freebsd".
> > There is no member named pathname.
> > Reading symbols from /opt/modules/fuse.ko...done.
> > Loaded symbols for /opt/modules/fuse.ko
> > Reading symbols from /opt/modules/rtc.ko...done.
> > Loaded symbols for /opt/modules/rtc.ko
> > Reading symbols from /boot/kernel/snd_ich.ko...Reading symbols from
> > /boot/kernel/snd_ich.ko.symbols...done.
> > done.
> > Loaded symbols for /boot/kernel/snd_ich.ko
> > Reading symbols from /boot/kernel/msdosfs.ko...Reading symbols from
> > /boot/kernel/msdosfs.ko.symbols...done.
> > done.
> > Loaded symbols for /boot/kernel/msdosfs.ko
> > #0 0x in ?? ()
> > (kgdb) frame 6
> > Error accessing memory address 0x0: Bad address.
> > (kgdb) pid 79759
> > Undefined command: "pid". Try "help".
> > (kgdb) proc 79759
> > (kgdb) frame 6
> > #6 0x8043036b in vm_object_deallocate
> > (object=0xff0053024a90) at /var/src/sys/vm/vm_object.c:509
> > 509 pause("vmo_de", 1);
> > (kgdb) p *object
> > $1 = {mtx = {lock_object = {lo_name = 0x804f21c4 "vm object",
> > lo_type = 0x804f3018 "standard object", lo_flags = 21168128,
> > lo_witness_data = {
> >lod_list = {stqe_next = 0x0}, lod_witness = 0x0}}, mtx_lock = 4,
> > mtx_recurse = 0}, object_list = {tqe_next = 0xff0005018a90,
> >tqe_prev = 0xff00539a6850}, shadow_head = {lh_first =
> > 0xff005d3afa90}, shadow_list = {le_next = 0x0, le_prev =
> > 0xff005d2cd048}, memq = {
> >tqh_first = 0xff007eb9fa58, tqh_last = 0xff007f864820}, root
> > = 0xff007ee14d38, size = 427, generation = 66, ref_count = 2,
> > shadow_count = 1,
> > type = 0 '\0', flags = 256, pg_color = 0, paging_in_progress = 0,
> > resident_page_count = 44, backing_object = 0x0, backing_object_offset =
> > 0, pager_object_list = {
> >tqe_next = 0x0, tqe_prev = 0x0}, cache = 0x0, handle = 0x0, un_pager
> > = {vnp = {vnp_size = 576646}, devp = {devp_pglist = {tqh_first = 0x8cc86,
> >tqh_last = 0x0}}, swp = {swp_bcount = 576646}}}
> > (kgdb) p (object->shadow_head)
> > $2 = {lh_first = 0xff005d3afa90}
> > (kgdb) p *object->shadow_head.lh_first
> > $3 = {mtx = {lock_object = {lo_name = 0x804f21c4 "vm object",
> > lo_type = 0x804f3018 "standard object", lo_flags = 21168128,
> > lo_witness_data = {
> >lod_list = {stqe_next = 0x0}, lod_witness = 0x0}}, mtx_lock = 4,
> > mtx_recurse = 0}, object_list = {tqe_next = 0xff0066c32340,
> >tqe_prev = 0xff012f673ac0}, shadow_head = {lh_first = 0x0},
> > shadow_list = {le_next = 0x0, le_prev = 0xff0053024ad0}, memq = {
> >tqh_first = 0xff007779f9a0, tqh_last = 0xff0077c04140}, root
> > = 0xff0077c04130, size = 387, generation = 3, ref_count = 1,
> > shadow_count = 0,
> > type = 0 '\0', flags = 8452, pg_color = 0, paging_in_progress = 0,
> > resident_page_count = 2, backing_object = 0xff00
Re: "sleeping without queue" ?
On Tue, Jul 22, 2008 at 03:59:57PM -0400, Mikhail Teterin wrote:
> Kostik Belousov написав(ла):
> >On Tue, Jul 22, 2008 at 03:26:29PM -0400, Mikhail Teterin wrote:
> >>Kostik Belousov написав(ла):
> >>>Did you switched to the process before doing backtrace (using the proc
> >>>
> >>>command)?
> >>Ok, thanks. Did not know about this one. Here:
> >>...
> >>(kgdb) proc 79759
> >>(kgdb) bt
> >>#0 sched_switch (td=0xff01286dc000, newtd=0xff00010ce000,
> >>flags=2) at /var/src/sys/kern/sched_4bsd.c:928
> >>#1 0x in ?? ()
> >>#2 0x802f1108 in mi_switch (flags=678281216, newtd=0x2) at
> >>/var/src/sys/kern/kern_synch.c:442
> >>#3 0x80318513 in sleepq_check_timeout () at
> >>/var/src/sys/kern/subr_sleepqueue.c:519
> >>#4 0x80318c85 in sleepq_timedwait (wchan=0x80688408) at
> >>/var/src/sys/kern/subr_sleepqueue.c:597
> >>#5 0x802f16a2 in _sleep (ident=0x80688408, lock=0x0,
> >>priority=0, wmesg=0x804f3059 "vmo_de", timo=1) at
> >>/var/src/sys/kern/kern_synch.c:224
> >>#6 0x8043036b in vm_object_deallocate
> >>(object=0xff0053024a90) at /var/src/sys/vm/vm_object.c:509
> >From this frame, please, print the object (like p *object) and
> >likewise, print the object that is at the head of the object->shadow_head
> >list.
> kgdb /usr/obj/var/src/sys/SILVER-SMP/kernel.debug /dev/mem
> [GDB will not be able to debug user-mode threads:
> /usr/lib/libthread_db.so: Undefined symbol "ps_pglobal_lookup"]
> GNU gdb 6.1.1 [FreeBSD]
> Copyright 2004 Free Software Foundation, Inc.
> GDB is free software, covered by the GNU General Public License, and you are
> welcome to change it and/or distribute copies of it under certain
> conditions.
> Type "show copying" to see the conditions.
> There is absolutely no warranty for GDB. Type "show warranty" for details.
> This GDB was configured as "amd64-marcel-freebsd".
> There is no member named pathname.
> Reading symbols from /opt/modules/fuse.ko...done.
> Loaded symbols for /opt/modules/fuse.ko
> Reading symbols from /opt/modules/rtc.ko...done.
> Loaded symbols for /opt/modules/rtc.ko
> Reading symbols from /boot/kernel/snd_ich.ko...Reading symbols from
> /boot/kernel/snd_ich.ko.symbols...done.
> done.
> Loaded symbols for /boot/kernel/snd_ich.ko
> Reading symbols from /boot/kernel/msdosfs.ko...Reading symbols from
> /boot/kernel/msdosfs.ko.symbols...done.
> done.
> Loaded symbols for /boot/kernel/msdosfs.ko
> #0 0x in ?? ()
> (kgdb) frame 6
> Error accessing memory address 0x0: Bad address.
> (kgdb) pid 79759
> Undefined command: "pid". Try "help".
> (kgdb) proc 79759
> (kgdb) frame 6
> #6 0x8043036b in vm_object_deallocate
> (object=0xff0053024a90) at /var/src/sys/vm/vm_object.c:509
> 509 pause("vmo_de", 1);
> (kgdb) p *object
> $1 = {mtx = {lock_object = {lo_name = 0x804f21c4 "vm object",
> lo_type = 0x804f3018 "standard object", lo_flags = 21168128,
> lo_witness_data = {
>lod_list = {stqe_next = 0x0}, lod_witness = 0x0}}, mtx_lock = 4,
> mtx_recurse = 0}, object_list = {tqe_next = 0xff0005018a90,
>tqe_prev = 0xff00539a6850}, shadow_head = {lh_first =
> 0xff005d3afa90}, shadow_list = {le_next = 0x0, le_prev =
> 0xff005d2cd048}, memq = {
>tqh_first = 0xff007eb9fa58, tqh_last = 0xff007f864820}, root
> = 0xff007ee14d38, size = 427, generation = 66, ref_count = 2,
> shadow_count = 1,
> type = 0 '\0', flags = 256, pg_color = 0, paging_in_progress = 0,
> resident_page_count = 44, backing_object = 0x0, backing_object_offset =
> 0, pager_object_list = {
>tqe_next = 0x0, tqe_prev = 0x0}, cache = 0x0, handle = 0x0, un_pager
> = {vnp = {vnp_size = 576646}, devp = {devp_pglist = {tqh_first = 0x8cc86,
>tqh_last = 0x0}}, swp = {swp_bcount = 576646}}}
> (kgdb) p (object->shadow_head)
> $2 = {lh_first = 0xff005d3afa90}
> (kgdb) p *object->shadow_head.lh_first
> $3 = {mtx = {lock_object = {lo_name = 0x804f21c4 "vm object",
> lo_type = 0x804f3018 "standard object", lo_flags = 21168128,
> lo_witness_data = {
>lod_list = {stqe_next = 0x0}, lod_witness = 0x0}}, mtx_lock = 4,
> mtx_recurse = 0}, object_list = {tqe_next = 0xff0066c32340,
>tqe_prev = 0xff012f673ac0}, shadow_head = {lh_first = 0x0},
> shadow_list = {le_next = 0x0, le_prev = 0xff0053024ad0}, memq = {
>tqh_first = 0xff007779f9a0, tqh_last = 0xff0077c04140}, root
> = 0xff0077c04130, size = 387, generation = 3, ref_count = 1,
> shadow_count = 0,
> type = 0 '\0', flags = 8452, pg_color = 0, paging_in_progress = 0,
> resident_page_count = 2, backing_object = 0xff0053024a90,
> backing_object_offset = 163840,
> pager_object_list = {tqe_next = 0x0, tqe_prev = 0x0}, cache = 0x0,
> handle = 0x0, un_pager = {vnp = {vnp_size = 365278}, devp = {devp_pglist = {
>tqh_first = 0x592de, tqh_last = 0x0}}, swp = {swp
Re: "sleeping without queue" ?
Kostik Belousov написав(ла):
On Tue, Jul 22, 2008 at 03:26:29PM -0400, Mikhail Teterin wrote:
Kostik Belousov написав(ла):
Did you switched to the process before doing backtrace (using the proc
command)?
Ok, thanks. Did not know about this one. Here:
...
(kgdb) proc 79759
(kgdb) bt
#0 sched_switch (td=0xff01286dc000, newtd=0xff00010ce000,
flags=2) at /var/src/sys/kern/sched_4bsd.c:928
#1 0x in ?? ()
#2 0x802f1108 in mi_switch (flags=678281216, newtd=0x2) at
/var/src/sys/kern/kern_synch.c:442
#3 0x80318513 in sleepq_check_timeout () at
/var/src/sys/kern/subr_sleepqueue.c:519
#4 0x80318c85 in sleepq_timedwait (wchan=0x80688408) at
/var/src/sys/kern/subr_sleepqueue.c:597
#5 0x802f16a2 in _sleep (ident=0x80688408, lock=0x0,
priority=0, wmesg=0x804f3059 "vmo_de", timo=1) at
/var/src/sys/kern/kern_synch.c:224
#6 0x8043036b in vm_object_deallocate
(object=0xff0053024a90) at /var/src/sys/vm/vm_object.c:509
From this frame, please, print the object (like p *object) and
likewise, print the object that is at the head of the object->shadow_head
list.
kgdb /usr/obj/var/src/sys/SILVER-SMP/kernel.debug /dev/mem
[GDB will not be able to debug user-mode threads:
/usr/lib/libthread_db.so: Undefined symbol "ps_pglobal_lookup"]
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "amd64-marcel-freebsd".
There is no member named pathname.
Reading symbols from /opt/modules/fuse.ko...done.
Loaded symbols for /opt/modules/fuse.ko
Reading symbols from /opt/modules/rtc.ko...done.
Loaded symbols for /opt/modules/rtc.ko
Reading symbols from /boot/kernel/snd_ich.ko...Reading symbols from
/boot/kernel/snd_ich.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/snd_ich.ko
Reading symbols from /boot/kernel/msdosfs.ko...Reading symbols from
/boot/kernel/msdosfs.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/msdosfs.ko
#0 0x in ?? ()
(kgdb) frame 6
Error accessing memory address 0x0: Bad address.
(kgdb) pid 79759
Undefined command: "pid". Try "help".
(kgdb) proc 79759
(kgdb) frame 6
#6 0x8043036b in vm_object_deallocate
(object=0xff0053024a90) at /var/src/sys/vm/vm_object.c:509
509 pause("vmo_de", 1);
(kgdb) p *object
$1 = {mtx = {lock_object = {lo_name = 0x804f21c4 "vm object",
lo_type = 0x804f3018 "standard object", lo_flags = 21168128,
lo_witness_data = {
lod_list = {stqe_next = 0x0}, lod_witness = 0x0}}, mtx_lock = 4,
mtx_recurse = 0}, object_list = {tqe_next = 0xff0005018a90,
tqe_prev = 0xff00539a6850}, shadow_head = {lh_first =
0xff005d3afa90}, shadow_list = {le_next = 0x0, le_prev =
0xff005d2cd048}, memq = {
tqh_first = 0xff007eb9fa58, tqh_last = 0xff007f864820}, root
= 0xff007ee14d38, size = 427, generation = 66, ref_count = 2,
shadow_count = 1,
type = 0 '\0', flags = 256, pg_color = 0, paging_in_progress = 0,
resident_page_count = 44, backing_object = 0x0, backing_object_offset =
0, pager_object_list = {
tqe_next = 0x0, tqe_prev = 0x0}, cache = 0x0, handle = 0x0, un_pager
= {vnp = {vnp_size = 576646}, devp = {devp_pglist = {tqh_first = 0x8cc86,
tqh_last = 0x0}}, swp = {swp_bcount = 576646}}}
(kgdb) p (object->shadow_head)
$2 = {lh_first = 0xff005d3afa90}
(kgdb) p *object->shadow_head.lh_first
$3 = {mtx = {lock_object = {lo_name = 0x804f21c4 "vm object",
lo_type = 0x804f3018 "standard object", lo_flags = 21168128,
lo_witness_data = {
lod_list = {stqe_next = 0x0}, lod_witness = 0x0}}, mtx_lock = 4,
mtx_recurse = 0}, object_list = {tqe_next = 0xff0066c32340,
tqe_prev = 0xff012f673ac0}, shadow_head = {lh_first = 0x0},
shadow_list = {le_next = 0x0, le_prev = 0xff0053024ad0}, memq = {
tqh_first = 0xff007779f9a0, tqh_last = 0xff0077c04140}, root
= 0xff0077c04130, size = 387, generation = 3, ref_count = 1,
shadow_count = 0,
type = 0 '\0', flags = 8452, pg_color = 0, paging_in_progress = 0,
resident_page_count = 2, backing_object = 0xff0053024a90,
backing_object_offset = 163840,
pager_object_list = {tqe_next = 0x0, tqe_prev = 0x0}, cache = 0x0,
handle = 0x0, un_pager = {vnp = {vnp_size = 365278}, devp = {devp_pglist = {
tqh_first = 0x592de, tqh_last = 0x0}}, swp = {swp_bcount = 365278}}}
Another question is what scheduler do you use ?
options SCHED_4BSD # 4BSD scheduler
options PREEMPTION # Enable kernel thread preemption
Also, show the output of ps axl .
UID PID PPID CPU PRI NI VSZ RSS MWCHAN STAT TT
Re: "sleeping without queue" ?
On Tue, Jul 22, 2008 at 01:09:28PM -0400, Mikhail Teterin wrote: > Kris Kennaway написав(ла): > >Mikhail Teterin wrote: > >>Kris Kennaway написав(ла): > >>>Well, I mean kernel backtrace. > >>Can I obtain that remotely and without restarting/panicking the box? > >>Thanks, > >kgdb on /dev/mem or procstat >[EMAIL PROTECTED]:~ (107) kgdb /boot/kernel/kernel /dev/mem >[...] >(kgdb) bt >#0 0x in ?? () >Error accessing memory address 0x0: Bad address. > > Even less luck with procstat: > >[EMAIL PROTECTED]:~ (108) locate procstat >[EMAIL PROTECTED]:~ (109) procstat >procstat: Нев?дома команда. >[EMAIL PROTECTED]:~ (110) man procstat >No manual entry for procstat > > I'm sorry, but you'll need to be more specific. What should I type? Thanks, Did you switched to the process before doing backtrace (using the proc command) ? What is the exact version of the system ? Note that procstat appeared in the late RELENG_7. Also, show the output of ps axl . pgpHpbt1prlWo.pgp Description: PGP signature
Re: "sleeping without queue" ?
On Tue, Jul 22, 2008 at 03:26:29PM -0400, Mikhail Teterin wrote: > Kostik Belousov написав(ла): > >Did you switched to the process before doing backtrace (using the proc > > > >command)? > Ok, thanks. Did not know about this one. Here: > ... > (kgdb) proc 79759 > (kgdb) bt > #0 sched_switch (td=0xff01286dc000, newtd=0xff00010ce000, > flags=2) at /var/src/sys/kern/sched_4bsd.c:928 > #1 0x in ?? () > #2 0x802f1108 in mi_switch (flags=678281216, newtd=0x2) at > /var/src/sys/kern/kern_synch.c:442 > #3 0x80318513 in sleepq_check_timeout () at > /var/src/sys/kern/subr_sleepqueue.c:519 > #4 0x80318c85 in sleepq_timedwait (wchan=0x80688408) at > /var/src/sys/kern/subr_sleepqueue.c:597 > #5 0x802f16a2 in _sleep (ident=0x80688408, lock=0x0, > priority=0, wmesg=0x804f3059 "vmo_de", timo=1) at > /var/src/sys/kern/kern_synch.c:224 > #6 0x8043036b in vm_object_deallocate > (object=0xff0053024a90) at /var/src/sys/vm/vm_object.c:509 From this frame, please, print the object (like p *object) and likewise, print the object that is at the head of the object->shadow_head list. Another question is what scheduler do you use ? > #7 0x8042920e in vm_map_delete (map=0xff0015ba4b60, > start=18446742979242478224, end=140737488355328) at > /var/src/sys/vm/vm_map.c:2315 > #8 0x804293df in vm_map_remove (map=0xff0015ba4b60, > start=0, end=140737488355328) at /var/src/sys/vm/vm_map.c:2423 > #9 0x8042b813 in vmspace_exit (td=0xff01286dc000) at > /var/src/sys/vm/vm_map.c:324 > #10 0x802c8cff in exit1 (td=0xff01286dc000, rv=0) at > /var/src/sys/kern/kern_exit.c:294 > #11 0x802ca08e in sys_exit (td=Variable "td" is not available. > ) at /var/src/sys/kern/kern_exit.c:98 > #12 0x8045a700 in syscall (frame=0xb0d89c70) at > /var/src/sys/amd64/amd64/trap.c:852 > #13 0x8043f38b in Xfast_syscall () at > /var/src/sys/amd64/amd64/exception.S:290 > #14 0x00080095f34c in ?? () > Previous frame inner to this frame (corrupt stack?) > > >What is the exact version of the system ? Note that procstat > >appeared in the late RELENG_7. > FreeBSD 7.0-STABLE #0: Sat Mar 8 16:02:37 EST 2008 > > > >Also, show the output of ps axl . > UID PID PPID CPU PRI NI VSZ RSS MWCHAN STAT TT TIME COMMAND >0 79759 79758 0 96 0 016 - DE+ p60:00,00 > /bin/tcsh -fc > /meow/ports/editors/openoffice.org-3/work/BEB300_m3/solver/300/unxfbsdx.pro/bin/ma It makes sense to show the whole ps axl output. > > Yours, > >-mi pgpAvegd51ob6.pgp Description: PGP signature
Re: "sleeping without queue" ?
Kostik Belousov написав(ла): Did you switched to the process before doing backtrace (using the proc command)? Ok, thanks. Did not know about this one. Here: ... (kgdb) proc 79759 (kgdb) bt #0 sched_switch (td=0xff01286dc000, newtd=0xff00010ce000, flags=2) at /var/src/sys/kern/sched_4bsd.c:928 #1 0x in ?? () #2 0x802f1108 in mi_switch (flags=678281216, newtd=0x2) at /var/src/sys/kern/kern_synch.c:442 #3 0x80318513 in sleepq_check_timeout () at /var/src/sys/kern/subr_sleepqueue.c:519 #4 0x80318c85 in sleepq_timedwait (wchan=0x80688408) at /var/src/sys/kern/subr_sleepqueue.c:597 #5 0x802f16a2 in _sleep (ident=0x80688408, lock=0x0, priority=0, wmesg=0x804f3059 "vmo_de", timo=1) at /var/src/sys/kern/kern_synch.c:224 #6 0x8043036b in vm_object_deallocate (object=0xff0053024a90) at /var/src/sys/vm/vm_object.c:509 #7 0x8042920e in vm_map_delete (map=0xff0015ba4b60, start=18446742979242478224, end=140737488355328) at /var/src/sys/vm/vm_map.c:2315 #8 0x804293df in vm_map_remove (map=0xff0015ba4b60, start=0, end=140737488355328) at /var/src/sys/vm/vm_map.c:2423 #9 0x8042b813 in vmspace_exit (td=0xff01286dc000) at /var/src/sys/vm/vm_map.c:324 #10 0x802c8cff in exit1 (td=0xff01286dc000, rv=0) at /var/src/sys/kern/kern_exit.c:294 #11 0x802ca08e in sys_exit (td=Variable "td" is not available. ) at /var/src/sys/kern/kern_exit.c:98 #12 0x8045a700 in syscall (frame=0xb0d89c70) at /var/src/sys/amd64/amd64/trap.c:852 #13 0x8043f38b in Xfast_syscall () at /var/src/sys/amd64/amd64/exception.S:290 #14 0x00080095f34c in ?? () Previous frame inner to this frame (corrupt stack?) What is the exact version of the system ? Note that procstat appeared in the late RELENG_7. FreeBSD 7.0-STABLE #0: Sat Mar 8 16:02:37 EST 2008 Also, show the output of ps axl . UID PID PPID CPU PRI NI VSZ RSS MWCHAN STAT TT TIME COMMAND 0 79759 79758 0 96 0 016 - DE+ p60:00,00 /bin/tcsh -fc /meow/ports/editors/openoffice.org-3/work/BEB300_m3/solver/300/unxfbsdx.pro/bin/ma Yours, -mi ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: "sleeping without queue" ?
Kris Kennaway написав(ла): Mikhail Teterin wrote: Kris Kennaway написав(ла): Well, I mean kernel backtrace. Can I obtain that remotely and without restarting/panicking the box? Thanks, kgdb on /dev/mem or procstat [EMAIL PROTECTED]:~ (107) kgdb /boot/kernel/kernel /dev/mem [...] (kgdb) bt #0 0x in ?? () Error accessing memory address 0x0: Bad address. Even less luck with procstat: [EMAIL PROTECTED]:~ (108) locate procstat [EMAIL PROTECTED]:~ (109) procstat procstat: Невідома команда. [EMAIL PROTECTED]:~ (110) man procstat No manual entry for procstat I'm sorry, but you'll need to be more specific. What should I type? Thanks, -mi ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: "sleeping without queue" ?
Mikhail Teterin wrote: Kris Kennaway написав(ла): Well, I mean kernel backtrace. Can I obtain that remotely and without restarting/panicking the box? Thanks, -mi kgdb on /dev/mem or procstat Kris ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: "sleeping without queue" ?
Kris Kennaway написав(ла): Well, I mean kernel backtrace. Can I obtain that remotely and without restarting/panicking the box? Thanks, -mi ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: "sleeping without queue" ?
Jeremy Chadwick wrote: On Tue, Jul 22, 2008 at 12:13:25PM -0400, Mikhail Teterin wrote: Kris Kennaway ???(??): Mikhail Teterin wrote: Hello! My attempt to build openoffice.org-3 seems to be hanging. Pressing Ctrl-T produces: load: 0.11 cmd: tcsh 79759 [sleeping without queue] 0.00u 0.00s 0% 0k (tcsh is used by OOo's build-script). What is this "sleeping without queue" state, and why is process in it for so long? This is an 4-CPU amd64 system with 4Gb of RAM. Only 16% of the swap is currently in use and the box seems to be perfectly fine otherwise. Uptime is 55 days, two different X-sessions are functional... The kernel is FreeBSD 7.0-STABLE #0: Sat Mar 8 16:02:37. Thanks! What is the process backtrace? Hard to say... The process ID 79759. According to ps(1), that PID exists: 79759 p6 DE+0:00,00 /bin/tcsh -fc /meow/ports/editors/openoffice.org-3/work/BEB300_m3/solver/300/unxfbsdx.pro/bin/makedepend @/tmp/mk2WUYYi > ../../../unxfbsdx.pro/misc/s_addincol.dpcc According to gdb, it does not: gdb 79759 GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "amd64-marcel-freebsd"...79759: No such file or directory. Syntax appears wrong; "gdb [program] 79759" would be what you want. Well, I mean kernel backtrace. Kris ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: "sleeping without queue" ?
Jeremy Chadwick написав(ла): On Tue, Jul 22, 2008 at 12:13:25PM -0400, Mikhail Teterin wrote: Kris Kennaway написав(ла): Mikhail Teterin wrote: Hello! My attempt to build openoffice.org-3 seems to be hanging. Pressing Ctrl-T produces: load: 0.11 cmd: tcsh 79759 [sleeping without queue] 0.00u 0.00s 0% 0k (tcsh is used by OOo's build-script). What is this "sleeping without queue" state, and why is process in it for so long? This is an 4-CPU amd64 system with 4Gb of RAM. Only 16% of the swap is currently in use and the box seems to be perfectly fine otherwise. Uptime is 55 days, two different X-sessions are functional... The kernel is FreeBSD 7.0-STABLE #0: Sat Mar 8 16:02:37. What is the process backtrace? Hard to say... The process ID 79759. According to ps(1), that PID exists: 79759 p6 DE+0:00,00 /bin/tcsh -fc /meow/ports/editors/openoffice.org-3/work/BEB300_m3/solver/300/unxfbsdx.pro/bin/makedepend @/tmp/mk2WUYYi > ../../../unxfbsdx.pro/misc/s_addincol.dpcc According to gdb, it does not: [...] Syntax appears wrong; "gdb [program] 79759" would be what you want. Yes, indeed. The result is similar, though: % gdb /bin/tcsh 79759 [...] Attaching to program: /bin/tcsh, process 79759 ptrace: No such process. /meow/ports/79759: No such file or directory. Thanks, -mi ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: "sleeping without queue" ?
On Tue, Jul 22, 2008 at 12:13:25PM -0400, Mikhail Teterin wrote: > Kris Kennaway ???(??): >> Mikhail Teterin wrote: >>> Hello! >>> >>> My attempt to build openoffice.org-3 seems to be hanging. Pressing >>> Ctrl-T produces: >>> >>>load: 0.11 cmd: tcsh 79759 [sleeping without queue] 0.00u 0.00s >>> 0% 0k >>> >>> (tcsh is used by OOo's build-script). What is this "sleeping without >>> queue" state, and why is process in it for so long? >>> >>> This is an 4-CPU amd64 system with 4Gb of RAM. Only 16% of the swap >>> is currently in use and the box seems to be perfectly fine otherwise. >>> Uptime is 55 days, two different X-sessions are functional... The >>> kernel is FreeBSD 7.0-STABLE #0: Sat Mar 8 16:02:37. >>> >>> Thanks! >> >> What is the process backtrace? > Hard to say... The process ID 79759. According to ps(1), that PID exists: > 79759 p6 DE+0:00,00 /bin/tcsh -fc > /meow/ports/editors/openoffice.org-3/work/BEB300_m3/solver/300/unxfbsdx.pro/bin/makedepend > > @/tmp/mk2WUYYi > ../../../unxfbsdx.pro/misc/s_addincol.dpcc > According to gdb, it does not: > gdb 79759 > GNU gdb 6.1.1 [FreeBSD] > Copyright 2004 Free Software Foundation, Inc. > GDB is free software, covered by the GNU General Public License, and you are > welcome to change it and/or distribute copies of it under certain > conditions. > Type "show copying" to see the conditions. > There is absolutely no warranty for GDB. Type "show warranty" for details. > This GDB was configured as "amd64-marcel-freebsd"...79759: No such file > or directory. Syntax appears wrong; "gdb [program] 79759" would be what you want. -- | Jeremy Chadwickjdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: "sleeping without queue" ?
Kris Kennaway написав(ла): Mikhail Teterin wrote: Hello! My attempt to build openoffice.org-3 seems to be hanging. Pressing Ctrl-T produces: load: 0.11 cmd: tcsh 79759 [sleeping without queue] 0.00u 0.00s 0% 0k (tcsh is used by OOo's build-script). What is this "sleeping without queue" state, and why is process in it for so long? This is an 4-CPU amd64 system with 4Gb of RAM. Only 16% of the swap is currently in use and the box seems to be perfectly fine otherwise. Uptime is 55 days, two different X-sessions are functional... The kernel is FreeBSD 7.0-STABLE #0: Sat Mar 8 16:02:37. Thanks! What is the process backtrace? Hard to say... The process ID 79759. According to ps(1), that PID exists: 79759 p6 DE+0:00,00 /bin/tcsh -fc /meow/ports/editors/openoffice.org-3/work/BEB300_m3/solver/300/unxfbsdx.pro/bin/makedepend @/tmp/mk2WUYYi > ../../../unxfbsdx.pro/misc/s_addincol.dpcc According to gdb, it does not: gdb 79759 GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "amd64-marcel-freebsd"...79759: No such file or directory. Interestingly, the file mentioned in the command-line -- the s_addincol.dpcc -- does not exist anywhere under /meow/ports/editors/openoffice.org-3/work -mi ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: "sleeping without queue" ?
Mikhail Teterin wrote: Hello! My attempt to build openoffice.org-3 seems to be hanging. Pressing Ctrl-T produces: load: 0.11 cmd: tcsh 79759 [sleeping without queue] 0.00u 0.00s 0% 0k (tcsh is used by OOo's build-script). What is this "sleeping without queue" state, and why is process in it for so long? This is an 4-CPU amd64 system with 4Gb of RAM. Only 16% of the swap is currently in use and the box seems to be perfectly fine otherwise. Uptime is 55 days, two different X-sessions are functional... The kernel is FreeBSD 7.0-STABLE #0: Sat Mar 8 16:02:37. Thanks! What is the process backtrace? Kris ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
