Jake,
So, if we make a “normal” PCI device driver for such bridge,
it will receive some resources, and later can behave as a bus driver?
How such a the bridge driver can allocate it’s physical memory window?
( I’ve got to port a VME bridge driver in the opposite direction - from
Linux, and it is detected as “bridge other”)
Regards,
– pa
From: Jake Oshins
Sent: Monday, November 23, 2009 03:12
Newsgroups: ntdev
Subject: Re: Re:How to troubleshoot "Code 12"
So many weird not-quite-PCI-compliant parts of the various chipsets have
been labeled "Bridge Other" that the only thing we've been able to do in the
past is ignore all problems with them, load no driver and leave them in
whatever state the BIOS configured them. Loading your driver starts the
process of treating "Bridge Other" like a valid device.
--
Jake Oshins
Hyper-V I/O Architect
Windows Kernel Group
If you load your own driver, it will behave in whatever way you like. At
the point you take control of it, it looks like just another PCI device to
Windows.
–
Jake Oshins
Hyper-V I/O Architect
Windows Kernel Group
This post implies no warranties and confers no rights.
“Pavel A.” wrote in message news:xxxxx@ntdev…
> Jake,
>
> So, if we make a “normal” PCI device driver for such bridge,
> it will receive some resources, and later can behave as a bus driver?
> How such a the bridge driver can allocate it’s physical memory window?
>
> ( I’ve got to port a VME bridge driver in the opposite direction - from
> Linux, and it is detected as “bridge other”)
>
> Regards,
> – pa
>
>
> ~~~~~
>
> From: Jake Oshins
> Sent: Monday, November 23, 2009 03:12
> Newsgroups: ntdev
> Subject: Re: Re:How to troubleshoot “Code 12”
>
> So many weird not-quite-PCI-compliant parts of the various chipsets have
> been labeled “Bridge Other” that the only thing we’ve been able to do in
> the
> past is ignore all problems with them, load no driver and leave them in
> whatever state the BIOS configured them. Loading your driver starts the
> process of treating “Bridge Other” like a valid device.
>
> –
> Jake Oshins
> Hyper-V I/O Architect
> Windows Kernel Group
>
>
>
>