How to hook a context switch??

To add to this... I'm using linux 2.4.20 kernel.... It would appreciable if someone could help me in debugging this problem.

Thanks in Advance, Gromer

Hi,

Considering that I'm reading this in alt.os.development, the first thing I'd suggest is rewriting the entire OS to your liking. Starting with a "hello world" kernel booted from GRUB seems to be a popular way to begin. :-)

On a more serious note, was there meant to be an attachment or something? It's a little hard for anyone to debug code without seeing it...

Cheers,

Brendan

Sorry the actual post was snipped off... below is pasted the actual one..

Hi,

I have one issue and would like to get some expert advise from the group. The below shown code snippet gives some idea about the scenario. I have basically one function (func_1) which does a wake_up after processing some information. Once the wake_up is executed the system crashes.

So to debug this, i've put printks after the add_wait_queue() and schedule function to capture the functions that gets executed with a wake_up... but for no help.. Im unable to find the thread which gets executed after the wake_up.

I'm wondering how to capture or debug which thread/function gets the CPU when this wake_up has been executed... Any pointer would be highly appreciable.

How is such a situation usually debugged?? Can such a context switching be hooked..

/* Wait on here when we're waiting device to be ready */ wait_queue_head_t waitDev;

void func_1( struct func_arg*) {

/*..Do some useful work */

wake_up(&waitDev); /* crash occurs here */

int sec_func (struct func_arg2 *) {

/* some processing work done here */ .... .. set_current_state(TASK_UNINTERRUPTIBLE); add_wait_queue(&waitDev, &wait); spin_unlock(mutex); schedule(); remove_wait_queue(&waitDev, &wait); spin_lock(chip->mutex);

/* some more work is being done here */

Brendan wrote:

You seem to have snipped the initialization of waitDev and wait; forgetting to initialize one or both could easily cause this. If that's not it, it'd help if you found out what specific instruction faulted.

As far as finding out which thread was running when it faulted, the oops output should clearly show this (as well as the function if you look up the address).

Or by "crash", do you mean something other than an oops, such as a lockup or reboot? If a lockup, are you running X, which would prevent you from seeing the oops if the system doesn't survive long enough to log it?

-Scott