On Fri, 2009-01-09 at 13:22 +0100, Matthias Kaehlcke wrote:
obj-m ist not a command, it's a Makefile target used by the kernel
build system. it serves to specify the object files needed to build a
module
for more details have a look at section 3.3 of
Documentation/kbuild/makefiles.txt
Hi list,
First of all, in the meantime I discovered that it's NOT the timer
code... A simple module entry and exit with a printk() will cause a
(very) occasional fault in free_module().
It seems the problem is solved by using modpost through make.
I've scoured on Google but I can't seem to
Hi Peter, Matthias et al,
Sorry for the delay. Thanks for all your feedback so far !
I'll try to give a better description of the problem and what I think
I've learnt so far :
First, my small test module code has always used del_timer_sync() on
exit. The SAM9260 platform is a single CPU however,
Perhaps I should also add my compile invoke (Codesourcery) :
arm-none-linux-gnueabi-gcc -Wall -c -O hello_timer.c -o hello_timer -v
And and an example of a segmentation fault I get on occasion :
Timer module Exited
Unable to handle kernel NULL pointer dereference at virtual address
0062
Hi Peter,
El Sun, Jan 04, 2009 at 08:55:50AM +0800 Peter Teoh ha dit:
ah...two points:
a. that the timer is NOT per-CPU. but a global entity. but many
CPU can own the timer - as deduced from timer-base structure, but
only one is running - based on timer-runng_base. correct? so
Yes, it is still valid and happens. Looking into /proc/sched_debug:
CFS is confirmed.
Next:
Looking into kernel/timer.c:update_process_times():
/*
* Called from the timer interrupt handler to charge one tick to the current
* process. user_tick is 1 if the tick is user time, 0
Hello all,
I've just joined up with this list, so this is mainly an initial ping
to see if I can post.
I'm a newbie studying embedded linux on an Olimex SAM9-L9260 target,
cross compiling on Ubuntu 8.10.
Eventually I'd like to ask a couple of questions. On the subject of
timer INTs, I actually
On Sat, Jan 3, 2009 at 6:20 PM, Microbit_Ubuntu
micro...@virginbroadband.com.au wrote:
Hello all,
I've just joined up with this list, so this is mainly an initial ping
to see if I can post.
I'm a newbie studying embedded linux on an Olimex SAM9-L9260 target,
cross compiling on Ubuntu 8.10.
El Sat, Jan 03, 2009 at 11:13:45PM +0800 Peter Teoh ha dit:
On Sat, Jan 3, 2009 at 6:20 PM, Microbit_Ubuntu
micro...@virginbroadband.com.au wrote:
Hello all,
I've just joined up with this list, so this is mainly an initial ping
to see if I can post.
I'm a newbie studying embedded
ah...two points:
a. that the timer is NOT per-CPU. but a global entity. but many
CPU can own the timer - as deduced from timer-base structure, but
only one is running - based on timer-runng_base. correct? so
logically the logic of clean deletion (making sure not being in used
in another
Hi All,
In Understanding The Linux Kernel, 3rd edition I read that
*scheduler_tick()* is invoked once every tick to perform some operations
related to scheduling. I am confused here, how costly it would be to call
the function after every tick? Does it really happened? If not, then how
On Friday 02 January 2009 10:55:26 Shyam Burkule wrote:
Hi All,
Hi!
first off, UTLK is a bit outdated when it comes to schduling :s
In Understanding The Linux Kernel, 3rd edition I read that
*scheduler_tick()* is invoked once every tick to perform some operations
related to scheduling. I
is confirmed.
Next:
Looking into kernel/timer.c:update_process_times():
/*
* Called from the timer interrupt handler to charge one tick to the current
* process. user_tick is 1 if the tick is user time, 0 for system.
*/
void update_process_times(int user_tick)
{
scheduler_tick
Hi...
I actually followed your direction and made the pointer static. But that did not
solve the problem which I think is expected if I am not wrong. Because even though
the klife pointer passed in klife_open is local, we save the pointer in
filp-private_data for any future access to that
Hi
I actually followed your direction and made the pointer static. But that did
not solve the problem which I think is expected if I am not wrong. Because even
though the klife pointer passed in klife_open is local, we save the pointer in
filp-private_data for any future access to that memory
Hi..
I made all my register functions inline and also replaced xchg with spin_lock and spin_unlock. But that did not help. I am having the same result.
Thank you for considering my suggestions. At least we are one step
closer to the solution. So it's not about being inlined or not nor
Hi
I made all my register functions inline and also replaced xchg with spin_lock
and spin_unlock. But that did not help. I am having the same result.
To clarify the confusion, I actually run a userspace program that calls the
module's open routine which registers the hook. So registration is
Hi
I am trying to reigster a hook and then call it from timer interrupt handler
do_timer so that I can schedule a tasklet from inside my registered function
(It might not have any practical value, but I want to learn the process,
scheduling tasklet from timer interrupt context).
Changes I
Hello...
Why is registering an empty function and calling it from inside do_timer
freezing the system after a short period of good run?
There are several suspects:
1. your code (call_timer_hook) is called while xtime_lock is held. it
could lead to lock contention.
2. you're running out of
Hi
Thanks for your reply. Regarding your suspects -
1. I am actually calling the register_timer_interrupt routine to register the
hook only once by running the userspace program once that registers the hook.
So there should not be any lock contention I think unless the lock is global in
the
20 matches
Mail list logo
