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: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Fab Tillier > Sent: Tuesday, September 23, 2008 12:01 AM > To: Leonid Keller > Cc: [email protected] > 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 > [email protected] > http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ofw > _______________________________________________ ofw mailing list [email protected] http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ofw
