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

Attachment: aacraid_kexec_4.patch
Description: aacraid_kexec_4.patch

Reply via email to