Cool! Thanks. I reran ksymoops, and as it turns out the Letext below turns into do_page_fault, so that fits well. That will come in handy, and it answers question number 2.
Thanks again. Any thoguhts on the first question :) ? Neil Frank Rowand wrote: > > Neil Horman wrote: > > > > Hello all! > > If anyone has a moment, I've got a question regarding the attached > > oops > > message. On the platform we are debugging we get this occasional oops > > message > > (attached). It doesn't start in any one point from the application code, > > but > > the lower half of it (from sys_read down) is always identiacal. > > Specifically I'm > > interested in the following snippet: > > >Trace; c00202d4 <handle_mm_fault+6c/100> > > >Trace; c0009e3c <Letext+190/3cc> > > >Trace; c00029a8 <ret_from_except+0/34> > > >Trace; c02e6e94 <END_OF_CODE+19a49c/??? > > >Trace; c002397c <do_generic_file_read+260/48c> > > > Questions: > > 1) Can anyone think of any other theories that might cause this END_OF_CODE > > stack frame behavior? > > 2) Regarding the Letext stack frame: I see this often as well, and I'm a > > little > > puzzled. Is its appearance to be expected. I expected to see after a > > ret_from_except stack frame a link to one of the memory management handler > > routines (do_page_fault, etc), but I don't. For my own education, what is > > that > > Letext line? > > If you look in System.map you should see that each address for which an Letext > entry also has another entry with a valid name. > > You can get better symbols in your stack trace if you do something like: > > mv System.map System.map.OLD > grep -v Letext System.map.OLD >System.map > > -Frank > -- > Frank Rowand <frank_rowand at mvista.com> > MontaVista Software, Inc > ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
