[ofw] Loading drivers on LHS

[Fab Tillier]

This won't quite do it - think of the problem of WSD trying to laod when
there's no HCA (it was disabled or removed/remplaced).  WSD tries to
open IBAL, but there's no kernel device object for it to open, so it
fails.  Later when an HCA is enabled (or added), WSD doesn't try to open
IBAL again, so you don't have WSD support at all.

 

That said, the filter driver model should help get SAN support, though
there's more to it than that - like hooking bus relations queries into
the IOC PnP manager.

 

-Fab

 

From: Bhushan Pandit [mailto:pandit.bhushan at gmail.com] 
Sent: Thursday, May 10, 2007 12:34 AM
To: Fab Tillier
Cc: ofw at lists.openfabrics.org
Subject: Re: [ofw] Loading drivers on LHS

 

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/f5c3560c/attachment.html>