Lines Matching refs:you

3 the Oops" or "running it through ksymoops".  If you post an Oops from 2.6 that
4 has been run through ksymoops, people will just tell you to repost it.
11 If you are unsure send it to the person responsible for the code relevant to
12 what you were doing.  If it occurs repeatably try and describe how to recreate
15 If you are totally stumped as to whom to send the report, send it to 
25 in which case you can run dmesg > file to read the data from the kernel
26 buffers and save it.  Or you can cat /proc/kmsg > file, however you
28 If the machine has crashed so badly that you cannot enter commands or
29 the disk is not available then you have three options :-
32     has restarted.  Messy but it is the only option if you have not
33     planned for a crash. Alternatively, you can take a picture of
35     nothing.  If the messages scroll off the top of the console, you
37     will allow you to read more of the text. (Caveat: This needs vesafb,
63 Actually, there are things you can do that make this easier. I have two 
78 ksymoops will do this too with the correct tools, but if you don't have
79 the tools you can just do a silly program:
85 stuff are the values reported by the Oops - you can just cut-and-paste 
89 Alternatively, you can use the shell script in scripts/decodecode.
103 Finally, if you want to see where the code comes from, you can do
108 and then you get a better idea of what happens than with the gdb 
111 Now, the trick is just then to combine all the data you have: the C 
113 listing and the code disassembly (and additionally the register dump you 
115 corrupted pointers were, and when you have the assembler listing you can 
119 Essentially, you just look at what doesn't match (in this case it was the 
121 Then you need to find out _why_ they don't match. Often it's simple - you 
122 see that the code uses a NULL pointer and then you look at the code and 
124 you just check against it..
127 some small amount of concentration, you're right. Which is why I will