On May 9, 2008, at 12:21 AM, David Miller wrote:
I figured that if the flushes are the root cause, then this should
take
care of the problem. However, the kernel still doesn't boot.
That patch you posted is dangerous. If the stack isn't flushed,
there will be garabage in the frame pointer slots of the stack
frame, and likely that will cause an OOPS.
That was not indented as a proper patch, that was just a quick hack
attempt to help me solve my problems.
But I'm curious. How is it dangerous not to call save_stack-trace()?
No frame pointers will be accessed since no stack trace is recorded.
If nothing is recorded, how can they be accessed later? trace-
>nr_entries just remains 0, and print_stack_trace() properly handles
stack traces of length 0. I assume the rest of lockdep is robust
enough to handle such a corner case, too.
(I'm looking at the 2.6.24 source, since that is what I'm working with
atm.)
Please, let me try to resolve this as I find time to do so.
Sure, I just need to get my stuff to work. I'd appreciate any hints on
how to get lockdep semi-working/limping, if there is an easy way to do
so.
Anyway, thanks for your feedback.
- Bjoern
--
To unsubscribe from this list: send the line "unsubscribe sparclinux" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
