e hw queue hasn't online
> CPUs.
>
> Fix this issue by forcing to use blk_mq.
>
> BTW, I have been used virtio-scsi(scsi_mq) for several years, and it has
> been quite stable, so it shouldn't cause extra risk.
I think that's ok now that we have I/O schedulers for blk-mq.
Acked-by:
On 11/08/2017 19:23, Michael S. Tsirkin wrote:
> On Fri, Aug 11, 2017 at 04:09:26PM +0200, Paolo Bonzini wrote:
>> On 10/08/2017 23:41, Michael S. Tsirkin wrote:
>>>>> Then we probably should fail probe if vq size is too small.
>>>> What does this mean?
On 10/08/2017 23:41, Michael S. Tsirkin wrote:
>>> Then we probably should fail probe if vq size is too small.
>> What does this mean?
>
> We must prevent driver from submitting s/g lists > vq size to device.
What is the rationale for the limit? It makes no sense if indirect
descriptors are
t; be configured from the qemu command line.
>
> Thanks Paolo Bonzini, Christoph Hellwig.
>
> Signed-off-by: Richard W.M. Jones <rjo...@redhat.com>
> ---
> drivers/scsi/virtio_scsi.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/
t; be configured from the qemu command line.
You can clear .can_queue from the templates. Otherwise looks good.
Paolo
> Thanks Paolo Bonzini, Christoph Hellwig.
>
> Signed-off-by: Richard W.M. Jones <rjo...@redhat.com>
> ---
> drivers/scsi/virtio_scsi.c | 2 ++
> 1 file chan
On 10/08/2017 18:40, Richard W.M. Jones wrote:
> If using indirect descriptors, you can make the total_sg as large as
> you want. If not, BUG is too serious because the function later
> returns -ENOSPC.
>
> Thanks Paolo Bonzini, Christoph Hellwig.
>
> Signed-off-by: Ri
On 10/08/2017 17:40, Richard W.M. Jones wrote:
> OK this is looking a bit better now.
>
> With scsi-mq enabled: 175 disks
> virtqueue_size=64: 318 disks *
> virtqueue_size=16: 775 disks *
> With scsi-mq disabled: 1755 disks
> * = new results
On 10/08/2017 16:16, Richard W.M. Jones wrote:
> On Thu, Aug 10, 2017 at 02:53:58PM +0200, Paolo Bonzini wrote:
>> can_queue and cmd_per_lun are different. can_queue should be set to the
>> value of vq->vring.num where vq is the command virtqueue (the first one
>&g
On 10/08/2017 14:22, Richard W.M. Jones wrote:
> On Wed, Aug 09, 2017 at 06:50:10PM +0200, Paolo Bonzini wrote:
>> On 09/08/2017 18:01, Christoph Hellwig wrote:
>>> On Mon, Aug 07, 2017 at 03:07:48PM +0200, Paolo Bonzini wrote:
>>>> can_queue should depen
On 09/08/2017 18:01, Christoph Hellwig wrote:
> On Mon, Aug 07, 2017 at 03:07:48PM +0200, Paolo Bonzini wrote:
>> can_queue should depend on the virtqueue size, which unfortunately can
>> vary for each virtio-scsi device in theory. The virtqueue size is
>> retrieved by
On 07/08/2017 14:27, Richard W.M. Jones wrote:
> Also I noticed this code in virtio_scsi.c:
>
> cmd_per_lun = virtscsi_config_get(vdev, cmd_per_lun) ?: 1;
> shost->cmd_per_lun = min_t(u32, cmd_per_lun, shost->can_queue);
>
> but setting cmd_per_lun (as a qemu virtio-scsi-pci
On 05/08/2017 17:51, Richard W.M. Jones wrote:
> On Sat, Aug 05, 2017 at 03:39:54PM +0200, Christoph Hellwig wrote:
>> For now can you apply this testing patch to the guest kernel?
>>
>> diff --git a/drivers/scsi/virtio_scsi.c b/drivers/scsi/virtio_scsi.c
>> index 9be211d68b15..0cbe2c882e1c 100644
Multi-queue virtio-scsi uses a different scsi_host_template struct.
Add the .device_alloc field there, too.
Fixes: 25d1d50e23275e141e3a3fe06c25a99f4c4bf4e0
Cc: sta...@vger.kernel.org
Cc: David Gibson <da...@gibson.dropbear.id.au>
Signed-off-by: Paolo Bonzini <pbonz...@redhat.com>
t;James E.J. Bottomley" <j...@linux.vnet.ibm.com>
Cc: "Martin K. Petersen" <martin.peter...@oracle.com>
Cc: Hannes Reinecke <h...@suse.de>
Cc: linux-scsi@vger.kernel.org
Cc: sta...@vger.kernel.org
Signed-off-by: Paolo Bonzini <pbonz...@redhat.com>
---
dr
t
>
> s/controller something/controller or something/ ?
Acked-by: Paolo Bonzini <pbonz...@redhat.com>
with this change.
Paolo
On 05/04/2017 19:21, Christoph Hellwig wrote:
> +static ssize_t
> +zeroing_mode_store(struct device *dev, struct device_attribute *attr,
> +const char *buf, size_t count)
> +{
> + struct scsi_disk *sdkp = to_scsi_disk(dev);
> +
> + if (!capable(CAP_SYS_ADMIN))
> +
On 29/03/2017 18:28, Bart Van Assche wrote:
> On Wed, 2017-03-29 at 16:51 +0200, Paolo Bonzini wrote:
>> On 28/03/2017 20:50, Bart Van Assche wrote:
>>> This means that just like the start and end of a discard must be aligned on
>>> a
>>> discard_granu
On 23/03/2017 23:53, Lars Ellenberg wrote:
> Thin does not claim to zero data on discard. which is ok, and correct,
> because it only punches holes on full chunks (or whatever you call
> them), and leaves the rest in the mapping tree as is.
>
> And that behaviour would prevent DRBD from
On 28/03/2017 18:48, Bart Van Assche wrote:
>> +if (rq->cmd_flags & REQ_UNMAP) {
>> +switch (sdkp->provisioning_mode) {
>> +case SD_LBP_WS16:
>> +return sd_setup_write_same16_cmnd(cmd, true);
>> +case SD_LBP_WS10:
>> +
On 28/03/2017 19:00, Bart Van Assche wrote:
> On Thu, 2017-03-23 at 10:33 -0400, Christoph Hellwig wrote:
>> Now that we use the proper REQ_OP_WRITE_ZEROES operation everywhere we can
>> kill this hack.
>>
>> [ ... ]
>>
>> diff --git a/Documentation/ABI/testing/sysfs-block
>>
On 28/03/2017 20:50, Bart Van Assche wrote:
>
> This means that just like the start and end of a discard must be aligned on a
> discard_granularity boundary, WRITE SAME commands with the UNMAP bit set must
> also respect that granularity. I think this means that either
>
On 16/01/2017 18:26, Fam Zheng wrote:
>> Is the endianness correct for big-endian host here?
>
> I think so. The fc_host sysfs uses u64 to represent port_name and node_name,
> this patch does the same, so using virtio_* helpers for these fields should
> handle the endianness correctly.
I was
> How it this supposed to work?
> You do export the WWPN/WWNN of the associated host to the guest (nb:
> will get interesting for non NPIV setups ...), but virtio scsi will
> still do a LUN remapping.
> IE the LUNs you see on the host will be different from the LUNs
> presented to the guest.
On 16/01/2017 17:04, Fam Zheng wrote:
> + node_name = virtio_cread64(vdev,
> + offsetof(struct virtio_scsi_config, primary_wwnn));
> + port_name = virtio_cread64(vdev,
> + offsetof(struct virtio_scsi_config, primary_wwpn));
> +
On 08/12/2016 00:31, Tyrel Datwyler wrote:
> The first byte of each CRQ entry is used to indicate whether an entry is
> a valid response or free for the VIOS to use. After processing a
> response the driver sets the valid byte to zero to indicate the entry is
> now free to be reused. Add a
else
> + } else {
> + unsigned int flags = FOLL_TOUCH | FOLL_HWPOISON;
> +
> + if (write_fault)
> + flags |= FOLL_WRITE;
> +
> npages = __get_user_pages_unlocked(current, current->mm, addr,
> 1,
> -write_fault, 0, page,
> -FOLL_TOUCH|FOLL_HWPOISON);
> +page, flags);
> + }
> if (npages != 1)
> return npages;
>
>
Acked-by: Paolo Bonzini <pbonz...@redhat.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
*vq)
> struct virtio_scsi *vscsi = shost_priv(sh);
>
> virtscsi_vq_done(vscsi, >event_vq, virtscsi_complete_event);
> -};
> +}
>
> /**
> * virtscsi_add_cmd - add a virtio_scsi_cmd to a virtqueue
>
Acked-by: Paolo Bonzini <pbonz...@redhat.com>
--
To unsubscribe
On 06/06/2016 17:47, John Snow wrote:
> > > Various downstreams may have backported the VPD fix to older versions,
> > > we need to be careful not to block those, too ... so targeting the core
> > > behavior seems like the more strictly correct, easily maintainable
> > > solution.
> >
> > I
On 06/06/2016 17:41, John Snow wrote:
> On 06/06/2016 11:05 AM, Paolo Bonzini wrote:
>> For ATAPI, you have to blacklist all versions up to 2.2 inclusive.
>>
>> This gives:
>>
>> - QEMU / QEMU CD-ROM / 0.8.(this is IDE and SCSI)
>> - QEMU / QEMU
On 06/06/2016 16:22, Hannes Reinecke wrote:
> So either we dig into what went wrong with qemu 0.8, or we figure out
> from which qemu version things start to behave nicely, and blacklist
> earlier versions.
>
> > > Either way, this patch is wrong.
> >
> > If we can identify which versions
On 10/05/2016 19:31, James Bottomley wrote:
> > What about a SPACE ALLOCATION FAILED error or a similar error that
> > can be fixed by administrator actions (or just by a concurrent
> > process doing an UNMAP)? Would a subsequent cache flush cause data
> > loss?
>
> You're now asking about
On 10/05/2016 16:16, James Bottomley wrote:
> > If "is performed" just means "completes", maybe with an error, the
> > application would have to resubmit write requests and then try to
> > flush the write cache again.
> >
> > I'm not aware of applications that keep acknowledged write data
> >
On 25/09/2015 11:27, Paolo Bonzini wrote:
> This is v3 of the series to provide an "official" sg.h header (and
> scsi_ioctl.h too, though it's basically obsolete) together with the other
> userspace API definitions. The change from v2 to v3 is that defaults
> for
On 02/11/2015 16:05, Mike Snitzer wrote:
> > In any case, if we don't start path activation we should return
> > ENOTCONN, not ENOTTY.
>
> Currently, if we don't start path activation we're returning EIO.
> ENOTCONN is used for when we do start path activation (and ENOTCONN is
> the means for
On 02/11/2015 14:56, Hannes Reinecke wrote:
> But then the real question remains:
>
> What is the 'correct' behaviour for ioctls when no path retry
> is active (or when no paths are present)?
>
> Should we start path activation?
> If so, should we wait for path activation to finish, risking
On 02/11/2015 08:28, Hannes Reinecke wrote:
>
> With the original code we would need to wait for path activation
> before we would be able to figure out if the ioctl is valid.
> However, the callback to verify the ioctl is sd_ioctl(), which as
> a first step calls scsi_verify_ioctl().
> So my
On 31/10/2015 23:47, Mike Snitzer wrote:
> Yes, with your commit ec8013be ("dm: do not forward ioctls from logical
> volumes to the underlying device") you added protections to disallow
> issuing ioctls to a partition that could impact the rest of the device.
>
> Given that I can see why you're
On 31/10/2015 19:13, Mike Snitzer wrote:
> > But that's wrong, I think. It's a false positive in
> > scsi_verify_blk_ioctl().
> >
> > If the ioctl is valid when bdev becomes non-NULL (and it will be if
> > ti->len becomes equal to i_size_read(bdev->bd_inode) >> SECTOR_SHIFT),
> > you should
On 29/10/2015 14:18, Mike Snitzer wrote:
> > 4) dmesg shows that scsi_verify_blk_ioctl() failed for SG_IO (0x2285);
> >it returns -ENOIOCTLCMD, later replaced with -ENOTTY in vfs_ioctl().
> >
> > $ dmesg
> > <...>
> > [] device-mapper: multipath: Failing path 65:144.
> > []
On 17/09/2015 17:32, Bart Van Assche wrote:
>
>> +
>> +#ifndef __KERNEL__
>> +/* Keep in sync with SG_DEFAULT_TIMEOUT of scsi/sg.h */
>> #define SG_DEFAULT_TIMEOUT(60*HZ) /* HZ == 'jiffies in 1
>> second' */
>> #endif
>
> Is it useful and/or necessary to export this constant ?
NEL__", but they are actually useful for userspace as
well. Add them to the new header.
Cc: James Bottomley <jbottom...@parallels.com>
Cc: Christoph Hellwig <h...@lst.de>
Cc: linux-scsi@vger.kernel.org
Cc: Bart Van Assche <bart.vanass...@sandisk.com>
Signed-off-by: Paolo Bonzini <pbonz..
roken driver cpqfc", 2005-10-29).
Remove it, just in time for the the tenth anniversary of its demise.
Cc: James Bottomley <jbottom...@parallels.com>
Cc: Christoph Hellwig <h...@lst.de>
Cc: linux-scsi@vger.kernel.org
Reviewed-by: Bart Van Assche <bart.vanass...@sandisk.com>
This is v3 of the series to provide an "official" sg.h header (and
scsi_ioctl.h too, though it's basically obsolete) together with the other
userspace API definitions. The change from v2 to v3 is that defaults
for sg.c are not exported in include/uapi/linux/sg.c.
Paolo
2.5.0
--
To unsubscribe
: linux-scsi@vger.kernel.org
Reviewed-by: Bart Van Assche <bart.vanass...@sandisk.com>
Signed-off-by: Paolo Bonzini <pbonz...@redhat.com>
---
include/scsi/sg.h | 6 --
1 file changed, 6 deletions(-)
diff --git a/include/scsi/sg.h b/include/scsi/sg.h
index 3afec7032448..370c78c37926 100644
--- a
Some are in scsi.h. Keep them together in preparation for exposing them
in UAPI headers.
Cc: James Bottomley <jbottom...@parallels.com>
Cc: Christoph Hellwig <h...@lst.de>
Cc: linux-scsi@vger.kernel.org
Reviewed-by: Bart Van Assche <bart.vanass...@sandisk.com>
Signed-off-by: Pa
scsi_idlun used to be under
"#ifdef __KERNEL__", but they are actually useful for userspace as
well. Add them to the new header.
Signed-off-by: Paolo Bonzini <pbonz...@redhat.com>
---
include/scsi/scsi_ioctl.h | 50 +-
include/scsi/sg.h
roken driver cpqfc", 2005-10-29).
Remove it, just in time for the the tenth anniversary of its demise.
Signed-off-by: Paolo Bonzini <pbonz...@redhat.com>
---
include/scsi/scsi.h | 6 ++
include/scsi/scsi_ioctl.h | 8
2 files changed, 6 insertions(+), 8 deletions(-)
diff
Some are in scsi/scsi.h. Keep them together in preparation for exposing
them in UAPI headers.
Suggested-by: Christoph Hellwig <h...@lst.de>
Signed-off-by: Paolo Bonzini <pbonz...@redhat.com>
---
include/scsi/scsi.h | 20
include/scsi/scsi_
in uapi/linux/scsi_ioctl.h, even those
formerly in scsi/scsi.h [requested by hch]
... and reverting to the flat uapi/linux/ structure instead of
creating uapi/linux/scsi/.
Paolo
Paolo Bonzini (4):
scsi: remove old-style type names from sg.h
scsi: cleanup scsi/scsi_ioctl.h
scsi: move all
These will not be exported by the new linux/sg.h header, and scsi/sg.h will
not have any user API after linux/sg.h is created. Since they have no
user in the kernel, they can be zapped.
Signed-off-by: Paolo Bonzini <pbonz...@redhat.com>
---
include/scsi/sg.h | 6 --
1 file chan
On 16/09/2015 15:39, Christoph Hellwig wrote:
> Hi Paolo,
>
> can you just move them to include/linux/ directly?
I'm trying to cater to the objections that were made to Andy's patch.
If you mean the non-UAPI headers, James wanted them to stay in scsi/; if
you mean the UAPI headers, Douglas
On 16/09/2015 16:23, Christoph Hellwig wrote:
> > I'm trying to cater to the objections that were made to Andy's patch.
> > If you mean the non-UAPI headers, James wanted them to stay in scsi/; if
> > you mean the UAPI headers, Douglas complained about the flat structure
> > of include/linux/.
>
gro...@redhat.com>
Cc: James Bottomley <jbottom...@parallels.com>
Cc: Christoph Hellwig <h...@lst.de>
Cc: Douglas Gilbert <dgilb...@interlog.com>
Cc: Linux SCSI List <linux-scsi@vger.kernel.org>
Signed-off-by: Paolo Bonzini <pbonz...@redhat.com>
---
Similar to Andy Grov
virtio_scsi_driver = {
Reviewed-by: Paolo Bonzini pbonz...@redhat.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
On 23/04/2015 20:10, Christoph Hellwig wrote:
T10 PI is just another optional feature, LLDDs should work without
the infrastructure.
Signed-off-by: Christoph Hellwig h...@lst.de
---
drivers/scsi/Kconfig | 1 -
drivers/scsi/virtio_scsi.c | 11 ++-
2 files changed, 10
capacity failed
block/partition-generic.c | 6 +++---
drivers/scsi/sd.c | 22 +-
2 files changed, 16 insertions(+), 12 deletions(-)
Reviewed-by: Paolo Bonzini pbonz...@redhat.com
Though patch 3 could be seen as a change in userspace ABI, so I'm less
sure about
On 05/03/2015 14:37, Paolo Bonzini wrote:
On 05/03/2015 14:33, Christoph Hellwig wrote:
Any chance to get reviews for this series? Also we should at least
expedite this first patch into 4.0-rc as it fixes scanning races
in virtio_scsi.
I reviewed 1 and 3, but I'm not really qualified
-host-hostt-module))
+ goto fail_put_device;
return 0;
+
+fail_put_device:
+ put_device(sdev-sdev_gendev);
+fail:
+ return -ENXIO;
}
EXPORT_SYMBOL(scsi_device_get);
Reviewed-by: Paolo Bonzini pbonz...@redhat.com
--
To unsubscribe from this list: send the line
)
drv-rescan(dev);
module_put(dev-driver-owner);
}
+ device_unlock(dev);
}
EXPORT_SYMBOL(scsi_rescan_device);
Reviewed-by: Paolo Bonzini pbonz...@redhat.com
--
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body
On 05/03/2015 14:33, Christoph Hellwig wrote:
Any chance to get reviews for this series? Also we should at least
expedite this first patch into 4.0-rc as it fixes scanning races
in virtio_scsi.
I reviewed 1 and 3, but I'm not really qualified for patch 2.
Paolo
On Mon, Feb 02, 2015 at
On 02/02/2015 13:59, Christoph Hellwig wrote:
On Fri, Jan 30, 2015 at 10:46:17AM +0100, Paolo Bonzini wrote:
Great, we might want to revert that patch in 3.21.
Is that fix in any tree yet? Seems like I missed it for the scsi
tree at least. So unless you want it for 3.19/stable we might
.
This is useful for vhost ANY_LAYOUT support when guests are allowed to
generate
incoming virtio request headers combined with subsequent SGL payloads into a
single iovec.
Cc: Michael S. Tsirkin m...@redhat.com
Cc: Paolo Bonzini pbonz...@redhat.com
Signed-off-by: Nicholas Bellinger n...@linux
On 30/01/2015 02:08, Fam Zheng wrote:
On Fri, 01/30 00:11, Paolo Bonzini wrote:
On 29/01/2015 00:00, Christoph Hellwig wrote:
Lock the device embedded in the scsi_device to protect against
concurrent calls to -remove.
Signed-off-by: Christoph Hellwig h...@lst.de
I wonder if this makes
On 29/01/2015 00:00, Christoph Hellwig wrote:
Lock the device embedded in the scsi_device to protect against
concurrent calls to -remove.
Signed-off-by: Christoph Hellwig h...@lst.de
I wonder if this makes this problem: https://lkml.org/lkml/2015/1/5/9 go
away.
Paolo
---
(sdkp);
_
--
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
Reviewed-by: Paolo Bonzini pbonz...@redhat.com
--
To unsubscribe from this list: send
)
sd_config_discard(sdkp, SD_LBP_WS16);
else if (sdkp-lbpws10)
sd_config_discard(sdkp, SD_LBP_WS10);
This is the right fix. Ming, how do you reproduce the QEMU bug?
Acked-by: Paolo Bonzini pbonz...@redhat.com
--
To unsubscribe from
On 05/12/2014 14:05, Ming Lei wrote:
[ 50.112885] sd 0:0:1:0: [sda] FAILED Result: hostbyte=DID_OK
driverbyte=DRIVER_SENSE
[ 50.113859] sd 0:0:1:0: [sda] Sense Key : Illegal Request [current]
[ 50.113859] sd 0:0:1:0: [sda] Add. Sense: Invalid field in cdb
[ 50.113859] sd 0:0:1:0:
On 07/11/2014 06:08, Martin K. Petersen wrote:
The whitelist is only meant as a starting point and is by no means
comprehensive:
- All intel SSD models except for 510
- Micron M5*
- Samsung SSDs
- Seagate SSDs
Signed-off-by: Martin K. Petersen martin.peter...@oracle.com
/esp_scsi.h
+++ b/drivers/scsi/esp_scsi.h
@@ -1,4 +1,4 @@
-/* esp_scsi.h: Defines and structures for the ESP drier.
+/* esp_scsi.h: Defines and structures for the ESP driver.
*
* Copyright (C) 2007 David S. Miller (da...@davemloft.net)
*/
A good start. :)
Reviewed-by: Paolo Bonzini pbonz
num_tags;
struct list_headesp_cmd_pool;
Reviewed-by: Paolo Bonzini pbonz...@redhat.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
);
switch (esp-event) {
case ESP_EVENT_CHECK_PHASE:
switch (esp-sreg ESP_STAT_PMASK) {
Reviewed-by: Paolo Bonzini pbonz...@redhat.com
--
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to majord...@vger.kernel.org
More
-by: Paolo Bonzini pbonz...@redhat.com
Paolo
--
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
On 21/11/2014 10:27, Hannes Reinecke wrote:
A read to ESP_INTRPT will clear ESP_STATUS and ESP_SSTEP. So read
all status registers in one go to avoid losing information.
(ESP_STAT_TCNT is actually kept in the status register, it is cleared by
writing TCLO/MID/HI).
Reviewed-by: Paolo Bonzini
On 21/11/2014 10:27, Hannes Reinecke wrote:
The am53c974 has a design flaw causing it to throw an
DMA interrupt whenever a DMA transmission completed,
even though DMA interrupt reporting is disabled.
This confuses the esp routines as it would register
a DMA interrupt whenever a cdb has been
On 21/11/2014 10:27, Hannes Reinecke wrote:
CONFIG2_FENAB ('feature enable') changed definition between chip
revisions, from 'Latch SCSI Phase' to 'Latch SCSI Phase, display
chip ID upon reset, and enable 24 bit addresses'.
So only enable it for am53c974 where we know what it's doing.
On 21/11/2014 10:27, Hannes Reinecke wrote:
The am53c974 has an design issue where a single byte might be
left in the SCSI FIFO after a DMA transfer.
As the handling code is currently untested add a WARN_ON()
statement here.
Signed-off-by: Hannes Reinecke h...@suse.de
---
config1;
u8 config2;
+ u8 config4;
u8 scsi_id;
u32 scsi_id_mask;
Reviewed-by: Paolo Bonzini pbonz...@redhat.com
--
To unsubscribe from this list: send the line unsubscribe linux
On 21/11/2014 10:27, Hannes Reinecke wrote:
This patch adds a new implementation for the Tekram DC-390T /
AMD AM53c974 SCSI controller, based on the generic
esp_scsi infrastructure.
Signed-off-by: Hannes Reinecke h...@suse.de
---
drivers/scsi/Kconfig| 18 ++
drivers/scsi/Makefile
Oops, hit send too early. A small nit:
On 21/11/2014 10:27, Hannes Reinecke wrote:
+static void pci_esp_dma_drain(struct esp *esp)
+{
+ u8 resid;
+ int lim = 1000;
+
+
+ if ((esp-sreg ESP_STAT_PMASK) == ESP_DOP ||
+ (esp-sreg ESP_STAT_PMASK) == ESP_DIP)
+
On 21/11/2014 11:38, Hannes Reinecke wrote:
esp-msg_out_len = 0;
*p++ = IDENTIFY(0, lun);
@@ -648,12 +651,21 @@ static void esp_autosense(struct esp *esp, struct
esp_cmd_entry *ent)
esp_write_tgt_sync(esp, tgt);
esp_write_tgt_config3(esp, tgt);
- val = (p -
On 21/11/2014 11:22, Hannes Reinecke wrote:
On 11/21/2014 11:08 AM, Paolo Bonzini wrote:
On 21/11/2014 10:27, Hannes Reinecke wrote:
CONFIG2_FENAB ('feature enable') changed definition between chip
revisions, from 'Latch SCSI Phase' to 'Latch SCSI Phase, display
chip ID upon reset
ESP_FLAG_USE_FIFO0x0040
u8 select_state;
#define ESP_SELECT_NONE 0x00 /* Not selecting */
Reviewed-by: Paolo Bonzini pbonz...@redhat.com
--
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to majord
On 15/11/2014 04:47, Ming Lei wrote:
Since virtio_scsi has supported multi virtqueue already,
it is natural to map the virtque to hw-queue of blk-mq.
Cc: Paolo Bonzini pbonz...@redhat.com
Signed-off-by: Ming Lei ming@canonical.com
---
V1:
- support non-mq too
drivers/scsi
On 10/11/2014 17:05, Christoph Hellwig wrote:
a) there is no multiath support for it, and we simply can't break existing
setups that use.
b) there is no support for I/O schedulers at all. This might be okay
for virtio-scsi, where in general you have a host scheduler, but for
On 09/11/2014 17:57, Ming Lei wrote:
Since virtio_scsi has supported multi virtqueue already,
it is natural to map virtque to hw-queue of blk-mq.
Cc: Paolo Bonzini pbonz...@redhat.com
Signed-off-by: Ming Lei ming@canonical.com
---
drivers/scsi/virtio_scsi.c | 154
sd_config_discard(sdkp, SD_LBP_DISABLE);
}
Reviewed-by: Paolo Bonzini pbonz...@redhat.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
Il 09/10/2014 06:14, Nicholas A. Bellinger ha scritto:
AFAICT from qemu code, the ioctl VHOST_SCSI_CLEAR_ENDPOINT is always
called during shutdown in order to release the endpoint and drop this
new configfs dependency.
As far as I can see, the only path leading to the ioctl is
Il 09/10/2014 10:49, Paolo Bonzini ha scritto:
It does not happen if you close QEMU with SIGTERM, ctrl-c, or with the
quit command, because no attempt is done to bring down the VM data
structures (or free memory, or close file descriptors) in case of a
fatal exit. The kernel should do
Il 29/08/2014 08:08, Hannes Reinecke ha scritto:
No.
FAILED for any eh_abort_cmd() means that the TMF hasn't been sent.
So the midlayer escalates to the next EH step.
The command will only ever be re-issued once EH completes.
Then the answer to Hans's question is yes. It is legal to call
Il 28/08/2014 14:26, Hans de Goede ha scritto:
Then, blk_complete_request will do nothing because its call to
blk_mark_rq_complete returns true.
All this, of course, as long as -scsi_done is called _before_ eh_abort
returns.
What about calling scsi_done after eh_abort if eh_abort
Il 28/08/2014 16:17, Hannes Reinecke ha scritto:
As mentioned earlier, as soon as SCSI EH is invoked control
is assumed to be transferred back to the SCSI midlayer.
How the midlayer interprets any return value from the various eh_XX
callbacks is immaterial to the LLDD.
So even if the
Il 28/08/2014 17:50, Elliott, Robert (Server Storage) ha scritto:
Is the block layer prevented from issuing a new command with the
same tag before the error handling is finished?
Tags are chosen by the LLDs, so it's up to it to pick the right tags.
Paolo
--
To unsubscribe from this list: send
Il 23/08/2014 16:52, Hans de Goede ha scritto:
Hi All,
Now that the UAS driver is no longer marked as CONFIG_BROKEN,
I'm getting quite a few bug reports about issues with UAS drives.
One if the issues is that there might be a number of bugs in the
abort handling path, as I don't think
Il 25/08/2014 12:28, Bart Van Assche ha scritto:
From SPC-4: 7.5.8 Control mode page [ ... ] A task aborted status (TAS)
bit set to zero specifies that aborted commands shall be terminated by
the device server without any response to the application client. A TAS
bit set to one specifies
Il 18/07/2014 16:57, Ming Lei ha scritto:
- if (sc-sense_buffer) {
+ if (resp-sense_len) {
In the (unlikely) case that sc-sense_buffer == NULL, you'd pass a NULL
to memcpy.
If you want, you can change this if to
if (sc-sense_buffer resp-sense_len)
but frankly it seems like
Christoph asked me to rebase the two virtio-scsi patches from
http://thread.gmane.org/gmane.linux.kernel/1717796 that do not apply
anymore, patch 2 and 6.
These are on top of his drivers-for-3.16 branch, more precisely commit
8faeb529b2da (virtio-scsi: fix various bad behavior on aborted
@canonical.com
[Add initialization in virtscsi_target_alloc. - Paolo]
Signed-off-by: Paolo Bonzini pbonz...@redhat.com
---
drivers/scsi/virtio_scsi.c | 42 +-
1 file changed, 29 insertions(+), 13 deletions(-)
diff --git a/drivers/scsi/virtio_scsi.c b/drivers/scsi
,
struct device *dev)
{
Reviewed-by: Paolo Bonzini pbonz...@redhat.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
?
Not that there's much to review there. :)
Reviewed-by: Paolo Bonzini pbonz...@redhat.com
Paolo
--
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
Il 24/06/2014 16:28, Christoph Hellwig ha scritto:
Adding Paul and Nathan to cc here. I'm pretty sure the backend for ibmvscsi in
KVM was all done in qemu and there is no dependency on ibmvstgt.
FWIW the ibmvscsi backend is indeed entirely in userspace
(hw/scsi/spapr_vscsi.c in the QEMU
1 - 100 of 378 matches
Mail list logo
