On Wednesday, June 14, 2006 1:00 PM, Mike Reed wrote: > > James Bottomley wrote: > > > > I was still thinking of something that made mpt_config() > never return > > -EAGAIN. How does the following work out? It's my first pass at > > sorting out the frame and active logic in mptbase: > > > pCfg->wait_done needs to be initialized to zero before sleeping. > agreed > It takes seven to ten seconds for the ioc->active value to become > non-zero and the wake up to occur. > > It appears that the order of execution during "lsiutil 99" testing > has changed. Once the driver marks the fibre targets missing, they > never return. Hmmm.... Until this is resolved, this patch cannot > be applied. I'll see if I can sort out how the execution order > has changed. not clear what you mean by "they never return" > > Another comment, for every i/o, this patch introduces overhead. > spinlock and checking a list which is empty 99.99[...]% of the time. > I'll have to perform an iop measurement to see if there is a > measurable impact on system performance. > What overhead? We don't read config pages on every I/O. James patch only effects the reading of config pages when there is a host reset. One concern on this patch. A possible deadlock situation could occur if we run out of message frames. Meaning there is another way that mpt_get_msg_frame() could return NULL, and that is becuase the ioc->FreeQ list is empty. This patch only addresses the case when there is a host reset. Utimatley we need to address both cases when NULL is returned. Id rather try to come up with a solution where the fix is isolated inside of mpt_get_msg_frame(). Eric Moore - : send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
