Decoding Oops
Jan 10, 2008, 07:00 (0 Talkback[s])
WEBINAR:
On-Demand
Re-Imagining Linux Platforms to Meet the Needs of Cloud Service Providers
"'This week, a total of 49 oopses and warnings have been
reported, compared to 53 reports in the previous week,' Arjan van
de Ven noted, sending out a list of the week's top 10 kernel
oopses. Al Viro suggested, 'FWIW, people moaning about the lack of
entry-level kernel work would do well by decoding those to the
level of 'this place in this function, called from <here>,
with so-and-so variable being <this>' and posting the
results." This was met by multiple requests for documentation on
how to actually decode an oops. Linus Torvalds explained:
"'It's actually not necessarily at all that trivial, unless you
have a deep understanding of the code generated for the
architecture in question (and even then, some oopses take more time
to figure out than others, thanks to inlining and tailcalls etc).
If the oops happened with a kernel you generated yourself, it's
usually rather easy. Especially if you said 'y' to the 'generate
debugging info' question at configuration time...'"
Complete
Story
Related Stories:
