From: James Bottomley <James.Bottomley@HansenPartnership.com>
To: Adam Talbot <ajtalbot1@gmail.com>
Cc: linux-scsi@vger.kernel.org
Subject: Re: mvsas panics and dies when attached to a port extender on newer kernels
Date: Wed, 15 Apr 2015 22:16:01 -0700 [thread overview]
Message-ID: <1429161361.2608.4.camel@HansenPartnership.com> (raw)
In-Reply-To: <CAH_2GhcsaDoxuxBwTT7cUsfp+5e_KjxtkJ4tFE1N05U=FCkJnA@mail.gmail.com>
On Tue, 2015-04-14 at 14:41 -0700, Adam Talbot wrote:
> Removing the sas expander and attaching the SATA drives directly works
> just fine. I had to limp along with the drives direct attached for a
> while, while debugging.
Well, that narrows it down. It looks like there's a longstanding bug in
mvs_task_prep_ata() where the physical PHY field is populated by taking
an index through the HBA phy table. This field is ignored for STP but
the phy table is too small and it uses the expander phy number to index
it (hence the GPF as we fall off the end of the phy table trying to
dereference sas_phy->id).
This should fix the problem.
James
---
diff --git a/drivers/scsi/mvsas/mv_sas.c b/drivers/scsi/mvsas/mv_sas.c
index 2d5ab6d..454536c 100644
--- a/drivers/scsi/mvsas/mv_sas.c
+++ b/drivers/scsi/mvsas/mv_sas.c
@@ -441,14 +441,11 @@ static u32 mvs_get_ncq_tag(struct sas_task *task, u32 *tag)
static int mvs_task_prep_ata(struct mvs_info *mvi,
struct mvs_task_exec_info *tei)
{
- struct sas_ha_struct *sha = mvi->sas;
struct sas_task *task = tei->task;
struct domain_device *dev = task->dev;
struct mvs_device *mvi_dev = dev->lldd_dev;
struct mvs_cmd_hdr *hdr = tei->hdr;
struct asd_sas_port *sas_port = dev->port;
- struct sas_phy *sphy = dev->phy;
- struct asd_sas_phy *sas_phy = sha->sas_phy[sphy->number];
struct mvs_slot_info *slot;
void *buf_prd;
u32 tag = tei->tag, hdr_tag;
@@ -468,7 +465,7 @@ static int mvs_task_prep_ata(struct mvs_info *mvi,
slot->tx = mvi->tx_prod;
del_q = TXQ_MODE_I | tag |
(TXQ_CMD_STP << TXQ_CMD_SHIFT) |
- (MVS_PHY_ID << TXQ_PHY_SHIFT) |
+ ((sas_port->phy_mask & TXQ_PHY_MASK) << TXQ_PHY_SHIFT) |
(mvi_dev->taskfileset << TXQ_SRS_SHIFT);
mvi->tx[mvi->tx_prod] = cpu_to_le32(del_q);
next prev parent reply other threads:[~2015-04-16 5:16 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-04-14 21:03 mvsas panics and dies when attached to a port extender on newer kernels Adam Talbot
2015-04-14 21:16 ` James Bottomley
2015-04-14 21:41 ` Adam Talbot
2015-04-16 5:16 ` James Bottomley [this message]
2015-04-16 17:26 ` Adam Talbot
2015-04-16 17:28 ` James Bottomley
2015-04-16 17:31 ` Adam Talbot
2015-04-17 2:26 ` Adam Talbot
2015-04-14 21:46 ` Laurence Oberman
-- strict thread matches above, loose matches on Subject: below --
2015-04-13 15:11 Adam Talbot
2015-04-23 11:10 ` Ceriel Jacobs
2015-04-23 16:27 ` Adam Talbot
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=1429161361.2608.4.camel@HansenPartnership.com \
--to=james.bottomley@hansenpartnership.com \
--cc=ajtalbot1@gmail.com \
--cc=linux-scsi@vger.kernel.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox