Jake,
Anton, I disagree, because I don’t think that the video driver is loaded and in the chain.
Actually, this us exactly my point - video driver is not yet in a chain, so that it will be after, rather than before, the OP’s driver in a call chain when it connects to interrupt source. Therefore, whenever video device interrupts, it will always be the OP’s driver’s ISR and not video driver’s one who will get invoked first. If the OP’s driver does something time-consuming in its ISR before returning FALSE and video device interrupts frequently, it will result in system slowdown. However, if video driver has a chance to handle interrupt first the problem does not arise.
Please pay a special attention to the quote below:
[begin quote]
by interrupt storm I mean to say that my ISR is being called constantly from the time that it is first loaded. The machine runs extremely slow, and task manager shows CPU usage of 100%. When I open dbgview I see the print statements from my ISR scrolling by constantly. By interrupt storm I DO NOT mean the device is constantly asserting interrupts, or that an interrupt is being asserted but never handled/deasserted.
[end quote]
If what you are saying (i.e. IRQ get enabled by the OP’s driver so that video interrupt gets enabled and remains unhandled until video driver loads) was true, then there would be a different scenario -there would be an interrupt storm in its classical definition, and I am not sure the OP would be able to ever reach the point when he can run the Task Manager. However, if he reached the point when video driver gets loaded, the problem would disappear…
Anton Bassov
xxxxx@gmail.com wrote:
Definitely a question worth asking in case I missed the obvious. I was actually a little confused on that myself at first because there’s AMD64 and IA64. The processor is an Intel X64 dual core, so I’m using a binary compiled under the AMD64 environment. Correct me if that’s a mistake.
Nope, that’s the right one. Did you sign it, or turn off signing?
Vista 64 will not load an unsigned driver binary unless you disable
signing at boot time, or hook up the kernel debugger.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
I actually did both. It’s test signed and even if it wasn’t Vista should allow me to install it anyway.
Test signed? You mean a self signed certificate?
I though EVERY 64-bit Vista/W2K8 driver HAD to have a signature from an
approved CA (for example Verisign), unless you disabled signature checking
at boot time?
I thought test signatures where for .cat signing, not 64-bit binary signing.
Jan
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@gmail.com
Sent: Thursday, October 30, 2008 4:23 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] PCIe Driver Getting Interrupt Storm
I actually did both. It’s test signed and even if it wasn’t
Vista should allow me to install it anyway.
You can import the cer file into the SUT and the driver will load in test
mode.
“Jan Bottorff” wrote in message news:xxxxx@ntdev…
> Test signed? You mean a self signed certificate?
>
> I though EVERY 64-bit Vista/W2K8 driver HAD to have a signature from an
> approved CA (for example Verisign), unless you disabled signature checking
> at boot time?
>
> I thought test signatures where for .cat signing, not 64-bit binary
> signing.
>
> Jan
>
>> -----Original Message-----
>> From: xxxxx@lists.osr.com
>> [mailto:xxxxx@lists.osr.com] On Behalf Of
>> xxxxx@gmail.com
>> Sent: Thursday, October 30, 2008 4:23 PM
>> To: Windows System Software Devs Interest List
>> Subject: RE:[ntdev] PCIe Driver Getting Interrupt Storm
>>
>> I actually did both. It’s test signed and even if it wasn’t
>> Vista should allow me to install it anyway.
>>
>
>
The driver package installs correctly if I use devcon dp_add. The files are copied to the driver store and the installation is logged in setupapi.dev.log. But still when I do devcon update I simply get “devcon failed” and no output in the setupapi log. I think this rules out problems with the INF file.