Hide menu

Lab 0 - Pintos: Introduction and Installation on Linux:

This information might change without any notice..

The follwing instructions are for installing Pinots in Linux (mint).

Pintos is an instructional operating system that runs on x86 machines. You will run it in QEMU -- a computer system emulator, which runs as a user process under Linux. Pintos is written in C. The lab assignments require modification of the provided version of Pintos by adding functionality to parts of it, for instance, synchronization of threads and memory management.


Step 1: The first thing you must do is to create a repository:

       svnadmin create $HOME/svnlinuxrepository

Step 2: Import the linux Pintos files into it (have patience, this may take a few minutes):

       svn import /home/TDDB68/labs/linux/ file://$HOME/svnlinuxrepository -m "linux pintos "

Step 3: Now check out a working copy into a directory called pintos:

       svn checkout file://$HOME/svnlinuxrepository/pintos linuxpintos
       cd linuxpintos

Step 4: Run the following script to instruct svn to ignore some files


Step 5: Do not allow anyone else to read your code:

       chmod -R og-rwx $HOME/svnlinuxrepository/ $HOME/linuxpintos

Commit your code:
       cd linuxpintos/src/
       svn -m "initial commit message" commit

Step 6: go int utils

       cd utils
       ln -s $(which qemu-system-i386) qemu

Step 7:
       chmod +x pintos
       chmod +x pintos-mkdisk
       chmod +x backtrace
       chmod +x pintos-gdb

Step 8: Make the pintos commands available in your terminal using the follwoing command: (you might also want to add this to your ~/.bashrc file, you might need to create the file if it is missing.)

       export PATH="${HOME}/linuxpintos/src/utils/:${PATH}/"


To compile Pintos for the first time, change your current directory to the threads directory (cd pintos/src/threads) and issue the command:


Go down to the build directory and start Pintos to see that it runs:

        cd build
        pintos --qemu -- run alarm-multiple
You should get a new window with an output that ends with something similar to the following:

eriha@parlomba1:build$ pintos --qemu -- run alarm-multiple
Writing command line to /tmp/EAhN6wTYgK.dsk...
qemu -hda /tmp/EAhN6wTYgK.dsk -m 4 -net none -serial stdio
Kernel command line: run alarm-multiple
Pintos booting with 4,088 kB RAM...
371 pages available in kernel pool.
371 pages available in user pool.
Calibrating timer...  314,163,200 loops/s.
Boot complete.
Executing 'alarm-multiple':
(alarm-multiple) begin
(alarm-multiple) Creating 5 threads to sleep 7 times each.
(alarm-multiple) Thread 0 sleeps 10 ticks each time,
(alarm-multiple) thread 1 sleeps 20 ticks each time, and so on.
(alarm-multiple) If successful, product of iteration count and
(alarm-multiple) sleep duration will appear in nondescending order.
(alarm-multiple) thread 0: duration=10, iteration=1, product=10
(alarm-multiple) thread 0: duration=10, iteration=2, product=20
(alarm-multiple) thread 1: duration=20, iteration=1, product=20
(alarm-multiple) thread 2: duration=30, iteration=1, product=30
(alarm-multiple) thread 0: duration=10, iteration=3, product=30
(alarm-multiple) thread 0: duration=10, iteration=4, product=40
(alarm-multiple) thread 1: duration=20, iteration=2, product=40
(alarm-multiple) thread 3: duration=40, iteration=1, product=40
(alarm-multiple) thread 4: duration=50, iteration=1, product=50
(alarm-multiple) thread 0: duration=10, iteration=5, product=50
(alarm-multiple) thread 0: duration=10, iteration=6, product=60
(alarm-multiple) thread 1: duration=20, iteration=3, product=60
(alarm-multiple) thread 2: duration=30, iteration=2, product=60
(alarm-multiple) thread 0: duration=10, iteration=7, product=70
(alarm-multiple) thread 3: duration=40, iteration=2, product=80
(alarm-multiple) thread 1: duration=20, iteration=4, product=80
(alarm-multiple) thread 2: duration=30, iteration=3, product=90
(alarm-multiple) thread 4: duration=50, iteration=2, product=100
(alarm-multiple) thread 1: duration=20, iteration=5, product=100
(alarm-multiple) thread 1: duration=20, iteration=6, product=120
(alarm-multiple) thread 2: duration=30, iteration=4, product=120
(alarm-multiple) thread 3: duration=40, iteration=3, product=120
(alarm-multiple) thread 1: duration=20, iteration=7, product=140
(alarm-multiple) thread 2: duration=30, iteration=5, product=150
(alarm-multiple) thread 4: duration=50, iteration=3, product=150
(alarm-multiple) thread 3: duration=40, iteration=4, product=160
(alarm-multiple) thread 2: duration=30, iteration=6, product=180
(alarm-multiple) thread 4: duration=50, iteration=4, product=200
(alarm-multiple) thread 3: duration=40, iteration=5, product=200
(alarm-multiple) thread 2: duration=30, iteration=7, product=210
(alarm-multiple) thread 3: duration=40, iteration=6, product=240
(alarm-multiple) thread 4: duration=50, iteration=5, product=250
(alarm-multiple) thread 3: duration=40, iteration=7, product=280
(alarm-multiple) thread 4: duration=50, iteration=6, product=300
(alarm-multiple) thread 4: duration=50, iteration=7, product=350
(alarm-multiple) end
Execution of 'alarm-multiple' complete.

Debugging using bactrace

The backtrace tool is very convenient to find out where the pintos kernel panics. When a kernel panic happens pintos will print out the addresses call stack of the functions that were running whne the panic happend. However, from a humans perspecitve the adresses will not be of much help. The backtrace command can help translate addresses to human understandable form. For example if we run the following command (whitout having a disk file):

        pintos --qemu -- ls 
Pintos will panic and output similar to the following will show up:
Writing command line to /tmp/HQKKT9krUO.dsk...
qemu -hda /tmp/HQKKT9krUO.dsk -m 4 -net none -serial stdio
Kernel command line: ls
Pintos booting with 4,088 kB RAM...
371 pages available in kernel pool.
371 pages available in user pool.
Calibrating timer...  209,510,400 loops/s.
Boot complete.
Kernel PANIC at ../../threads/init.c:308 in run_actions(): unknown action `ls' (use -h for help)
Call stack: 0xc0106e2b.
The `backtrace' program can make call stacks useful.
Read "Backtraces" in the "Debugging Tools" chapter
of the Pintos documentation for more information.
If we run backtrace with the call stack address:
        backtrace 0xc0106e2b 
A hint where the crash might have happen will show.
        0xc0106e2b: debug_panic (.../../lib/kernel/debug.c:34)
Be aware that the line number might be a bit inaccurate.

Debugging wih GDB

Here is an example of how to debug pintos using gdb.
  1. Change to the pintos/threads/build directory.
  2. Start pintos pintos -v --qemu --gdb -- run alarm-single
    Something similar will show up:
    Writing command line to /tmp/efpJEn9yH8.dsk...
    qemu -hda /tmp/efpJEn9yH8.dsk -m 4 -net none -nographic -s -S

    pintos will now halt
  3. Open another terminal and run pintos-gdb kernel.o
  4. In the gdb command line runt target remote localhost:1234
  5. Type: c
  6. Go back to the first terminal and see that pintos now will continue executing!

Migrating Pintos labs from Solaris to Linux

This information is only for students from preivous years
IDA has now retired Solaris. Those of you who used Solaris for Pintos labs and still are not finished with the labs need to migrate your existing lab files to Linux. The simplest way is probably to download a fresh Pintos for Linux from the lab page and then copy over the source files you modified when using Solaris, of course removing the corresponding files that already exist in Linux-Pintos.

Page responsible: Christoph W Kessler
Last updated: 2016-01-27