On Thu, Dec 20, 2018 at 2:28 PM Richard Weinberger <richard@xxxxxx> wrote: > > Am Donnerstag, 20. Dezember 2018, 15:19:24 CET schrieb Martin Townsend: > > The hung task timeout is the default 2 minutes and it's setup to panic > > so I don't know if it recovers. I'll ask them to try a longer value or > > disable the panic and see if it recovers. > > Yes, please. Done. > > > I checked and LOCKDEP=y and the held locks are in the original trace. > > Are there particular locking checks you would like? Currently its > > setup like this: > > │ │ [*] RT Mutex debugging, deadlock detection > > │ │ -*- Spinlock and rw-lock debugging: basic checks > > │ │ -*- Mutex debugging: basic checks > > │ │ [ ] Wait/wound mutex debugging: Slowpath testing > > │ │ [*] Lock debugging: detect incorrect freeing of live locks > > │ │ [ ] Lock debugging: prove locking correctness > > Hmm, this should be okay. > So it does not look like a traditional deadlock. > > Basically we need to figure why and where exactly cma_alloc() hangs. > And of course also we need to know if it is really cma_alloc(). > > Can you please dig into that? Will do, would CMA_DEBUG help or would it produce too much log information? > > Thanks, > //richard > > ______________________________________________________ Linux MTD discussion mailing list http://lists.infradead.org/mailman/listinfo/linux-mtd/