What instead tty_locked()?

Здравствуйте!

Вопрос не связан с конкретным дистрибутивом, а только с ядром.
Есть плата последовательных портов от Advantech, MIC-3612.
Драйвер для Linux нормально работает с ядром 3.0, а с 3.2 уже
не компилируется. В ядре в include/linux/serial_core.h в структуре
uart_port уменьшили количество типов - это не проблема, в структуре
uart_state удалили элемент
struct tasklet_struct *tlet;
а в драйвере для tlet трижды вызывается
tasklet_schedule(tlet);
это я закомментировал, а главная трудность - в tty.h теперь нет функции
tty_locked(), а драйвер её существенно использует. Без неё или
с попытками её заменить чем-то другим драйвер не работает, в лучшем случае
срабаттывает один раз.

В ядре 3.0 в include/linux/tty.h есть определения:

extern struct task_struct *__big_tty_mutex_owner;
#define tty_locked() (current == __big_tty_mutex_owner)

а в ядре 3.2 их нет и я пока не понял, чем заменить tty_locked().

Я оставил запрос на сайте Advantech, но, м.б., кто-нибудь уже знает решение?

Пётр.

во первых, ссылку на исходники в студию, чтобы точно знать о чём говори...
во-вторых, если это то о чём я думаю, то сравни изменения в ядре в drivers/tty/serial/serial_core.c , аналогично измени свои...
и проверь, может ядерные дрова в новой версии нормально работают с железякой и ей свой драйвер уже не нужен...

Fat-Zer написал:

во первых, ссылку на исходники в студию, чтобы точно знать о чём говори...
во-вторых, если это то о чём я думаю, то сравни изменения в ядре в drivers/tty/serial/serial_core.c , аналогично измени свои...
и проверь, может ядерные дрова в новой версии нормально работают с железякой и ей свой драйвер уже не нужен...

Нет, без драйвера от производителя даже не создаются устройства - /dev/ttyAPx.
Я и попытался изменить свои - закомментировал места, где используются UPIO_DWABP и UPIO_DWAPB32,
вызовы tasklet_schedule(tlet), а без

BUG_ON(!tty_locked());

драйвер работать не хочет, попытки заменить его на что-то другое пока к успеху не привели.
Мне посоветовали посмотреть kernel api.
Вот страница с драйвером для Linux:
http://support.advantech.com.tw/support/DownloadSRDetail_New.aspx?SR_ID=1-1W8FZ5&Doc_Source=Download

Пётр.

"Peter" написал:

Я и попытался изменить свои - закомментировал места, где используются UPIO_DWABP и UPIO_DWAPB32,

похоже эти константы и правда ни где не используются, но я бы поосторожнее с этим был: объявил бы их у себя...

"Peter" написал:

вызовы tasklet_schedule(tlet)

вот это я не понял, зачем....

"Peter" написал:

а безBUG_ON(!tty_locked());драйвер работать не хочет, попытки заменить его на что-то другое пока к успеху не привели.

это обычный assert, в этом месте модуль может только упасть... их удалять безопасно...

Fat-Zer написал:

[quote="Peter"]Я и попытался изменить свои - закомментировал места, где используются UPIO_DWABP и UPIO_DWAPB32,

похоже эти константы и правда ни где не используются, но я бы поосторожнее с этим был: объявил бы их у себя...
[/quote]
Их просто нет в include/linux/serial_core.h в ядре 3.2, поэтому их надо закомментировать в драйвере.

"Peter" написал:

вызовы tasklet_schedule(tlet)

вот это я не понял, зачем....

Так я же сказал, что в ядре 3.2 из структуры uart_state удалили элемент с tlet,
поэтому и вызов для него не работает.

"Peter" написал:

а безBUG_ON(!tty_locked());драйвер работать не хочет, попытки заменить его на что-то другое пока к успеху не привели.

это обычный assert, в этом месте модуль может только упасть... их удалять безопасно...

Так это было первое, что я сделал - закомментировал этот вызов, но с этими изменениями драйвер
не работает - 1-я команда через порт проходит, но вся программа после этого зависает.
Интефейс зависает, во всяком случае.

Я делал поиск в Интернете по tty_locked(), действительно, его просто удаляют.
Благодарю за интерес к моей проблеме.

Пётр.

"Peter" написал:

Так это было первое, что я сделал - закомментировал этот вызов, но с этими изменениями драйвер не работает - 1-я команда через порт проходит, но вся программа после этого зависает.Интефейс зависает, во всяком случае.

это на 3.0 экспериментировал? а с BUG_ON'ом в dmesg'е ругани нет?

Fat-Zer написал:

[quote="Peter"]Так это было первое, что я сделал - закомментировал этот вызов, но с этими изменениями драйвер не работает - 1-я команда через порт проходит, но вся программа после этого зависает.Интефейс зависает, во всяком случае.

это на 3.0 экспериментировал? а с BUG_ON'ом в dmesg'е ругани нет?[/quote]
Так я же говорил, что с ядром 3.0 драйвер работает. В его тексте предусмотрена ветка 3.x.

Пётр.

"Peter" написал:

Так я же говорил, что с ядром 3.0 драйвер работает. В его тексте предусмотрена ветка 3.x.

смотри: на 3.2 хрен знат почему не работает...
если с закомментированным BUG_ON'ом он не будет работать и на 3.0, то assert'ы каким-то магическим образом всё заставляют работать, иначе дело в других изменениях и tty_locked можно более не говорить....

Fat-Zer написал:

[quote="Peter"]Так я же говорил, что с ядром 3.0 драйвер работает. В его тексте предусмотрена ветка 3.x.

смотри: на 3.2 хрен знат почему не работает...
если с закомментированным BUG_ON'ом он не будет работать и на 3.0, то assert'ы каким-то магическим образом всё заставляют работать, иначе дело в других изменениях и tty_locked можно более не говорить....[/quote]
Вполне возможно, но не зря же автор вставил этот оператор.
Сейчас даже один раз не срабатывает, а в /var/log/kernel.log видно, что происходит крах,
там дамп регистров.

Пётр.

"Peter" написал:

Вполне возможно, но не зря же автор вставил этот оператор.

это же assert. автор вставил его только для отладки или, если компилятор его не выкинул, для экстренного завершения... в редких случаях может маскировать другие ошибки.

Fat-Zer написал:

[quote="Peter"]Вполне возможно, но не зря же автор вставил этот оператор.

это же assert. автор вставил его только для отладки или, если компилятор его не выкинул, для экстренного завершения... в редких случаях может маскировать другие ошибки.[/quote]
Да, я уже и сам думаю, что причина где-то глубже, тем более, что я не помню,
чтобы он срабатывал с предидущими ядрами. Возможно, он также играет роль задержки.
Порт открывается, устройства в /dev создаются, но вчера я посмотрел /var/log/kern.log
и оказалось, что что при попытке обращения к порту там оказывается дамп регистров,
какие ещё сообщения, не помню.

Пётр.

Если просто закомментировать BUG_ON(!tty_locked());
а tasklet_schedule(tlet) заменить на schedule(), он вызывается и в в другом месте драйвера,
то после попытки обращения к порту в /var/log.kern.log возникают сообщения

BUG: scheduling while atomic: server/3117/0x00010000

server - это имя компьютера, 3117 - это pid, либо 3179 во 2-й раз, за ним другие
сообщения и дамп регистров, после 2-й команды программа зависает.
В самом драйвере atomic не используются.

Пётр.

"Peter" написал:

а tasklet_schedule(tlet) заменить на schedule(), он вызывается и в в другом месте драйвера,

чисто ради исследования человеческой психологии: чем такая замена обусловлена?
на tty_wakeup(state->port.tty) пробовал заменять, как это в ядре сделано?

Fat-Zer написал:

[quote="Peter"]а tasklet_schedule(tlet) заменить на schedule(), он вызывается и в в другом месте драйвера,

чисто ради исследования человеческой психологии: чем такая замена обусловлена?
на tty_wakeup(state->port.tty) пробовал заменять, как это в ядре сделано?[/quote]
Я подумал, что, если там вызывается tasklet_schedule(tlet), то это зачем-то надо, подпрограмма с этим
вызовом имеет в названии wake_up, а т.к. из uart_state удалили tlet, то я и заменил на просто schedule().
Вроде бы я сделал это не сразу же, а в ходе экспериментов.

Пётр.

попробуй вот этот патч:
http://bpaste.net/show/71776/

попытался бекпортировать максимум изменений в 8250.c и serial_device.c

Очень благодарен за интерес, попробую.
Я пробовал также просто закооментировать вызов tasklet_schedule(tlet),
но так программа зависает срзу же при 1-м обращении к порту.

Пётр.

Fat-Zer написал:

попробуй вот этот патч:
http://bpaste.net/show/71776/

попытался бекпортировать максимум изменений в 8250.c и serial_device.c

Очень благодарен за патч! Работает почти нормально, команды проходят и исполняются.
Скажи, пожалуйста, ты сам строил новые 8250.c и serial_core.c?
Если да, то на основании каких документов, т.е. информации?
В используемый дистрибутив должен был входить пакет linux-source, с файлом Changelog
в /usr/share/doc.linux-source/, но в реальности пакета нет, нет и libqt4-multimedia,
хотя должен был быть. Программа на Qt.

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

Пётр.

"Peter" написал:

Скажи, пожалуйста, ты сам строил новые 8250.c и serial_core.c?
Если да, то на основании каких документов, т.е. информации?

я же сразу написал, что делать:

"Fat-Zer" написал:

во-вторых, если это то о чём я думаю, то сравни изменения в ядре в drivers/tty/serial/serial_core.c , аналогично измени свои...

так и поступил: положил перед собой в gvimdiff'е версию от производителя, из 3.0 и из 3.2. если в ядре изменений нет, то оставлял как в драйвере. если старая версия совпадает с вендорной, то заменял новой, если все три различные, то /dev/brain в помощь.

может я и слишком многое там так исправил...

"Peter" написал:

В используемый дистрибутив должен был входить пакет linux-source, с файлом Changelogв /usr/share/doc.linux-source/, но в реальности пакета нет, нет и libqt4-multimedia,хотя должен был быть. Программа на Qt.

не распарсил.

"Peter" написал:

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

а можно ли в исходниках этой программки посмотреть, при каком условии эта программка выдаёт такую панельку?
если исходников нет, то можно разницу strace'ов раскурить попробовать на старой и новой версиях... или через какую-либо другую отладку...

Дело в том, что у меня в этом дистрибутиве нет исходного кода ядра, если бы был,
я, конечно, сравнил бы его с кодом ядра 3.0.

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

Пётр.

"Peter" написал:

Дело в том, что у меня в этом дистрибутиве нет исходного кода ядра, если бы был,я, конечно, сравнил бы его с кодом ядра 3.0.

на kernel.org то не забанили же...

"Peter" написал:

но к логике работы это отношения не имеет.

скорее тут ошибка не в логике программы, а в драйвере... хорошо было бы знать на каком системном вызове и какую ошибку он возвращает в старом и новом варианте...