From: Tomas Henzl <thenzl@redhat.com>
To: scameron@beardog.cce.hp.com
Cc: james.bottomley@hansenpartnership.com,
linux-scsi@vger.kernel.org, linux-kernel@vger.kernel.org,
smcameron@yahoo.com, akpm@linux-foundation.org,
mikem@beardog.cce.hp.com
Subject: Re: [PATCH 2/2] hpsa: export resettable_on_kexec host attribute
Date: Wed, 09 Mar 2011 16:33:54 +0100 [thread overview]
Message-ID: <4D779DE2.5030908@redhat.com> (raw)
In-Reply-To: <20110309151457.GI12760@beardog.cce.hp.com>
On 03/09/2011 04:14 PM, scameron@beardog.cce.hp.com wrote:
> On Wed, Mar 09, 2011 at 01:27:53PM +0100, Tomas Henzl wrote:
>
>> On 03/09/2011 12:10 AM, Stephen M. Cameron wrote:
>>
>>> From: Stephen M. Cameron <scameron@beardog.cce.hp.com>
>>>
>>> This attribute, requested by Redhat, allows kexec-tools to know
>>> whether the controller can honor the reset_devices kernel parameter
>>>
>>
> [...]
>
>
>> and actually reset the controller. For kdump to work properly it
>> Hi Stephen,
>>
>> thanks for posting this.
>> Some of the devices are served by the cciss driver by default - I guess
>> a very similar patch for cciss is needed too.
>> Shouldn't be the 0x409C0E11 and 0x409D0E11 (640x boards) also added to the list?
>> (And the 'unknown' devices.)
>>
> There's a bit of a fine point here regarding the unknown devices.
>
> If hpsa_allow_any=1 module parameter is set, then the unknown device
> is considered to be resettable (as it's unknown, it's obviously not
> on the list of known unresettable controllers). If hpsa_allow_any
> is not set, then the unknown devices are not reset -- and the driver
> doesn't even try to do anything with them.
>
> So, the patch is consistent with this, in that if hpsa_allow_any is
> not set, then there won't be any corresponding sysfs entries at all
> for those devices because those devices won't be service by hpsa
> at all. And if hpsa_allow_any is set, then those devices will be
> marked as resettable, and the reset code will attempt to reset them.
>
> I think we've got all the unresettable devices listed (when I add the 6400
> boards to the list of course) and I think we're going to try pretty hard to
> make sure new boards are resettable, so, that's probably ok, right?
>
> Or, do you want to be extra safe, and say that new, unknown boards are assumed
> to be non-resettable? (Since new boards generally mean driver changes to make
> sure the driver knows those boards, that's not such a big deal -- except for
> people who want to continue to use old OSes on new hardware, which, there seem
> to be quite a few of those people.)
>
My comment has targeted the new unknown boards, to resolve this it would be easier
to have a list of resettable controllers. (complement to what it is now).
Fact is, that I forgot that a hpsa_allow_any option has to be set before you can
use an 'unknown' controller and combined with your promise
> we're going to try pretty hard to make sure new boards are resettable
I'm fine with the original approach.
-- tomash
> I think my preference would be to assume that unknown boards are resettable
> if hpsa_allow_any=1, and assume unresettable otherwise (and for purposes of
> sysfs attributes, this is what the patch already does.)
>
> -- steve
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
next prev parent reply other threads:[~2011-03-09 15:35 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-03-08 23:09 [PATCH 0/2] hpsa: add sysfs host attribute to indicate whether reset_devices is honored Stephen M. Cameron
2011-03-08 23:09 ` [PATCH 1/2] hpsa: move device attributes to avoid forward declarations Stephen M. Cameron
2011-03-08 23:10 ` [PATCH 2/2] hpsa: export resettable_on_kexec host attribute Stephen M. Cameron
2011-03-09 6:33 ` Américo Wang
2011-03-09 14:36 ` scameron
2011-03-09 14:36 ` scameron
2011-03-09 12:27 ` Tomas Henzl
2011-03-09 14:27 ` scameron
2011-03-09 15:14 ` scameron
2011-03-09 15:33 ` Tomas Henzl [this message]
2011-03-09 14:36 ` Vivek Goyal
2011-03-09 14:51 ` scameron
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4D779DE2.5030908@redhat.com \
--to=thenzl@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=james.bottomley@hansenpartnership.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-scsi@vger.kernel.org \
--cc=mikem@beardog.cce.hp.com \
--cc=scameron@beardog.cce.hp.com \
--cc=smcameron@yahoo.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.