фрискейловцы славятся тем что суют мьютексы где надо и ненадо, в вашем случае они явно сунули его там где не должно его быть, похоже код выполняющийся в контексте softirq пытается уйти в состояние ожидания при захвате мьютекса, что для softirq недопустимо
смотрите код модуля dcp - сравните с тем что было в старом ядре. Я сейчас практически не занимаюсь этим, нет времени. Следите за изменениями в git - у них уже 3 бранча для ядра 2.6.35, возможно в последнем уже нет этой ошибки, я там патч специально сделал чтобы можно было быстро адаптировать для нашей платы новые ветки. В принципе если отключить crypto device в ядре проблема уйдет но с ней придет медленная работа wifi с програмным шифрованием.
Итак, промежуточные результаты: кровь пили два мьютекса - один в файле "/.../drivers/crypto/dcp.c" функция "dcp_perform_op" и следом за ней вызывалась функция "dcp_clock", где то там, в глубине тоже был мьютекс. После комментирования пар "lock - unlock" - стало все чистенько, работает без сбоев. Зачем они там нужны, вот вопрос? Посмотрел в старом ядре - все также, а работало. Новые ветви из git пока не скачал, очень медленно тянет почему то...
А вы там посмотрите конфиг - может dcp не включено было :) Очевидно что это критическая область и там нужен атомарный доступ, но они не учли что этот код может быть вызван в контексте softirq. Лучше замените соостветствующие мьютексы спин-блокировками, думаю там наиболее подходящий вариант
spin_lock_bh()/spin_unlock_bh()
он кроме блокировки отключает softirq к тому же может быть выван в любом контексте - в отличии от мьютексов на спин-блокировке поток не засыпает а находится в состоянии активного ожидания.
Не, dcp включено.
Почитав про мьютексы в прерываниях, я именно так и решил сделать, как вы посоветовали - использовать спин-локи, уже начал реализовывать, посмотрим что получится.
Ядро с git я так и не смог скачать(:
30.01.2011 23:50 
30.01.2011 23:55
