Patch 1/1
If hpsa is selected as the Smart Array driver cciss may try to load in the
kdump kernel. When this happens kdump fails and a core file cannot be created.
This patch prevents cciss from trying to load in this scenario. This effects
primarily older Smart Array controllers.
From: Mike Miller <[email protected]>
Signed-off-by: Mike Miller <[email protected]>
---
drivers/block/cciss.c | 6 ++++++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/drivers/block/cciss.c b/drivers/block/cciss.c
index 1c1b8e5..a6c0973 100644
--- a/drivers/block/cciss.c
+++ b/drivers/block/cciss.c
@@ -4960,6 +4960,12 @@ static int cciss_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
ctlr_info_t *h;
unsigned long flags;
+ /*
+ * if this is the kdump kernel and the user has set the flags to
+ * use hpsa rather than cciss just bail
+ */
+ if ((reset_devices) && (cciss_allow_hpsa == 1))
+ return -ENODEV;
rc = cciss_init_reset_devices(pdev);
if (rc) {
if (rc != -ENOTSUPP)
On Mon, 15 Apr 2013 12:59:06 -0500 Mike Miller <[email protected]> wrote:
> Patch 1/1
>
> If hpsa is selected as the Smart Array driver cciss may try to load in the
> kdump kernel. When this happens kdump fails and a core file cannot be created.
> This patch prevents cciss from trying to load in this scenario. This effects
> primarily older Smart Array controllers.
>
OK, this is weird. kdump and scsi drivers are pretty darn remote things
and I've never heard of such an interaction. Can you tell us a bit more
about how and why this happened? Is there something special about
cciss, or can we expect similar kdump interactions with other device drivers?
On Mon, 15 Apr 2013 12:59:06 -0500 Mike Miller <[email protected]> wrote:
> Patch 1/1
>
> If hpsa is selected as the Smart Array driver cciss may try to load in the
> kdump kernel. When this happens kdump fails and a core file cannot be created.
> This patch prevents cciss from trying to load in this scenario. This effects
> primarily older Smart Array controllers.
>
> ...
>
> --- a/drivers/block/cciss.c
> +++ b/drivers/block/cciss.c
> @@ -4960,6 +4960,12 @@ static int cciss_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
> ctlr_info_t *h;
> unsigned long flags;
>
> + /*
> + * if this is the kdump kernel and the user has set the flags to
> + * use hpsa rather than cciss just bail
> + */
> + if ((reset_devices) && (cciss_allow_hpsa == 1))
> + return -ENODEV;
OK, wazzup. That's the only occurrence of the symbol
"cciss_allow_hpsa" in Linux and needless to say, the compiler laughed
at me.
On Tue, 2013-04-16 at 15:00 -0700, Andrew Morton wrote:
> On Mon, 15 Apr 2013 12:59:06 -0500 Mike Miller <[email protected]> wrote:
>
> > Patch 1/1
> >
> > If hpsa is selected as the Smart Array driver cciss may try to load in the
> > kdump kernel. When this happens kdump fails and a core file cannot be created.
> > This patch prevents cciss from trying to load in this scenario. This effects
> > primarily older Smart Array controllers.
> >
>
> OK, this is weird. kdump and scsi drivers are pretty darn remote things
> and I've never heard of such an interaction. Can you tell us a bit more
> about how and why this happened? Is there something special about
> cciss, or can we expect similar kdump interactions with other device drivers?
I thought it was weird, too. I've never seen this happen before and it
was very hard to duplicate this in the lab. I think the reason it did
happen was twofold. The cciss driver was being loaded first from the
kdump initramfs image and the driver load sequence is now different than
it used to be. We used to call cciss_pci_init as one the first things we
did from our probe function, cciss_init_one. Now if reset_devices is
true we immediately call into cciss_hard_reset controller and we do not
check to see if cciss_allow_hpsa is set. Sorry, that's the best
explanation I have.
Offhand, I don't know of any of any other hardware devices that have 2
distinctly different drivers, one block and one scsi. So I don't _think_
this would happen with other drivers/devices.
-- mikem
>
>
On Wed, 2013-04-17 at 15:02 -0700, Andrew Morton wrote:
> On Mon, 15 Apr 2013 12:59:06 -0500 Mike Miller <[email protected]> wrote:
>
> > Patch 1/1
> >
> > If hpsa is selected as the Smart Array driver cciss may try to load in the
> > kdump kernel. When this happens kdump fails and a core file cannot be created.
> > This patch prevents cciss from trying to load in this scenario. This effects
> > primarily older Smart Array controllers.
> >
> > ...
> >
> > --- a/drivers/block/cciss.c
> > +++ b/drivers/block/cciss.c
> > @@ -4960,6 +4960,12 @@ static int cciss_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
> > ctlr_info_t *h;
> > unsigned long flags;
> >
> > + /*
> > + * if this is the kdump kernel and the user has set the flags to
> > + * use hpsa rather than cciss just bail
> > + */
> > + if ((reset_devices) && (cciss_allow_hpsa == 1))
> > + return -ENODEV;
>
> OK, wazzup. That's the only occurrence of the symbol
> "cciss_allow_hpsa" in Linux and needless to say, the compiler laughed
> at me.
Argh. Sorry about that. I could have sworn I tested that on rc7. I'll
have another patch ready in a bit to add the flag.
>