Hello,
Here’s an outline of the problem:
There’s a piece of hardware consisting of a PCI bridge and several PCI
devices underneath it. The physical wiring of IRQ lines on those
devices does not match the contents of INTERRUPT_PIN register in PCI
configuration space, which makes it impossible for an OS to figure out
proper IRQ value for these devices (well one device(first) gets
correct value, but that’s sheer luck).
In Linux and NT (legacy) drivers this is covered with adhoc code which
in case of:
Linux: Gets the correct IRQ value by looking at the first device
under the parent bus.
NT: Walks the devices under the bridge in order, obtains the resource
list via HalAssignSlotResources but for all the devices uses the
CmResourceTypeInterrupt values of the device in slot zero.
I can imagine a way to do that with WDM like this:
In FILTER_RESOURCE_REQUIREMENTS on device in slot zero, set some
global variable associated with the particular bus to the pair of
Interrupt.Vector/Level, and for all other slots see if the pair is set
and put into resource list.
Apart from global variable (a map actually) this would, most
likely(?), require some sort locking, implies that things would only
work if the kernel would send proper IRP in the proper order, means
that attempt by the kernel to rebalance things should probably be
rejected.
IOW the above “solution” feels very fragile and i’m wondering if
there’s a better way to achieve the goal of having this (admittedly
broken hardware) work under newer versions of Windows
(HalAssignSlotResources is returning errors on both Vista and 7)
Thanks in advance.
Sincerely,
Vassili
You’re out of luck. If you want any Windows system after NT 4.0 to work
with your device, you’re going to have to make the interrupt routing
spec-compliant.
By the way, the contents of the Interrupt Line register are meaningless and
ignored.
–
Jake Oshins
Hyper-V I/O Architect
Windows Kernel Group
This post implies no warranties and confers no rights.
“Vassili Karpov” wrote in message news:xxxxx@ntdev…
> Hello,
>
> Here’s an outline of the problem:
>
> There’s a piece of hardware consisting of a PCI bridge and several PCI
> devices underneath it. The physical wiring of IRQ lines on those
> devices does not match the contents of INTERRUPT_PIN register in PCI
> configuration space, which makes it impossible for an OS to figure out
> proper IRQ value for these devices (well one device(first) gets
> correct value, but that’s sheer luck).
>
> In Linux and NT (legacy) drivers this is covered with adhoc code which
> in case of:
>
> Linux: Gets the correct IRQ value by looking at the first device
> under the parent bus.
>
> NT: Walks the devices under the bridge in order, obtains the resource
> list via HalAssignSlotResources but for all the devices uses the
> CmResourceTypeInterrupt values of the device in slot zero.
>
> I can imagine a way to do that with WDM like this:
>
> In FILTER_RESOURCE_REQUIREMENTS on device in slot zero, set some
> global variable associated with the particular bus to the pair of
> Interrupt.Vector/Level, and for all other slots see if the pair is set
> and put into resource list.
>
> Apart from global variable (a map actually) this would, most
> likely(?), require some sort locking, implies that things would only
> work if the kernel would send proper IRP in the proper order, means
> that attempt by the kernel to rebalance things should probably be
> rejected.
>
> IOW the above “solution” feels very fragile and i’m wondering if
> there’s a better way to achieve the goal of having this (admittedly
> broken hardware) work under newer versions of Windows
> (HalAssignSlotResources is returning errors on both Vista and 7)
>
> Thanks in advance.
>
> Sincerely,
> Vassili
>
On Mon, 3 Aug 2009, Jake Oshins wrote:
You’re out of luck. If you want any Windows system after NT 4.0 to work
with your device, you’re going to have to make the interrupt routing
spec-compliant.
I see, thanks, it should be(and was) noted though that things do work
with a legacy driver on XP, but no such luck on Vista or 7.
By the way, the contents of the Interrupt Line register are meaningless
and ignored.
I know, i never mentioned Interrupt Line register though only Interrupt
Pin.
–
mailto:xxxxx@comtv.ru