833 lines
21 KiB
HTML
833 lines
21 KiB
HTML
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
|
|
<HTML
|
|
><HEAD
|
|
><TITLE
|
|
>When Bad Things Happen To Good People</TITLE
|
|
><META
|
|
NAME="GENERATOR"
|
|
CONTENT="Modular DocBook HTML Stylesheet Version 1.7"><LINK
|
|
REL="HOME"
|
|
TITLE="The Linux Gamers' HOWTO"
|
|
HREF="index.html"><LINK
|
|
REL="PREVIOUS"
|
|
TITLE="Various Topics"
|
|
HREF="x343.html"><LINK
|
|
REL="NEXT"
|
|
TITLE="Video Cards"
|
|
HREF="x608.html"></HEAD
|
|
><BODY
|
|
CLASS="SECT1"
|
|
BGCOLOR="#FFFFFF"
|
|
TEXT="#000000"
|
|
LINK="#0000FF"
|
|
VLINK="#840084"
|
|
ALINK="#0000FF"
|
|
><DIV
|
|
CLASS="NAVHEADER"
|
|
><TABLE
|
|
SUMMARY="Header navigation table"
|
|
WIDTH="100%"
|
|
BORDER="0"
|
|
CELLPADDING="0"
|
|
CELLSPACING="0"
|
|
><TR
|
|
><TH
|
|
COLSPAN="3"
|
|
ALIGN="center"
|
|
>The Linux Gamers' HOWTO</TH
|
|
></TR
|
|
><TR
|
|
><TD
|
|
WIDTH="10%"
|
|
ALIGN="left"
|
|
VALIGN="bottom"
|
|
><A
|
|
HREF="x343.html"
|
|
ACCESSKEY="P"
|
|
>Prev</A
|
|
></TD
|
|
><TD
|
|
WIDTH="80%"
|
|
ALIGN="center"
|
|
VALIGN="bottom"
|
|
></TD
|
|
><TD
|
|
WIDTH="10%"
|
|
ALIGN="right"
|
|
VALIGN="bottom"
|
|
><A
|
|
HREF="x608.html"
|
|
ACCESSKEY="N"
|
|
>Next</A
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
><HR
|
|
ALIGN="LEFT"
|
|
WIDTH="100%"></DIV
|
|
><DIV
|
|
CLASS="SECT1"
|
|
><H1
|
|
CLASS="SECT1"
|
|
><A
|
|
NAME="AEN457"
|
|
></A
|
|
>6. When Bad Things Happen To Good People</H1
|
|
><P
|
|
>Of course we can't cover every Bad Thing that happens, but I'll outline some items of common
|
|
sense.</P
|
|
><P
|
|
>There are two types of bad things: random and repeatable. It's very difficult to diagnose
|
|
or fix random problems that you don't have any control over when they happen or not. However, if
|
|
the problem is repeatable "it happens when I press the left arrow key twice", then you're in
|
|
business.</P
|
|
><DIV
|
|
CLASS="SECT2"
|
|
><H2
|
|
CLASS="SECT2"
|
|
><A
|
|
NAME="AEN461"
|
|
></A
|
|
>6.1. RTFM!</H2
|
|
><P
|
|
>Read the friendly manual. The `manual' can take on a few forms. For open source games
|
|
there's the readme files that come with the game. Commercial games will have a printed manual
|
|
and maybe some readme files on the CD the game came on. Don't forget to browse the CD your
|
|
game came on for helpful tips and advice.</P
|
|
><P
|
|
>Don't forget the game's website. The game's author has probably seen people with your
|
|
exact same problem many times over and might put information specific to that game on the
|
|
website. A prime example of this is Loki Software's online FAQs located at <A
|
|
HREF="http://faqs.lokigames.com"
|
|
TARGET="_top"
|
|
>http://faqs.lokigames.com</A
|
|
>.</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="SECT2"
|
|
><H2
|
|
CLASS="SECT2"
|
|
><A
|
|
NAME="AEN466"
|
|
></A
|
|
>6.2. Look For Updates and Patches</H2
|
|
><P
|
|
>If you're playing an open source game that you compiled, make sure you have the newest
|
|
version by checking the game's website. If your game came from a distro make sure there's not
|
|
an update rpm/deb for the game.</P
|
|
><P
|
|
>Commercial game companies like Loki release patches for their games. Often a game will
|
|
have MANY patches (Myth2) and some games are unplayable without them (Heretic2). Check the
|
|
game's website for patches whether you have a problem running the game or not; there may be an
|
|
update for a security problem that you may not even be aware of.</P
|
|
><P
|
|
>By the way, Loki now has a utility that searches for Loki Software on your hard drive
|
|
and automatically updates them. Check out <A
|
|
HREF="http://updates.lokigames.com"
|
|
TARGET="_top"
|
|
>http://updates.lokigames.com</A
|
|
>.</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="SECT2"
|
|
><H2
|
|
CLASS="SECT2"
|
|
><A
|
|
NAME="AEN472"
|
|
></A
|
|
>6.3. Newsgroups</H2
|
|
><P
|
|
>If you don't know what netnews (Usenet) is, then this is definitely worth 30 minutes of
|
|
your time to learn about. Install a newsreader. I prefer console tools more, so I use tin,
|
|
but slrn is also popular. Netscape has a nice graphical "point and click" newsreader
|
|
too.</P
|
|
><P
|
|
>For instance, I can browse Loki Software's news server with <B
|
|
CLASS="COMMAND"
|
|
>tin -g
|
|
news.lokigames.com</B
|
|
>. You can also specify which news server to use using the
|
|
<TT
|
|
CLASS="VARNAME"
|
|
>$NNTP</TT
|
|
> environment variable or with the file
|
|
<TT
|
|
CLASS="FILENAME"
|
|
>/etc/nntpserver</TT
|
|
>.</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="SECT2"
|
|
><H2
|
|
CLASS="SECT2"
|
|
><A
|
|
NAME="AEN479"
|
|
></A
|
|
>6.4. Google Group Search</H2
|
|
><P
|
|
>Every post made to Usenet gets archived at Google's database at <A
|
|
HREF="http://groups.google.com"
|
|
TARGET="_top"
|
|
>http://groups.google.com</A
|
|
>. This archive used to be at <A
|
|
HREF="http://www.deja.com"
|
|
TARGET="_top"
|
|
>http://www.deja.com</A
|
|
>, but was bought by Google. Many people still know the
|
|
archive as "deja".</P
|
|
><P
|
|
>It's almost certain that whatever problem you have with Linux, gaming related or not,
|
|
has already been asked about and answered on Usenet. Not once, not twice, but many times
|
|
over. If you don't understand the first response you see (or if it doesn't work), then try
|
|
one of the other many replies. If the page is not in a language you can understand, there are
|
|
many translation sites which will convert the text into whatever language you like, including
|
|
<A
|
|
HREF="http://www.freetranslation.com"
|
|
TARGET="_top"
|
|
>http://www.freetranslation.com</A
|
|
> and <A
|
|
HREF="http://translation.lycos.com"
|
|
TARGET="_top"
|
|
>http://translation.lycos.com</A
|
|
>. My web browser of choice, Opera (available at
|
|
<A
|
|
HREF="http://www.opera.com"
|
|
TARGET="_top"
|
|
>http://www.opera.com</A
|
|
>) allows you to use the right mouse button to select
|
|
a portion of text and left click the selection to translate it into another language. Very
|
|
useful when a Google group search yields a page in German which looks useful and my wife (who
|
|
reads German well) isn't around.</P
|
|
><P
|
|
>The Google group search has a basic and advanced search page. Don't bother with the
|
|
simple search. The advanced search is at <A
|
|
HREF="http://groups.google.com/advanced_group_search"
|
|
TARGET="_top"
|
|
>http://groups.google.com/advanced_group_search</A
|
|
>.</P
|
|
><P
|
|
>It's easy to use. For example, if my problem was that Quake III crashed everytime Lucy
|
|
jumps, I would enter "linux quake3 crash lucy jumps" in the "Find messages with all of the
|
|
words" textbox.</P
|
|
><P
|
|
>There are fields for which newsgroup you want to narrow your search to. Take the time
|
|
to read and understand what each field means. I promise you. You won't be disappointed with
|
|
this service. Use it, and you'll be a much happier person. Do note that they don't archive
|
|
private newsgroups, like Loki Software's news server. However, so many people use Usenet, it
|
|
almost doesn't matter.</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="SECT2"
|
|
><H2
|
|
CLASS="SECT2"
|
|
><A
|
|
NAME="AEN492"
|
|
></A
|
|
>6.5. Debugging: call traces and core files</H2
|
|
><P
|
|
>This is generally not something you'll do for commercial games. For open source games,
|
|
you can help the author by giving a corefile or stack trace. Very quickly, a core file (aka
|
|
core dump) is a file that holds the "state" of the program at the moment it crashes. It holds
|
|
valuable clues for the programmer to the nature of the crash -- what caused it and what the
|
|
program was doing when it happened. If you want to learn more about core files, I have a
|
|
great gdb tutorial at <A
|
|
HREF="http://www.dirac.org/linux"
|
|
TARGET="_top"
|
|
>http://www.dirac.org/linux</A
|
|
>.</P
|
|
><P
|
|
>At the *very* least, the author will be interested in the call stack when the game
|
|
crashed. Here is how you can get the call stack at barf-time:</P
|
|
><P
|
|
>Sometimes distros set up their OS so that core files (which are mainly useful to
|
|
programmers) aren't generated. The first step is to make your system allow unlimited
|
|
coresizes:</P
|
|
><TABLE
|
|
BORDER="1"
|
|
BGCOLOR="#E0E0E0"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
><FONT
|
|
COLOR="#000000"
|
|
><PRE
|
|
CLASS="SCREEN"
|
|
> ulimit -c unlimited
|
|
</PRE
|
|
></FONT
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
><P
|
|
>You will now have to recompile the program and pass the -g option to gcc (explaining
|
|
this is beyond the scope of this document). Now, run the game and do whatever you did to
|
|
crash the program and dump a core again. Run the debugger with the core file as the 2nd
|
|
argument:</P
|
|
><TABLE
|
|
BORDER="1"
|
|
BGCOLOR="#E0E0E0"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
><FONT
|
|
COLOR="#000000"
|
|
><PRE
|
|
CLASS="SCREEN"
|
|
> $ gdb CoolGameExecutable core
|
|
</PRE
|
|
></FONT
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
><P
|
|
>And at the (gdb) prompt, type "backtrace". You'll see something like:</P
|
|
><TABLE
|
|
BORDER="1"
|
|
BGCOLOR="#E0E0E0"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
><FONT
|
|
COLOR="#000000"
|
|
><PRE
|
|
CLASS="SCREEN"
|
|
> #0 printf (format=0x80484a4 "z is %d.\n") at printf.c:30
|
|
#1 0x8048431 in display (z=5) at try1.c:11
|
|
#2 0x8048406 in main () at try1.c:6
|
|
</PRE
|
|
></FONT
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
><P
|
|
>It may be quite long, but use your mouse to cut and paste this information into a file.
|
|
Email the author and tell him:</P
|
|
><P
|
|
></P
|
|
><OL
|
|
TYPE="1"
|
|
><LI
|
|
><P
|
|
>The game's name</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
>Any error message that appears on the screen when the game
|
|
crashes.</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
>What causes the crash and whether it's a repeatable crash or
|
|
not.</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
>The call stack</P
|
|
></LI
|
|
></OL
|
|
><P
|
|
>If you have good bandwidth, ask the author if he would like the core file that his
|
|
program dumped. If he says yes, then send it. Remember to ask first, because core files can
|
|
get very, very big.</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="SECT2"
|
|
><H2
|
|
CLASS="SECT2"
|
|
><A
|
|
NAME="SAVEDGAMES"
|
|
></A
|
|
>6.6. Saved Games</H2
|
|
><P
|
|
>If your game allows for saved games, then sending the author a copy of the saved game is
|
|
useful because it helps the tech reproduce whatever is going wrong. For commercial games,
|
|
this option is more fruitful than sending a core file or call stack since commercial games
|
|
can't be recompiled to include debugging information. You should definitely ask before
|
|
sending a save game file because they tend to be long, but gaming companies usually have lots
|
|
of bandwidth. Mike Phillips (formerly of Loki Software) mentioned that sending in saved games
|
|
to Loki is definitely a good thing.</P
|
|
><P
|
|
>Needless to say, this only applies if your game crashes reproducably at a certain point.
|
|
If the game segfaults every time you run it, or is incredibly slow, a saved game file won't be
|
|
of much help.</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="SECT2"
|
|
><H2
|
|
CLASS="SECT2"
|
|
><A
|
|
NAME="AEN518"
|
|
></A
|
|
>6.7. What to do when a file or library isn't being found (better living through
|
|
strace)</H2
|
|
><P
|
|
>Sometimes you'll see error messages that indicate a file wasn't found. The file could
|
|
be a library:</P
|
|
><TABLE
|
|
BORDER="1"
|
|
BGCOLOR="#E0E0E0"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
><FONT
|
|
COLOR="#000000"
|
|
><PRE
|
|
CLASS="SCREEN"
|
|
> % ./exult
|
|
./exult: error while loading shared library: libSDL-1.2.so.0: cannot load shared object
|
|
file: No such file or directory
|
|
</PRE
|
|
></FONT
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
><P
|
|
>or it could be some kind of data file, like a <TT
|
|
CLASS="FILENAME"
|
|
>wad</TT
|
|
>
|
|
or <TT
|
|
CLASS="FILENAME"
|
|
>map</TT
|
|
> file:</P
|
|
><TABLE
|
|
BORDER="1"
|
|
BGCOLOR="#E0E0E0"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
><FONT
|
|
COLOR="#000000"
|
|
><PRE
|
|
CLASS="SCREEN"
|
|
> % qf-client-sdl
|
|
IP address 192.168.0.2:27001 UDP Initialize Error: W_LoadWadFile: couldn't load gfx.wad
|
|
</PRE
|
|
></FONT
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
><P
|
|
>Suppose <TT
|
|
CLASS="FILENAME"
|
|
>gfx.wad</TT
|
|
> is already on my system, but couldn't be found
|
|
because it isn't in the right directory. Then where IS the right directory? Wouldn't it be
|
|
helpful to know where these programs looked for the missing files?</P
|
|
><P
|
|
>This is where strace shines. strace tells you what system calls are being made, with
|
|
what arguments, and what their return values are. In my `Kernel Module Programming Guide'
|
|
(due to be released to LDP soon), I outline everything you may want to know about strace. But
|
|
here's a brief outline using the canonical example of what strace looks like. Give the
|
|
command:</P
|
|
><TABLE
|
|
BORDER="1"
|
|
BGCOLOR="#E0E0E0"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
><FONT
|
|
COLOR="#000000"
|
|
><PRE
|
|
CLASS="SCREEN"
|
|
> strace -o ./LS_LOG /bin/ls
|
|
</PRE
|
|
></FONT
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
><P
|
|
>The -o option sends strace's output to a file; here, LS_LOG. The last argument to
|
|
strace is the program we're inspecting, here, "ls". Look at the contents of LS_LOG. Pretty
|
|
impressive, eh? Here is a typical line:</P
|
|
><TABLE
|
|
BORDER="1"
|
|
BGCOLOR="#E0E0E0"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
><FONT
|
|
COLOR="#000000"
|
|
><PRE
|
|
CLASS="SCREEN"
|
|
> open(".", O_RDONLY|O_NONBLOCK|0x18000) = 4
|
|
</PRE
|
|
></FONT
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
><P
|
|
>We used the <TT
|
|
CLASS="FUNCTION"
|
|
>open()</TT
|
|
> system call to open "." with various arguments,
|
|
and the return value of the call is <SPAN
|
|
CLASS="RETURNVALUE"
|
|
>4</SPAN
|
|
>. What does this have to do
|
|
with files not being found?</P
|
|
><P
|
|
>Suppose I want to watch the StateOfMind demo because I can't ever seem to get enough of
|
|
it. One day I try to run it and something bad happens:</P
|
|
><TABLE
|
|
BORDER="1"
|
|
BGCOLOR="#E0E0E0"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
><FONT
|
|
COLOR="#000000"
|
|
><PRE
|
|
CLASS="SCREEN"
|
|
> % ./mind.i86_linux.glibc2.1
|
|
Loading & massaging...
|
|
Error:Can't open data file 'mind.dat'.
|
|
</PRE
|
|
></FONT
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
><P
|
|
>Let's use strace to find out where the program was looking for the data file.</P
|
|
><TABLE
|
|
BORDER="1"
|
|
BGCOLOR="#E0E0E0"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
><FONT
|
|
COLOR="#000000"
|
|
><PRE
|
|
CLASS="SCREEN"
|
|
> strace ./mind.i86_linux.glibc2.1 2> ./StateOfMind_LOG
|
|
</PRE
|
|
></FONT
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
><P
|
|
>Pulling out vim and searching for all occurrences of <TT
|
|
CLASS="FILENAME"
|
|
>mind.dat</TT
|
|
>, I
|
|
find the following lines:</P
|
|
><TABLE
|
|
BORDER="1"
|
|
BGCOLOR="#E0E0E0"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
><FONT
|
|
COLOR="#000000"
|
|
><PRE
|
|
CLASS="SCREEN"
|
|
> open("/usr/share/mind.dat",O_RDONLY) = -1 ENOENT (No such file)
|
|
write(2, "Error:", 6Error:) = 6
|
|
write(2, "Can\'t open data file \'mind.dat\'."..., ) = 33
|
|
</PRE
|
|
></FONT
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
><P
|
|
>It was looking for <TT
|
|
CLASS="FILENAME"
|
|
>mind.dat</TT
|
|
> in only one directory. Clearly,
|
|
<TT
|
|
CLASS="FILENAME"
|
|
>mind.dat</TT
|
|
> isn't in <TT
|
|
CLASS="FILENAME"
|
|
>/usr/share</TT
|
|
>.
|
|
Now we can try to locate <TT
|
|
CLASS="FILENAME"
|
|
>mind.dat</TT
|
|
> and move it into
|
|
<TT
|
|
CLASS="FILENAME"
|
|
>/usr/share</TT
|
|
>, or better, create a symbolic link.</P
|
|
><P
|
|
>This method works for libraries too. Suppose the library <TT
|
|
CLASS="FILENAME"
|
|
>libmp3.so.2</TT
|
|
> is in <TT
|
|
CLASS="FILENAME"
|
|
>/usr/local/include</TT
|
|
> but your new game "Kill-Metallica" can't find
|
|
it. You can use strace to determine where Kill-Metallica was looking for the library and make
|
|
a symlink from <TT
|
|
CLASS="FILENAME"
|
|
>/usr/local/include/libmp3.so.2</TT
|
|
> to wherever
|
|
Kill-Metallica was looking for the library file.</P
|
|
><P
|
|
>strace is a very powerful utility. When diagnosing why things aren't being found, it's
|
|
your best ally, and is even faster than looking at source code. As a last note, you can't
|
|
look up information in source code of commercial games from Lokisoft or Tribsoft. But you can
|
|
still use strace with them!</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="SECT2"
|
|
><H2
|
|
CLASS="SECT2"
|
|
><A
|
|
NAME="HOSEDCONSOLES"
|
|
></A
|
|
>6.8. Hosed consoles</H2
|
|
><P
|
|
>Sometimes a game will exit abnormally and your console will get `hosed'. There are a
|
|
few definitions of a hosed console. The text characters could look like gibberish. Your
|
|
normally nice black screen could look like a quasi-graphics screen. When you press
|
|
<B
|
|
CLASS="KEYCAP"
|
|
>ENTER</B
|
|
>, a newline doesn't get echo'ed to the screen. Sometimes, certain keys
|
|
of the keyboard won't respond. Logging out and back in don't always work, but there are a
|
|
few things that might:</P
|
|
><P
|
|
></P
|
|
><UL
|
|
><LI
|
|
><P
|
|
>If you don't see any character on the screen as you type in, your terminal
|
|
settings may be wrong. Try "stty echo". This should let input characters echo
|
|
again.</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
>At the prompt, type "reset". This should clear up many problems, including
|
|
consoles hosed by an SVGAlib or ncurses based game.</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
>Try running the game again and normally. Once I had to kill Quake III in a
|
|
hurry, so I performed a <SPAN
|
|
CLASS="KEYSYM"
|
|
>Ctl-Alt-Backspace</SPAN
|
|
>. The console was hosed with a
|
|
quasi-graphics screen. Running Quake III and quitting normally fixed the
|
|
problem.</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
>The commands deallocvt and openvt will work for most of the other problems
|
|
you'll have. <B
|
|
CLASS="COMMAND"
|
|
>deallocvt N</B
|
|
> kills terminal <TT
|
|
CLASS="LITERAL"
|
|
>N</TT
|
|
> entirely, so
|
|
that <TT
|
|
CLASS="LITERAL"
|
|
>Alt-FN</TT
|
|
> doesn't even work anymore. <B
|
|
CLASS="COMMAND"
|
|
>openvt -c N</B
|
|
>
|
|
starts it back up.</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
>If certain keys on your keyboard don't work, be creative. If you want to
|
|
reboot but the `o' key doesn't work, try using halt. One method I've come up with is typing a
|
|
command at the prompt and using characters on the screen with mouse cut/paste. For example,
|
|
you can type "ps ax", and you're sure to have an `h', `a', `l' and a `t' somewhere on the
|
|
screen. You can use the mouse to cut and paste the word "halt".</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
>The most regrettable option is a reboot. If you can, an orderly shutdown is
|
|
preferable; use "halt" or "shutdown". If you can't, ssh in from a another machine. That
|
|
sometimes works when your console is very badly hosed. In the worst case scenario, hit the
|
|
reset or power switch.</P
|
|
></LI
|
|
></UL
|
|
><P
|
|
>Note that if you use a journalling filesystem like ext3, reiserfs or xfs, hitting the
|
|
power switch isn't all that bad. You're still supposed to shutdown in an orderly manner, but
|
|
the filesystem integrity will be maintained. You won't normally see an fsck for the
|
|
partitions that use the journalling filesystem.</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="SECT2"
|
|
><H2
|
|
CLASS="SECT2"
|
|
><A
|
|
NAME="AEN576"
|
|
></A
|
|
>6.9. Locked System</H2
|
|
><P
|
|
>When a computer "locks", also called "hung", the keyboard and mouse become completely
|
|
unresponsive. This is a direct consequence of a bug in the Linux kernel. While Linux is
|
|
known for stability, these things do happen, especiallly for gaming which entails highly
|
|
synchronized hardware events which occur very fast, even to a computer. When a computer
|
|
locks, it can be a "hard lock", meaning the kernel has completely stopped functioning. This
|
|
often indicates misbehaving or faulty hardware. There's no recovery from this kind of lock
|
|
other than pressing the reset or power button. The lock can also be a "soft lock", meaning
|
|
that the kernel is still functioning in some capacity. It's possible to recover from this
|
|
gracefully.</P
|
|
><P
|
|
></P
|
|
><UL
|
|
><LI
|
|
><P
|
|
>The first thing you should try is to hit
|
|
<TT
|
|
CLASS="LITERAL"
|
|
>control-alt-backspace</TT
|
|
> which kills X. If you gain control of your system,
|
|
the kernel wasn't really locked in the first place. If this didn't work after a few seconds,
|
|
you'll definitely want to reboot the system using the following
|
|
instructions.</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
>Use <TT
|
|
CLASS="LITERAL"
|
|
>control-alt-delete</TT
|
|
> to reboot the system. You'll know
|
|
this worked if you hear the computer beep after a few seconds (this is BIOS saying "I'm OK"
|
|
during a power on cycle).</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
>Log into another system and ssh into the hung system. If you can ssh in,
|
|
reboot or halt the system.</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
>If you can't ssh into the system, you'll need to use the "magic SysRq key"
|
|
which is documented in <TT
|
|
CLASS="FILENAME"
|
|
>/usr/src/linux/Documentation/sysrq.txt</TT
|
|
>. Here's a
|
|
summary for the x86 architecture (see the documentation for other architectures). Note if
|
|
your keyboard doesn't have a <B
|
|
CLASS="KEYCAP"
|
|
>SysRq</B
|
|
> key, use the <B
|
|
CLASS="KEYCAP"
|
|
>PrintScreen</B
|
|
>
|
|
key:
|
|
|
|
<P
|
|
></P
|
|
><OL
|
|
TYPE="1"
|
|
><LI
|
|
><P
|
|
>Hit <TT
|
|
CLASS="LITERAL"
|
|
>alt-SysRq-s</TT
|
|
>. This will attempt to sync your mounted
|
|
filesystems so that changes to files get flushed to disk. You may hear disk activity. If
|
|
you're looking at a console, the system should print the devices which were
|
|
flushed.</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
>A few seconds later, hit <TT
|
|
CLASS="LITERAL"
|
|
>alt-SysRq-u</TT
|
|
>. This will attempt
|
|
to remount all your mounted filesystems as read-only). You should hear disk activity. If
|
|
you're looking at a console, the system will print the devices which were
|
|
remounted.</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
>A few seconds later, use <TT
|
|
CLASS="LITERAL"
|
|
>alt-SysRq-b</TT
|
|
> to reboot the
|
|
system.</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
>You can hit <TT
|
|
CLASS="LITERAL"
|
|
>alt-SysRq-h</TT
|
|
> for a very terse help
|
|
screen.</P
|
|
></LI
|
|
></OL
|
|
></P
|
|
></LI
|
|
></UL
|
|
><P
|
|
>To use the magic SysRq key, your kernel needs to have been compiled with magic SysRq
|
|
support. You'll find this option under "<TT
|
|
CLASS="LITERAL"
|
|
>Kernel Hacking | Kernel Debugging | Magic
|
|
SysRq key</TT
|
|
>" in whatever kernel config menu you like to use. If the magic SysRq key
|
|
sequence doesn't shut your system down gracefully, your kernel has crashed hard and you'll
|
|
need to use the reset or power button to recover.</P
|
|
></DIV
|
|
></DIV
|
|
><DIV
|
|
CLASS="NAVFOOTER"
|
|
><HR
|
|
ALIGN="LEFT"
|
|
WIDTH="100%"><TABLE
|
|
SUMMARY="Footer navigation table"
|
|
WIDTH="100%"
|
|
BORDER="0"
|
|
CELLPADDING="0"
|
|
CELLSPACING="0"
|
|
><TR
|
|
><TD
|
|
WIDTH="33%"
|
|
ALIGN="left"
|
|
VALIGN="top"
|
|
><A
|
|
HREF="x343.html"
|
|
ACCESSKEY="P"
|
|
>Prev</A
|
|
></TD
|
|
><TD
|
|
WIDTH="34%"
|
|
ALIGN="center"
|
|
VALIGN="top"
|
|
><A
|
|
HREF="index.html"
|
|
ACCESSKEY="H"
|
|
>Home</A
|
|
></TD
|
|
><TD
|
|
WIDTH="33%"
|
|
ALIGN="right"
|
|
VALIGN="top"
|
|
><A
|
|
HREF="x608.html"
|
|
ACCESSKEY="N"
|
|
>Next</A
|
|
></TD
|
|
></TR
|
|
><TR
|
|
><TD
|
|
WIDTH="33%"
|
|
ALIGN="left"
|
|
VALIGN="top"
|
|
>Various Topics</TD
|
|
><TD
|
|
WIDTH="34%"
|
|
ALIGN="center"
|
|
VALIGN="top"
|
|
> </TD
|
|
><TD
|
|
WIDTH="33%"
|
|
ALIGN="right"
|
|
VALIGN="top"
|
|
>Video Cards</TD
|
|
></TR
|
|
></TABLE
|
|
></DIV
|
|
></BODY
|
|
></HTML
|
|
> |