From: Michael Reed <mdr@sgi.com>
To: linux-scsi <linux-scsi@vger.kernel.org>,
"Moore, Eric" <Eric.Moore@lsi.com>,
"Prakash, Sathya" <Sathya.Prakash@lsi.com>
Cc: Michael Reed <mdr@sgi.com>, Jeremy Higdon <jeremy@sgi.com>
Subject: [PATCH 1/1] Fusion SAS and Fibre Channel: target missing after resetting external raid
Date: Tue, 04 Mar 2008 10:50:38 -0600 [thread overview]
Message-ID: <47CD7DDE.7030907@sgi.com> (raw)
Following a hard reset of a SAS raid, one of the raid targets is occasionally
missing. I tracked this down to a pretty obscure little bug.
The LSI fusion drivers for SAS and Fibre Channel both use their respective
transport layers. Those transport layers increment the target number
assigned to new targets.
The routine __scsi_scan_target uses the "this_id" element of the Scsi_Host
structure to avoid scanning the scsi host adapter. Both fusion drivers set
"this_id" from a value returned in a firmware PortFacts response. For my
particular test case (SAS) the firmware id assigned to the initiator was
173. After enough raid resets to cause the raid targets to go and come a
sufficient number of times, the id assigned by the transport to a raid
target would match the id assigned by the host adapter to the "this_id"
field, resulting in that target not being scanned.
static void __scsi_scan_target(struct device *parent, unsigned int channel,
unsigned int id, unsigned int lun, int rescan)
{
struct Scsi_Host *shost = dev_to_shost(parent);
int bflags = 0;
int res;
struct scsi_target *starget;
if (shost->this_id == id)
/*
* Don't scan the host adapter
*/
return;
....
The fix is simple. Fusion SAS and Fibre Channel (subject to same bug) should
just leave "this_id" initialized to "-1".
Applies to 2.6.25-rc3-git5.
Signed-off-by: Michael Reed <mdr@sgi.com>
--
--- kou/drivers/message/fusion/mptfc.c 2008-01-24 16:58:37.000000000 -0600
+++ ko/drivers/message/fusion/mptfc.c 2008-03-04 09:01:18.428176326 -0600
@@ -1238,8 +1238,6 @@ mptfc_probe(struct pci_dev *pdev, const
sh->max_id = ioc->pfacts->MaxDevices;
sh->max_lun = max_lun;
- sh->this_id = ioc->pfacts[0].PortSCSIID;
-
/* Required entry.
*/
sh->unique_id = ioc->id;
--- kou/drivers/message/fusion/mptsas.c 2008-03-04 08:38:58.000000000 -0600
+++ ko/drivers/message/fusion/mptsas.c 2008-03-04 09:01:04.284807301 -0600
@@ -3176,8 +3176,6 @@ mptsas_probe(struct pci_dev *pdev, const
sh->transportt = mptsas_transport_template;
- sh->this_id = ioc->pfacts[0].PortSCSIID;
-
/* Required entry.
*/
sh->unique_id = ioc->id;
next reply other threads:[~2008-03-04 16:50 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-03-04 16:50 Michael Reed [this message]
2008-03-04 17:22 ` [PATCH 1/1] Fusion SAS and Fibre Channel: target missing after resetting external raid Moore, Eric
2008-03-13 19:53 ` Michael Reed
2008-03-20 22:46 ` Moore, Eric
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=47CD7DDE.7030907@sgi.com \
--to=mdr@sgi.com \
--cc=Eric.Moore@lsi.com \
--cc=Sathya.Prakash@lsi.com \
--cc=jeremy@sgi.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 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.