> -----Original Message----- > From: Eric W. Biederman [mailto:ebiederm@xxxxxxxxxxxx] > Sent: Monday, June 26, 2006 12:52 PM > To: Miller, Mike (OS Dev) > Cc: vgoyal@xxxxxxxxxx; Maneesh Soni; Andrew Morton; > Neela.Kolli@xxxxxxxxxxx; linux-scsi@xxxxxxxxxxxxxxx; > fastboot@xxxxxxxxxxxxxx; linux-kernel@xxxxxxxxxxxxxxx > Subject: Re: [Fastboot] [RFC] [PATCH 2/2] kdump: cciss driver > initialization issue fix > > "Miller, Mike (OS Dev)" <Mike.Miller@xxxxxx> 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 - : send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
