RE: [Fastboot] [RFC] [PATCH 2/2] kdump: cciss driver initialization issue fix

["Miller, Mike (OS Dev)" <Mike.Miller@hp.com>]

> -----Original Message-----
> From: Eric W. Biederman [mailto:ebiederm@xmission.com] 
> Sent: Monday, June 26, 2006 12:52 PM
> To: Miller, Mike (OS Dev)
> Cc: vgoyal@in.ibm.com; Maneesh Soni; Andrew Morton; 
> Neela.Kolli@engenio.com; linux-scsi@vger.kernel.org; 
> fastboot@lists.osdl.org; linux-kernel@vger.kernel.org
> Subject: Re: [Fastboot] [RFC] [PATCH 2/2] kdump: cciss driver 
> initialization issue fix
> 
> "Miller, Mike (OS Dev)" <Mike.Miller@hp.com> writes:
> 
> > Thanks Eric, that helps me understand. Section 8.2.2 of the 
> open cciss 
> > spec supports a reset message. Target 0x00 is the 
> controller. We could 
> > add this to the init routine to ensure the board is made sane again 
> > but this would drastically increase init time under normal 
> circumstances.
> 
> Where does the init time penalty come from? How large is the 
> init penalty?  I suspect it is from waiting for the scsi 
> disks to spin up.
> But I am just guessing in the dark.

The penalty is in the firmware and self-test operations.

> 
> > And I suspect this is a hard reset, also. Not sure if that would 
> > negatively impact kdump. If there were some condition we could test 
> > against and perform the reset when that condition is met it 
> would not 
> > impact 99.9% of users.
> 
> I am wondering if it is possible to look at the controller 
> and see if it is in a bad state, (i.e. in some state besides 
> just coming out of reset) and if so issue a reset.  If this 
> really is a long operation that would be the ideal way to handle it.

It's not really in a bad state at this time, is it? Maybe some commands
hanging around.

> 
> If the amount of time is really user noticeable and testing 
> for it is impossible then it is probably time to talk kernel 
> command line options.

I was informed of the crashboot command line parameter. I can implement
that as a test.

> 
> Although it might simply be appropriate to handle commands 
> completing you didn't start.  I am not at all familiar with 
> that particular piece of hardware so I can't make a good 
> guess on what needs to happen there.

Not sure about doing this.

mikem
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/