> Yes that's correct. However I would recommend you look into how long the > DMA bursts are before moving to a mutex. In addition softirqs are not > internally locked and need to be implemented by the user for your > information. > Hope this Helps, > Nick
Ok, thanks, I know the DMA burst can be quite long so I'll try sticking to mutex. I checked softirq and tasklet are in interrupt context, so I'll move the FIFO read stuff to workqueue. Best regards, Chan 보낸 사람 : "nick" <[email protected]> 보낸 날짜 : 2015-06-05 22:04:21 ( +09:00 ) 받는 사람 : 김찬 <[email protected]>, [email protected] <[email protected]> 참조 : 제목 : Re: I want to sleep while holding a mutex On 2015-06-05 09:01 AM, Chan Kim wrote: > >> While here is your issue your trying to sleep in an atomic/ non sleep able >> context of your driver. >> My best guess is in interrupt context but it could be somewhere else related >> to your hardware. >> Nick > > For your information, I'm using smsc911x driver in linux ver 3.3. > The FIFO burst write function is called inside ndo->start_xmit function (net > device operation, I think it's process context) > and FIFO burst read function is called from NAPI poll function. (it's in > softirq context, is this a problem?). > I remember somewhere reading the softirq is like interrupt context except the > difference that interrupt is enabled during softirq processing. > If softirq is where you should not sleep (in my case for DMA), then, I'll > have to move it to workqueue or tasklet. > Do you think my understanding sounds more like it? > Chan > Yes that's correct. However I would recommend you look into how long the DMA bursts are before moving to a mutex. In addition softirqs are not internally locked and need to be implemented by the user for your information. Hope this Helps, Nick > > > 보낸 사람 : "nick" > 보낸 날짜 : 2015-06-05 21:48:18 ( +09:00 ) > 받는 사람 : 김찬 , [email protected] > 참조 : > 제목 : Re: I want to sleep while holding a mutex > > > > On 2015-06-05 08:45 AM, Chan Kim wrote: >> >>>>> Are you trying to use the mutex during a interrupt handler as you >>>>> can't you need something atomic or not able to sleep like a spinlock. >>>>> Nick >>>> >>>> I use mutex during FIFO burst write or burst read. I don't want other >>> processes to mess up the FIFO access. >>>> spinlock is not for long interval I understand. >>>> Chan >>>> >>> That's during interrupt context. What you need to do is offload the data >>> into >>> main memory during interrupt context and lock with a spinlock. Afterwards >>> you can use a mutex around the main work function called after the >>> interrupt. >>> Nick >> >> >> I believe I lock_mutex and unlock_mutex are called in the process context. >> Both for transmission and for reception (rx is from softirq, it's ok.). It's >> only that the process is woken up by the interrupt routine. (ISR calls >> wake_up_interruptible). ISR doesn't lock or unlock any mutex. >> >> Chan >> > While here is your issue your trying to sleep in an atomic/ non sleep able > context of your driver. > My best guess is in interrupt context but it could be somewhere else related > to your hardware. > Nick >> >> >> 보낸 사람 : "nick" >> 보낸 날짜 : 2015-06-05 21:40:20 ( +09:00 ) >> 받는 사람 : 김찬 , [email protected] >> 참조 : >> 제목 : Re: I want to sleep while holding a mutex >> >> >> >> On 2015-06-05 08:37 AM, 김찬 wrote: >>> >>>> Are you trying to use the mutex during a interrupt handler as you can't you >>>> need something atomic or not able to sleep like a spinlock. >>>> Nick >>> >>> I use mutex during FIFO burst write or burst read. I don't want other >>> processes to mess up the FIFO access. >>> spinlock is not for long interval I understand. >>> Chan >>> >> That's during interrupt context. What you need to do is offload the data >> into main memory during interrupt >> context and lock with a spinlock. Afterwards you can use a mutex around the >> main work function called >> after the interrupt. >> Nick >>> ________________________________ >>> 보낸 사람 : "nick" >>> 보낸 날짜 : 2015-06-05 21:34:25 ( +09:00 ) >>> 받는 사람 : 김찬 , [email protected] >>> 참조 : >>> 제목 : Re: I want to sleep while holding a mutex >>> >>> >>> >>> On 2015-06-05 08:30 AM, Chan Kim wrote: >>>> Hello, >>>> I need to write to and read from a Ethernet chip's FIFO and for that I >>>> want to use DMA controller. So I modified an existing driver and made the >>>> process to sleep using wait_event_interruptible after triggering DMA >>>> transfer and made it woken up by ISR using wake_up_interruptible. My >>>> problem is that the original driver was using spinlock to protect the FIFO >>>> access. But as all know, while holding spinlock, I should not sleep. So I >>>> tried replacing spinlock with mutex. (Because, I might sleep while >>>> acquiring the mutex, and after getting the mutex, I'll sleep again after >>>> DMA trigger. I get woken up by the ISR, and I'll release the mutex. No >>>> problem! I thought. ) But I still get this 'scheduling while atomic BUG'. >>>> The question is : I need to go to sleep until DMA completion while holding >>>> a lock (for FIFO read and write). Isn't it ok to sleep while holding a >>>> mutex? >>>> Best regards, >>>> Chan Kim >>>> _______________________________________________ >>>> Kernelnewbies mailing list >>>> [email protected] >>>> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies >>>> >>> Are you trying to use the mutex during a interrupt handler as you can't you >>> need something >>> atomic or not able to sleep like a spinlock. >>> Nick _______________________________________________ Kernelnewbies mailing list [email protected] http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
