Как решить "BUG: планирование при атомарном: swapper/0x00000103/0, CPU # 0"? в драйвере TSC2007?

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

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

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

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

Ответ 1

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

Обычными примерами вещей, которые могут спать, являются mutex_lock(), kmalloc(..., GFP_KERNEL), get_user() и put_user().

Ответ 2

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

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

Ответ 3

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

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

Надеюсь, это полезно кому-то еще!

Ответ 4

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

preempt_disable();

// Your code with locks and schedule()

preempt_enable();