[ofw] SVN rev 1559

[Tzachi Dar]

Hi Fab,

This issue is not as simple as it looks:

The problem comes from the fact that mlx4 driver is used also with other
drivers. For example, let's look at mlx4 as a base for an Ethernet
driver. (I believe that if we dig enough the same problem will also
happen for ipoib)

NDIS has a function called MiniportShutdown that is called when there is
a shutdown. On a first look, it seems that once this function is called
the driver should clean it's resources.

However on MSDN the text says: "MiniportShutdown should call no NdisXxx
functions." In other words, cleaning the resource in the normal way is
not allowed, since spinlocks can not be removed, memory can not be freed
etc.

As a result, we are forced to either not clean the resource at all, or
make a new path that clean hw resources but not memory resources (not
calling NDIS functions).

Remembering that MiniportShutdown is only called when the machine is
going down it seems too hard to create this extra cleanup path.

Thanks
Tzachi

> -----Original Message-----
> From: ofw-bounces at lists.openfabrics.org 
> [mailto:ofw-bounces at lists.openfabrics.org] On Behalf Of Fab Tillier
> Sent: Tuesday, September 23, 2008 12:01 AM
> To: Leonid Keller
> Cc: ofw at lists.openfabrics.org
> Subject: [ofw] SVN rev 1559
> 
> Hi Leo,
> 
> I'm updating my source base and looking over the changes.  
> You commented out an assertion in the complib pool 
> abstraction that all objects were returned before a pool is 
> destroyed.  You added a comment that you hit the assertion 
> during shutdown.
> 
> Was it not possible to fix the caller to force all items to 
> be returned to the pool, rather than removing the check?  The 
> check is actually valuable, since the destructor for pool 
> objects won't be called for objects that were not returned, 
> potentially leaking more resources.
> 
> To refresh our memories:
> >Index: core/complib/cl_pool.c
> >===================================================================
> >--- core/complib/cl_pool.c      (revision 1558)
> >+++ core/complib/cl_pool.c      (revision 1559)
> >@@ -180,8 +180,10 @@
> >                 * if they haven't, then most likely they 
> are still using memory
> >                 * that will be freed, and the destructor 
> will not be called!
> >                 */
> >-               CL_ASSERT( cl_qcpool_count( p_pool ) == 
> p_pool->num_objects );
> >
> >+// Assert can happen in shutdown. Need to find a way to 
> distinguish between the cases
> >+//             CL_ASSERT( cl_qcpool_count( p_pool ) == 
> p_pool->num_objects );
> >+
> >                /* call the user's destructor for each 
> object in the pool */
> >                if( p_pool->pfn_dtor )
> >                {
> >
> 
> -Fab
> _______________________________________________
> ofw mailing list
> ofw at lists.openfabrics.org
> http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ofw
>