Re: IRQ Tracing Problem in Linux 2.6.28 Kernel

[Jeffrey Cao <jcao.linux@gmail.com>]

On 2009-04-13, Sol Kavy <skavy@ubicom.com> wrote:
> The following back trace represents a deadlock in Ubicom's SMP port of 2.6.28 kernel.   I am sure that we are doing something unexpected.  I would appreciate the community's help in understanding what is going wrong.
>
> Thanks in advance for any pointers,
>
> Sol Kavy
>
> Problem:
> Ubicom's initial port does not use GENERIC_CLOCKEVENTS.  Instead it uses a periodic timer based on HZ.  The periodic timer calls do_timer() on each tick.
>
> From the arch directory perspective, we are required to hold the xtime_lock before calling do_timer().  The lock is indeed help by cpu 3 as evidenced in the output below.
>
> The call to get_jiffies_64() at the top of the backtrace is attempting to read the jiffies in a reliable fashion.  The caller is required to wait for the xtime_lock not to be held.  Clearly, since we are in  a path that is holding the xtime_lock, this will never make forward progress.
For x86 arch, function get_jiffies_64() seems not to wait the xtime_lock,
but to do something related to CPU ordering:
get_jiffies_64()
|->read_seqbegin()
   |->smp_rmb()
      |->alternative("lock; addl $0,0(%%esp)", "lfence", X86_FEATURE_XMM2)
I'm not sure if this is the same as to accquire xtime_lock spinlock. Maybe this
is a point you need check.


Jeffrey

--
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs