- From: Philippe Gerum <philippe.gerum_at_openwide.fr>
- Date: Mon, 6 Jan 2003 22:22:52 +0100
Muks Raju wrote: > 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? > Oops. This one is a bit tricky. udelay() indirectly accesses the "current" Linux task context to get some calibration information it needs about the CPU speed. The problem is: you have _no_ "current" Linux task when running on behalf of a real-time task (*) and dereferencing the symbol "current" (as defined in linux/asm/current.h) is invalid in this context. This is a recurrent problem that happens when using context-sensitive Linux kernel code on behalf of RTAI tasks. (*) The basic reason is that "current" (i.e. the pointer to the control block of the Linux task which is supposedly running at the time you ask for it) is ingeniously computed from the active stack pointer's value (i.e. %esp). This is possible because each Linux (x86) task control block is laid in the first 8k of any given task's stack. But RTAI tasks created by the UP sched have their own stack space, therefore in the first 8k of a RT stack you'll find, well, nothing that can be seen as a Linux task control block, but probably many reasons for your box to go sky high if you attempt to refer to it as such... :o) PS: in order to complete my previous mail: you can get mixed c/assembly listings from an object file using "objdump -S", and you can use "insmod -m ..." to get a load map of a particular module upon insertion in the kernel. Credit due to Alessandro Rubini who pointed me to these timesaving tricks. Philippe.
Received on 2003-01-06Z21:22:52