[1891ВМ12Я 0]

Продолжаются приключения с Ultrascale и PCI-E портом. Плата пробовалась на бытовом компьютере через CPCI-Serial самодельный переходник - отлично, пробовалась в корзине с i7 процессорным модулем - отлично. Но вот, этот i7 модуль умер. И срочно нашли замену, Fastwel CPC-512. И с ним проблемы

 

На этом CPC-512 чтение запись MMIO работает отлично, MSI прерывания ходят. Но по зависанию прошивки ПЛИС, я обнаружил, что зависание прям с первой же попытки, не случайное не периодическое, а просто с ходу, когда я пытаюсь делать MRd запросы по шине s_axis_rq и получать ответы по шине m_axis_rc, тут "s" это имеется ввиду что это у PCI-E ядра это slave, и "m" наоборот, просто не стал инвертировать эти буквы

 

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

 

Работало с адресами, выделенными через dma_alloc_coherent, но пробовал также и через dma_map_single - результат всё тот же, оно просто не хочет давать результаты чтения! Как понять, что запрос ушел без ошибки? Ориентируюсь на s_axis_rq_tready. Пробовал выделять не сколько надо, а больше, например по размеру страницы памяти

 

Подозрения:
1) Ориентируюсь на if(s_axis_rq_tready == 4'b1111) begin, а вдруг оно просто один бит ready?

2) Оно дает мне ready, но вдруг оно как то сигнализирует что надо повторить? Я снимаю valid бит на отправку лишь когда есть второй s_axis_rq_tready == 4'b1111

3) А может настройка компьютера какая то неверная? Что предположительно может быть

4) Я проверял, что у меня dma_mask 32 битное, все адреса 32 битные должны быть в запросах MWr и MRd

5) У меня фиксированные tag биты и прочие биты не меняю в запросе, но для одного запроса это не должно быть проблемой. Увы, на первом же и повиснет, то есть повиснет в месте где жду ответ CplD

 

Добавлено: Драйвер для Linux. Может какие то флаги в kmalloc добавить дополнительные? GFP_DMA есть. Может работать через softmmu - не пробовал еще, или это не относится к реальному железу. Может какие диапазоны указать пошире. Явно какая то настройка кроется в ОС, и в БИОС всё облазил

[makc 192]

Приведите подробные примеры запросов, которые зависают. Непонятные проблемы может вызывать несоблюдение требований к выравниванию адресов, размеров запросов, переходы запроса через границу аппаратной страницы (4 КБ) и т.п. Вы же никаких подробностей не даёте, поэтому пока что можно только посочувствовать и пожелать удачи.

PS: В идеале нужно привести дампы TLP, которые вызывают такие проблемы, и выдачу lspci -vvv

[1891ВМ12Я 0]

4 hours ago, makc said:

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

PS: В идеале нужно привести дампы TLP, которые вызывают такие проблемы, и выдачу lspci -vvv

Да, Вы правы, я добавлю всё это когда появится возможность завтра. Адреса выровнены, все инкременты кратны 256 байт (максимальный размер payload). Запрашиваю по 256 байт (64 DW):

if(s_axis_rq_tready == 4'b1111) begin
	s_axis_rq_tdata <= {32'h0, {1'b0, 3'b0, 3'b0, 1'b0, 16'h0, 8'hCC}, {bdf, 1'b0, 4'b0000, 11'd64}, {32'h0, h2ddr_source_addr[31:2], 2'b0}};
	s_axis_rq_tuser <= {32'b0, 4'b1010, 8'b0, 1'b0, 2'b0, 1'b0, 1'b0, 3'b0, 4'b0, 4'b1111};
	s_axis_rq_tkeep <= 8'h0F;
	s_axis_rq_tvalid <= 1;
	s_axis_rq_tlast <= 1;
	m_axis_rc_tready <= 1;
end

На других компьютерах работает, даже если тут размер страницы был бы не 4096, это надо бы уточнить, вдруг 8192 или 16384. Вся суть заминки в том, что на другом похожем модуле всё работало с этой же прошивкой. Пока теряюсь в догадках, какие идеи могут быть чтобы проверить

 

s_axis_rq_tdata <= {32'h0, {1'b0, 3'b0, 3'b0, 1'b0, 16'h0, 8'hCC}, {bdf, 1'b0, 4'b0000, 11'd64}, {32'h0, h2ddr_source_addr[31:2], 2'b0}};

Тут, справа на лево 2 бита нулевые (выровнено по 4 байтам), h2ddr_source_addr это адрес буфера выделенного в драйвере, он передается через MMIO (эта часть работает железно). Затем идет 32 бита нулей, так как у меня dma_mask 32 бит, дефолтные. Далее указано что хочу 64 DW. Четыре нуля это Memory Read Request согласно таблице в документации. Далее poison bit должен быть нулем. Затем следует BDF и он 16 битный регистр, его я в драйвере пишу и читаю (readback).

 

Далее идет tag, у меня настройка .AXISTEN_IF_ENABLE_CLIENT_TAG("FALSE"), значит это поле игнорируется hard ip блоком, в общем, не участвует и не влияет. Есть тут подозрения... Это поле 8'hCC

 

Далее 16 бит Completer ID, то есть PCI root port, это bus device function 0, всё нули. Верно ли это? Но для чтений MMIO я задаю это 16 нулями и всё работает. Далее Requester ID Enable Endpoint mode: Must be set to 1’b0 - верно. Transaction Class (TC) ставлю нулями, но как я понял из документации, мне эти 3 бита вернется в пакете CplD

 

Затем три бита - атрибуты. Если опция не включена - ядро забивает это нулями. Ни в конфиге ядра, ни в текстовом списке настроек не вижу чтобы это было включено или выключено. Может влиять? Force ECRC оставил нулем, с этим работает

 

Вроде нигде ошибки нет. И память точно выделяется, ее я вижу в драйвере, ее адрес. Его же пишу как обычно в MMIO для инициации чтения со стороны ПЛИС, как и на рабочих системах. Всё же в системе другие PCI-E устройства, и очевидно в их наборе команд точно есть MRd, без него не обойтись

 

Добавлено: у меня DWORD aligned режим, и 4 DW заголовок. Но в s_axis_rq_tuser задано что first byte enable это 1111, будто передается еще один DW. А может это ошибка для MRd так задавать??? Может у него не должно быть такого слова, и другие компьютеры это принимали, а этот не хочет?

[dxp 33]

5 часов назад, 1891ВМ12Я сказал:

все инкременты кратны 256 байт (максимальный размер payload)

256 — достаточно большой MPS, обычно такое на серверах, на настольных хостах как правило 128. Тут нет ошибки? Что lspci говорит про реальный MPS?

[1891ВМ12Я 0]

6 hours ago, dxp said:

256 — достаточно большой MPS, обычно такое на серверах, на настольных хостах как правило 128. Тут нет ошибки? Что lspci говорит про реальный MPS?

Прислали фото, max payload 256/512 bytes, read request 512 bytes

[dxp 33]

Так хост/железка вам не доступны? Если виснет гарантировано сразу, самое оно ILA подключить и посмотреть состояние PCIe ядра.

5GT/s -- это Gen2 дивайс?

[1891ВМ12Я 0]

6 minutes ago, dxp said:

Так хост/железка вам не доступны? Если виснет гарантировано сразу, самое оно ILA подключить и посмотреть состояние PCIe ядра.

5GT/s -- это Gen2 дивайс?

В другом городе, захожу по удаленке и затем по ssh. Да, это Gen 2. У меня там UART, так и определил что повесилось, ни единого пакета в ответ. Но я перепроверю, пока кажется что ни одного в ответ

[dxp 33]

а нету доступа удалённого до хоста, с которого можно к ПЛИС прицепиться по JTAG?

[1891ВМ12Я 0]

10 minutes ago, dxp said:

а нету доступа удалённого до хоста, с которого можно к ПЛИС прицепиться по JTAG?

Есть, могу хоть ILA или по UART, но главное что смотреть. Проект работал на других процессорных модулях. Ответы не приходят. Я могу в прошивку добавить вывод в UART какого либо статуса, но какой статус поможет понять, почему нет ответа на чтение?

[dxp 33]

первым делом смотреть состояние потоковых портов — что с ними, готовы принимать-отправлять или tready в нуле. Например, если второе, то скорее всего почему-то затык внутри — кредиты кончились, например, по какой-то причине. Можно повесить счётчик и определить, сколько передано до зависания. Может там на первом же пакете всё падает.

[1891ВМ12Я 0]

On 3/20/2023 at 12:30 PM, dxp said:

первым делом смотреть состояние потоковых портов — что с ними, готовы принимать-отправлять или tready в нуле. Например, если второе, то скорее всего почему-то затык внутри — кредиты кончились, например, по какой-то причине. Можно повесить счётчик и определить, сколько передано до зависания. Может там на первом же пакете всё падает.

Вы оказались правы. Действительно, 1 пакет всё же принимается, я зафиксировал на каком такте всё обрывается - на первом же. И на первом же такте tlast. Стал смотреть, там маска 0x07 = 0111, всего три DW пришло. Смотрю содержимое и вижу там 40009000 00000000 00000000, то есть первое слово 40009000

 

И тут догадка появилась! По схеме там стоит pci-e switch. А что если компьютер умеет 256/512 байт, а свитч нет??? Но там стоит PEX8725 и "In addition to low latency, the device supports a packet payload size of up to 2048 bytes" - не причина

 

40009000 - что за странный адрес, а может не адрес а спец пакет, заголовок. Пойду читать документацию, что значит в CplD такое содержимое. Буду рад идеям

 

Идея появилась! А что если это тандемный ответ? Что если мне стоит пропустить этот ответ, а дальше уже пойдет корректный??? Просто первый пакет корявый и заслоняет собой второй корректный. Вот так брать и откидывать неполный пакет и считать что начинаем принимать данные с нуля. Хотя, у меня есть счетчик 256 битных слов с шины, и он устанавливает отладочный регистр при tlast, похоже ничего после него не приходит

[dxp 33]

5 часов назад, 1891ВМ12Я сказал:

По схеме там стоит pci-e switch. А что если компьютер умеет 256/512 байт, а свитч нет??? Но там стоит PEX8725 и "In addition to low latency, the device supports a packet payload size of up to 2048 bytes" - не причина

Коммутатор, даже если ограничивает MPS ниже RC и дивайса, не должен влиять — при енумерации RC проверяет всю топологию, и если находит узел, который режет MPS — например, на 128 байт, то всем узлам в этой цепочке устанавливается MPS 128, несмотря на Capability. У вас, судя по скрину, свич не ограничивает.

6 часов назад, 1891ВМ12Я сказал:

Идея появилась! А что если это тандемный ответ? Что если мне стоит пропустить этот ответ, а дальше уже пойдет корректный??? Просто первый пакет корявый и заслоняет собой второй корректный. Вот так брать и откидывать неполный пакет и считать что начинаем принимать данные с нуля. Хотя, у меня есть счетчик 256 битных слов с шины, и он устанавливает отладочный регистр при tlast, похоже ничего после него не приходит

Что за тандемный ответ?

Надо разбирать заголовок, чтобы понять, что там пришло.

[1891ВМ12Я 0]

On 3/24/2023 at 5:04 AM, dxp said:

Надо разбирать заголовок, чтобы понять, что там пришло

Мне удалось прочитать 1 слово DW однократно, второй раз оно не читает! Сделал специальный выделенный из проекта тест с чисто PCI-e. Сделал регулирование числа слов для чтения через регистр, запросил 1 и однократно оно сработало!
 

40010000 03000001 00000000 AAAA1111

 

Где 0xAAAA1111 это то, что я расположил в буфере, второе слово BBBB2222 и так далее. Маска при этом 0x0F, то есть 4 DW, это верно. Но 2 4 8 и далее слов - не читаются. Я нашел в документации форматы ответов, ведь у меня requester раз я читаю, requester completion такой как в таблице. Сейчас посмотрим что же у меня за ошибка получается когда 40009000. Сие означает что у меня 1001: Request terminated by a Completion timeout, а 4 означает что request completed

 

На Kintex 7 эти времена можно было задавать и ставить побольше. А как это делать в Ultra Scale???

 

Почему нулевой requester id это странно, ведь у меня ненулевой BDF= 0x0300. В успешном ответе это видим. Попробую тэг сделать счетчиком. Тэг не помог. Я сделал формирование запроса в драйвере, прям пишу 4 DW из драйвера которые идут в запрос - ну работает но так же: 1) первые два запроса на 1 DW уходят успешно даже если для второго изменить адрес 2) третий запрос на 1 DW и последующие никогда не приходят ответы 3) на большее число слов - таймаут. Как поднять таймаут в документации не видать

 

[dxp 33]

Имхо, таймаут тут ни при чём. Он там достаточно большой и служит для того, чтобы терминировать запросы, на которые за вменяемое время не пришли ответы — чтобы запросы не висели вечно. У вас что-то ломается с логикой запросов — первые корректные, на них приходит, а потом что-то в них портится. Посмотрите внимательнее, что отсылаете. Попробуйте слать подряд несколько одинаковых запросов. Например, первый проходит, ещё раз его же. Если проходит, то ещё несколько раз. Если это работает, то по крайней мере покажет, что с буферами и очередями запросов проблем нет.

А если на совершенно корректные запросы (ну, раз хотя бы один работает) дальше ломается, то тогда уже смотреть, что там с логикой транспорта — может кредитов выделено с гулькин нос и они не возобновляются (бредово, конечно, но кто знает, что там может быть). У вас тут не самая простая топология — коммутатор имеется, проблема может быть на любом уровне.

[1891ВМ12Я 0]

9 hours ago, dxp said:

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

 Шлю одинаковые 1 в 1, два проходят а на третий нет ответа

9 hours ago, dxp said:

А если на совершенно корректные запросы (ну, раз хотя бы один работает) дальше ломается

Сдедал упрощенный тест где только MMIO и запрос на чтение MRd который собирается за 15 минут, причем данные запроса все 4 DW задаю в драйвере, чтобы еще быстрее перебирать варианты

 

В общем, на проц модуле всё такая же проблема, а на бытовом компьютере всё идеально работает, читает и 8 и 16 и 32 и 64 DW, вообще без проблем, и сколько угодно раз

 

Правильно ведь понимаю что прохождение PCI-E switch не должно влиять на формат запроса, все равно просим данные у BDF 0 0 0 у root port? А то вдруг надо просить у PCI-E switch, вычисляя как то свое положение на топологии при помощи драйвера?