Hi Mark, I was going to try and test this patch rather than the last, but I am getting this compile error again where line 640 is the beginning of function aac_rx_init():
CC [M] drivers/scsi/aacraid/rx.o drivers/scsi/aacraid/rx.c: In function '_aac_rx_init': drivers/scsi/aacraid/rx.c:640: warning: ISO C90 forbids mixed declarations and code drivers/scsi/aacraid/rx.c:649: error: expected declaration or statement at end of input drivers/scsi/aacraid/rx.c:649: warning: control reaches end of non-void function make[3]: *** [drivers/scsi/aacraid/rx.o] Error 1 make[2]: *** [drivers/scsi/aacraid] Error 2 make[1]: *** [drivers/scsi] Error 2 make: *** [drivers] Error 2 I applied it to the scsi-misc tree I pulled yesterday after removing the old patch. Judith On Tue, Apr 03, 2007 at 11:58:17AM -0400, Salyzyn, Mark wrote: > I will do you one better, James, I will slip in a little cleanup in sa.c > (support file for the old PPC based ARC cards) where I discovered the restart > platform function was ALSO left unset which could result in similar pain of > null pointer discovery. > > Please note: The issue Judith ran into, where the card took longer than 3 > minutes to initialize because of a problem drive may require the extension of > the timeout to address (insmod parameter aacraid.startup_timeout=540 may do > the trick). Extending the timeout may have been a fact of life given that the > restart of the adapter normally occurs on BIOS load long before the driver > instantiates settling the problem drives; if this is the case a small and > lower priority follow-up hardening patch can help the users that find adding > the insmod parameter repugnant in order to support kexec and kdump in the > face of problem drives. Problem drives may have lead to the need to get a > kernel dump ... > > You will find enclosed the pristine patch based on the initial patch, > dropping the static function, and adding the three missing platform function > initializations. > > Attached is the patch I feel will address this interrupt issue. As an added > 'perk' I have also added the code to detect if the controller was previously > initialized for interrupted operations by ANY operating system should the > reset_devices kernel parameter not be set and we are dealing with a naïve > kexec without the addition of this kernel parameter. The reset handler is > also improved. Related to reset operations, but not pertinent specifically to > this issue, I have also altered the handling somewhat so that we reset the > adapter if we feel it is taking too long (three minutes) to start up. > > ObligatoryDisclaimer: Please accept my condolences regarding Outlook's > handling of patches. > > This attached patch is against current scsi-misc-2.6 MINUS the initial > version of this patch and the first patch that sets the missing platform > function related to this discussion. > > Signed-off-by: Mark Salyzyn <[EMAIL PROTECTED]> > > --- > > Sincerely -- Mark Salyzyn > > > -----Original Message----- > > From: James Bottomley [mailto:[EMAIL PROTECTED] > > Sent: Tuesday, April 03, 2007 10:52 AM > > To: Salyzyn, Mark > > Cc: Judith Lebzelter; [EMAIL PROTECTED] > > Subject: RE: [PATCH] aacraid: [Fastboot] Panics for AACRAID > > driverduring'insmod' for kexec test. > > > > > > On Tue, 2007-04-03 at 09:30 -0400, Salyzyn, Mark wrote: > > > 0x48 status code means the Firmware is trying to boot the > > Kernel. This > > > phase is most likely blocked because of the hard drive > > failure as you > > > suspected; the kernel is not declared up and running until after the > > > drives have spun up, and a problem drive could be tricking > > the Firmware > > > into a recovery loop holding things back ... > > > > I'm constructing what I hope will be the last pre 2.6.21 > > merge tree ... > > do you have a clean patch with the two necessary fixes for > > the panic you > > can send to the list? > > > > James - To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
