1. При сбое cma_allocation выводится обратная трассировка сбоя.
например.
[35.360001] страница: bef55be8 count: 58 mapcount: 56 отображение: bc4001dc index: 0x3
[35.366855] флаги: 0x8019040c (ссылка | обновление | архив_1 | mappedtodisk | невидимый | заблокированный)
[35.375173] raw: 8019040c bc4001dc 00000003 00000037 0000003a b9eb1a98 b9eb1a98 00000000
[35.383299] raw: be008c00
[35.385916] страница сброшена из-за: VM_BUG_ON_PAGE (PageLRU (страница) || PageUnevictable (страница))
[35.393995] page-> mem_cgroup: be008c00
[35.397668] ------------ [вырезать здесь] ------------
[35.402281] Ошибка ядра в mm / vmscan.c: 1350!
[35.406458] Внутренняя ошибка: К сожалению, ошибка: 0 [# 1] PREEMPT SMP ARM
[37.778079] Backtrace:
[37.780531] [<80360610>] (shrink_page_list) из [<803617c8>]
(Reclaim_clean_pages_from_list + 0x14c / 0x1a8) * * тысяча двадцать-шесть
[37.790093] r10: b9c6fb88 r9: b9c6fb9c r8: b9c6fb0c r7: 8141e100 r6: 81216588 r5: b9c6fb9c
[37.797914] r4: bf05ffb8
[37.800444] [<8036167c>] (reclaim_clean_pages_from_list) из [<80352b2c>] (alloc_contig_range + 0x17c / 0x4e0)
[37.810178] r10: 00000000 r9: 8121e384 r8: 814790c4 r7: b9c6e000 r6: 0006a000 r5: 00081a00
[37.817999] r4: b9c6fb9c
[37.820529] [<803529b0>] (alloc_contig_range) из [<803bd8c8>] (cma_alloc + 0x154 / 0x5dc)
[37.828527] r10: 00040000 r9: 00017c00 r8: fffffff4 r7: 00017c00 r6: 8147bf24 r5: 00009e00
[37.836347] r4: 00069e00
[37.838878] [<803bd774>] (cma_alloc) из [<80694188>] (dma_alloc_from_contiguous + 0x40 / 0x44)
[37,847310] r10: 00000000 r9: 80607f30 r8: b9c6fd64 r7: 00017c00 r6: 17c00000 r5: 81216588
[37.855131] r4: 00000001
[37.857661] [<80694148>] (dma_alloc_from_contiguous) из [<80218720>] (__alloc_from_contiguous + 0x54 / 0x144)
[37.867396] [<802186cc>] (__alloc_from_contiguous) из [<80218854>] (cma_allocator_alloc + 0x44 / 0x4c)
[37,876523] r10: 00000000 r9: b9c6fe08 r8: 81216588 r7: 00c00000 r6: b94d0140 r5: 80607f30
[37.884343] r4: 00000001
[37.886870] [<80218810>] (cma_allocator_alloc) из [<80217e28>] (__dma_alloc + 0x19c / 0x2e4)
[37,895125] r5: bd2da400 r4: 014000c0
[37.898695] [<80217c8c>] (__dma_alloc) из [<80218000>] (arm_dma_alloc + 0x4c / 0x54)
[37.906258] r10: 00000080 r9: 17c00000 r8: 80c01778 r7: bd2da400 r6: 8148ff6c r5: 00c00000
[37.914079] r4: 00000707
[37.916608] [<80217fb4>] (arm_dma_alloc) из [<80607f30>]
[37.924690] r5: 81490278 r4: 81216588
Вы можете отладить ошибку выделения cma, используя эту обратную трассировку.
Постоянно проверяйте / proc / pagetypeinfo перед размещением и после выделения, он даст вам подсказку, вернулись ли страницы на начальный этап или нет.
Чтобы получить информацию о страницах, перейдите по ссылке ниже: -
ссылка
стабильная ошибка ядра, вот патч ссылка
По ссылке : -
Этот механизм cma налагает следующие недостатки.
Ошибка выделения
CMA может не выделить непрерывную память по следующим причинам.
1-1. Прямой пиннинг
Любой поток ядра может закрепить любые подвижные страницы в течение длительного времени. Если подвижная страница, которую необходимо перенести для непрерывного выделения памяти, уже кем-то закреплена, миграция не может быть завершена. В результате непрерывное выделение может быть неудачным, если страница не будет откреплена в течение длительного времени.
1-2. Непрямой контактЕсли бы подвижная страница зависела от объекта, объект увеличил бы количество ссылок подвижной страницы, чтобы утверждать, что страница безопасна для использования. Если в этом случае имеется подвижная страница, которую необходимо перенести для непрерывного выделения памяти, страница не может быть свободной для непрерывного выделения.
В результате непрерывное выделение может быть неудачным.
Короче говоря, cma не гарантирует успех и быструю задержку непрерывного выделения памяти. И основной причиной является тот факт, что выбранный клиент 2-го класса (подвижные страницы) был недостаточно хорош (трудно перенести / удалить)