Помощь - Поиск - Пользователи - Календарь
Полная версия этой страницы: PCI шина - сколь глубока нора ...
Форум разработчиков электроники ELECTRONIX.ru > Интерфейсы > Форумы по интерфейсам > ISA/PCI/PCI-X/PCI Express
Bios71
чтобы на практике устройства "определялись" БИОСом и не "терялись" на концах деревьев ...

задача практическая ... имею более 70 PCI-шин и до 140 PCI- устройств

на самых "дальних" PCI-ветках/шинах (за 9/10-тым P2P мостом) "подветки" и PCI-устройства ... теряются crying.gif

PS: пока подозрения есть толко на ограничения(какие???) по таймингу , т.е. если "подрезать" ветки стоящие ранее - то в "проблемных" все "находится"
PS2:еще особенности
Latency L0 кое где до 12000 nS (max по спецификациям 8000)
L1 64000 nS (max по спецификациям 128000)

krux
возможность раз:
PCI-to-PCI bridge specification говорит о максимальной первичной задержке ответа в 16 тактов от любого таргета (с изначальной дефолтной длительностью) плюс 8 тактов на каждую последующую completion
если каждый бридж съедает по 1 такту upstream и 1 такту downstream, то для классического PCI-to-PCI bridge стабильно работать будут только bus0 иследующие за ним 8 уровней иерархии...
а всё, что навешено дальше 8го - фактически будет обрубаться первым в иерархии бриджем, как completion timeout.

возможность два:
BIOS производит энумерацию рекурсивно, при этом одновременно выделяет ресурсы, плюс обеспечивает выравнивание и, соответственно, повторное выделение/перемещение окон. Вероятно, в какойто момент ему приходится настолько сильно увеличивать окно под какой-то из бриджей, что это приводит к "отрезанию" большей части доступной на тот момент оперативки, в результате чего процесс энумерации тупо прерывается, и остальные устройства не ищутся.
основное предположение здесь связано с размещением диапазонов окон устройств-потомков в диапазон окна бриджа-родителя.
Bios71
Цитата(krux @ Dec 18 2013, 21:42) *
возможность раз:
PCI-to-PCI bridge specification говорит о максимальной первичной задержке ответа в 16 тактов от любого таргета (с изначальной дефолтной длительностью) плюс 8 тактов на каждую последующую completion
если каждый бридж съедает по 1 такту upstream и 1 такту downstream, то для классического PCI-to-PCI bridge стабильно работать будут только bus0 иследующие за ним 8 уровней иерархии...
а всё, что навешено дальше 8го - фактически будет обрубаться первым в иерархии бриджем, как completion timeout.

возможность два:
BIOS производит энумерацию рекурсивно, при этом одновременно выделяет ресурсы, плюс обеспечивает выравнивание и, соответственно, повторное выделение/перемещение окон. Вероятно, в какойто момент ему приходится настолько сильно увеличивать окно под какой-то из бриджей, что это приводит к "отрезанию" большей части доступной на тот момент оперативки, в результате чего процесс энумерации тупо прерывается, и остальные устройства не ищутся.
основное предположение здесь связано с размещением диапазонов окон устройств-потомков в диапазон окна бриджа-родителя.


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

с БИОСом действительно не все играет как задумано (хотя я и есть "биос")
виндовс-девайс-менеджер (который я раньше уважал) НЕ показывает "потерянные" устройства,

в самой дальней ветке последний(с PCIe-девайсом) и предпоследний мосты (на нем P2P и новая ветка) имеют за собой что то (!!!!) , RW-Everything и PCI.EXE(DOS) показывают часть(первый ряд) затерянных устройств ... но без выделенных ресурсов (а P2P неотображаемый мост не видит 11/12 уровень мостов с устройствами biggrin.gif )

под такое гигантское(и прожорливое) число устройств выделяю больше 2.5 Гб памяти (на машине 16Гб)
но первые 4Гб являются волшебными ... их любят все и в них лезут, и система и PCI и выделенные ресурсы , а они НЕ резиновые

буду копать
krux
а может у вас ещё и конфликт шин случился? всмысле двум физически разным шинам записаны одни и те же [primary bus number]:[secondary bus number]:[subordinate bus number]

64-битные BARы, которые ещё и работают ;-) встречаются очень редко, поэтому не смотрите на то что у вас 16 ГБайт. фактически под PCI у вас их всё равно 4 ;-)
и ещё для информации к размышлению: устройствам с 32-разрядными BARами, которые захотят совершить DMA-транзакцию, память (в которую они будут писать/читать) нужна будет тоже из первых 4Гб, т.е. копирование данных туда-сюда из верхних 12 Гбайт будет неизбежно.



и ещё, у вас PCI или PCI-Express?
у PCI-Express привязку к тактам сделать невозможно, т.е. её там нет, зато вместо этого есть таймауты.
Bios71
Цитата(krux @ Dec 19 2013, 11:59) *
а может у вас ещё и конфликт шин случился? всмысле двум физически разным шинам записаны одни и те же [primary bus number]:[secondary bus number]:[subordinate bus number]

проверял, вроде все уникально/индивидуально

Цитата(krux @ Dec 19 2013, 11:59) *
64-битные BARы, которые ещё и работают ;-) встречаются очень редко, поэтому не смотрите на то что у вас 16 ГБайт. фактически под PCI у вас их всё равно 4 ;-)
и ещё для информации к размышлению: устройствам с 32-разрядными BARами, которые захотят совершить DMA-транзакцию, память (в которую они будут писать/читать) нужна будет тоже из первых 4Гб, т.е. копирование данных туда-сюда из верхних 12 Гбайт будет неизбежно.

это я и имел ввиду про "волшебные".... первые 4Гб

Цитата(krux @ Dec 19 2013, 11:59) *
и ещё, у вас PCI или PCI-Express?
у PCI-Express привязку к тактам сделать невозможно, т.е. её там нет, зато вместо этого есть таймауты.

PCI-Express мосты через удлинитель http://www.onestopsystems.com/pcie_hib38_x8.php (с расширителем до 4-х) на PEG порту(x4) IvyBridge
krux
не уверен насколько это поможет... но вдруг
Нажмите для просмотра прикрепленного файла
Нажмите для просмотра прикрепленного файла

для удлинителя ещё одна проблема может быть c ACK latency timeout, при, например, переполнении replay buffer в самом свиче из-за ошибок CRC.
но в этом случае это скорее "наука о контактах", либо придется возиться с глазковыми диаграммами и тогда без родного софта от свичей не обойтись.
в интернетах оно зовётся PLX_SDK_v7_10_Final_2013-08-09
написано на java, периодически глючит, вылетает и т.п. прелести.
этот софт позволяет делать многие вещи со свичами, но для активации плюшек на каждую определенную модель свича нужен отдельный ключ, т.е. в идеале всё равно понадобится NDA, и тогда тут всё печально.

L0 и L1 Latency вы где крутите? на IvyBridge?
дело в том что тогда это фактически параметры общения между рут-портом IvyBridge и первым свичем, и к дальним таргетам в иерархии эти параметры никак не относятся.
Bios71
Цитата(krux @ Dec 19 2013, 16:08) *
для удлинителя ещё одна проблема может быть c ACK latency timeout, при, например, переполнении replay buffer в самом свиче из-за ошибок CRC.
но в этом случае это скорее "наука о контактах", либо придется возиться с глазковыми диаграммами и тогда без родного софта от свичей не обойтись.

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


Цитата(krux @ Dec 19 2013, 16:08) *
в интернетах оно зовётся PLX_SDK_v7_10_Final_2013-08-09
написано на java, периодически глючит, вылетает и т.п. прелести.
этот софт позволяет делать многие вещи со свичами, но для активации плюшек на каждую определенную модель свича нужен отдельный ключ, т.е. в идеале всё равно понадобится NDA, и тогда тут всё печально.

NDA нас(точнее клиента) сильно не испугаешь, хочу еще посоветовать им поменять DUAL (с адаптером) на -PCIe-HIB38-x8-QUAD

Цитата(krux @ Dec 19 2013, 16:08) *
L0 и L1 Latency вы где крутите? на IvyBridge?
дело в том что тогда это фактически параметры общения между рут-портом IvyBridge и первым свичем, и к дальним таргетам в иерархии эти параметры никак не относятся.

ну вроде в процессе энумерации для ASPM задержки считаются накопительно , как-то так :

Цитата

Setting ASPM for Link...
UP STREAM PORT -> [B1|D0|F0] <--> [B0|D1|F0] <- DN STREAM PORT
Getting Overwr Aspm Settings for DNSTREAM PORT: Calc ASPM = 0 ... Setup ASPM = 0
Getting Overwr Aspm Settings for UPSTREAM PORT: Calc ASPM = 0 ... Setup ASPM = 0
Status = EFI_SUCCESS : Calc ASPM = 0 ... Overwr ASPM = 0
Calculate MPL :
Link # 1, Link MPL=0; Total MPL=0 dn->[B4|DB|F0]<->[B13|D0|F0]<-up;
Link # 2, Link MPL=0; Total MPL=0 dn->[B2|D8|F0]<->[B3|D0|F0]<-up;
Link # 3, Link MPL=0; Total MPL=0 dn->[B0|D1|F0]<->[B1|D0|F0]<-up;
Calculated MPL 0

Calculate L0s:
Link# 0 Lat=2000(nS) dn->[B4|DB|F0]<->[B3|D0|F0]<-up;
Link# 1 Lat=4000(nS) dn->[B2|D8|F0]<->[B1|D0|F0]<-up;
Link# 2 Lat=2000(nS) dn->[B0|D1|F0]<->[B47|D0|F0]<-up;
Total Calclulated latency: 8000 (nS)
Calculate L1 :
Link# 0 Lat=32000(nS) dn->[B4|DB|F0]<->[B3|D0|F0]<-up;
Link# 1 Lat=32000(nS) dn->[B2|D8|F0]<->[B1|D0|F0]<-up;
Link# 2 Lat=8000(nS) dn->[B0|D1|F0]<->[B47|D0|F0]<-up;
Total Calclulated latency: 34000 (nS)

krux
боюсь, что тут придётся ASPM выключить (и в ACPI соответственно сделать тоже самое).
хотя бы то тех пор пока отлаживаете всё остальное.
Bios71
Цитата(krux @ Dec 19 2013, 17:49) *
боюсь, что тут придётся ASPM выключить. хотя бы то тех пор пока отлаживаете всё остальное

так он и выключен, просто статистика ведется (в процессе PCI-энумерации), что карты поддерживают (Gen1/2/3 ... x1/x4/x8) и пр. сколько стоит т.е. длится L0/L1 для ASPM.... и я ее/статистику посматриваю для "выявления подозрительных мест"

Цитата(krux @ Dec 19 2013, 17:49) *
и в ACPI соответственно сделать тоже самое
.


а вот ето новенькое ... в каком месте и какими методами ... это можно увидеть .... привествуются ссылки
krux
ну так ACPI же заполняется BIOS-ом, соответственно в FADT
поле IA_PC
бит PCIe ASPM Control

сейчас все операционки читают ACPI, поэтому если BIOS засунул в ACPI что-то не то, то возможны всякие приколы, смешные и не очень.
например windows может найти только 2 ядра процессора вместо 16 (8 с гипертредингом)

http://acpi.info/
Bios71
Цитата(krux @ Dec 19 2013, 19:13) *
FADT
поле IA_PC
бит PCIe ASPM Control
http://acpi.info/


проверил(RW-Everything), запрещающий бит стоит sad.gif
Bios71
Цитата(Bios71 @ Dec 19 2013, 13:45) *
PCI-Express мосты через удлинитель http://www.onestopsystems.com/pcie_hib38_x8.php (с расширителем до 4-х) на PEG порту(x4) IvyBridge


методом "научного тыка" нащупано ограничение для удлинителя onestopsystems, максимум 64 шины за ним wacko.gif
krux
Bios71
спасибо за инфу
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.
Invision Power Board © 2001-2025 Invision Power Services, Inc.