On Tue, 2015-02-03 at 11:24 +0200, Michael S. Tsirkin wrote:
>
> On Tue, Feb 03, 2015 at 06:29:55AM +, Nicholas A. Bellinger wrote:
> > From: Nicholas Bellinger
> >
> > Required for ANY_LAYOUT support when the incoming virtio-scsi response
> > header + fixed size sense buffer payload may spa
On Tue, 2015-02-03 at 11:32 +0200, Michael S. Tsirkin wrote:
> On Tue, Feb 03, 2015 at 06:29:58AM +, Nicholas A. Bellinger wrote:
> > From: Nicholas Bellinger
> >
> > This patch adds ANY_LAYOUT prerequisites logic for accepting a set of
> > protection + data payloads via iov_iter. Also inclu
On Tue, 2015-02-03 at 11:35 +0200, Michael S. Tsirkin wrote:
> On Tue, Feb 03, 2015 at 06:29:54AM +, Nicholas A. Bellinger wrote:
> > From: Nicholas Bellinger
> >
> > Hi MST, Paolo, Al & Co,
> >
> > Here is -v3 for adding vhost/scsi ANY_LAYOUT + VERSION_1 host feature
> > bit support.
> >
>
On Tue, 2015-02-03 at 11:37 +0200, Michael S. Tsirkin wrote:
> On Tue, Feb 03, 2015 at 06:30:01AM +, Nicholas A. Bellinger wrote:
> > From: Nicholas Bellinger
> >
> > With the new ANY_LAYOUT logic in place for vhost_scsi_handle_vqal(),
> > there is no longer a reason to keep around the legacy
On Tue, 2015-02-03 at 11:40 +0200, Michael S. Tsirkin wrote:
> On Tue, Feb 03, 2015 at 06:30:00AM +, Nicholas A. Bellinger wrote:
> > From: Nicholas Bellinger
> >
> > Signal support of VIRTIO_F_ANY_LAYOUT + VIRTIO_F_VERSION_1 feature bits
> > required for virtio-scsi 1.0 spec layout requireme
On Wed, Feb 04, 2015 at 01:13:58AM -0800, Nicholas A. Bellinger wrote:
> On Tue, 2015-02-03 at 11:40 +0200, Michael S. Tsirkin wrote:
> > On Tue, Feb 03, 2015 at 06:30:00AM +, Nicholas A. Bellinger wrote:
> > > From: Nicholas Bellinger
> > >
> > > Signal support of VIRTIO_F_ANY_LAYOUT + VIRTI
On Tue, 2015-02-03 at 12:14 +0200, Michael S. Tsirkin wrote:
> On Tue, Feb 03, 2015 at 06:29:59AM +, Nicholas A. Bellinger wrote:
> > From: Nicholas Bellinger
> >
> > This patch adds ANY_LAYOUT support with a new vqs[].vq.handle_kick()
> > callback in vhost_scsi_handle_vqal().
> >
> > It cal
On Wed, Feb 04, 2015 at 01:40:25AM -0800, Nicholas A. Bellinger wrote:
> > > + /*
> > > + * Any associated T10_PI bytes for the outgoing / incoming
> > > + * payloads are included in calculation of exp_data_len here.
> > > + */
> > > + if (out_size > req_s
Since you mentioned problem does not happen on Windows, what do you use
to emulate the workload (iometer ?)
CrystalDiskMark, HD Tune, ATTO Disk Benchmark
Tested for 2-3 hours, but got stable results. Directly afterwards booted
Live CD with Linux and immediately got poor results.
and did you
On Tue, 2015-02-03 at 23:56 +, Al Viro wrote:
> On Tue, Feb 03, 2015 at 06:29:59AM +, Nicholas A. Bellinger wrote:
> > +* Copy over the virtio-scsi request header, which when
> > +* ANY_LAYOUT is enabled may span multiple iovecs, or a
> > +* single iovec
On Wed, Feb 04, 2015 at 02:11:20AM -0800, Nicholas A. Bellinger wrote:
> On Tue, 2015-02-03 at 23:56 +, Al Viro wrote:
> > On Tue, Feb 03, 2015 at 06:29:59AM +, Nicholas A. Bellinger wrote:
> > > + * Copy over the virtio-scsi request header, which when
> > > + * ANY_LAYOUT
On Wed, 2015-02-04 at 11:20 +0100, Michael S. Tsirkin wrote:
> On Wed, Feb 04, 2015 at 02:11:20AM -0800, Nicholas A. Bellinger wrote:
> > On Tue, 2015-02-03 at 23:56 +, Al Viro wrote:
> > > On Tue, Feb 03, 2015 at 06:29:59AM +, Nicholas A. Bellinger wrote:
> > > > +* Copy ov
On Wed, 2015-02-04 at 10:42 +0100, Michael S. Tsirkin wrote:
> On Wed, Feb 04, 2015 at 01:40:25AM -0800, Nicholas A. Bellinger wrote:
> > > > + /*
> > > > +* Any associated T10_PI bytes for the outgoing /
> > > > incoming
> > > > +* payloads are includ
On Wed, 2015-02-04 at 02:41 -0800, Nicholas A. Bellinger wrote:
> On Wed, 2015-02-04 at 10:42 +0100, Michael S. Tsirkin wrote:
> > On Wed, Feb 04, 2015 at 01:40:25AM -0800, Nicholas A. Bellinger wrote:
> > > > > + /*
> > > > > + * Any associated T10_PI bytes for the outgoin
On Tue, 3 Feb 2015, Nicholas Mc Guire wrote:
> This is only an API consolidation to make things more readable.
Please remove the above; the g_NCR5380.c change invalidates it.
> Instances of var * HZ / 1000 are replaced by msecs_to_jiffies(var).
> In addition some timing constants that assume
On Wed, Feb 04, 2015 at 02:41:07AM -0800, Nicholas A. Bellinger wrote:
> On Wed, 2015-02-04 at 10:42 +0100, Michael S. Tsirkin wrote:
> > On Wed, Feb 04, 2015 at 01:40:25AM -0800, Nicholas A. Bellinger wrote:
> > > > > + /*
> > > > > + * Any associated T10_PI bytes for the
On Wed, Feb 04, 2015 at 02:41:07AM -0800, Nicholas A. Bellinger wrote:
> On Wed, 2015-02-04 at 10:42 +0100, Michael S. Tsirkin wrote:
> > On Wed, Feb 04, 2015 at 01:40:25AM -0800, Nicholas A. Bellinger wrote:
> > > > > + /*
> > > > > + * Any associated T10_PI bytes for the
On Wed, Feb 04, 2015 at 02:55:12AM -0800, Nicholas A. Bellinger wrote:
> On Wed, 2015-02-04 at 02:41 -0800, Nicholas A. Bellinger wrote:
> > On Wed, 2015-02-04 at 10:42 +0100, Michael S. Tsirkin wrote:
> > > On Wed, Feb 04, 2015 at 01:40:25AM -0800, Nicholas A. Bellinger wrote:
> > > > > > +
> Please use trace__enabled(), for instance,
> trace_ufshcd_command_enabled().
>
> This also uses jump_labels and is a nop when it is not enabled.
I accept your comment and will fix it.
I'll wait a bit longer with sending v2 in case there are more comments.
Thanks,
Gilad.
--
QUALCOMM ISRAEL, on
On Wednesday 04 February 2015 10:15:12 Tina Ruchandani wrote:
> 'struct timeval' will have its tv_sec value overflow on 32-bit systems
> in year 2038 and beyond. This patch replaces the use of struct timeval
> for computing mpi_request.TimeStamp, and instead uses ktime_t which provides
> 64-bit sec
On Wednesday 04 February 2015 11:28:35 Tina Ruchandani wrote:
> 'struct timeval' will have its tv_sec value overflow on 32-bit systems
> in year 2038 and beyond. This patch replaces the use of struct timeval
> for computing mpi_request.TimeStamp, and instead uses ktime_t which provides
> 64-bit sec
On Wednesday 04 February 2015 08:39:54 Tina Ruchandani wrote:
> struct timeval will have its tv_sec field overflow on 32-bit systems
> in year 2038 and beyond. This patch removes the usage of struct timeval
> and instead uses 64-bit ktime_t to get the current milliseconds
> to populate pmcraid_time
On Wednesday 04 February 2015 08:34:48 Tina Ruchandani wrote:
> Function stex_gettime uses 'struct timeval' whose tv_sec value
> will overflow on 32-bit systems in year 2038 and beyond. This patch
> replaces the use of struct timeval and do_gettimeofday with
> ktime_get_real_seconds, which returns
On Wednesday 04 February 2015 08:42:03 Tina Ruchandani wrote:
> struct timeval will have its tv_sec field overflow on 32-bit systems
> in year 2038 and beyond. This patch removes the usage of struct timeval
> and instead uses ktime_get_real_seconds() which returns 64-bit wall-clock
> seconds.
>
>
On Wed, 2015-02-04 at 17:29 +1100, Stephen Rothwell wrote:
> Hi James,
>
> After merging the scsi tree, today's linux-next build (powerpc
> ppc64_defconfig) failed like this:
>
> drivers/scsi/scsi_logging.c: In function 'sdev_prefix_printk':
> drivers/scsi/scsi_logging.c:119:6: error: void value
R5380.c was not even compile-tested
(crosstool-ng m68k-unknown-elf and m68k-unknown-uclinux-uclibc fail to
build atari_defconfig or multi_defconfig (or I failed to build the
toolchain properly))
Patch is against 3.19.0-rc7 (localversion-next is -next-20150204)
drivers/scsi/NC
Summary:
When removing a SCSI device with scsi-mq, blk_mq_update_tag_set_depth()
ends up waiting for commands to *other* SCSI devices to complete. If
those other SCSI devices are in the SDEV_BLOCK state, then the removal
deadlocks.
Setup:
kernel 3.19-rc7 with the following additional commits:
From: "Lad, Prabhakar"
this patch fixes following sparse warnings:
osst.c:5699:1: warning: symbol 'dev_attr_ADR_rev' was not declared. Should it
be static?
osst.c:5713:1: warning: symbol 'dev_attr_media_version' was not declared.
Should it be static?
osst.c:5726:1: warning: symbol 'dev_attr_ca
bnx2fc_global_lock is only used in bnx2fc_fcoe.c
Signed-off-by: Fabian Frederick
---
drivers/scsi/bnx2fc/bnx2fc_fcoe.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/scsi/bnx2fc/bnx2fc_fcoe.c
b/drivers/scsi/bnx2fc/bnx2fc_fcoe.c
index 98d06d1..66fb527 100644
--- a/dr
> -Original Message-
> From: linux-scsi-ow...@vger.kernel.org [mailto:linux-scsi-
> ow...@vger.kernel.org] On Behalf Of Tony Battersby
> Sent: Wednesday, 04 February, 2015 12:39 PM
> To: linux-scsi; Jens Axboe; Christoph Hellwig
> Cc: Sreekanth Reddy
> Subject: Device removal lockup with
From: Praveen Madhavan
Date: Tue, 3 Feb 2015 17:18:26 +0530
> This patch is to use firmware version macros from t4fw_version.h
> and also enables 40g T5 adapter.
>
> Signed-off-by: Praveen Madhavan
Applied.
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body o
On Wed, 28 Jan 2015 10:29:46 -0500 Nate Dailey
wrote:
> I'm writing about something that appears to be an issue with raid1's
> narrow_write_error, particular to non-512-byte-sector disks. Here's what
> I'm doing:
>
> - 2 disk raid1, 4K disks, each connected to a different SAS HBA
> - mount a f
is needed rather the declaration
is simply updated.
Patch was only compile tested for x86_64_defconfig + CONFIG_X86_VSMP=y
CONFIG_HYPERV=m, SCSI_LOWLEVEL=y, CONFIG_HYPERV_STORAGE=m
Patch is against 3.19.0-rc7 (localversion-next is -next-20150204)
drivers/scsi/storvsc_drv.c |6 --
1 file
This code in vhost_scsi_make_tpg() is confusing because we limit "tpgt"
to UINT_MAX but the data type of "tpg->tport_tpgt" and that is a u16.
I looked at the context and it turns out that in
vhost_scsi_set_endpoint(), "tpg->tport_tpgt" is used as an offset into
the vs_tpg[] array which has VHOST_S
34 matches
Mail list logo
