Messages in this thread | | | Subject | RE: [Fastboot] [RFC] [PATCH 2/2] kdump: cciss driver initialization issue fix | Date | Mon, 26 Jun 2006 13:51:43 -0500 | From | "Miller, Mike (OS Dev)" <> |
| |
> -----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/
| |