Regarding threaded irq and normal irq
HI all, I want to know whether threaded_irq will be in interrupt context or process context. I heard they replace workqueues. But i dont know which context they will be running in. Any furthur references where i get more info.. -- With regards, Sandeep Kumar Anantapalli,
On Thu, Sep 1, 2011 at 5:48 PM, sandeep kumar <coolsandyforyou@gmail.com> wrote:
HI all,
I want to know whether threaded_irq will be in interrupt context or process context. I heard they replace workqueues. But i dont know which context they will be running in.
Any furthur references where i get more info..
Frankly I am not sure, but after reading Documentation/gpio.txt - where it says: Accessing such GPIOs requires a context which may sleep, for example a threaded IRQ handler, and those accessors must be used instead of spinlock-safe accessors without the cansleep() name suffix. we can immediately deduced that threaded IRQ handler is sleepable/blocking-allowed, and therefore process context. Correct?
-- With regards, Sandeep Kumar Anantapalli,
_______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
-- Regards, Peter Teoh
Hi peter,
we can immediately deduced that threaded IRQ handler is sleepable/blocking-allowed, and therefore process context.
Correct?
Hmm..But when i tried to take a mutex lock in threaded_irq, it is throwing a warning message "BUG: sleeping function called from invalid context"... So i was wondering which way it is.. Thank you, Sandeep On Tue, Sep 6, 2011 at 1:22 AM, Peter Teoh <htmldeveloper@gmail.com> wrote:
On Thu, Sep 1, 2011 at 5:48 PM, sandeep kumar <coolsandyforyou@gmail.com> wrote:
HI all,
I want to know whether threaded_irq will be in interrupt context or
process context.
I heard they replace workqueues. But i dont know which context they will be running in.
Any furthur references where i get more info..
Frankly I am not sure, but after reading Documentation/gpio.txt - where it says:
Accessing such GPIOs requires a context which may sleep, for example a threaded IRQ handler, and those accessors must be used instead of spinlock-safe accessors without the cansleep() name suffix.
we can immediately deduced that threaded IRQ handler is sleepable/blocking-allowed, and therefore process context.
Correct?
-- With regards, Sandeep Kumar Anantapalli,
_______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
-- Regards, Peter Teoh
-- With regards, Sandeep Kumar Anantapalli,
Hi :) On 06/09/2011, sandeep kumar <coolsandyforyou@gmail.com> wrote:
Hmm..But when i tried to take a mutex lock in threaded_irq, it is throwing a warning message "BUG: sleeping function called from invalid context"... So i was wondering which way it is..
Please don't top post :) Anyway, regarding that "BUG:" message, could it be that mutex function mistakenly assume it's called inside top half, thus bails out since sleeping is forbidden there? which mutex function do you use? (sorry I don't follow every locking functions exist now) -- regards, Mulyadi Santosa Freelance Linux trainer and consultant blog: the-hydra.blogspot.com training: mulyaditraining.blogspot.com
On Tue, Sep 6, 2011 at 10:51 AM, Mulyadi Santosa <mulyadi.santosa@gmail.com> wrote:
Hi :)
On 06/09/2011, sandeep kumar <coolsandyforyou@gmail.com> wrote:
Hmm..But when i tried to take a mutex lock in threaded_irq, it is throwing a warning message "BUG: sleeping function called from invalid context"... So i was wondering which way it is..
Please don't top post :)
Anyway, regarding that "BUG:" message, could it be that mutex function mistakenly assume it's called inside top half, thus bails out since How can mutex assume? IMHO the message would have printed because sleeping would be forbidden there but again AFAIK in the threaded handler we can do I2C transactions which can sleep.So kind of paradox there. ps:I have seen the code where sandeep is doing the taking the mutex lock. He is taking mutex lock at the beginging of the handler and releasing at the end. sleeping is forbidden there? which mutex function do you use? (sorry I don't follow every locking functions exist now)
-- regards,
Mulyadi Santosa Freelance Linux trainer and consultant
blog: the-hydra.blogspot.com training: mulyaditraining.blogspot.com
_______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
On Tue, Sep 6, 2011 at 10:59 AM, anish singh <anish198519851985@gmail.com> wrote:
On Tue, Sep 6, 2011 at 10:51 AM, Mulyadi Santosa <mulyadi.santosa@gmail.com> wrote:
Hi :)
On 06/09/2011, sandeep kumar <coolsandyforyou@gmail.com> wrote:
Hmm..But when i tried to take a mutex lock in threaded_irq, it is throwing a warning message "BUG: sleeping function called from invalid context"... So i was wondering which way it is..
Please don't top post :)
Anyway, regarding that "BUG:" message, could it be that mutex function mistakenly assume it's called inside top half, thus bails out since How can mutex assume? IMHO the message would have printed because sleeping would be forbidden there but again AFAIK in the threaded handler we can do I2C transactions which can sleep.So kind of paradox there.
something like using in_irq() inside the threaded irq handler? I think after going thorough the code of mutex_lock we can find out the reason why it is printing the warning eventhough we are calling it in a threaded handler i.e. kernel thread.
From the code: 126 /** 127 * might_sleep - annotation for functions that can sleep 128 * 129 * this macro will print a stack trace if it is executed in an atomic 130 * context (spinlock, irq-handler, ...).
129 line no is important. This might_sleep is called by mutex_lock function and in the defintion of __might_sleep i found below code.I think this below if condition is false because irqs_disabled is true.This causes the warning. if ((preempt_count_equals(preempt_offset) && !irqs_disabled()) || system_state != SYSTEM_RUNNING || oops_in_progress) return; Hope i am right?
ps:I have seen the code where sandeep is doing the taking the mutex lock. He is taking mutex lock at the beginging of the handler and releasing at the end.
sleeping is forbidden there? which mutex function do you use? (sorry I don't follow every locking functions exist now)
-- regards,
Mulyadi Santosa Freelance Linux trainer and consultant
blog: the-hydra.blogspot.com training: mulyaditraining.blogspot.com
_______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
On Tue, Sep 6, 2011 at 8:17 AM, sandeep kumar <coolsandyforyou@gmail.com> wrote:
Hi peter,
we can immediately deduced that threaded IRQ handler is sleepable/blocking-allowed, and therefore process context.
Correct? Hmm..But when i tried to take a mutex lock in threaded_irq, it is throwing a warning message "BUG: sleeping function called from invalid context"... So i was wondering which way it is..
Were you attempting to convert your normal IRQ handler to threaded IRQ handler? If yes then there is a special sequence of operation needed to code (eg): http://lwn.net/Articles/324980/ perhaps error arising from violation of these implementation? Being "threaded" means that the IRQ handler is executing at the thread context, or process context.
Thank you, Sandeep On Tue, Sep 6, 2011 at 1:22 AM, Peter Teoh <htmldeveloper@gmail.com> wrote:
On Thu, Sep 1, 2011 at 5:48 PM, sandeep kumar <coolsandyforyou@gmail.com> wrote:
HI all,
I want to know whether threaded_irq will be in interrupt context or process context. I heard they replace workqueues. But i dont know which context they will be running in.
Any furthur references where i get more info..
Frankly I am not sure, but after reading Documentation/gpio.txt - where it says:
Accessing such GPIOs requires a context which may sleep, for example a threaded IRQ handler, and those accessors must be used instead of spinlock-safe accessors without the cansleep() name suffix.
we can immediately deduced that threaded IRQ handler is sleepable/blocking-allowed, and therefore process context.
Correct?
-- With regards, Sandeep Kumar Anantapalli,
_______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
-- Regards, Peter Teoh
-- With regards, Sandeep Kumar Anantapalli,
-- Regards, Peter Teoh
participants (4)
-
anish singh -
Mulyadi Santosa -
Peter Teoh -
sandeep kumar