Re: [Fastboot] [RFC] [PATCH 2/2] kdump: cciss driver initialization issue fix
- From: Vivek Goyal <vgoyal@xxxxxxxxxx>
- Date: Mon, 26 Jun 2006 15:43:03 -0400
On Mon, Jun 26, 2006 at 01:21:04PM -0600, Eric W. Biederman wrote:
[..]
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.
Ok. Reasonable. Roughly long does that take? 1 millisecond? 1 second?
1 minute? 1 hour?
IIRC, for MPT fusion, this delay was in order of seconds.
And I suspect this is a hard reset, also. Not sure if that wouldwould not
negatively impact kdump. If there were some condition we could test
against and perform the reset when that condition is met it
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.
Not bad as in broken. But bad as in unexpected. If it is just a matter
of outstanding commands we might even be able to just ask the adapter
to cancel all of the at initialization time.
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.
Sounds like a start.
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.
Well I would certainly print a warning.
cciss already prints a warning message if it receives a command completion
message which driver thinks it has not issued. But what do you do after
that? Simply ignore it and assume that everything is fine or you think that
there is something wrong with the device (During normal boot it should
not happen) and raise a BUG()?
Thanks
Vivek
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
- References:
- RE: [Fastboot] [RFC] [PATCH 2/2] kdump: cciss driver initialization issue fix
- From: Miller, Mike (OS Dev)
- Re: [Fastboot] [RFC] [PATCH 2/2] kdump: cciss driver initialization issue fix
- From: Eric W. Biederman
- RE: [Fastboot] [RFC] [PATCH 2/2] kdump: cciss driver initialization issue fix
- Prev by Date: Re: [Fastboot] [RFC] [PATCH 2/2] kdump: cciss driver initialization issue fix
- Next by Date: Re: [RFC][PATCH] delay accounting taskstats interface send tgid once
- Previous by thread: Re: [Fastboot] [RFC] [PATCH 2/2] kdump: cciss driver initialization issue fix
- Next by thread: RE: [Fastboot] [RFC] [PATCH 2/2] kdump: cciss driver initialization issue fix
- Index(es):
Relevant Pages
|