It's a report of a bug in the kernel, for example, if the kernel tried
to access an invalid memory location. It doesn't necessarily indicate
a programming error - faulty hardware can cause an OOPS as well.
The following explaination may not be 100% accurate, hopefully
somebody else will post a better one, but here goes:
As far as I know it doesn't stand for anything, and the name is a
kind-of joke, (as in, "oops, we've found a bug in the kernel").
On X86, an OOPS contains information such as:
Text description - something like "Unable to handle NULL pointer
dereference". This tells you what sort of error it is.
The number of the oops, (I.E. whether it was the first, second, third,
etc, starting with 0000).
The CPU it occured on, (0 on a single processor machine). Note, I
think that on a multi processor machine, there isn't a physical
relationship between CPU and number, I.E. CPUs are assigned numbers on
boot, in a semi-random fashion.
The contents of the CPU's registers.
A stack backtrace.
The code the CPU was executing.
A call trace, which is, basically, a list of functions that the
process was in at the moment of the OOPS. The actual numeric values
are almost completely useless[1], because they depend on your
particular kernel. Only somebody who has access to the corresponding
symbol map for that kernel can identify the actual names of the
functions, and this is why there are often posts by developers on this
list asking people to decode an OOPS they have posted.
[1] Without it being decoded, you can still check, for example,
whether the CPU was executing data, but it's mostly speculation.
John.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/