"Легальный" deadlock при управлении питанием в W2K/XP

From

Leo Yuriev ()

To

Gennady Mayko ()

Date

2003-01-22T17:46:25Z

Area

SU.WINDOWS.NT.PROG

From: "Leo Yuriev" <ly@elcat.kg>

Wed Jan 22 2003 16:22, Gennady Mayko wrote to Leo Yuriev:

 GM> From: "Gennady Mayko" <gennady.mayko@broadcom.com>

 GM> Добрый день!

 LY>> From: "Leo Yuriev" <ly@elcat.kg>

 LY>> BusFDO является "power policy owner" для своего стека, но над каждым
 LY>> ChildPDO есть "ChildFDO", соответственно каждый из этих ChildFDO
 LY>> является  "power policy owner" на своем стеке.
 LY>> Но даже если будут два "power policy owner" то ситуация будет не хуже
 LY>> чем  с одним "power policy owner". Просто на каждый SystemPower-запрос
 LY>> будет  посылаться не один, а два (или больше) DevicePower-запроса. При
 LY>> этом при  PowerDown "главным" будет самый нижний "power policy owner", а
 LY>> при  PowerUp - самый верхний. Я экспериментировал, все работает если нет
 LY>> описаной deadlock-ситуации.

 GM> --
 GM> Я стараюсь так не делать и иметь только один "power policy owner" драйвер
 GM> в стеке драйверов, который отвечает за все "манипуляции" с "power" для
 GM> устройства (PCI платы), которым он управляет.

Конечно больше одного "power policy owner" это ненормально, но я все же
убежден что в этом нет ничего фатального. Точнее говоря два "power policy
owner" не создают каких-либо ситуаций, которые невозможно получить другим
способом, просто лишние IRP.

И стека драйверов тут получается как минимум два, один от BusPDO (который под
BusFDO), и второй от каждого ChildPDO и выше. Поэтому и "power policy owner"
должно быть два. Другое дело что BusFDO и все ChildPDO обслуживаются одним
драйвером.

 GM> Насколько я понял, в описанном тобой случае эти 2 драйвера каким-то
 GM> образом должны знать о состоянии друг друга и "договориться" о совместных
 GM> действиях в той или иной ситуации (например, после п.3 BusFDO уже не
 GM> должен пытаться посылать запрос на PowerDeviceD3 или по крайней мере
 GM> должен его отложить до обработки уже запущенного).

Как я уже говорил для BusFDO и ChildPDO драйвер один, еще один драйвер будет
для ChildFDO. Причем этому драйвер будет (и должно быть) все равно как
работает его "шина".

Никакой синхронизации и/или взаимодействия не получается, потому что над
BusFDO и над ChildPDO может быть сколь угодно толстый "пирог" драйверов. Иначе
говоря ни BusFDO, ни ChildPDO не могут знать ли power-стек "корреспондента"
каким-либо IRP-запросом. Мне кажется это именно изян в архитектуре управления
питанием W2K/XP.

 GM> Нельзя ли IdleDetection перенести выше, в ChildPDO, так чтобы полностью
 GM> избавить BusFDO от этого? Я понимаю, что это своеобразное "дублирование"
 GM> и "размазывание" ответственности (потому что может быть несколько
 GM> ChildPDO), но все же...

IdleDetection есть и в BusFDO, и в Child (но не в PDO, а в FDO). Никакого
дублирования нет, BusFDO отключается по таймауту неиспользования всех его
ChildPDOs, а в Child-стеках IdleDetection делает (или не делает) FDO-драйвер.

 GM> А какой шиной (bus) управляет BusFDO и чем управляют ChildPDO, если не
 GM> секрет?

Я делаю драйвера с использованием своей библиотеки С++, в которой частности
реализован "образцовый" bus-драйвер. Поэтому это относится к "универсальному"
случаю. Последние "эксперименты" делаются на плате Omega2-PCI, ChildPDO это
memory-mapped COM-порты (http://leo.yuriev.ru/SerialXP).

 GM> --
 GM> С уважением,
 GM> Геннадий Майко.

Взаимно.
Леонид.

--- ifmail v.2.15dev5
 * Origin: FidoNet Online - http://www.fido-online.com (2:5020/400)