Lines Matching refs:process

6   Linux: a port of the Linux kernel as a normal Intel Linux process.
191   3. You can debug the User Mode Linux like any normal process.
342   You can also get the kernel build process to install them as follows:
514   down and the process will exit.
553   because UML occupies the upper .5G of the 3G process address space
566   load itself in the top .5G of that smaller process address space,
1654   Slip is another, less general, mechanism for a process to communicate
2106   files just like any other process and make them available inside the
2472   Since the user-mode kernel runs as a normal Linux process, it is
2473   possible to debug it with gdb almost like any other process.  It is
2503   Not every bug is evident in the currently running process.  Sometimes,
2510   What you want is the stack of whatever process is sleeping when it
2511   shouldn't be.  You need to figure out which process that is, which is
2512   generally fairly easy.  Then you need to get its host process id,
2546   process execute, e.g. calling a function
2548   o  when you're done looking at that process, reattach to the current
2566   Here, specifying any pid which is not the process id of a UML thread
2574   ddd works on UML, but requires a special kludge.  The process goes
2606      as you do on any other process.
2613   the process.  This support is what is needed to debug kernel modules
2628   automates the process for you.
2672        Attaching to program: /home/jdike/linux/2.4/um/./linux, process 1
2820   and repeat the process above.  You'll also need to re-enable break-
3044   Let's guess that the last process in the process list is fsck:
3083   process is being ptraced by the signal thread, so it must be detached
3125        #1  0x10068ccd in usr1_pid (pid=1980) at process.c:30
3183        #1  0x10068ccd in usr1_pid (pid=1980) at process.c:30
3302   That's pretty bogus.  Page tables aren't supposed to be in process
3468   caught by the signal thread, which detaches the process:
3811   and repeat the build process with ARCH=um on all the steps.
3893   This is a syslogd bug.  There's a race between a parent process
4097        #1  0x10091411 in change_sig (signal=10, on=1) at process.c:218
4175   In this case, you'll need to get a backtrace from the process men-
4211   If gdb hangs when attaching to that process, go back to a shell and
4233   happens, we need a backtrace from the offending process.  Run the
4235   current process is not the idle thread, then send in the backtrace.
4250   If this is the case, then some other process is at fault, and went to
4252   process should not have gone to sleep and stayed asleep.  Then attach
4290   o  redid the config process