Как решить "BUG: планирование пока атомное: swapper / 0x00000103 / 0, CPU # 0"? в TSC2007 Драйвер? - PullRequest
21 голосов
/ 21 августа 2010

Я нашел драйвер tsc2007 и изменил его в соответствии с нашими потребностями. Наша фирма производит собственную плату TI DM365. В этой плате мы использовали TSC2007 и подключили вывод PENIRQ к GPIO0 DM365. Это замечено на водителе. когда я касаюсь сенсорного экрана, курсор двигается, но в то же время я получаю

BUG: scheduling while atomic: swapper /0x00000103/0, CPU#0

предупреждение и встраиваемый Linux падает. есть 2 файла, которые я изменил и загрузил в http://www.muhendislikhizmeti.com/touchscreen.zip один с таймером другой нет. это дает эту ошибку в любом случае.

Я нашел решение в сети, которое мне нужно, чтобы использовать рабочую очередь и звонить с использованием schedule_work () API. но они размыты для меня сейчас. Кто-нибудь есть идеи, как решить эту проблему, и может дать мне несколько советов, с чего начать использовать рабочую очередь.

Ответы [ 4 ]

33 голосов
/ 23 августа 2010

«Планирование в атомарном режиме» означает, что вы пытались спать где-то, что не следует делать - например, в критической секции, защищенной спин-блокировкой, или в обработчике прерываний.

Типичные примеры того, что может спать.mutex_lock(), kmalloc(..., GFP_KERNEL), get_user() и put_user().

13 голосов
/ 02 декабря 2011

Точно так, как сказано в 1-м ответе, планирование в то время как атомарное происходит, когда планировщик запутывается и, следовательно, не может работать должным образом, и это потому, что планировщик попытался выполнить «schedule ()» в разделе, который содержит планируемое код внутрине подлежит планированию.

Например, использование снов внутри секции, защищенной спин-блокировкой.Попытка использовать другую блокировку (семафоры, мьютексы ...) внутри кода, защищенного спин-блокировкой, также может нарушить работу планировщика.Кроме того, использование спин-блокировки в пользовательском пространстве может заставить планировщик вести себя как таковой.Надеюсь, это поможет

4 голосов
/ 15 августа 2015

Для кого-то еще с подобной ошибкой - у меня была эта проблема, потому что у меня была функция, вызванная из атомарного контекста, которая использовала kzalloc(..., GFP_KERN), когда она должна была использовать GFP_NOWAIT или GFP_ATOMIC.

Это всего лишь один пример функции, которая спит, когда вы не хотите этого делать, и к этому нужно относиться с осторожностью при программировании ядра.

Надеюсь, что это пригодится кому-то еще!

2 голосов
/ 14 февраля 2014

Спасибо за первые два ответа, в моем случае этого было достаточно, чтобы отключить приоритет:

preempt_disable();

// Your code with locks and schedule()

preempt_enable();
Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...