Народ. Кто-то делал? Не могу понять. В двух проводах запутался. Из альтеровской корки идут два провода. Я устанавливаю первый в 1, получаю ACK по второму. Устанавливаю первый в 0, получаю ACK по второму. Система реагирует в обоих случаях одинакого. Вешается. После генерации прерывания. Что я еще не сделал?

Что-то не понял... что за "провода"?
Это Вы про INTA# и INTB#?
Если 2 прерывания - то у Ваc девайс должен быть "multifunction".
Это так?

В корке квартуса есть app_int_sts, который подключен к виртуальному INTA, и app_int_ack , который поднимается на такт когда сингнал доходит до INTA. Я поднимаю app_int_sts (тоесть делаю Assert_INTA) потом жду единицы на app_int_ack, и опускаю app_int_sts (делаю Deassert_INTA) итог - жесткий клин системы при попытки что-то прочитать из карточки.

К сожалению - не помогу. Думал вопрос Ваш касается другого.
С Альтеровской дела не имел. Делал на Xilinx.

У меня какая-то лажа с PCIe. Чтобы прерывание сгенерировать что-то еще нужно?

Стабильно генерит 1 прерывание и клин. Чует мое сердце что еще что-то нужно сделать. PC должен же как-то сказать плате, что обработка прерывания уже началась.

Это обычно делается в пользовательской части. Например, считывается регистр состояния, или данные, что автоматически приводит к сбросу запроса на прерывание.
Ну или нужен бит запрета прерывания, который Вы будете устанавливать сразу по входу в обработчик.

Общий алгоритм такой - вход в прерывание - выясняете Ваше - не Ваше, если нет - отдаете управление, если Ваше, то сбрасываете запрос как можно быстрей, делаете необходимые действия, выходите из обработчика.

Алгоритм я знаю. Я не могу понять почему у меня железка виснет после первого прерывания. Причем MSI-x прерывания работают совершенно нормально. Хотя сейчас попробую вставить чтение из железки, может войдя в обработчик я обязан хоть что-то из железки прочитать. Хотя бред.

А запрос - то сбрасывается ? Вы обязаны сбросить запрос по входу, а уж чтением или каким другим действием - не важно.
Еще бывают зависоны, если нераспознано, что прерывание от чужого устройства, и вместо отдачи управления - попытка что-то делать, которая, естетственно, не сбрасывает и не может сбросить чужой запрос.

Я сразу сбрасываю запрос. Поднимаю INTA, дожидаюсь ACK и опускаю INTA. Или я должен опустить INTA из обработчика прерывания? Тоесть Deassert_INTA должен случиться уже из обработчика? В общем сейчас попробую.

Да.

Не пашет. По событию поднимаю INTA, в обработчике прерывания делаю запись по адресу, чем сбрасываю INTA.

Осциллографом проверяли, что INTA падает ?

Обработчик возвращает TRUE ? (если винда, конечно).

У меня PCIe, INTA виртуальное. Проверял SignalTapом. Падает.


У меня линух, обработчик, точно такой же как и для прерываний MSI, которые бегают. IRQ_HANDLED возвращаю.

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

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


Не похоже. Иначе бы у меня комп крашился из за переполнения стека или еще чего. У меня в обработчике стоит счетчик, который я могу посмотреть. Раньше он показывал 1, а теперь показывает два. Обмен работает. И запись и чтение и DMA из карточки в ОЗУ компа и обратно, и MSI-X прерывания работает. Клины у меня с поддержкой легаси прерываний. Но после легаси прерывания затыкается.

А в цепочке обработчиков ничего больше не сидит ?
Так клинит обычно, когда "залипает" запрос прерывания. В остальных случаях он бы у Вас вывалился и больше не вернулся в обработчик - машина бы не повисла. При зацикливании в обработчике стек не переполняется - в обработчике прерывания запрещены, после выхода из обработчика стек восстанавливается, и обработчик вызывается снова с корректными параметрами. Помахать чем-нибудь из обработчика можете ?

Висит что-то. Но какая разница. У меня весь обмен по PCIe после этого пдает. Обычно так бывает если с PCIe какие-то не корректные данные приходят.

Вот пример из примера Альтеры.

deassert request when Interrupt ASSERTION is ack-ed Они сразу же опускают INTA, как только из корки приходит ACK. Но после этого корка тупо помирает и компьютер зависает. На контр-альт-дел не реагирует, но перезагружается, сразу как только я через JTAG начинаю новую прошивку лить в Альтеру. Если делать app_int_req <= 1'b0; уже из обработчика прерывания, когда уже вошли в обработчик, и сбросили вектор, то тоже не работает. Я уже все варианты перепробовал.

Из обработчика прерывания можно каким нибудь проводом дергать ? Надо понять, встает шина или "залип" запрос на обработку прерывания. Иначе дальше не двинетесь. Нужно что-то поднять и опустить во время нахождения в обработчике, чтобы было видно зацикливание.

А у Линукса что-ли нет ядерного отладчика?
Быть не может.

Встает шина. Если после этого попробовать что-то прочитать из карточки, то в карточку не приходит запросов вообще, и как результат читаются одни FF. И сразу после чтения жесткий зависон всего.

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


У меня явно не в отладчике проблема. У меня явно что-то не то по шине твориться. У меня совершенно нормально бегают MSI-X прерывания. У меня запись/чтение нормально работают. У меня только непонятно с легаси. По моему я что-то упустил. Хотя там всего два вывода. Я уже все варианты перепробовал.

"жесткий зависон всего" - это как? Это ведь экспресс?
Карты в других слотах работают или тоже зависают?

Комп вообще ни на что не реагирует, пока карточку через jtag не остановиш.

У меня один сплот для видеокарточки, в него мое и воткнуто.

А после остановки карточки оживает? А если просто карточку выдернуть?
Похоже что карточка бомбардирует root complex какими-то запросами, и случается DOS. Что мне кажется странным. Наверное, такими запросами должны быть неснятые прерывания, которые процессор непрерывно обрабатывает. Как это может случиться под Линуксом - не скажу.



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

Может быть. Сигнал что INTA случилось, имеет более высокий приоритет. НО! У меня всего две линии. Одну я могу либо вверх либо вниз. А другой - просто ACK. У меня нет других возможностей на INTА влиять.


Все не пашет. Ни клава ни мышка. И сама карточка не пашет после первого прерывания. Я явно что-то делаю не так.

Ну так в случае DOS клава с мышкой работать и не должны - им не хватит времени. Да и обработка мышки скорее всего сделана не в самом обрабортчике мышиного прерывания.

Вот обработчик.
В аттаче картинка.
app_int_sts - INTA
app_int_ack - ACK для INTA.
vector_pending - кол-векторов которые требуют обработки,
..clear_req - шина по которой вектора сбрасываются.
dma_tx_reg_addr - адресс внутри карточки, dataA - имеет адресс 0х10000 запись в этот регистр поднимает clear_req, и запрос на обработку прерывания сбрасывается, INTA опускается.

Видно что одно прерывание проходит нормально, а когда происходит второе прерывание, обработчик в переывание входит, но сбросить запрос на прерывание уже не получается, потому что карточка стоит. Потом, как я понимаю, когда заканчиваются TAGи, зависает и комп. Если, через JTAG начать заливать новую прошивку в ПЛИС, комп уходит в мягкий ресет.

Спасибо. Вообще-то Верилог в Альтере с драйвером под Линукс - тройное "не моё"

В экспрессе при обработке legacy, насколько я помню, карточка шлет отдельные пакеты на установку и сброс прерывания. При этом могут быть какие-то тонкости с упорядочением пакетов на шине. Иногда бывает нужно для правильного упорядочения поставить явный барьер - чтение из карточки после записи. Мне кажется, стоит для начала поэкспериментировать, проходит ли запись/чтение в карточку в первом прерывании после сброса сигнала прерывания. Ну и проверить тонкости правил упорядочения пакетов прерываний в стандарте.

Поставил три чтения сразу после сброса INTA. Работает. Что-то происходит уже после.

ЗЫ, у меня и квартус под линух 64 бита.

Добрый день.
У меня тоже возникли проблемы с прерываниями PCIe.
Плата - кит от альтеры на C4. Операционка WinXP x32.
MSI-X и MSI не использую.
Проявляется проблема в том, что при загрузке винды происходит вызов OnInterrupt, который я прикручиваю в вызове IoConnectInterrupt.
Плата точно не генерит это прерывание, т.к. все сигналы запросов зажаты в 0.
В обработчике (OnInterrupt) я просто пишу в плату определенное число и вторым компом по SignalTap наблюдаю. Такой вот дебаг.
Так вот, если обработчик вернет TRUE, то процентов на 95 комп перегрузится.
Если вернет FALSE, то обработчик будет вновь и вновь вызываться. Это даст винде загрузиться, но потом она все равно зависнет или перегрузится.

С другой стороны, если включить комп с выключенной платой, а потом ее включить (подать питание) и найти поиском в диспетчере устройств, то она будет работать корректно. Если в ней раскоментарить генерацию прерываний, то они будут нормально генериться и обрабатываться драйвером.

Если обработчик вообще не прикручивать с помощью IoConnectInterrupt, то все будет хорошо.

Драйвер изначально был сделан для PCI устройства. Там такой проблемы не было.

Может стоит пользоваться IoConnectInterruptEx? Но я пока не планирую MSI...
Подкиньте, пожалуйста, идеи.

у PCIe нет отдельной сигнальной цепи-прерывания в разъеме, как в PCI.
и по факту все прерывания, формируемые со стороны платы передаются как MSI.
Другое дело, что вы можете их в операционке получить через legacy/compatibility layers как будто это и не MSI вовсе.
Вот только работать оно будет ровно так, как вы описали - т.е. глючить.

разбиратся с MSI придётся всё равно.

Не пугайтесь раньше времени, все что Вы описали происходит вполне закономерно.
MSI или Legacy - совершенно не важно в Вашем случае.

В обработчике прерывания на первом месте должна стоять проверка - а запущено ли приложение?
Если приложение под данный драйвер запущено не было, то обработчик должен вернуть FALSE.
На втором месте в обработчике должна стоять проверка -моя ли плата дала данное прерывание?
Читаем признак (бит установленный в 1) из нашей платы. Если плата не давала прерывание - возвращаем FALSE.
В общем, обработчик может вернуть TRUE только если приложение запущено (ОС загружена, естественно) и плата давала прерывание.

Лет 8 назад мое попадались платы с каким-то дурным чипсетом NEC, на которых моей PCI-плате давали прерывание общее с кем-то из девайсов, и
ISR() в моем драйвере вызывался намного чаще, чем моя плата выставляла прерывания на шину. Проблему решили как написано выше.

Дерзайте, все будет работать.

Спасибо.

soldat_shveyk,

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

krux,

буду пробовать MSI.

Пробуйте MSI.
Отпишитесь потом в этой ветке, если не затруднит, - помогло или нет.

Перешел я на использование IOConnectInterruptEx, FULLY_SPECIFIED (в XP можно только эту версию использовать).
В описании на альтеровскую корку написано, что по включению используются legacy (lane-based) и для использования MSI надо ручками менять биты в одном из конфиг регов. До этого я не дошел, так что фактически продолжаю использовать legacy.
IOConnectInterruptEx ничего нового не дал. Все осталось как есть. Есть пару подробностей относительно срабатывания OnInterrupt при старте винды. Ранее я писал, что если я верну TRUE, то винда перегрузится. Это не совсем точно.
В обработчике прерывания я лезу в плату и проверяю бит, что это мое прерывание. Так вот перезагрузку вызывает именно обращение к моей плате. Если в обработчике я просто буду делать DebugPrint и возвращать TRUE, то винда загрузится. Но обработчик прерывания будет постоянно вызываться и вызываться, точно так же, как и в случае, когда обработчик всегда возвращал FALSE.
Я предполагаю, что перезагрузка происходит потому, что ServiceContext, передаваемый обработчику вовсе не содержит адреса на мой DeviceExtension, поля которого я использую при обращении к плате. Надо будет выкинуть в дебаг его значение.
Выглядит, как будто это прерывание никак обрабатывается (не сбрасывается источник) и мне его постоянно присылают.
Похожее наблюдается, если в девайсе установить прерывание и не чистить - хоть OnInterruptEx будет возвращать TRUE, обработчик прерывания будет постоянно вызываться, пока в девайсе оно не снимется.
Я даже подумал, что может корка глючит. После загрузки винды дернул сигнал запроса прерывания вверх-вниз, но это ничего не поменяло.
Вот такие новости.

Идея про неправильный ServiceContext себя не подтвердила. Он приходит правильный. Я в ПЛИС завел счетчик, который инкрементирую каждый раз при вызове OnInterrupt. Смотрю за ним с другого компа через SignalTap. Так вот, в определенный момент OnInterrupt начинает непрерывно вызываться. Мой восьмибитный счетчик наматывает пару кругов, после чего комп виснет.
Как будто есть еще какой то источник прерывания кроме моего контроллера в ПЛИС, и его то и надо очистить.
Не исключаю, что в драйвере что-то кардинально не так. Уже подумываю откатиться назад на уровень примера toaster и заново потихоньку наращивать функционал.

С тостером та же фигня.
Тупик, блин.

Решил поглядеть, что будет на Win8 x64.
При загрузке винды тоже есть вызов OnInterrupt, не вызванный моей платой. Но он только один и после того, как я на него верну TRUE, больше не повторяется. Винда нормально грузится и после этого прерывания корректно работают.

Чтобы отмести возможные глюки моей платы, воткнул в комп с winXP преходник PCIe -> USB3. Поставил для него мой драйвер (в железо не лазит, а только DbgPrint в функции OnInterrupt). Картина та же - сразу после утановки все тихо, а после перезагрузки винды непрерывные вызовы OnInterrupt.
Т.е. вроде как моя железяка ни при чем. Поставил переходнику родные дрова - все нормально работает. Значит и на мамку можно не грешить.

Разобрался я в чем дело.
soldat_shveyk первым же своим ответом в сообщении 33 все верно описал.
После перезагрузки винды начинали прилетать прерывания от сетевухи, на которые надо отвечать FALSE.
Сбило меня с толку то, что если я все время отвечал FALSE, то винда все равно перегружалась через какое-то время. Оказалось, что это совсем не связано с моим драйвером. На видюхе сдох вентилятор, она перегревалась и все падало. После его ремонта поведение винды стало предсказуемым - примерно раз в секунду валится чужое прерывание и никому особо жить не мешает. Свое прерывание я определяю прочитав один из регистор моей платы.
А вот если я все время возвращаю TRUE, то в случае прерывания от сетевухи она продолжает его генерить, отчего винда и перегружается.
В общем, теперь все хорошо.
Спасибо всем.
Следующий шаг - DMA. Так что, до новых встреч
Но уже, видимо, не в этой теме.