[ofw] Loading drivers on LHS

[Bhushan Pandit]

Hi,

In Solution 2, the issue of WSD requiring IBAL loaded could be solved by
making HCA driver as boot start SERVICE_BOOT_START (instead of current
SERVICE_DEMAND_START)? IPoIB could still remain as SERVICE_DEMAND_START.

This will load the HCA and IBBUS (as upper filter) at the boot time, and the
user mode clients would get the IBAT services available rightaway.

This may also help getting SAN boot support for SRP, currently the IB
(including SRP) drivers could not be used as boot drivers (using
txtsetup.oem) during the Windows installation, because IBBUS requires Win32
co-installer which is not available at that moment.

Thanks,

Bhushan.


On 5/10/07, Fab Tillier <ftillier at windows.microsoft.com> wrote:
>
>  Hi folks,
>
>
>
> I tried loading the IB drivers on LHS (Windows Server code name
> "Longhorn") and it doesn't work.  I tracked the problem down to the fact
> that the driver packages are now staged to a special system folder before
> being installed.  The IB co-installer uses the path of the binaries to find
> the drivers for the "InfiniBand Fabric" device, but since these didn't get
> staged with the HCA drivers, it fails and with it installation of the HCA
> drivers fails.
>
>
>
> I can't come up with a really good solution to this, so wanted to start a
> discussion for how this should be addressed.
>
>
>
> Solution 1: Don't fail the HCA driver installation if the co-installer
> can't install the IB Bus device.
>
> While this allows the HCA drivers to install, it doesn't install the IB
> Bus, which means no user-mode app will work (no IBAL device for it to open),
> and no IPoIB or other child devices (no bus driver) will be reported to the
> system.  A manual installation of the drivers for the IB bus driver is
> required to get things really running, so there's no longer an automatic
> installation path through the device manager.  Things can be scripted with
> devcon to work around this, though.
>
>
>
> Solution 2: Make ibbus an upper filter for the HCA, include all its
> information in the HCA's INF file.
>
> This solves the installation issue (and eliminates the co-installer), and
> kernel clients will get created as needed, so it's a pretty nice solution
> (it actually simplifies the PnP notifications required of HCA drivers).  The
> problem is that it impacts user-mode apps.  Currently, a user-mode client
> can load before any HCA is available in the system, and use the IBAL PnP
> notifications to detect arrival of an HCA.  If the IB bus driver is loaded
> as an upper filter, it will not be loaded until an HCA is loaded, so
> user-mode applications will no longer be able to rely on IBAL for CA PnP
> notifications.  This would impact WSD for sure, though WSD depends on the
> IBAT device anyway for address resolution, and this won't exist until the IB
> bus exists.  So WSD could be re-architected to delay-load IBAL until there
> are addresses reported by IBAT.
>
>
>
> Neither solution is all that great.  Any other thoughts and ideas?
>
>
>
> -Fab
>
> _______________________________________________
> ofw mailing list
> ofw at lists.openfabrics.org
> http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ofw
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openfabrics.org/pipermail/ofw/attachments/20070510/5f1499c7/attachment-0003.html>