[ofw][patch][[ibbus] boot in SAN environment

[Fab Tillier]

I think the delay is there so that the IOC PnP manager has time to sweep the fabric and discover the target again.  I think it would be great to have the query relations PNP IRP trigger a sweep, and block until it's complete.  I don't know how difficult this would be though.

-Fab

From: ofw-bounces at lists.openfabrics.org [mailto:ofw-bounces at lists.openfabrics.org] On Behalf Of Reuven Amitai
Sent: Monday, March 16, 2009 10:09 AM
To: Leonid Keller; James Yang; stan.smith at intel.com
Cc: ofw at lists.openfabrics.org
Subject: RE: [ofw][patch][[ibbus] boot in SAN environment

Hi,

Is this patch needed after Stan's patch ?
(Since IBBUS is on top of an HCA device, there is no longer a delay and the bfi is bounded at creation time
 -- If I understand the patch correctly ...)

Thanks, Reuven.


________________________________
From: ofw-bounces at lists.openfabrics.org [mailto:ofw-bounces at lists.openfabrics.org] On Behalf Of Leonid Keller
Sent: Monday, March 16, 2009 6:22 PM
To: James Yang
Cc: ofw at lists.openfabrics.org
Subject: [ofw][patch][[ibbus] boot in SAN environment

this patch adds a 5s delay to wait for hca up for remote boot in SAN environment.

Signed-off-by: James Yang

Index: core/bus/kernel/bus_pnp.c
===================================================================
--- core/bus/kernel/bus_pnp.c (revision 2032)
+++ core/bus/kernel/bus_pnp.c (working copy)
@@ -654,9 +654,10 @@
  IN     IRP* const    p_irp,
   OUT    cl_irp_action_t* const p_action )
 {
- NTSTATUS   status;
+ NTSTATUS   status = STATUS_SUCCESS; /*default to success*/
  bus_fdo_ext_t  *p_ext;
  bus_filter_t  *p_bfi;
+ int     waitLoop = 0;

  BUS_ENTER( BUS_DBG_PNP );

@@ -673,16 +674,18 @@
  p_bfi = p_ext->bus_filter;
  CL_ASSERT( p_bfi->magic == BFI_MAGIC );

- if ( p_bfi->ca_guid == 0ULL )
+ while ( p_bfi->ca_guid == 0ULL )
  {
   /* HCA not yet bound to a BFI slot (no PNP ADD event seen), no bus
    * relations yet.
    */
-  status = STATUS_SUCCESS;
-  BUS_PRINT(BUS_DBG_PNP, ("%s ca_guid %I64x\n",p_bfi->whoami,
+  BUS_PRINT(BUS_DBG_ERROR, ("%s ca_guid %I64x\n",p_bfi->whoami,
         p_bfi->ca_guid));
+  cl_thread_suspend( 100 ); /* suspend for 100 ms */
+  waitLoop++;
+  if(waitLoop>50) break;
  }
- else
+ if ( p_bfi->ca_guid != 0ULL )
  {
   status = port_mgr_get_bus_relations( p_bfi->ca_guid, p_irp );
   if( status == STATUS_SUCCESS ||
@@ -1271,6 +1274,7 @@
  switch( p_io_stack->Parameters.Power.Type )
  {
  case SystemPowerState:
+#if 0
   /*
    * Process on the way up the stack.  We cannot block since the
    * power dispatch function can be called at elevated IRQL if the
@@ -1287,7 +1291,7 @@
   *p_action = IrpDoNothing;
   status = STATUS_PENDING;
   break;
-
+#endif
  case DevicePowerState:
  default:
   /* Pass down and let the PDO driver handle it. */
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openfabrics.org/pipermail/ofw/attachments/20090316/e1a95d95/attachment.html>