Hi, Anish, > > > > I see in the source (linux ver 3.3) that wake_up_interruptible > > function doesn't sleep so I used in it an ISR but I'm getting > > 'BUG:scheduling while atomic' message. (I'm not sure it's coming from > > this) > > Remove it and check if the problem goes away.
I later figured out that the 'scheduling while atomic' is coming from other line. I was calling wait_event_interruptible while I hold spinlock. So temporarily removing spinlock acquisition made the BUG message go away. I'm thinking of changing that spinlock to mutex (semaphore with count 1) and am curious if I'll still get that message. Anyway I need to protect the critical section (it's FIFO write and read that cannot be messed up). > > I'm looking for the exact cause but Is there any caveat when using > > wake_up_interruptible() in an ISR? (I found some drivers use it in > > ISR, some use it in work_struct) > > > > I think there should be no problem using this api in isr context. Yes I saw that. Waking up a process in ISR using wake_up_interruptible works. > > I also read in > > http://www.slideshare.net/rampalliraj/tasklet-vs-work- > queues?from_action=save that tasklet is not allowed to sleep but work is. > (because tasklet is not in process context, but in bottom-half) I don't know > if > I have to move the wake_up_interruptible function to tasklet or work(queue) > or even it matters to the current problem. > > > > Any help would be greatly appreciated. > > What are you trying to achieve. I'm replacing FIFO write, read to DMA access and after triggering the DMA, the process sleeps and gets woken up by DMA completion interrupt. It almost works except a single 32 bit data duplication in the middle of packet data for now. Thanks! Chan _______________________________________________ Kernelnewbies mailing list [email protected] http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
