soft lockup on omap3 (dm3730)

jean-philippe francois jp.francois at cynove.com
Thu Mar 8 03:26:19 EST 2012


Le 7 mars 2012 17:37, Russell King - ARM Linux
<linux at arm.linux.org.uk> a écrit :
> On Wed, Mar 07, 2012 at 05:16:35PM +0100, jean-philippe francois wrote:
>> Is the backtrace pointing to this offset because soft_lockup can only
>> detect lockups at the output of critical sections ?
>
> Correct - soft lockups on ARM can only be detected when hardware
> interrupts are enabled.  Any region which masks hard interrupts
> effectively prevents the soft lockup detector firing should
> execution get stuck inside such a region.

But then, how is the soft lockup detector able to break this hard lockup ?
 Without soft / hard lockup detection configured, the loop
runs forever. Anyway, Thanks for the suggestion, I will try to printk  my way
out of this problem.

>
>> I don't know how to progress on this problem, any hint is welcome.
>>
>> int omap3isp_video_queue_streamon(struct isp_video_queue *queue)
>> {
>>        struct isp_video_buffer *buf;
>>        unsigned long flags;
>>
>>        mutex_lock(&queue->lock);
>>
>>        if (queue->streaming)
>>                goto done;
>>
>>        queue->streaming = 1;
>>
>>        spin_lock_irqsave(&queue->irqlock, flags);
>>        list_for_each_entry(buf, &queue->queue, stream) {
>>                printk(KERN_INFO "inside list_for_each\n");
>>                queue->ops->buffer_queue(buf);
>>        }
>>        spin_unlock_irqrestore(&queue->irqlock, flags);  <---- soft lockup
>> says this is the culprit.
>
> My guess is something inside buffer_queue() is responsible.  If things
> get stuck for quite a period of time, the only thing I can suggest is
> using printk() based debugging to try and find where things get stuck.
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel



More information about the linux-arm-kernel mailing list