Lines Matching refs:it

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.
9 Find the Oops and send it to the maintainer of the kernel area that seems to be
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
13 it.  That's worth even more than the oops.
15 If you are totally stumped as to whom to send the report, send it to 
23 handed to syslogd which writes it to a syslog file, typically
26 buffers and save it.  Or you can cat /proc/kmsg > file, however you
31 (1) Hand copy the text from the screen and type it in after the machine
32     has restarted.  Messy but it is the only option if you have not
52 NOTE: the message from Linus below applies to 2.4 kernel.  I have preserved it
53 for historical reasons, and because some of the information in it still
71 information of which function and the offset in the function that it 
74 Oh, it helps if the report happens on a kernel that is compiled with the 
84 and compile it with gcc -g and then do "disassemble str" (where the "XX" 
112 sources (and general knowledge of what it _should_ do), the assembly 
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 
123 wonder how the NULL pointer got there, and if it's a valid thing to do 
124 you just check against it..
129 info etc looked up: it simply gets too hard to look it up (I have some 
135 _Sometimes_ it happens that I just see the disassembled code sequence 
136 from the panic, and I know immediately where it's coming from. That's when