Roman Kononov wrote:
On 08/14/2007 07:56 AM, Peter Stuge wrote:
Roman did make a good point about IRQL but that does not eliminate the problem, we will still be changing hardware state underneath the OS and that is ALWAYS a bad idea.
The CF8/CFC sequence can preserve CF8 port value. What other hardware state would be changed?
http://www.hollistech.com/Resources/Misc%20articles/getbusdata.htm http://www.freelists.org/archives/wdmaudiodev/03-2004/msg00010.html
BTW, here is the "official" example: http://support.microsoft.com/kb/253232
Unfortunately, AFAIK, this approach does not work for cases like yours. It requires the "DeviceObject", which MUST be associated with a PARTICULAR PCI function.
Q: In the above links, among HtsReadWriteConfig() and WritePCIConfigSpace() argument lists, which arguments are bus number and device number? A: They are inside PDEVICE_OBJECT, which structure is "opaque".
Regarding how long DPC method takes. A scheduled DPC is launched as soon as the CPU's IRQL drops below DISPATCH_LEVEL. The CPU can be at DISPATCH_LEVEL (and higher) only running kernel code. This can last many time slices. This means that the DPC method might be quite expensive.
According to the official documentation, DPC is running at IRQL_DISPATCH_LEVEL. Nonetheless, I think there is still problem because only one DPC object of one "type" can exist in the system at one instance. This means we need to provide different DPC object "type" for different processor in multiprocessor environment to ensure "atomic" execution of the I/O code which seems to be an overkill and make the system too much loaded. I found this when trying to code the "DPC approach" in my latest device driver. Perhaps, using a kernel mode spinlock is a better approach. To ensure an atomic execution of the I/O operation. Seems to be the DPC approach is not the right solution for this type of problem.
I'm still working on this problem right now.
Regards, Darmawan Salihun