From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jeff Garzik Subject: Re: FW: + qla3xxx-is-bust.patch added to -mm tree Date: Thu, 13 Jul 2006 13:06:19 -0400 Message-ID: <44B67D8B.4080303@garzik.org> References: <0BB3E5E7462EEA4295BC02D49691DC0722399F@AVEXCH1.qlogic.org> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: netdev@vger.kernel.org, linux-driver@qlogic.com Return-path: Received: from srv5.dvmed.net ([207.36.208.214]:44943 "EHLO mail.dvmed.net") by vger.kernel.org with ESMTP id S1030246AbWGMRGW (ORCPT ); Thu, 13 Jul 2006 13:06:22 -0400 To: Ron Mercer In-Reply-To: <0BB3E5E7462EEA4295BC02D49691DC0722399F@AVEXCH1.qlogic.org> Sender: netdev-owner@vger.kernel.org List-Id: netdev.vger.kernel.org Ron Mercer wrote: > Jeff, > > Regarding your June 22nd post: > >> 14) Surely there is a better way to down the adapter than masking the >> interrupts and resetting the adapter? If this is ever used in non-MSI > >> situations (common in Linux today), there is the possibility of >> screaming interrupts, in shared-interrupt situations. > > > The actual downing of the adapter frees interrupts before issuing a > reset. Perhaps you are referring to the ql_reset_work() path? This > handles chip reset requests generated by the iSCSI driver or iSCSI > firmware. What you see is that interrupts are masked and reset is > allowed to continue. I have made a change where the interrupt is freed > before the reset continues. I will post a new patch that covers all > issues tomorrow. Freeing a kernel interrupt reservation does not imply that your hardware has stopped delivering them... in a shared interrupt situation, the code sequence free_irq() perform some action could cause the kernel to call _another_ driver's interrupt handling routine over and over again, until _your_ hardware stops raising the interrupt condition. Jeff