Re: [PATCHv3 0/2] target: make location of /var/targets configurable

[Nicholas A. Bellinger]

On Thu, 2016-06-09 at 16:51 -0700, Lee Duncan wrote:
> Ping?
> 
> We really need to move the target database out of /var/target
> 

This series has already merged up for v4.7-rc1.

--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2] Add support for SCT Write Same

[Shaun Tancheff]

On Thu, Jun 9, 2016 at 4:22 AM, Christoph Hellwig  wrote:
>> + if (ata_id_sct_write_same(dev->id))
>> + sdev->sct_write_same = 1;
>> +
>
> What's the point of this flag?  It should simply clear the no_write_same
> flag for this device.  Due to the way how we have both a per-host and
> per-device flag that might not be completely trivial, but untangling
> that mess might be a good idea anyway.

Agreed. I looks like clearing the no_write_same flag mostly works
but the queue limits don't make any sense because they get cleared.
I'll see if I can untangle it.

>> @@ -3305,6 +3308,37 @@ static unsigned int ata_scsi_write_same_xlat(struct 
>> ata_queued_cmd *qc)
>>   goto invalid_param_len;
>>
>>   buf = page_address(sg_page(scsi_sglist(scmd)));
>> +
>> + if (ata_id_sct_write_same(dev->id)) {
>
> Various comments:
>
>  - The plain page_address above looks harmful, how do we know that
>the page is mapped into kernel memory?  This might actually be broken
>already, though.

I think it just happens to work because it's always used with a recently
allocated page. Fixing it to include the (possible) offset is just a good thing.

>  - Why is this below the check that rejects non-unmap WRITE SAME
>commands?

Yeah, tunnel vision. For some reason I was thinking that it was
either WRITE SAME or SCT. But this case is actually TRIM and/or SCT which
makes the demuxing what the user expects a little less clear.

Now I am thinking that the cleanest method is to try and honor the unmap
flag to pick the command path.

If trim is available and unmap is set then you get the current behavior.
else if SCT is available follow the SCT path
else fail with the current error (unmap is not set).

In this way if you device supports both TRIM and SCT then you can WRITE SAME
or TRIM.

>  - Shouldn't we still translate discard command to TRIM?  Maybe we
>need a check of the operation in the request structure..
>

-- 
Shaun Tancheff
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] scsi:stex.c Support Pegasus 3 product

[Julian Calaby]

Hi Charles,

On Mon, Jun 6, 2016 at 5:53 PM, Charles Chiou  wrote:
> From: Charles 
>
> Pegasus series is a RAID support product by using Thunderbolt technology.
>
> The newest product, Pegasus 3 is support Thunderbolt 3 technology with 
> another chip.
>
> 1.Change driver version.
>
> 2.Add Pegasus 3 VID, DID and define it's device address.
>
> 3.Pegasus 3 use msi interrupt, so stex_request_irq P3 type enable msi.
>
> 4.For hibernation, use msi_lock in stex_ss_handshake to prevent msi register 
> write again when handshaking.
>
> 5.Pegasus 3 don't need read() as flush.
>
> 6.In stex_ss_intr & stex_abort, P3 only clear interrupt register when getting 
> vendor defined interrupt.
>
> 7.Add reboot notifier and register it in stex_probe for all supported device.
>
> 8.For all supported device in restart flow, we get a callback from notifier 
> and set S6flag for stex_shutdown & stex_hba_stop to send restart command to 
> FW.
>
> Signed-off-by: Charles 
> Signed-off-by: Paul 
> ---
>  drivers/scsi/stex.c | 282 
> +++-
>  1 file changed, 214 insertions(+), 68 deletions(-)
>
> diff --git a/drivers/scsi/stex.c b/drivers/scsi/stex.c
> index 5b23175..9de2de2 100644
> --- a/drivers/scsi/stex.c
> +++ b/drivers/scsi/stex.c
> @@ -87,7 +95,7 @@ enum {
> MU_STATE_STOP   = 5,
> MU_STATE_NOCONNECT  = 6,
>
> -   MU_MAX_DELAY= 120,
> +   MU_MAX_DELAY= 50,

This won't cause problems for older adapters, right?

> MU_HANDSHAKE_SIGNATURE  = 0x5555,
> MU_HANDSHAKE_SIGNATURE_HALF = 0x5a5a,
> MU_HARD_RESET_WAIT  = 3,
> @@ -540,11 +556,15 @@ stex_ss_send_cmd(struct st_hba *hba, struct req_msg 
> *req, u16 tag)
>
> ++hba->req_head;
> hba->req_head %= hba->rq_count+1;
> -
> -   writel((addr >> 16) >> 16, hba->mmio_base + YH2I_REQ_HI);
> -   readl(hba->mmio_base + YH2I_REQ_HI); /* flush */
> -   writel(addr, hba->mmio_base + YH2I_REQ);
> -   readl(hba->mmio_base + YH2I_REQ); /* flush */
> +   if (hba->cardtype == st_P3) {
> +   writel((addr >> 16) >> 16, hba->mmio_base + YH2I_REQ_HI);
> +   writel(addr, hba->mmio_base + YH2I_REQ);
> +   } else {
> +   writel((addr >> 16) >> 16, hba->mmio_base + YH2I_REQ_HI);
> +   readl(hba->mmio_base + YH2I_REQ_HI); /* flush */
> +   writel(addr, hba->mmio_base + YH2I_REQ);
> +   readl(hba->mmio_base + YH2I_REQ); /* flush */
> +   }

The first writel() lines in each branch of the if statement are
identical, so they could be outside of it.

Would it make sense to add a helper that does the readl() flush only
for non-st_P3? This could be a function pointer in the hba structure
which shouldn't slow stuff down.

>  }
>
>  static void return_abnormal_state(struct st_hba *hba, int status)
> @@ -974,15 +994,31 @@ static irqreturn_t stex_ss_intr(int irq, void *__hba)
>
> spin_lock_irqsave(hba->host->host_lock, flags);
>
> -   data = readl(base + YI2H_INT);
> -   if (data && data != 0x) {
> -   /* clear the interrupt */
> -   writel(data, base + YI2H_INT_C);
> -   stex_ss_mu_intr(hba);
> -   spin_unlock_irqrestore(hba->host->host_lock, flags);
> -   if (unlikely(data & SS_I2H_REQUEST_RESET))
> -   queue_work(hba->work_q, >reset_work);
> -   return IRQ_HANDLED;
> +   if (hba->cardtype == st_yel) {

I note that there's a few different card types beyond sd_yel and
st_P3. Does this function only get called for st_yel and st_P3?

> +   data = readl(base + YI2H_INT);
> +   if (data && data != 0x) {
> +   /* clear the interrupt */
> +   writel(data, base + YI2H_INT_C);
> +   stex_ss_mu_intr(hba);
> +   spin_unlock_irqrestore(hba->host->host_lock, flags);
> +   if (unlikely(data & SS_I2H_REQUEST_RESET))
> +   queue_work(hba->work_q, >reset_work);
> +   return IRQ_HANDLED;
> +   }
> +   } else {
> +   data = readl(base + PSCRATCH4);
> +   if (data != 0x) {
> +   if (data != 0) {
> +   /* clear the interrupt */
> +   writel(data, base + PSCRATCH1);
> +   writel((1 << 22), base + YH2I_INT);
> +   }
> +   stex_ss_mu_intr(hba);
> +   spin_unlock_irqrestore(hba->host->host_lock, flags);
> +   if (unlikely(data & 

Re: [PATCHv3 0/2] target: make location of /var/targets configurable

[Lee Duncan]

Ping?

We really need to move the target database out of /var/target

On 04/14/2016 06:18 PM, Lee Duncan wrote:
> These patches make the location of "/var/target" configurable,
> though it still defauls to "/var/target".
> 
> This "target database directory" can only be changed
> after the target_core_mod loads but before any
> fabric drivers are loaded, and must be the pathname
> of an existing directory.
> 
> This configuration is accomplished via the configfs
> top-level target attribute "dbroot", i.e. dumping
> out "/sys/kernel/config/target/dbroot" will normally
> return "/var/target". Writing to this attribute
> changes the loation where the kernel looks for the
> target database.
> 
> The first patch creates this configurable value for
> the "dbroot", and the second patch modifies users
> of this directory to use this new attribute.
> 
> Changes from v2:
>  * Add locking around access to target driver list
> 
> Changes from v1:
>  * Only allow changing target DB root before it
>can be used by others
>  * Validate that new DB root is a valid directory
> 
> Lee Duncan (2):
>   target: make target db location configurable
>   target: use new "dbroot" target attribute
> 
>  drivers/target/target_core_alua.c |  6 ++--
>  drivers/target/target_core_configfs.c | 62 
> +++
>  drivers/target/target_core_internal.h |  6 
>  drivers/target/target_core_pr.c   |  2 +-
>  4 files changed, 72 insertions(+), 4 deletions(-)
> 

-- 
Lee Duncan
SUSE Labs
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: kernel BUG in drivers/scsi/53c700.c:1129

[James Bottomley]

On Thu, 2016-06-09 at 21:36 +0200, Helge Deller wrote:
> Hi James,
> 
> I just tried Debian kernel 4.6.1-1 on my historic 715/64 machine, and it
> ran into this  BUG() in the LASI scsi driver:
> 
>  scsi 0:0:6:0: no saved request for untagged cmd
> 
> Any idea?
> 
> Helge
>  
> [0.00] Linux version 4.6.0-1-parisc (debian-ker...@lists.debian.org) 
> (gcc version 5.4.0 20160603 (Debian 5.4.0-3) ) #1 Debian 4.6.1-1 (2016-06-06)
> ...
> [0.00] Determining PDC firmware type: Snake.
> [0.00] model 60a0 0481   773c7d2c  
> 0004 0072 0072
> [0.00] vers  000c
> [0.00] model 9000/715
> [0.00] Total Memory: 160 MB
> ...
> [   43.18] SCSI subsystem initialized
> [   45.076000] 53c700: Version 2.8 By james.bottom...@hansenpartnership.com
> [   45.156000] scsi0: 53c710 rev 2 
> [   46.204000] scsi host0: LASI SCSI 53c700
> [   58.268000] scsi 0:0:6:0: no saved request for untagged cmd
> [   58.336000] [ cut here ]
> [   58.392000] kernel BUG at 
> /build/linux-XAODSw/linux-4.6.1/drivers/scsi/53c700.c:1129!
> [   58.484000] CPU: 0 PID: 0 Comm: swapper Not tainted 4.6.0-1-parisc #1 
> Debian 4.6.1-1
> [   58.58] task: 1083cdd8 ti: 107b1000 task.ti: 107b1000
> [   58.644000] 
> [   58.66]  YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI
> [   58.716000] PSW: 01001110 Not tainted
> [   58.788000] r00-03  0004ff0e 0084e388 00a8ea8c 107ba400
> [   58.848000] r04-07    15b88cc0 0006
> [   58.912000] r08-11  198ca400 00ff 0020 
> [   58.976000] r12-15  00ff 1003 10801020 0001
> [   59.036000] r16-19  107b1240 0002 00ff 0001
> [   59.10] r20-23  0001 000e 0084f388 
> [   59.164000] r24-27  107ba500 0083b540 1021a7a4 107b5020
> [   59.224000] r28-31   0040 107ba480 104d52bc
> [   59.288000] sr00-03     000d
> [   59.352000] sr04-07     
> [   59.416000] 
> [   59.432000] IASQ:   IAOQ: 00a8ea8c 00a8ea90
> [   59.50]  IIR: 03ffe01fISR: 000d  IOR: 00a8ea90
> [   59.564000]  CPU:0   CR30: 107b1000 CR31: f00e
> [   59.632000]  ORIG_R28: 10855e80
> [   59.668000]  IAOQ[0]: process_script_interrupt+0x13ec/0x16a4 [53c700]
> [   59.748000]  IAOQ[1]: process_script_interrupt+0x13f0/0x16a4 [53c700]
> [   59.824000]  RP(r2): process_script_interrupt+0x13ec/0x16a4 [53c700]
> [   59.90] Backtrace:
> [   59.928000]  [<00a8ea8c>] process_script_interrupt+0x13ec/0x16a4 [53c700]
> [   60.012000] 
> [   60.028000] CPU: 0 PID: 0 Comm: swapper Not tainted 4.6.0-1-parisc #1 
> Debian 4.6.1-1
> [   60.12] Backtrace:
> [   60.148000]  [<1015bffc>] show_stack+0x3c/0x50
> [   60.204000]  [<10425d40>] dump_stack+0x28/0x38
> [   60.256000]  [<1015c180>] die_if_kernel+0x134/0x20c
> [   60.316000]  [<1015cd34>] handle_interruption+0x804/0x828
> [   60.38] 
> [   60.40] Kernel panic - not syncing: Fatal exception in interrupt
> [   60.40] ---[ end Kernel panic - not syncing: Fatal exception in 
> interrupt

It looks like either an unsolicited reselection or possibly a spurious
interrupt left over from something.  Can you define NCR_700_DEBUG in
drivers/scsi/53c700.h and see what it says?

Thanks,

James


--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Zpráva pro vás!

[BertP]

Jsem zastupujicí investicní zajem ze strany Dubaji, pro ktere hledáme vasi
ucast. Odpoved na e-mailu nize v pripade zajmu.

E-mail: plippb...@gmail.com


--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3] storvsc: use small sg_tablesize on x86

[Olaf Hering]

On Thu, Jun 09, James Bottomley wrote:

> On Thu, 2016-06-09 at 18:25 +0200, Olaf Hering wrote:
> > Reducing the sg_tablesize allows booting of 32bit kernels in VMs,
> > after
> > commit be0cf6ca301c61458dc4aa1a37acf4f58d2ed3d6 ("scsi: storvsc: Set
> > the
> > tablesize based on the information given by the host")
> > 
> > [5.567138] hv_storvsc vmbus_1: adjusting sg_tablesize 0x800 -> 
> > 0x20
> 
> Are you really sure 32 is the correct size?

Its a size that works, while the current state does not work at all.

> I know 32 it what it had before, but the reason for the commit you
> quote was to improve performance ...

The commit above broke 32bit. Whoever wants to improve performance on
this dead horse can submit another patch.

Olaf
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH V2 2/2] aacraid: remove wildcard for series 9 controllers

[Don Brace]

Depends on smartpqi driver adoption

Reviewed-by: Kevin Barnett 
Reviewed-by: Scott Teel 
Signed-off-by: Don Brace 
---
 0 files changed

diff --git a/drivers/scsi/aacraid/linit.c b/drivers/scsi/aacraid/linit.c
index 79871f3..d5b26fa 100644
--- a/drivers/scsi/aacraid/linit.c
+++ b/drivers/scsi/aacraid/linit.c
@@ -160,7 +160,6 @@ static const struct pci_device_id aac_pci_tbl[] = {
{ 0x9005, 0x028b, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 62 }, /* Adaptec PMC 
Series 6 (Tupelo) */
{ 0x9005, 0x028c, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 63 }, /* Adaptec PMC 
Series 7 (Denali) */
{ 0x9005, 0x028d, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 64 }, /* Adaptec PMC 
Series 8 */
-   { 0x9005, 0x028f, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 65 }, /* Adaptec PMC 
Series 9 */
{ 0,}
 };
 MODULE_DEVICE_TABLE(pci, aac_pci_tbl);
@@ -239,7 +238,6 @@ static struct aac_driver_ident aac_drivers[] = {
{ aac_src_init, "aacraid", "ADAPTEC ", "RAID", 2, 
AAC_QUIRK_SRC }, /* Adaptec PMC Series 6 (Tupelo) */
{ aac_srcv_init, "aacraid", "ADAPTEC ", "RAID", 2, 
AAC_QUIRK_SRC }, /* Adaptec PMC Series 7 (Denali) */
{ aac_srcv_init, "aacraid", "ADAPTEC ", "RAID", 2, 
AAC_QUIRK_SRC }, /* Adaptec PMC Series 8 */
-   { aac_srcv_init, "aacraid", "ADAPTEC ", "RAID", 2, 
AAC_QUIRK_SRC } /* Adaptec PMC Series 9 */
 };
 
 /**

--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH V2 0/2] initial submit of Microsemi smartpqi driver

[Don Brace]

These patches are based on Linus's tree

- add smartpqi to kernel.org
- remove PCI IDs from aacraid driver
  - Depends on adoption of smartpqi driver

Changes since initial upload
 - Forgot to give correct ownership to the author.
Changes since V1
 - Corrected make ARCH=i386 kbuild test robot issue.

---

Don Brace (1):
  aacraid: remove wildcard for series 9 controllers

Kevin Barnett (1):
  smartpqi: initial commit of Microsemi smartpqi driver


 drivers/scsi/smartpqi/Kconfig  |   50 
 drivers/scsi/smartpqi/Makefile |3 
 drivers/scsi/smartpqi/smartpqi.h   | 1135 
 drivers/scsi/smartpqi/smartpqi_init.c  | 6817 
 drivers/scsi/smartpqi/smartpqi_sas_transport.c |  350 +
 drivers/scsi/smartpqi/smartpqi_sis.c   |  394 +
 drivers/scsi/smartpqi/smartpqi_sis.h   |   32 
 7 files changed, 8781 insertions(+)
 create mode 100644 drivers/scsi/smartpqi/Kconfig
 create mode 100644 drivers/scsi/smartpqi/Makefile
 create mode 100644 drivers/scsi/smartpqi/smartpqi.h
 create mode 100644 drivers/scsi/smartpqi/smartpqi_init.c
 create mode 100644 drivers/scsi/smartpqi/smartpqi_sas_transport.c
 create mode 100644 drivers/scsi/smartpqi/smartpqi_sis.c
 create mode 100644 drivers/scsi/smartpqi/smartpqi_sis.h

--
Signature
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3] storvsc: use small sg_tablesize on x86

[James Bottomley]

On Thu, 2016-06-09 at 18:25 +0200, Olaf Hering wrote:
> Reducing the sg_tablesize allows booting of 32bit kernels in VMs,
> after
> commit be0cf6ca301c61458dc4aa1a37acf4f58d2ed3d6 ("scsi: storvsc: Set
> the
> tablesize based on the information given by the host")
> 
> [5.567138] hv_storvsc vmbus_1: adjusting sg_tablesize 0x800 -> 
> 0x20

Are you really sure 32 is the correct size?  That caps transfers at 128
k.  Even in the dim, dark, pre-64bit (at least on x86) days, our static
limit for sg tablesize was 128 (0.5M).

I know 32 it what it had before, but the reason for the commit you
quote was to improve performance ...

James

--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v3] storvsc: use small sg_tablesize on x86

[Olaf Hering]

Reducing the sg_tablesize allows booting of 32bit kernels in VMs, after
commit be0cf6ca301c61458dc4aa1a37acf4f58d2ed3d6 ("scsi: storvsc: Set the
tablesize based on the information given by the host")

[5.567138] hv_storvsc vmbus_1: adjusting sg_tablesize 0x800 -> 0x20

Signed-off-by: Olaf Hering 
---

As requested, use CONFIG_. For some reason IS_ENABLED(64_BIT)
does not work.

 drivers/scsi/storvsc_drv.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/scsi/storvsc_drv.c b/drivers/scsi/storvsc_drv.c
index 3ddcabb..ae42324 100644
--- a/drivers/scsi/storvsc_drv.c
+++ b/drivers/scsi/storvsc_drv.c
@@ -1673,11 +1673,15 @@ static int storvsc_probe(struct hv_device *device,
/* max cmd length */
host->max_cmd_len = STORVSC_MAX_CMD_LEN;
 
+#ifdef CONFIG_64BIT
/*
 * set the table size based on the info we got
 * from the host.
 */
host->sg_tablesize = (stor_device->max_transfer_bytes >> PAGE_SHIFT);
+#else
+   host->sg_tablesize = MAX_MULTIPAGE_BUFFER_COUNT;
+#endif
 
/* Register the HBA and start the scsi bus scan */
ret = scsi_add_host(host, >device);
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2] scsi_debug: fix sleep in invalid context

[Bart Van Assche]

On 05/31/2016 02:15 PM, Douglas Gilbert wrote:

In this post: http://www.spinics.net/lists/linux-scsi/msg97124.html
the author shows some kernel infrastructure complaining about a
sleep in an invalid context. Remove offending call to vmalloc().
Instead of using kzalloc() which reviewers didn't like, use a
bucket system (64 bytes on the stack) and potentially multiple
calls to sg_pcopy_from_buffer() to construct the 'data-in' buffer
for the SCSI REPORT LUNS command.


Reviewed-by: Bart Van Assche 
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC 7/8] nvmet/admin-cmd: Hookup T10-PI to ID_NS.ms + ID_NS.dps feature bits

[Christoph Hellwig]

FYI: NVMf requires metadata to be interleaved in the data, and you
need to indicate that in the Identify data.  Note that this is only
a requirement for the on the wire format and for the way the Namespaces are
exposed at the protocol level as RDMA HCA and FB HBAs should still
be able to handle our separate SGL.
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: NVMe over Fabrics target implementation

[Christoph Hellwig]

On Wed, Jun 08, 2016 at 09:36:15PM -0700, Nicholas A. Bellinger wrote:
> The configfs ABI should not dictate a single backend use-case.

And it doesn't.  I actually had a file backend implemented to
benchmark it against the loopback driver.  It needed absolutely
zero new configfs interface.  And if we at some point want
different backends using different attributes we can trivially
add them using configfs_register_group.

> Along with having common code and existing configfs
> ABI, we also get a proper starting point for target-core
> features that span across endpoints, and are defined for
> both scsi and nvme.  PR APTPL immediately comes to mind.

PRs are a useful feature on the road map.  However we need a separate
pluggable backend anyway for distributed backends like RBD or Bart's
DLM implementation.  Also the current LIO PR implementation will need
a lot of work to be usable for NVMe while actually following the
spec in all it's details and to be power ѕafe.   The right way to
go here is a PR API that allows different backends, and the existing
LIO one might be one of them after it's got the needed attention.
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC 0/2] nvme/loop: Add support for controllers-per-port model

[Christoph Hellwig]

On Wed, Jun 08, 2016 at 10:13:53PM -0700, Nicholas A. Bellinger wrote:
> I still don't see why a loopback controller on a port of an individual
> subsystem NQN can't be created + deleted directly from configfs, and
> operate independently of other loopback controllers on a port of a
> different subsystem NQNs.

I think you are misunderstanding the NVMe entities - there is no port
of a subsystem.  There are port, and there are subsystems and there
is an N to M relation between them, not an N to one relation.

Multiple controllers may and usually will use the same port to access
one or more subsystems, but multiple controllers may also use different
ports to use the same subsystem.

For full NVMe functionality we thus need to be able to create all
these objects indepdently.   While loopback ports are extremtly cheap
I see no reason to introduce a shortcut to break this model for our
debug local implementation - the whole point of the loopback driver
is to give you the full NVMe over Fabrics experience without needing
an (possibly expensive) transport.

> > Something like the patch below is the right way, it just needs a bit more
> > fine tuning and proper test cases:
> 
> I don't see how adding a internal mutex for loopback ports, and doing
> internal sequential list lookup holding the global nvmet_config_sem
> whilst doing nvmet_fabric_ops->add_port() helps to scale at all..

Scalability of the controller creation is not the prime goal for the
nvme-loop driver.  It's supposed to be the simples possible implementation
of a NVMe over Fabrics transport.

> AFAICT for loopback, neither of these is necessary.  Why can't a
> loopback controller on a port for a individual subsystem NQN be created
> + deleted directly from configfs,

We could trivially do this, but I think it's counter productive.  NVMe
over Fabrics does not automatically create one or multiple controllers,
and nvme-loop is just another transport that follows the higher level
spec.

> independent of other subsystem NQN's
> loopback controller ports..?

The only limitation at the moment is that there is only one port.  I've
shown you a fairly trivial patch to lift that limitation.  Subsystem
can be created and deleted independently from each other, as can
controllers, and as can ports for transport where more than one can
exists.
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PREEMPT-RT] [PATCH v2] scsi/fcoe: convert to kworker

[Sebastian Andrzej Siewior]

On 06/09/2016 03:15 PM, Laurence Oberman wrote:
> Hello

Hi,

> Apologies, somehow this fell off my radar.
> I will get the FCOE test bed up and get it done ASAP.

Thanks

> 
> Regards
> Laurence

Sebastian

--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PREEMPT-RT] [PATCH v2] scsi/fcoe: convert to kworker

[Laurence Oberman]

- Original Message -
> From: "Sebastian Andrzej Siewior" 
> To: "Laurence Oberman" , "James Bottomley" 
> 
> Cc: "Christoph Hellwig" , linux-scsi@vger.kernel.org, 
> "Martin K. Petersen"
> , "Vasu Dev" , 
> r...@linutronix.de, fcoe-de...@open-fcoe.org, "Chad
> Dupuis" 
> Sent: Thursday, June 9, 2016 9:09:37 AM
> Subject: Re: [PREEMPT-RT] [PATCH v2] scsi/fcoe: convert to kworker
> 
> On 04/22/2016 06:39 PM, Laurence Oberman wrote:
> > I have fcoe for testing.
> > I will pull this in next week and test it.
> 
> any update?
> 
> > 
> > Laurence Oberman
> > Principal Software Maintenance Engineer
> > Red Hat Global Support Services
> 
> Sebastian
> 
> 
Hello
Apologies, somehow this fell off my radar.
I will get the FCOE test bed up and get it done ASAP.

Regards
Laurence
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: CD media burnt using TAO mode fails to boot

[Thomas Schmitt]

Hi,

(I am currently not subscribed to linux-scsi but will do if a
 discussion arises. Just give me a note by direct mail.)

Alba Pompeo wrote:
> [9.698784] sr 1:0:0:0: [sr0] tag#12 Sense Key : 0x4 [current]
> [9.698788] sr 1:0:0:0: [sr0] tag#12 ASC=0x3e ASCQ=0x2
> [9.698795] sr 1:0:0:0: [sr0] tag#12 CDB: opcode=0x28 28 00 00 00 ae 96 00 
> 00 02 00

  4 3E 02 TIMEOUT ON LOGICAL UNIT

Quite a harsh reaction for an attempt to read the TAO roun-out blocks.
Normal would be rather something like

  5 30 02 CANNOT READ MEDIUM  INCOMPATIBLE FORMAT
  5 64 00 ILLEGAL MODE FOR THIS TRACK


> My best guess would be that this confuses the entity among the ISO
> payload, which is in charge for creating /dev/disk/by-label/ links
> while the system boots up.

At least with Archlinux it is/was the program blkid.

A few weeks ago i posted to linux-scsi 

  Date: Sun, 28 Feb 2016 14:41:59 +0100
  Subject: sr: Failures to read TAO CD track ends
  Message-Id: <6531578277915568...@scdbackup.webframe.org>

  http://marc.info/?l=linux-scsi=14592729714=2

with CD drive observations and remarks about drivers/scsi/sr.c and
its strange theory of 75 block fuzziness of READ CAPACITY.

The problem is rather about the last two blocks which are reported
to be part of a TAO track. They need to be handled mistrustingly,
because the CD drives show no uniform behavior with counting the
unreadable run-out blocks as part of readable payload or not.

As of april 19 2016 the problem gets circumvented in upstream
libblkid:
  
https://github.com/karelzak/util-linux/commit/bfebe74e3babe8c188a51269acc2673f1aea283f
At least for me it solved the failure of blkid on a TAO CD.

So it might be worth to inform the publishers of CD-sized ISOs that
they can close the pitfall by updating the blkid program which they
put into their ISOs.


Have a nice day :)

Thomas

--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PREEMPT-RT] [PATCH v2] scsi/fcoe: convert to kworker

[Sebastian Andrzej Siewior]

On 04/22/2016 06:39 PM, Laurence Oberman wrote:
> I have fcoe for testing.
> I will pull this in next week and test it.

any update?

> 
> Laurence Oberman
> Principal Software Maintenance Engineer
> Red Hat Global Support Services

Sebastian

--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

CD media burnt using TAO mode fails to boot

[Alba Pompeo]

Hello,

there is a recurrent problem bug in the kernel that makes a CD-R fail
to boot when burnt in TAO mode.

[9.698776] sr 1:0:0:0: [sr0] tag#12 UNKNOWN(0x2003) Result:
hostbyte=0x00 driverbyte=0x08
[9.698784] sr 1:0:0:0: [sr0] tag#12 Sense Key : 0x4 [current]
[9.698788] sr 1:0:0:0: [sr0] tag#12 ASC=0x3e ASCQ=0x2
[9.698795] sr 1:0:0:0: [sr0] tag#12 CDB: opcode=0x28 28 00 00 00
ae 96 00 00 02 00
[9.698798] blk_update_request: I/O error, dev sr0, sector 178776

My best guess would be that this confuses the entity among the ISO
payload, which is in charge for creating /dev/disk/by-label/ links
while the system boots up.

I posted about this on bugzilla too -
https://bugzilla.kernel.org/show_bug.cgi?id=118621

If any more information is needed, let me know.
Thank you.
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] aic7xxx: fix wrong return values

[Luis de Bethencourt]

On 09/06/16 02:04, Laurence Oberman wrote:
> 
> 
> - Original Message -
>> From: "Luis de Bethencourt" 
>> To: linux-ker...@vger.kernel.org
>> Cc: h...@suse.com, j...@linux.vnet.ibm.com, "martin petersen" 
>> ,
>> linux-scsi@vger.kernel.org, jav...@osg.samsung.com, "Luis de Bethencourt" 
>> 
>> Sent: Wednesday, June 8, 2016 6:23:02 PM
>> Subject: [PATCH] aic7xxx: fix wrong return values
>>
>> Convention of error codes says to return them as negative values.
>>
>> Signed-off-by: Luis de Bethencourt 
>> ---
>>  drivers/scsi/aic7xxx/aic7770_osm.c |  6 +++---
>>  drivers/scsi/aic7xxx/aic79xx_core.c| 24 
>>  drivers/scsi/aic7xxx/aic79xx_osm.c |  8 
>>  drivers/scsi/aic7xxx/aic79xx_osm_pci.c | 16 
>>  drivers/scsi/aic7xxx/aic79xx_pci.c |  2 +-
>>  drivers/scsi/aic7xxx/aic7xxx_core.c| 26 +-
>>  drivers/scsi/aic7xxx/aic7xxx_osm.c |  8 
>>  drivers/scsi/aic7xxx/aic7xxx_osm_pci.c | 12 ++--
>>  drivers/scsi/aic7xxx/aic7xxx_pci.c |  4 ++--
>>  9 files changed, 53 insertions(+), 53 deletions(-)
>>
>> diff --git a/drivers/scsi/aic7xxx/aic7770_osm.c
>> b/drivers/scsi/aic7xxx/aic7770_osm.c
>> index 3d401d0..50f030d 100644
>> --- a/drivers/scsi/aic7xxx/aic7770_osm.c
>> +++ b/drivers/scsi/aic7xxx/aic7770_osm.c
>> @@ -51,7 +51,7 @@ aic7770_map_registers(struct ahc_softc *ahc, u_int port)
>>   * Lock out other contenders for our i/o space.
>>   */
>>  if (!request_region(port, AHC_EISA_IOSIZE, "aic7xxx"))
>> -return (ENOMEM);
>> +return -ENOMEM;
>>  ahc->tag = BUS_SPACE_PIO;
>>  ahc->bsh.ioport = port;
>>  return (0);
>> @@ -87,10 +87,10 @@ aic7770_probe(struct device *dev)
>>  sprintf(buf, "ahc_eisa:%d", eisaBase >> 12);
>>  name = kstrdup(buf, GFP_ATOMIC);
>>  if (name == NULL)
>> -return (ENOMEM);
>> +return -ENOMEM;
>>  ahc = ahc_alloc(_driver_template, name);
>>  if (ahc == NULL)
>> -return (ENOMEM);
>> +return -ENOMEM;
>>  error = aic7770_config(ahc, aic7770_ident_table + edev->id.driver_data,
>> eisaBase);
>>  if (error != 0) {
>> diff --git a/drivers/scsi/aic7xxx/aic79xx_core.c
>> b/drivers/scsi/aic7xxx/aic79xx_core.c
>> index 109e2c9..bf850d8 100644
>> --- a/drivers/scsi/aic7xxx/aic79xx_core.c
>> +++ b/drivers/scsi/aic7xxx/aic79xx_core.c
>> @@ -6422,7 +6422,7 @@ ahd_init_scbdata(struct ahd_softc *ahd)
>>  scb_data->maxhscbs = ahd_probe_scbs(ahd);
>>  if (scb_data->maxhscbs == 0) {
>>  printk("%s: No SCB space found\n", ahd_name(ahd));
>> -return (ENXIO);
>> +return -ENXIO;
>>  }
>>  
>>  ahd_initialize_hscbs(ahd);
>> @@ -6501,7 +6501,7 @@ ahd_init_scbdata(struct ahd_softc *ahd)
>>  
>>  error_exit:
>>  
>> -return (ENOMEM);
>> +return -ENOMEM;
>>  }
>>  
>>  static struct scb *
>> @@ -7076,7 +7076,7 @@ ahd_init(struct ahd_softc *ahd)
>>  ahd->stack_size = ahd_probe_stack_size(ahd);
>>  ahd->saved_stack = kmalloc(ahd->stack_size * sizeof(uint16_t), 
>> GFP_ATOMIC);
>>  if (ahd->saved_stack == NULL)
>> -return (ENOMEM);
>> +return -ENOMEM;
>>  
>>  /*
>>   * Verify that the compiler hasn't over-aggressively
>> @@ -7115,7 +7115,7 @@ ahd_init(struct ahd_softc *ahd)
>> /*maxsegsz*/AHD_MAXTRANSFER_SIZE,
>> /*flags*/BUS_DMA_ALLOCNOW,
>> >buffer_dmat) != 0) {
>> -return (ENOMEM);
>> +return -ENOMEM;
>>  }
>>  #endif
>>  
>> @@ -7143,7 +7143,7 @@ ahd_init(struct ahd_softc *ahd)
>> /*nsegments*/1,
>> /*maxsegsz*/BUS_SPACE_MAXSIZE_32BIT,
>> /*flags*/0, >shared_data_dmat) != 0) {
>> -return (ENOMEM);
>> +return -ENOMEM;
>>  }
>>  
>>  ahd->init_level++;
>> @@ -7153,7 +7153,7 @@ ahd_init(struct ahd_softc *ahd)
>>   (void **)>shared_data_map.vaddr,
>>   BUS_DMA_NOWAIT,
>>   >shared_data_map.dmamap) != 0) {
>> -return (ENOMEM);
>> +return -ENOMEM;
>>  }
>>  
>>  ahd->init_level++;
>> @@ -7194,7 +7194,7 @@ ahd_init(struct ahd_softc *ahd)
>>  
>>  /* Allocate SCB data now that buffer_dmat is initialized */
>>  if (ahd_init_scbdata(ahd) != 0)
>> -return (ENOMEM);
>> +return -ENOMEM;
>>  
>>  if ((ahd->flags & AHD_INITIATORROLE) == 0)
>>  ahd->flags &= ~AHD_RESET_BUS_A;
>> @@ -7644,7 +7644,7 @@ ahd_default_config(struct ahd_softc *ahd)
>>  if (ahd_alloc_tstate(ahd, ahd->our_id, 'A') == NULL) {
>>  printk("%s: unable to allocate ahd_tmode_tstate.  "
>> 

Re: [PATCH v2] Add support for SCT Write Same

[Christoph Hellwig]

> + if (ata_id_sct_write_same(dev->id))
> + sdev->sct_write_same = 1;
> +

What's the point of this flag?  It should simply clear the no_write_same
flag for this device.  Due to the way how we have both a per-host and
per-device flag that might not be completely trivial, but untangling
that mess might be a good idea anyway.

> @@ -3305,6 +3308,37 @@ static unsigned int ata_scsi_write_same_xlat(struct 
> ata_queued_cmd *qc)
>   goto invalid_param_len;
>  
>   buf = page_address(sg_page(scsi_sglist(scmd)));
> +
> + if (ata_id_sct_write_same(dev->id)) {

Various comments:

 - The plain page_address above looks harmful, how do we know that
   the page is mapped into kernel memory?  This might actually be broken
   already, though.
 - Why is this below the check that rejects non-unmap WRITE SAME
   commands?
 - Shouldn't we still translate discard command to TRIM?  Maybe we
   need a check of the operation in the request structure..

--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2] scsi_debug: fix sleep in invalid context

[Christoph Hellwig]

Oh well,

not a fan og the casting, but as this is an important fix let's get
it in for now:

Acked-by: Christoph Hellwig 
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2] Add support for SCT Write Same

[Shaun Tancheff]

SATA drives may support write same via SCT. This is useful
for setting the drive contents to a specific pattern (0's).

Signed-off-by: Shaun Tancheff 
---
v2:
 - Remove fugly ata hacking from sd.c
---
 drivers/ata/libata-scsi.c  | 34 ++
 drivers/scsi/sd.c  |  2 +-
 include/linux/ata.h| 43 +++
 include/scsi/scsi_device.h |  1 +
 4 files changed, 79 insertions(+), 1 deletion(-)

diff --git a/drivers/ata/libata-scsi.c b/drivers/ata/libata-scsi.c
index bfec66f..b73eace 100644
--- a/drivers/ata/libata-scsi.c
+++ b/drivers/ata/libata-scsi.c
@@ -1204,6 +1204,9 @@ static int ata_scsi_dev_config(struct scsi_device *sdev,
if (!ata_id_has_unload(dev->id))
dev->flags |= ATA_DFLAG_NO_UNLOAD;
 
+   if (ata_id_sct_write_same(dev->id))
+   sdev->sct_write_same = 1;
+
/* configure max sectors */
blk_queue_max_hw_sectors(q, dev->max_sectors);
 
@@ -3305,6 +3308,37 @@ static unsigned int ata_scsi_write_same_xlat(struct 
ata_queued_cmd *qc)
goto invalid_param_len;
 
buf = page_address(sg_page(scsi_sglist(scmd)));
+
+   if (ata_id_sct_write_same(dev->id)) {
+   u16 *sctpg = buf;
+
+   put_unaligned_le16(0x0002,  [0]); /* SCT_ACT_WRITE_SAME */
+   put_unaligned_le16(0x0101,  [1]); /* WRITE PTRN FG */
+   put_unaligned_le64(block,   [2]);
+   put_unaligned_le64(n_block, [6]);
+   put_unaligned_le32(0u,  [10]);
+
+   tf->hob_feature = 0;
+   tf->feature = 0;
+   tf->hob_nsect = 0;
+   tf->nsect = 1;
+   tf->lbah = 0;
+   tf->lbam = 0;
+   tf->lbal = ATA_CMD_STANDBYNOW1;
+   tf->hob_lbah = 0;
+   tf->hob_lbam = 0;
+   tf->hob_lbal = 0;
+   tf->device = ATA_CMD_STANDBYNOW1;
+   tf->protocol = ATA_PROT_DMA;
+   tf->command = ATA_CMD_WRITE_LOG_DMA_EXT;
+   tf->flags |= ATA_TFLAG_ISADDR | ATA_TFLAG_DEVICE |
+ATA_TFLAG_LBA48 | ATA_TFLAG_WRITE;
+
+   ata_qc_set_pc_nbytes(qc);
+
+   return 0;
+   }
+
size = ata_set_lba_range_entries(buf, 512, block, n_block);
 
if (ata_ncq_enabled(dev) && ata_fpdma_dsm_supported(dev)) {
diff --git a/drivers/scsi/sd.c b/drivers/scsi/sd.c
index f459dff..b5ffcd3 100644
--- a/drivers/scsi/sd.c
+++ b/drivers/scsi/sd.c
@@ -794,7 +794,7 @@ static void sd_config_write_same(struct scsi_disk *sdkp)
struct request_queue *q = sdkp->disk->queue;
unsigned int logical_block_size = sdkp->device->sector_size;
 
-   if (sdkp->device->no_write_same) {
+   if (sdkp->device->no_write_same && !sdkp->device->sct_write_same) {
sdkp->max_ws_blocks = 0;
goto out;
}
diff --git a/include/linux/ata.h b/include/linux/ata.h
index 99346be..4132de3 100644
--- a/include/linux/ata.h
+++ b/include/linux/ata.h
@@ -104,6 +104,7 @@ enum {
ATA_ID_CFA_KEY_MGMT = 162,
ATA_ID_CFA_MODES= 163,
ATA_ID_DATA_SET_MGMT= 169,
+   ATA_ID_SCT_CMD_XPORT= 206,
ATA_ID_ROT_SPEED= 217,
ATA_ID_PIO4 = (1 << 1),
 
@@ -778,6 +779,48 @@ static inline bool ata_id_sense_reporting_enabled(const 
u16 *id)
 }
 
 /**
+ *
+ * Word: 206 - SCT Command Transport
+ *15:12 - Vendor Specific
+ * 11:6 - Reserved
+ *5 - SCT Command Transport Data Tables supported
+ *4 - SCT Command Transport Features Control supported
+ *3 - SCT Command Transport Error Recovery Control supported
+ *2 - SCT Command Transport Write Same supported
+ *1 - SCT Command Transport Long Sector Access supported
+ *0 - SCT Command Transport supported
+ */
+static inline bool ata_id_sct_data_tables(const u16 *id)
+{
+   return id[ATA_ID_SCT_CMD_XPORT] & (1 << 5) ? true : false;
+}
+
+static inline bool ata_id_sct_features_ctrl(const u16 *id)
+{
+   return id[ATA_ID_SCT_CMD_XPORT] & (1 << 4) ? true : false;
+}
+
+static inline bool ata_id_sct_error_recovery_ctrl(const u16 *id)
+{
+   return id[ATA_ID_SCT_CMD_XPORT] & (1 << 3) ? true : false;
+}
+
+static inline bool ata_id_sct_write_same(const u16 *id)
+{
+   return id[ATA_ID_SCT_CMD_XPORT] & (1 << 2) ? true : false;
+}
+
+static inline bool ata_id_sct_long_sector_access(const u16 *id)
+{
+   return id[ATA_ID_SCT_CMD_XPORT] & (1 << 1) ? true : false;
+}
+
+static inline bool ata_id_sct_supported(const u16 *id)
+{
+   return id[ATA_ID_SCT_CMD_XPORT] & (1 << 0) ? true : false;
+}
+
+/**
  * ata_id_major_version-   get ATA level of drive
  * @id: Identify data
  *
diff --git a/include/scsi/scsi_device.h b/include/scsi/scsi_device.h
index a6c346d..66f5af7 100644
--- a/include/scsi/scsi_device.h
+++ 

[PATCH v2] Add support for Write Same via SCT

[Shaun Tancheff]

At some point the method of issuing Write Same for ATA drives changed.
Currently write same is commonly available via SCT so expose the SCT
capabilities and use SCT Write Same if available.

This is useful for zoned based media that prefers to support discard
with lbprz set, aka discard zeroes data by mapping discard operations to 
reset write pointer operations. Conventional zones that do not support 
reset write pointer can still honor the discard zeroes data by issuing
a write same over the zone.

v2:
 - Remove fugly ata hacking from sd.c

Shaun Tancheff (1):
  Add support for SCT Write Same

 drivers/ata/libata-scsi.c  | 34 ++
 drivers/scsi/sd.c  |  2 +-
 include/linux/ata.h| 43 +++
 include/scsi/scsi_device.h |  1 +
 4 files changed, 79 insertions(+), 1 deletion(-)

-- 
2.8.1

--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] Add support for SCT Write Same

[Shaun Tancheff]

On Wed, Jun 8, 2016 at 10:39 PM, Martin K. Petersen
 wrote:
>
> > "Shaun" == Shaun Tancheff  writes:
>
> Shaun,
>
> Shaun> SATA drives may support write same via SCT. This is useful for
> Shaun> setting the drive contents to a specific pattern (0's).
>
> index 428c03e..c5c8424 100644
> --- a/drivers/scsi/sd.c
> +++ b/drivers/scsi/sd.c
> @@ -52,6 +52,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>
> No ATA stuff in sd.c, please.
>
>
> @@ -2761,24 +2762,26 @@ static void sd_read_write_same(struct scsi_disk 
> *sdkp, unsigned char *buffer)
>  {
> struct scsi_device *sdev = sdkp->device;
>
> -   if (sdev->host->no_write_same) {
> -   sdev->no_write_same = 1;
> -
> -   return;
> -   }
> -
> if (scsi_report_opcode(sdev, buffer, SD_BUF_SIZE, INQUIRY) < 0) {
> -   /* too large values might cause issues with arcmsr */
> -   int vpd_buf_len = 64;
> -
> sdev->no_report_opcodes = 1;
>
> /* Disable WRITE SAME if REPORT SUPPORTED OPERATION
>  * CODES is unsupported and the device has an ATA
>  * Information VPD page (SAT).
>  */
>
> The above comment tells you how to enable WRITE SAME in libata's
> SCSI-ATA translation.
>
>
> -   if (!scsi_get_vpd_page(sdev, 0x89, buffer, vpd_buf_len))
> +   if (!scsi_get_vpd_page(sdev, 0x89, buffer, SD_BUF_SIZE))
>
> That vpd_buf_len is intentional.



Got it. Looking at it again all of hacking here is not required.
Posting a cleaner v2 without this.

Thanks!

>
>
> --
> Martin K. Petersen  Oracle Linux Engineering




-- 
Shaun Tancheff
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html