Есть _почти_ рабочий драйвер, в котором ставятся на обслуживание DPC на другие процессоры. Работает замечательно на машинах с гиперфредингом. Но на 4-процессорном серваке система наглухо виснет при обработке DPC (BSoDa нет, отладчик удается подключить один раз из десяти, и ничего полезного не видно). Система Windows 2000 Advanced Server, двухпроцессорная с гиперфредингом (итого 4). С отключенным гиперфредингом аналогично. Единственное упоминание об аналогичной проблеме нашел на багтраке: Есть ли зерно истины в этих словах? И с чем еще может быть связана проблема?
В IPI системах есть один ведущий процессор, все остальные ведомые. Т.е. при инициализации системы работает только 0-ой, потом через трамплин-код подымаются другие и через IPI канал получают дальнейшее руководство к действию. Я так понял, что у тебя DPC-шки должны положить все процессоры в ожидания глобального лока. Думаю, что тебе нельзя лочить нулевой процессор выполняясь на другом, попробуй поставить DPC на нулевой процессор, чтобы гарантированно выполнится на нём.
Вчера нашел, в чем была проблема. Оказалось, что проявлялся крайне неочевидный deadlock между тремя разными функциями. Самым интересным во всем этом было поведение отладчиков: WinDbg не мог переключиться на "подвисший" процессор, потому что тот выполнялся на IRQL=DPC_LEVEL и с выключенными прерываниями. SoftIce же все время показывал одно и то же значение EIP на этом процессоре. Поэтому и возникло предположение об аппаратной природе ошибки
Nouzui В моей программулине естественно. На одном проце KeAcquireSpinLock, затем ставил в очередь DPC на остальные процы. В это время иногда срабатывало прерывание, часть обработки которого происходит также на DPC. В обработчике было ожидание на этом же спин-локе. Проблема в обнаружении была связана, как я уже написал, со странным (как поначалу казалось ) поведением отладчиков и с тем, что deadlock происходил при солидной нагрузке в непредсказуемых местах кода. Ну а нашелся он в результате десятитысячного просмотра кода
