Difference between PR and NI column values in the output of TOP command

For illustration, I am putting up a snippet of TOP output during one of my sessions --

top - 18:54:23 up 1 day, 23:33,  8 users,  load average: 1.23, 1.08, 1.02
Tasks: 295 total,   3 running, 289 sleeping,   0 stopped,   3 zombie
Cpu(s): 28.4%us,  1.9%sy,  0.0%ni, 67.8%id,  1.8%wa,  0.0%hi,  0.0%si,  0.0%st
Mem:   7941828k total,  7741560k used,   200268k free,    90992k buffers
Swap:  8388604k total,   186344k used,  8202260k free,  1479116k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+ COMMAND                                                                                        
   61 root      39  19     0    0    0 S  0.0  0.0   0:07.02 khugepaged                                                                                     
   60 root      25   5     0    0    0 S  0.0  0.0   0:00.00 ksmd                                                                                           
 4358 rtkit     21   1  164m  976  940 S  0.0  0.0   0:02.09 rtkit-daemon                                                                                   
    1 root      20   0 19352 1260 1032 S  0.0  0.0   0:05.40 init                                                                                           
    2 root      20   0     0    0    0 S  0.0  0.0   0:00.40 kthreadd                                                                                       
    4 root      20   0     0    0    0 S  0.0  0.0   0:04.24 ksoftirqd/0                                                                                    
   19 root      20   0     0    0    0 S  0.0  0.0   0:37.61 events/0                                                                                       
   23 root      20   0     0    0    0 S  0.0  0.0   0:00.00 cgroup                


I wanted to figure out the difference between the values under PR and NI columns, and I found the answer in the man page of C library function getpriority. The following snippet from the man page is the most relevant and explains the difference very well --
     
The  actual  priority range varies between kernel versions.  Linux before 1.3.36 had -infinity..15.  Since kernel 1.3.43 Linux has the range -20..19.  Within the kernel, nice values are actually represented using the corresponding range 40..1  (since  negative  numbers are  error  codes) and these are the values employed by the setpriority() and getpriority() system calls.  The glibc wrapper functions for these system calls handle the translations between the user-land and kernel representations of the nice  value  according  to  the formula unice = 20 - knice.

My Learnings on Linux: A fabulous diagram of the Linux Kernel I/O Stack, ...

My Learnings on Linux: A fabulous diagram of the Linux Kernel I/O Stack, ...: A fabulous diagram of the Linux Kernel I/O Stack, as copied directly from Wikipedia link http://en.wikipedia.org/wiki/Device_mapper ...

A fabulous diagram of the Linux Kernel I/O Stack, as copied directly from Wikipedia link http://en.wikipedia.org/wiki/Device_mapper

Enable Hibernate option on Fedora 16

• yum install gnome-tweak-tool
• yum install gnome-shell-extensions-alternative-status-menu
• Log Out and Log in back
• Launch the Gnome-tweak-tool and from Shell Extensions tab switch the alternative-status-menu extension to ON
  
  
  Courtesy of --
  http://ask.fedoraproject.org/question/478/edit-power-menu 

enable debug code on qemu

just run configure script with the --enable-debug option. The output should show the following --

tcg debug enabled yes
Mon debug enabled yes

Now, gdb will show the debugging symbols from qemu code

Significance of WCHAN in ps output

From the man ps ouput on linux --
       nwchan      WCHAN     address of the kernel function where the process  
                                             is sleeping (use wchan if you want the kernel
                                             function name). Running tasks will display a dash
                                             ('-') in this column.

The following text from the troubleshooting link is worth reading carefully --
http://www.tldp.org/HOWTO/SCSI-2.4-HOWTO/trouble.html

Text Follows --

When it looks like something has partially locked up the system, the ps command can be useful for finding out what may be causing the problem. The following options may be useful for identifying what part of the kernel may be causing the problem. This information could be forwarded to the maintainers.

ps -eo cmd,wchan ps -eo fname,tty,pid,stat,pcpu,wchan ps -eo pid,stat,pcpu,nwchan,wchan=WIDE-WCHAN-COLUMN -o args

The most interesting option for finding the location of the "hang" is "wchan". If this is a kernel address then ps will use /proc/ksyms to find the nearest symbolic location. The "nwchan" option outputs the numerical address of the "hang". If the system is not responding to keystrokes, then <Alt+ScrollLock> in text mode should output a stack trace while <Ctrl+ScrollLock> should output a list of all processes. If the log is still working, the output will be sent there as well as appearing on the console.
If the kernel has been built with the CONFIG_MAGIC_SYSRQ, then in text mode <Alt+SysRq+H> will list available commands. Of these <Alt+SysRq+S> is useful for doing an emergency sync while <Alt+SysRq+U> will remount file systems in read only mode. After that <Alt+SysRq+B> to reboot the machine might be your next move.

Function Calling Conventions on x86_64 -- Order of arguments and registers

I have been struggling with a memory corruption issue, and the need was to figure out the values of the arguments passed to a function. GDB would somehow not print the values of those arguments, and I set out to figure out through the registers. Through a trivial test program on a x86_64, I can see that the order of the arguments stored in registers is like this. If the called function is func1(int i, int j, int k, int l, int m, int n), the registers I found to be storing the values are like this --

%rdi --> i
%rsi --> j
%rdx --> k
%rcx --> l
%r8 --> m
%r9 --> n

My confusion was the order of the storage of the arguments, specifically, if %rdi would store the value of i, or the value of n.
My system configuration is this --
SUSE Linux Enterprise Server 10 (x86_64)
VERSION = 10
PATCHLEVEL = 3

AND

'uname -r' shows --
2.6.16.60-0.54.5-smp