Re: ubiformat & linux 3.0.14-rt

[Artem Bityutskiy <dedekind1@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 1669 bytes --]

On Mon, 2012-01-16 at 13:59 +0100, Tim Sander wrote:
> Hi Artem
> 
> Am Montag, 16. Januar 2012 schrieb Artem Bityutskiy:
> > On Mon, 2012-01-16 at 11:43 +0100, Tim Sander wrote:
> > > > http://git.infradead.org/ubifs-2.6.git/commit/1f5d78dc4823a85f112aaa2d0
> > > > f176 24f8c2a6c52
> > > > http://git.infradead.org/ubifs-2.6.git/commit/d34315da9146253351146140e
> > > > a4b 277193ee5e5f
> > > 
> > > Do you think it is worthwhile checking the ubifs 3.0 backport with the
> > > above two cherry-picked?
> > 
> > I've pushed them to the ubifs-v3.0 back-port tree as well. But I think
> > they are useless - sorry, I was confused.
> Ok i was wondering that logging was causing this cind of behavoir...
> 
> > Also, if you say this happens when you run ubiformat - this is something
> > about your flash driver. Do you use NOR or NAND? Can you detect which
> > interrupt takes too much time? If the theory is that this is your flash
> > driver interrupt - can you verify it by injecting some instrumentation
> > to the interrupt handler?
> This is a arm i.mx35 (pcm43) platform using the nor and nand driver. The 
> mxc_nand driver is loaded later which seems to be around the same time this 
> message:
> "sched: RT throttling activated" comes up and the ubi on the nand gets 
> attached. I will see what if i can dig s.t. up with the instrumentation and 
> will report back.

My theory is that this is related to the NOR driver then. UBI does not
use interrups. UBIFS uses hrtimer so it does have some code which may
run in interrupt context, but all it does - it wakes up a thread and
finishes.

-- 
Best Regards,
Artem Bityutskiy

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]