On Sat, Oct 4, 2014 at 7:31 PM, Gilles Chanteperdrix
<[email protected]> wrote:
> On Sat, Oct 04, 2014 at 06:26:33PM +0800, GP Orcullo wrote:
>> On Sat, Oct 4, 2014 at 6:48 AM, Gilles Chanteperdrix
>> <[email protected]> wrote:
>> > On Sat, Oct 04, 2014 at 06:45:08AM +0800, GP Orcullo wrote:
>> >> On Sat, Oct 4, 2014 at 3:14 AM, Gilles Chanteperdrix
>> >> <[email protected]> wrote:
>> >> > On Fri, Oct 03, 2014 at 11:28:52PM +0800, GP Orcullo wrote:
>> >> >> I've added BUG_ON(!hard_irqs_disabled()) to the code and got the
>> >> >> kernel to oops at startup.
>> >> >>
>> >> >> Where shall I start looking for the offending code?
>> >> >
>> >> > The thing is, all the tracepoints you have are late after the
>> >> > fault. A better strategy is to replace BUG_ON(!hard_irqs_disabled)
>> >> > with:
>> >> >
>> >> > if (!hard_irqs_disabled()) {
>> >> >    ipipe_trace_panic_freeze();
>> >> >    ipipe_trace_panic_dump();
>> >> >    BUG();
>> >> > }
>> >> >
>> >>
>> >> The results are almost similar.
>> >>
>> >
>> >> [   15.550769] Unable to handle kernel NULL pointer dereference at 
>> >> virtual address 0000000c
>> >
>>
>> This is due to user error - I've mixed up the module versions...
>>
>> > This is not caused by the code above. This is another bug.
>> >
>> > With the code above, you should see a line
>> > "BUG" or something.
>> >
>>
>> Getting this kernel to print any messages before lockup is very
>> difficult. Is there another way of debugging it beside using jtag?
>>
>
> I generally use printk or the I-pipe tracer in some creative way
> (trigger a trace freeze on some condition then BUG()). You could for
> instance check whether the Linux timer irq is still running by
> putting a printascii(".") there every HZ ticks. If it is not running
> check the same with the Xenomai timer irq, then finally the I-pipe
> timer ack function. On x86 we have the NMI watchdog to help with
> lockups, maybe someone could implement a similar functionality with
> FIQ on ARM.
>
> --
>                                             Gilles.


The cause of the lockups is due to CONFIG_PREEMPT. The board is
running for more than 6 hrs now after disabling it.

Thanks for all your help!

-- 
GP Orcullo

_______________________________________________
Xenomai mailing list
[email protected]
http://www.xenomai.org/mailman/listinfo/xenomai

Reply via email to