[arch-general] wchan info in ps
Hello list, is anyone actually getting WCHAN information from either ps or top? To try it just use "ps opid,wchan,cmd". I only get dashes, any idea why? Thanks, Dimitris
On Sat, Nov 14, 2009 at 7:12 PM, Dimitrios Apostolou <jimis@gmx.net> wrote:
Hello list,
is anyone actually getting WCHAN information from either ps or top? To try it just use "ps opid,wchan,cmd". I only get dashes, any idea why?
man ps wchan WCHAN name of the kernel function in which the process is sleeping, a "-" if the process is running, or a "*" if the process is multi-threaded and ps is not displaying threads. That said, I only get a dash for the ps itself, and sometimes also for the shell. PID WCHAN CMD 4040 n_tty_ -zsh 4620 rt_sig zsh 4626 poll_s irssi 12880 pause screen -r 12942 rt_sig /bin/zsh 14936 rt_sig /bin/zsh 14939 poll_s cmus 23759 poll_s vim lib/libalpm/dload.c 23770 rt_sig /bin/zsh 23842 - ps opid,wchan,cmd
On Sat, 14 Nov 2009, Xavier wrote:
On Sat, Nov 14, 2009 at 7:12 PM, Dimitrios Apostolou <jimis@gmx.net> wrote:
Hello list,
is anyone actually getting WCHAN information from either ps or top? To try it just use "ps opid,wchan,cmd". I only get dashes, any idea why?
man ps wchan WCHAN name of the kernel function in which the process is sleeping, a "-" if the process is running, or a "*" if the process is multi-threaded and ps is not displaying threads.
That said, I only get a dash for the ps itself, and sometimes also for the shell.
PID WCHAN CMD 4040 n_tty_ -zsh 4620 rt_sig zsh 4626 poll_s irssi 12880 pause screen -r 12942 rt_sig /bin/zsh 14936 rt_sig /bin/zsh 14939 poll_s cmus 23759 poll_s vim lib/libalpm/dload.c 23770 rt_sig /bin/zsh 23842 - ps opid,wchan,cmd
I get all dashes, so I must have broken something on my setup... :-( You are on 32-bit, right? Dimitris
On Sat, 14 Nov 2009, Xavier wrote:
On Sat, Nov 14, 2009 at 7:12 PM, Dimitrios Apostolou <jimis@gmx.net> wrote:
Hello list,
is anyone actually getting WCHAN information from either ps or top? To try it just use "ps opid,wchan,cmd". I only get dashes, any idea why?
man ps wchan WCHAN name of the kernel function in which the process is sleeping, a "-" if the process is running, or a "*" if the process is multi-threaded and ps is not displaying threads.
That said, I only get a dash for the ps itself, and sometimes also for the shell.
PID WCHAN CMD 4040 n_tty_ -zsh 4620 rt_sig zsh 4626 poll_s irssi 12880 pause screen -r 12942 rt_sig /bin/zsh 14936 rt_sig /bin/zsh 14939 poll_s cmus 23759 poll_s vim lib/libalpm/dload.c 23770 rt_sig /bin/zsh 23842 - ps opid,wchan,cmd
I still can't figure this one out. The output you get is the correct one (I get that on Redhat systems) however how did you manage to get it on arch??? I tried on two more PCs with archlinux, but I still get dashes! So I see the same bogus behavior on 3 different systems (all 32-bit), I guess it's not my fault. Ideas? Dimitris
On Sat, 14 Nov 2009, Dimitrios Apostolou wrote:
Hello list,
is anyone actually getting WCHAN information from either ps or top? To try it just use "ps opid,wchan,cmd". I only get dashes, any idea why?
I managed to resolve this issue. Arch builds its kernels (on 32-bit at least) without CONFIG_FRAME_POINTER and loses the ability to produce correct stacktraces, either with /proc/$PID/wchan or with SysRq-t or with gdb. On the other hand it has one more register free so minor optimisations can be performed. Why don't we set CONFIG_FRAME_POINTER=y? WCHAN output is very useful to be lost and frankly I don't think performance losses would be perceivable. Last but not least I haven't seen this disabled in any other distro.
Thanks, Dimitris
On Wed, Jan 6, 2010 at 7:04 PM, Dimitrios Apostolou <jimis@gmx.net> wrote:
On Sat, 14 Nov 2009, Dimitrios Apostolou wrote:
Hello list,
is anyone actually getting WCHAN information from either ps or top? To try it just use "ps opid,wchan,cmd". I only get dashes, any idea why?
I managed to resolve this issue. Arch builds its kernels (on 32-bit at least) without CONFIG_FRAME_POINTER and loses the ability to produce correct stacktraces, either with /proc/$PID/wchan or with SysRq-t or with gdb. On the other hand it has one more register free so minor optimisations can be performed.
Why don't we set CONFIG_FRAME_POINTER=y? WCHAN output is very useful to be lost and frankly I don't think performance losses would be perceivable. Last but not least I haven't seen this disabled in any other distro.
Sorry for not answering earlier, but I probably did not have any ideas when reading your previous answers. I am on 64-bit and I have the same result here using Arch kernel. The reason why it worked for me and still works is that I am always using a custom kernel, I use http://cgit.freedesktop.org/nouveau/linux-2.6/ to follow nouveau development. And I have CONFIG_FRAME_POINTER=y because this option is quite important indeed <<< If you say Y here the resulting kernel image will be slightly larger and slower, but it gives very useful debugging information in case of kernel bugs. (precise oopses/stacktraces/warnings) >>> I definitely want to get precise oopses/stacktraces/warnings so that I can report them if needed. Maybe the average arch user also wants to do that, I don't know. You can do some research to find out what the big distrib are using in their default kernel (fedora,suse,debian,ubuntu,...) and/or you can open a bug in Flyspray.
On Sun, 10 Jan 2010, Xavier wrote:
Maybe the average arch user also wants to do that, I don't know. You can do some research to find out what the big distrib are using in their default kernel (fedora,suse,debian,ubuntu,...) and/or you can open a bug in Flyspray.
Since I didn't get any replies here that's what I did: FS #17756 Dimitris
participants (2)
-
Dimitrios Apostolou
-
Xavier