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 <aacraid@xxxxxxxxxxx> --- Sincerely -- Mark Salyzyn > -----Original Message----- > From: James Bottomley [mailto:James.Bottomley@xxxxxxxxxxxx] > Sent: Tuesday, April 03, 2007 10:52 AM > To: Salyzyn, Mark > Cc: Judith Lebzelter; vgoyal@xxxxxxxxxx > 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
Attachment:
aacraid_kexec_4.patch
Description: aacraid_kexec_4.patch
