-------------------------------------------------- From: "Peter Teoh" <htmldeveloper@xxxxxxxxx> Sent: Monday, May 19, 2008 12:08 AM To: "Oliver Urbann" <ciVic@xxxxxx> Cc: <kernelnewbies@xxxxxxxxxxxx> Subject: Re: Bug in V4L2 driver by AMD?
u are right, since v4l_qbfr() is holding on to the iolock, then anything instructions inside this block should not reuse the lock again. it will deadlock. unless the iolock is a different variable....but from above..passed by dp, it should be the same variable. but I was wondering why preempt_schedule_irq() CAN DETECT deadlock... Call Trace: [<c034462d>] preempt_schedule_irq+0x3b/0x53 [<d08d9f39>] v4l_capt_unstall+0x15/0x81 [lxv4l2] [<d08da00b>] v4l_qbfr+0x66/0x75 [lxv4l2] [<d08daad7>] v4l_stream_copy+0x279/0x2b4 [lxv4l2] the reason is because the same lock is logically possible to be detected locked concurrently in two different parts of the kernel at the same time, essentially one will lock, and one will continue execution. but if the lock is already held by the same CPU, and attempted reuse of the same CPU will result in deadlock, if IRQ is disabled. And execution should be on the same CPU, right? (since there is no rescheduling done via schedule() or the like) Correct? In our case it is, so how can the kernel detect this as verified by the debug output????? Please share....
unfortunately we do not have access to the kernel source at the moment, so i do not know what is in line 682 in rtmutex.c. It seems that preempt_schedule_irq() calls rt_spin_lock_slowlock(), this function checks the spinlocks and throws that error. I asked the manufactor of our system for the sources, maybe they can help.
Oliver Urbann -- To unsubscribe from this list: send an email with "unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx Please read the FAQ at http://kernelnewbies.org/FAQ
