+@item
+@b{@samp{pintos put} always panics.}
+
+Here are the most common causes:
+
+@itemize @bullet
+@item
+The disk hasn't yet been formatted (with @samp{pintos run -f}).
+
+@item
+The file name specified is too long. The file system limits file names
+to 14 characters. If you're using a command like @samp{pintos put
+../../tests/userprog/echo}, that overflows the limit. Use
+@samp{pintos put ../../tests/userprog/echo echo} to put the file under
+the name @file{echo} instead.
+
+@item
+The file system is full.
+
+@item
+The file system already contains 10 files. (There's a 10-file limit for
+the base Pintos file system.)
+
+@item
+The file system is so fragmented that there's not enough contiguous
+space for your file.
+@end itemize
+
+@item
+@b{All my user programs die with page faults.}
+
+This will generally happen if you haven't implemented problem 2-1
+yet. The reason is that the basic C library for user programs tries
+to read @var{argc} and @var{argv} off the stack. Because the stack
+isn't properly set up yet, this causes a page fault.
+
+@item
+@b{I implemented 2-1 and now all my user programs die with
+@samp{system call!}.}
+
+Every reasonable program tries to make at least one system call
+(@func{exit}) and most programs make more than that. Notably,
+@func{printf} invokes the @code{write} system call. The default
+system call handler just prints @samp{system call!} and terminates the
+program. You'll have to implement 2-2 before you see anything more
+interesting. Until then, you can use @func{hex_dump} to convince
+yourself that 2-1 is implemented correctly (@pxref{Argument Passing to
+main}).
+