On Mon, Oct 6, 2014 at 6:04 AM, Gilles Chanteperdrix <[email protected]> wrote: > On Mon, Oct 06, 2014 at 06:00:23AM +0800, GP Orcullo wrote: >> 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. >> > >> >> >> 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! > > Xenomai runs fine with CONFIG_PREEMPT. The reason why CONFIG_PREEMPT > may be an issue is if you are using "preempt_disable" or > "preempt_enable", which use current, in a place where you > should not (on the context of a kernel-space thread for > instance). This happens for instance when using a plain Linux > spinlock in real-time code. > > But this should not happen. > > -- > Gilles.
Before disabling CONFIG_PREEMPT, I've been seeing this line: [ 123.982550] hrtimer: interrupt took 280933 ns Is this normal? -- GP Orcullo _______________________________________________ Xenomai mailing list [email protected] http://www.xenomai.org/mailman/listinfo/xenomai
