- From: Muks Raju <muks_at_ieee.org>
- Date: 06 Jan 2003 11:14:13 -0500
Hello
Ok! after a good weekend doing whats given below.. i was able to figure
out that a udelay called in ni_load_channelgain_list in the file
ni_mio_common.c in comedi was causing the problem. When i switched this
to a rt_busy_sleep for a 1usec it was fine. I didnt notice the problem
when the RTAI scheduler was not running. Its only when i load a module
which used the rtai UP scheduler that I would get this problem. Any
clues why this is happening?
Thanks
Muks
On Fri, 2003-01-03 at 13:22, Philippe Gerum wrote:
> Hello,
>
> Let's try one of these:
>
> 1. Define DEBUG_TRAP at the top of arch/i386/rtai.c, recompile and
> reload it along with your application. You'll see the faulting EIP in
> a console message. You'll have to chase the culprit in assembly mode
> (*).
>
> 2. If you don't want to fiddle with RTAI's kernel (you should, it's
> nice! :o), then define your own trap handler using
> RT_SET_RTAI_TRAP_HANDLER(your_trap_handler) in your init_module().
> Your handler must have the following prototype:
> int handler (int vec, int signo, struct pt_regs *regs, void *dummy).
> Calling rt_printk("FAULTY ADDRESS = %p\n",(void *)regs->eip); should do
> the trick, and again, you will have to chase the culprit in your code
> according to its address.
> <!> Remember to forcibly suspend the current RT task before returning
> 1 from your handler, otherwise you will get into more problems.
>
> 3. Try to use Viktor Tarasov's self-hosted GDB support for RTAI posted
> to this list nearly a year ago, but I cannot find the archive right
> now.
>
> 4. Use KGDB support for RTAI, but you will need another PC to serve as
> a debugging host through a serial line.
>
> (*) A simple recipe to locate a faulty code using its address [sorry
> if you are already familiar with this kind of stuff, I write this in
> case it helps]
>
> 0. Drink coffee. Twice.
>
> 1. Ensure that all your symbols are exported in your application
> (remove EXPORT_NO_SYMBOLS if any), and remove "static" qualifiers from
> any suspected routines.
>
> 2. Since your bug does not crash the box (lucky, lucky man...), just
> insmod all your modules, and wait for RTAI to suspend your task.
>
> 3. run "ksyms -a > module_syms" to get the "address to symbol"
> translation for all symbols from the running dynamic modules. Maybe
> you are unlucky, and what crashed is in the static part of the Linux
> kernel, so you might need to have the same translation for vmlinux,
> which leads to "objdump -d [/usr/src/linux]/vmlinux > kernel_syms".
>
> 4. Coffee again. Yes, I'm sure.
>
> 5. Ok, then, find the routine than embodies the faulty address if one
> of the two symfiles. If it's in a module and you don't read raw
> assembly output fluently ;o), just compute the offending statement
> offset from the start of the routine and use it to locate the same
> statement in the assembly output of the compiler for the file
> containing this routine. It should be somewhat simpler to understand
> the faulty context since you'll have symbol names used instead of
> raw hex values when applicable.
>
> 6. Consider going for a walk an hour at least, once you have found the
> bug, and repeatedly banged your head on the wall until your
> neighbourhood starts thinking that you definitely play Wagner far too
> loud. With all this coffee you drunk and this horrible headache, you
> won't sleep for a week anyway! :o)
>
> Good luck,
>
> Philippe.
>
> Muks Raju wrote:
> > Hello
> > Im having a serious problem indicated by this message :
> > Default Trap handler: vector 14 : Suspend RT task C305C420 . I know this
> > is because of a page fault. But i fail to see where this is occuring. I
> > have 2 modules. One of which is a driver using comedi which only does a
> > comedi_data_read when asked to do so by the other module. The other
> > module is a rtai periodic process which used a UP scheduler and also
> > FIFOs. Both these modules work perfectly independently. And i only get
> > the error when my real time module calls the driver. And this only
> > happens some times. Any hints about what could be going on.? Is there an
> > issue with using RTAI UP scheduler and fifos and comedi?. The trap seems
> > to be occuring at the point i call the comedi_data_read function or a
> > comedi_do_insn function. When my driver runs independently it works fine
> > with no faults.
> >
> > Thanks
> >
> > Muks
> >
> >
> > --
> > Muks Raju <muks_at_ieee.org>
> >
> >
> > _______________________________________________
> > RTAI mailing list
> > RTAI_at_rtai.org
> > https://mail.rtai.org/cgi-bin/mailman/listinfo/rtai
>
> _______________________________________________
> RTAI mailing list
> RTAI_at_rtai.org
> https://mail.rtai.org/cgi-bin/mailman/listinfo/rtai
--
Muks Raju <muks_at_ieee.org>
Received on 2003-01-06Z16:14:13