Подвисание HAL ф-ции чтения

[WWX]

Доброго времени суток.

В PCIe драйвере обнаружилась странность. При чтении относительно большого (порядка 64 МБ) куска памяти PCIe устройства хост (ПК) зависает приблизительно на 10 сек. Намертво (даже мышь не двигается). Затем развисает и продолжает нормально работать.

На текущий момент чтение реализовано через READ_REGISTER_BUFFER_ULONG в ф-ции StartIo (DriverObject->DriverStartIo = StartIo;).

DMA, возможно, решит проблему, но сейчас оно не используется.

Хотелось бы понять, почему так происходит.
Процессор на хосте 4-х ядерный. В то, что устройство во время пересылки забивает всю шину, не особо верится.

[Ochkarik]

ваша железка нормально эти данные выдает? какую скорость она способна осилить?
если 32Мб запросить - будет на 5 сек зависать?
есть возможность время транзакции чем-то измерить, в железке прошивкой счетчиков и ловушек наставить?

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

[WWX]

Спасибо за быстрый ответ.

ваша железка нормально эти данные выдает? какую скорость она способна осилить?
если 32Мб запросить - будет на 5 сек зависать?
есть возможность время транзакции чем-то измерить, в железке прошивкой счетчиков и ловушек наставить?

Данные передаются нормально, ошибок не обнаружено.
При 32 МБ задержка 6.45 сек. (судя по принтам в DebugView). (Раньше передавал немного меньше 64 МБ, а зависание длилось немного более 10 сек., так что тут вроде бы всё сходится.)
Как измерить время транзакции на плате не знаю. Могу только обернуть принтами вызов одиночной HAL ф-ции чтения.

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

Ф-ция DispatchReadWrite для этого подойдёт? Не уверен, но по-моему она на PASSIVE_LEVEL выполняется.

Код:

DriverObject->MajorFunction[IRP_MJ_READ] = DriverObject->MajorFunction[IRP_MJ_WRITE] = DispatchReadWrite;

В ней вообще можно напрямую осуществлять запись / чтение без StartIo или в общем случае так лучше не делать (реентерабельность страдает).

Кстати, ф-ция IoStartPacket (которую я пока что использую) вроде бы использует глобальную спин-блокировку. Это случайно не может служить причиной зависания?

[Ochkarik]

может. варианта собстно два - либо что то блокируется программно, либо вдруг - аппаратно(маловероятно но вдруг).
да, подойдет. любой вариант = попробовать чтоб проверить что это из за IRQL или нет

[WWX]

Да, если перенести вызов ф-ции чтения из StartIo в DispatchReadWrite, то ничего не виснет.
Правда такое решение, как мне кажется, не годится даже в качестве временного (DMA мне всё равно придётся прикручивать, но это долго).

Ещё остаётся неопределённость: висло из-за высокого IRQL или из-за глобальной спин-блокировки (которая, судя по всему, где только (в Windows'е) не используется).

[Ochkarik]

Поднимите IRQL вручную в DispatchReadWrite. Сможете убедится что дело не в IRQL а в глобальном спинлоке)
KeRaiseIrql()/KeLowerIrql 

ЗЫ перед выходом - верните обратно само собой.

Добавлено через 2 минуты и 37 секунд:
PS а зачем вам вообще StartIO?

[WWX]

Поднимите IRQL вручную в DispatchReadWrite. Сможете убедится что дело не в IRQL а в глобальном спинлоке)

Ну, похоже что причинами подвисания служили оба этих факта.
Поднятие IRQL до DISPATCH_LEVEL (в DispatchReadWrite) также приводит к полному зависанию на несколько секунд, несмотря на то, что процессор 4-х ядерный.

а зачем вам вообще StartIO?

Мне почему-то казалось, что осуществлять всю пересылку данных в DispatchReadWrite и завершать там IRP не слишком хорошо (даже без DMA). Сейчас вот чё-то сомневаюсь.
Так нормально вообще делать?

Может в качестве промежуточного варианта (пока DMA не подоспеет) так и сделаю, защитив пересылку каким-нибудь мьютексом (в Linux'е когда-то давным давно так и делал).
Другого варианта как избавиться от зависания без DMA я чё-то не вижу.

[Ochkarik]

ну если транзакция такая длинная по времени - то не хорошо что вызывающее приложение будет подвисать и перестанет на сообщения отвечать. винда его может посчитать зависшим.
другой вариант - асинхронный вызов ReadWrite (все равно пригодится даже для DMA) данные получать в отдельной нитке kernel  завершать IRP после получения.
если бы обработка была короткая . но секунд на 10 - лучше PsCreateSystemThread сделать. только с контекстом повнимательнее - чтоб доступен был вне контекста приложения.

[WWX]

Спасибо за помощь (в т. ч. за наводку). Поизучаю.