On 8 September 2010 20:46, Mulyadi Santosa <mulyadi.santosa@xxxxxxxxx> wrote: > After reading your attached backware (just briefly, not too deep), I > concluded that either it's something wrong with tree of task pointer > traversal....or doing lock with wrong assumption. > > NB: ehm, saw raw_spin_lock in this patch series, shouldn't it be > spinlock_irqsave? I thought exactly the same. But, the locking they did is in a hrtimer callback, which executes in hard irq context. > > PS: Glad you find the culprit. You might retry with a kernel image > that's fully compiled with -g or -ggdb but without -O2 or -Os. Should > give you better backtrace (lesser "value is optimized out"). > One of the authors said he'll send us a new patchset tomorrow. We'll try running it and seeing. :-) Thanks for the tip! I didn't know what "value is optimized out" meant! Regards, -- Vimal -- To unsubscribe from this list: send an email with "unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx Please read the FAQ at http://kernelnewbies.org/FAQ
