[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Kernel oops using DMA on MCM

>If you are interested I can send you its source as well.
Yes, that would be nice.

>The kernel backtraces are not identical at all times. To be more accurate,
>the initial
>Trace; c0014e8a <do_generic_file_read+3a8/3ae>
>Trace; c0026312 <search_binary_handler+52/fe>
>Trace; c0025836 <copy_strings+0/1ae>
>Trace; c002650e <do_execve+150/1aa>
>Trace; c00455f0 <sys_execve+2a/42>
>Trace; c00460be <system_call+50/58>
>part is identical in each trace

strange. The sequence above would of course occur if any process
dies and init respawns it but your OOPS says that it is cat that
has this calltrace and it is just bogus.

>Actually, option two may also be worthwhile to consider as well. If the CPU
>was just not caching the area, the driver would not need to be made any more
>complex than it currently is. Do you think this is something feasible to do?

This would imply modifications in several non-trivial places to set up
the MMU to do this and to make sure that your data is really allocated
in the uncached area. I really think it is easier to add the few lines
in the synch serial driver. 

Do you also have lots of network traffic when the problem happens?
After how long time does the problem occur (seconds? minutes? hours?)