headers
Dan Williams | 1 Oct 2011 03:43
Picon
Favicon

Re: [PATCH] [SCSI] libsas panic when single phy disabled on a wide port

On Thu, Sep 29, 2011 at 7:21 PM, Jack Wang <jack_wang <at> usish.com> wrote:
> I can reproduce this bug, so I'm ok to get this fix in.
>

Mark admits this is a band aid.  I'd like to understand the root cause
of why the port is NULL here.
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply | 7 comments |
headers
Dan Williams | 1 Oct 2011 03:49
Picon
Favicon

Re: [PATCH 1/5] isci: atapi support

On Wed, Sep 28, 2011 at 6:47 PM, Dan Williams <dan.j.williams <at> intel.com> wrote:
> Based on original implementation from Jiangbi Liu and Maciej Trela.
>
> ATAPI transfers happen in two-to-three stages.  The two stage atapi
> commands are those that include a dma data transfer.  The data transfer
> portion of these operations is handled by the hardware packet-dma
> acceleration.  The three-stage commands do not have a data transfer and
> are handled without hardware assistance in raw frame mode.
>
> stage1: transmit host-to-device fis to notify the device of an incoming
> atapi cdb.  Upon reception of the pio-setup-fis repost the task_context
> to perform the dma transfer of the cdb+data (go to stage3), or repost
> the task_context to transmit the cdb as a raw frame (go to stage 2).
>
> stage2: wait for hardware notification of the cdb transmission and then
> go to stage 3.
>
> stage3: wait for the arrival of the terminating device-to-host fis and
> terminate the command.
>
> To keep the implementation simple we only support ATAPI packet-dma
> protocol (for commands with data) to avoid needing to handle the data
> transfer manually (like we do for SATA-PIO).  This may affect
> compatibility for a small number of devices (see
> ATA_HORKAGE_ATAPI_MOD16_DMA).
>
> If the data-transfer underruns, or encounters an error the
> device-to-host fis is expected to arrive in the unsolicited frame queue
> to pass to libata for disposition.  However, in the DONE_UNEXP_FIS (data
> underrun) case it appears we need to craft a response.  In the
(Continue reading)

Permalink | Reply | 0 comments |
headers
Dan Williams | 1 Oct 2011 03:52
Picon
Favicon

[PATCH v2] isci: atapi support

Based on original implementation from Jiangbi Liu and Maciej Trela.

ATAPI transfers happen in two-to-three stages.  The two stage atapi
commands are those that include a dma data transfer.  The data transfer
portion of these operations is handled by the hardware packet-dma
acceleration.  The three-stage commands do not have a data transfer and
are handled without hardware assistance in raw frame mode.

stage1: transmit host-to-device fis to notify the device of an incoming
atapi cdb.  Upon reception of the pio-setup-fis repost the task_context
to perform the dma transfer of the cdb+data (go to stage3), or repost
the task_context to transmit the cdb as a raw frame (go to stage 2).

stage2: wait for hardware notification of the cdb transmission and then
go to stage 3.

stage3: wait for the arrival of the terminating device-to-host fis and
terminate the command.

To keep the implementation simple we only support ATAPI packet-dma
protocol (for commands with data) to avoid needing to handle the data
transfer manually (like we do for SATA-PIO).  This may affect
compatibility for a small number of devices (see
ATA_HORKAGE_ATAPI_MOD16_DMA).

If the data-transfer underruns, or encounters an error the
device-to-host fis is expected to arrive in the unsolicited frame queue
to pass to libata for disposition.  However, in the DONE_UNEXP_FIS (data
underrun) case it appears we need to craft a response.  In the
DONE_REG_ERR case we do receive the UF and propagate it to libsas.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Dan Williams | 1 Oct 2011 03:55
Picon
Favicon

Re: [GIT PATCH 0/5] isci updates for 3.2

On Wed, Sep 28, 2011 at 6:47 PM, Dan Williams <dan.j.williams <at> intel.com> wrote:
> This series functionally depends on the pending libsas fix for ata lun
> scanning.  For convenience those updates have been queued to
> "git://github.com:djbw/linux.git libsas".
>
> The following changes since commit 7705375e944ea94be7941b740efd0a77bb109cb1:
>
>  libsas: remove unused ata_task_resp fields (2011-09-28 18:06:10 -0700)
>
> are available in the git repository at:
>  git://github.com:djbw/linux.git isci
>
> The prominent update in this set is atapi support.  The rest are small
> bug fixes and feature enhancements.  More error handling and command
> termination fixes are in the works.
>

Reflowed with the fixed version of the atapi patch.

diff --git a/drivers/scsi/isci/request.c b/drivers/scsi/isci/request.c
index cb3dd6e..565a9f0 100644
--- a/drivers/scsi/isci/request.c
+++ b/drivers/scsi/isci/request.c
 <at>  <at>  -3106,7 +3106,8  <at>  <at>  static void
sci_request_started_state_enter(struct sci_base_state_machine *sm)
                        state = SCI_REQ_STP_PIO_WAIT_H2D;
                }
        } else {
-               BUG();
+               /* SSP or NCQ are fully accelerated, no substates */
(Continue reading)

Permalink | Reply | 0 comments |
headers
Dan Williams | 1 Oct 2011 04:04
Picon
Favicon

Re: [GIT PULL] libsas updates for 3.2

On Wed, Sep 28, 2011 at 7:01 PM, Dan Williams <dan.j.williams <at> intel.com> wrote:
> The following changes since commit 41e9a69641fb3fa86fa9277a179f3ad261d072f7:
>
>  [SCSI] ipr: Stop reading adapter dump prematurely (2011-09-22 15:30:28 +0400)
>
> are available in the git repository at:
>  git://github.com:djbw/linux.git libsas
>
> These have all appeared on the mailing list previously save for the last
> one "libsas: remove unused ata_task_resp fields" (just a cleanup).
>
> Just a convenience branch since isci's atapi support needed the lun
> scanning fixup as a baseline.
>

Given that none of the patches on the libsas-fixes branch would pass
Linus' "does this fix a known regression" test for late rc changes I
have gone ahead and moved those patches over to the libsas branch.  No
other changes have been made.

The locking fix might be a consideration, but since it has been this
way for quite a few releases we can wait for the 3.2 merge and submit
it to -stable.

--
Dan

The following changes since commit 41e9a69641fb3fa86fa9277a179f3ad261d072f7:

  [SCSI] ipr: Stop reading adapter dump prematurely (2011-09-22 15:30:28 +0400)
(Continue reading)

Permalink | Reply | 0 comments |
headers
Arnd Bergmann | 1 Oct 2011 22:03
Picon
Gravatar

[PATCH 03/26] scsi/mvsas: use proper namespace for IRQ_* symbols

The identifiers in the mvsas driver conflict with platform specific
interrupt definitions of the same name, so better prefix them
with MVS_ to avoid the collision.

Signed-off-by: Arnd Bergmann <arnd <at> arndb.de>
Cc: Xiangliang Yu <yuxiangl <at> marvell.com>
Cc: James Bottomley <James.Bottomley <at> suse.de>
Cc: linux-scsi <at> vger.kernel.org
---
 drivers/scsi/mvsas/mv_94xx.c |   10 +++---
 drivers/scsi/mvsas/mv_94xx.h |   58 +++++++++++++++++++++---------------------
 2 files changed, 34 insertions(+), 34 deletions(-)

diff --git a/drivers/scsi/mvsas/mv_94xx.c b/drivers/scsi/mvsas/mv_94xx.c
index 3501291..9c12e03 100644
--- a/drivers/scsi/mvsas/mv_94xx.c
+++ b/drivers/scsi/mvsas/mv_94xx.c
 <at>  <at>  -534,7 +534,7  <at>  <at>  static void mvs_94xx_interrupt_enable(struct mvs_info *mvi)
 	u32 tmp;

 	tmp = mr32(MVS_GBL_CTL);
-	tmp |= (IRQ_SAS_A | IRQ_SAS_B);
+	tmp |= (MVS_IRQ_SAS_A | MVS_IRQ_SAS_B);
 	mw32(MVS_GBL_INT_STAT, tmp);
 	writel(tmp, regs + 0x0C);
 	writel(tmp, regs + 0x10);
 <at>  <at>  -550,7 +550,7  <at>  <at>  static void mvs_94xx_interrupt_disable(struct mvs_info *mvi)

 	tmp = mr32(MVS_GBL_CTL);
(Continue reading)

Permalink | Reply | 0 comments |
headers
Dan Carpenter | 2 Oct 2011 00:59
Picon
Favicon

[patch] target: unlock on error in pscsi_create_virtdevice()

This function should take the lock on success but on the error cases
it doesn't.

Signed-off-by: Dan Carpenter <dan.carpenter <at> oracle.com>

diff --git a/drivers/target/target_core_pscsi.c b/drivers/target/target_core_pscsi.c
index ba9e94d..b619596 100644
--- a/drivers/target/target_core_pscsi.c
+++ b/drivers/target/target_core_pscsi.c
 <at>  <at>  -567,7 +567,7  <at>  <at>  static struct se_device *pscsi_create_virtdevice(
 			if (IS_ERR(sh)) {
 				pr_err("pSCSI: Unable to locate"
 					" pdv_host_id: %d\n", pdv->pdv_host_id);
-				return (struct se_device *) sh;
+				return ERR_CAST(sh);
 			}
 		}
 	} else {
 <at>  <at>  -609,6 +609,7  <at>  <at>  static struct se_device *pscsi_create_virtdevice(
 				hba->hba_flags &= ~HBA_FLAGS_PSCSI_MODE;
 			}
 			pdv->pdv_sd = NULL;
+			spin_unlock_irq(sh->host_lock);
 			return ERR_PTR(-ENODEV);
 		}
 		return dev;
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
(Continue reading)

Permalink | Reply | 2 comments |
headers
James Bottomley | 2 Oct 2011 19:18

Re: [RFT PATCH] libsas: fix port->dev_list locking

On Wed, 2011-09-21 at 22:05 -0700, Dan Williams wrote:
> port->dev_list maintains a list of devices attached to a given sas root port.
> It needs to be mutated under a lock as contexts outside of the
> single-threaded-libsas-workqueue access the list via sas_find_dev_by_rphy().
> Fixup locations where the list was being mutated without a lock.
> 
> This is a follow-up to commit 5911e963 "[SCSI] libsas: remove expander
> from dev list on error", where Luben noted [1]:
> 
>     > 2/ We have unlocked list manipulations in sas_ex_discover_end_dev(),
>     > sas_unregister_common_dev(), and sas_ex_discover_end_dev()
> 
>     Yes, I can see that and that is very unfortunate.
> 
> [1]: http://marc.info/?l=linux-scsi&m=131480962006471&w=2

Since this call for testing was issued 11 days ago, did anyone actually
test this patch?

James

--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply | 1 comment |
headers
@@@ | 2 Oct 2011 16:02
Picon
Favicon

Lieber Freund!!!


-- 
Lieber Freund!!!

Ich vermute das diese E-Mail eine Überraschung für Sie sein wird, aber es
ist wahr.Ich bin bei einer routinen Überprüfung in meiner Bank (Union Bank
PLC von Süd Afrika) wo ich arbeite, auf einem Konto gestoßen, was nicht in
anspruch genommen worden ist, wo derzeit USD$18.5M (Achtzehn Million, Fünf
Hundert Tausend, US Dollar)  gutgeschrieben sind. Dieses Konto gehörte
Herrn Peter Hartmann, der ein Kunde in unsere Bank war, der leider
verstorben ist. Herr Hartmann war ein gebürtiger Deutscher.

Damit es mir möglich ist dieses Geld $18,500,000 inanspruch
zunehmen,benötige ich die zusammenarbeit eines Ausländischen Partners wie
Sie,den ich als Verwandter und Erbe des verstorbenen Herrn Hartmann
vorstellen kann,damit wir das Geld inanspruch nehmen können. Für diese
Unterstützung erhalten Sie 30% der Erbschaftsumme und die restlichen 70%
teile ich mir mit meinen zwei Arbeitskollegen, die mich bei dieser
Transaktion ebenfalls unterstützen.Wenn Sie interessiert sind, können Sie
mir bitte eine E-Mail schicken, damit ich Ihnen mehr Details zukommen
lassen kann.

N.B.BITTE SENDEN SIE MIR LEWIS AWELE ANTWORT ZU durch mein E-mail:
(herrawel <at> aim.com )fÜR VERTRAULICHEN GRUND. Schicken Sie keine POST ZU
MEINEM BÜRO-E-MAIL. If you understand english,please kindly reply with
english

Mit freundlichen Grüßen

Herr LEWIS AWELE
(Continue reading)

Permalink | Reply | 0 comments |
headers
Mark Salyzyn | 3 Oct 2011 15:07

RE: [PATCH] [SCSI] libsas panic when single phy disabled on a wide port

100% agree with Dan! In fact it is my fault for not digging deeper when
I had the duplication relatively close at hand (but production pressures
had me move on, in my defense). I definitely attacked the symptom. The
patch is a piece of hardening, which can remain as paranoia after the
root cause has properly been discovered (turned into a BUG() likely).

I have lost the resources to duplicate this problem at the moment.

Sincerely -- Mark Salyzyn

-----Original Message-----
From: dan.j.williams <at> gmail.com [mailto:dan.j.williams <at> gmail.com] On
Behalf Of Dan Williams
Sent: Friday, September 30, 2011 9:43 PM
To: Jack Wang
Cc: Mark Salyzyn; linux-scsi <at> vger.kernel.org; Darrick Wong; Xiangliang
Yu; Luben Tuikov; James Bottomley
Subject: Re: [PATCH] [SCSI] libsas panic when single phy disabled on a
wide port

On Thu, Sep 29, 2011 at 7:21 PM, Jack Wang <jack_wang <at> usish.com> wrote:
> I can reproduce this bug, so I'm ok to get this fix in.
>

Mark admits this is a band aid.  I'd like to understand the root cause
of why the port is NULL here.
______________________________________________________________________
This email may contain privileged or confidential information, which should only be used for the purpose
for which it was sent by Xyratex. No further rights or licenses are granted to use such information. If you
are not the intended recipient of this message, please notify the sender by return and delete it. You may
(Continue reading)

Permalink | Reply | 6 comments |

Gmane