Re: hung task detected in ubifs

[Richard Weinberger <richard@xxxxxx>]

Am Donnerstag, 20. Dezember 2018, 18:03:46 CET schrieb Martin Townsend:
> I'm starting to think that MTD/UBI is a victim here.  I tried to
> reproduce what the client was seeing with no luck then on one boot I
> triggered a lockup really early in the boot:

Yes, this can be.
Maybe your CMA setup is odd or some other bug triggers.
Are other parts heavily using CMA? (hint: GPU stuff).
Maybe a different cma= setting helps.
See:
Documentation/admin-guide/kernel-parameters.txt

> Showing all locks held in the system:
> 5 locks held by systemd/1:
>  #0:  (&mm->mmap_sem){......}, at: [<80113ef0>] do_page_fault+0xb8/0x350
>  #1:  (&le->mutex){......}, at: [<80568150>] ubi_eba_read_leb+0x34/0x438
>  #2:  (of_dma_lock){......}, at: [<804ab890>]
> of_dma_request_slave_channel+0x140/0x228
>  #3:  (dma_list_mutex){......}, at: [<804a9d3c>] __dma_request_channel+0x24/0x8c
>  #4:  (cma_mutex){......}, at: [<80246814>] cma_alloc+0xc8/0x29c
> 2 locks held by khungtaskd/14:
>  #0:  (rcu_read_lock){......}, at: [<801b7920>] watchdog+0xdc/0x4b0
>  #1:  (tasklist_lock){......}, at: [<80162208>] debug_show_all_locks+0x38/0x1ac
> 
> This does point to some lockup in the CMA allocator when migrating
> pages for a contiguous allocation.  Out of interest do you know why
> do_DataAbort ends up calling filemap_fault and hence ending up in the
> ubifs layer?

Well, if you open and mmap a file, access to the memory will trigger a page
fault. This page fault is resolved by reading the pages from disk into memory.

Thanks,
//richard




______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/