From mboxrd@z Thu Jan 1 00:00:00 1970 From: Vivek Goyal Subject: Re: [2/3] 2.6.22-rc3: known regressions v2 Date: Fri, 1 Jun 2007 23:23:44 +0530 Message-ID: <20070601175344.GA13721@in.ibm.com> References: <465FED20.3090206@googlemail.com> <46600F27.1090202@googlemail.com> <20070601090115.3271a397.akpm@linux-foundation.org> Reply-To: vgoyal@in.ibm.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Received: from e34.co.us.ibm.com ([32.97.110.152]:33908 "EHLO e34.co.us.ibm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1760420AbXFASNQ (ORCPT ); Fri, 1 Jun 2007 14:13:16 -0400 Content-Disposition: inline In-Reply-To: <20070601090115.3271a397.akpm@linux-foundation.org> Sender: linux-scsi-owner@vger.kernel.org List-Id: linux-scsi@vger.kernel.org To: Andrew Morton Cc: Michal Piotrowski , Linus Torvalds , LKML , linux-pcmcia@lists.infradead.org, Robert de Rooy , Alan Cox , Tejun Heo , linux-ide@vger.kernel.org, Jeff Garzik , Gregor Jasny , linux-scsi@vger.kernel.org, James Bottomley , Mark Salyzyn , Yinghai Lu , Vivek Goyal , sparclinux@vger.kernel.org, David Miller , Mikael Pettersson On Fri, Jun 01, 2007 at 09:01:15AM -0700, Andrew Morton wrote: > On Fri, 01 Jun 2007 14:20:55 +0200 Michal Piotrowski wrote: > > > SCSI > > > > Subject : aacraid: adapter kernel panic'd fffffffd (kexec) > > References : http://lkml.org/lkml/2007/5/29/491 > > Submitter : Yinghai Lu > > Handled-By : Salyzyn, Mark > > Vivek Goyal > > Status : problem is being debugged > > Mark's aacraid-fix-shutdown-handler-to-also-disable-interrupts.patch is > known to fix this, so we can move this to "known regressions with patches" Hi Andrew, aacraid-fix-shutdown-handler-to-also-disable-interrupts.patch is meant to ensure that we don't perform an unnecessary reset of the device during a kexec boot. During kexec, we perform the device_shutdown() which should bring the device to a known sane state and a reset is not required while next kernel is coming up. I think this fix just masks Yinghai's problem and as such does not fix the root cause of the problem. In his case a software reset of the card is not successful and this is a problem. This problem will become visible during kdump. So I would think that this regression is still there just that got shifted from kexec to kdump. But we do need above patch to make sure kexec boot is fast and does not perform any unrequired device reset. Thanks Vivek