On Wed, Jul 09, 2014 at 09:49:56AM -0700, James Bottomley wrote:
As far as I can tell from the block MQ, we get one CPU thread per LUN.
No, that's entirely incorrect. IFF a device supports multiple hardware
queues we only submit I/O from CPUs (there might be more than one) this
queue is bound
Set cmd_per_lun to reflect value supported by the Host.
In this version of the patch I have addressed comments from
Christoph Hellwig h...@infradead.org
Signed-off-by: K. Y. Srinivasan k...@microsoft.com
Cc: sta...@vger.kernel.org
---
drivers/scsi/storvsc_drv.c |2 +-
1 files changed, 1
On Wed, Jul 09, 2014 at 01:12:17PM +0200, Hannes Reinecke wrote:
Hmm. I guess there is a race window between
atomic_read() and atomic_set().
Doesn't this cause issues when someone calls atomic_set() just before the
call to atomic_read?
There is a race window just _after_ the atomic_read, but
On Thu, Jul 10, 2014 at 12:53:36AM +, Elliott, Robert (Server Storage)
wrote:
the problem still occurs - fio results in low or 0 IOPS, with perf top
reporting unusual amounts of time spent in do_io_submit and io_submit.
The diff between the two version doesn't show too much other possible
Hannes, can you respin the patch with a comment explaining the limit?
Does it limit IO size for pass through IO not through block layer ?
The max_sectors limit also limits the size of passthrough requests.
--
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a
On Mon, Jul 07, 2014 at 05:20:01PM +0200, Tomas Henzl wrote:
The current implementation may mix the negative value returned
from pm8001_set_nvmd with with count. -(-ENOMEM) could be interpreted
as bytes programmed, this patch fixes it.
This still doesn;t look correct to me as err mixes up the
During IO with fabric faults, one generally sees several Unhandled error
code messages in the syslog as shown below:
sd 4:0:6:2: [sdbw] Unhandled error code
sd 4:0:6:2: [sdbw] Result: hostbyte=DID_NO_CONNECT driverbyte=DRIVER_OK
sd 4:0:6:2: [sdbw] CDB: Read(10): 28 00 00 00 00 00 00 00 08 00
On Wed, Jul 09, 2014 at 03:38:18PM -0700, James Bottomley wrote:
On Thu, 2014-07-03 at 10:18 -0700, Christoph Hellwig wrote:
On Thu, Jul 03, 2014 at 09:57:32AM -0700, Steven Haber wrote:
Both patches work fine -- zero uncommitted writes over several hundred
power cycles.
Thanks for
Thanks,
this looks very nice to me. It should also allow for later splitting
the error handling from scsi_io_completion into a separate function away
from the fast path.
--
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to majord...@vger.kernel.org
On 07/10/2014 09:41 AM, Maurizio Lombardi wrote:
During IO with fabric faults, one generally sees several Unhandled error
code messages in the syslog as shown below:
sd 4:0:6:2: [sdbw] Unhandled error code
sd 4:0:6:2: [sdbw] Result: hostbyte=DID_NO_CONNECT driverbyte=DRIVER_OK
sd 4:0:6:2:
On Wed, Jul 09, 2014 at 10:36:26PM +, KY Srinivasan wrote:
Ok; I am concerned about older kernels that do not have no_write_same flag.
I suppose I can work directly with these Distros and give them a choice:
either implement
the no_write_same flag or filter the command in our driver. I
On Wed, Jul 09, 2014 at 06:51:38PM +, KY Srinivasan wrote:
On Azure, we sometimes have unbounded I/O latencies and some distributions
(such as SLES12) based on recent kernels are invoking the Abort Handler.
Any kernel will invoke the abort handler if present, and then escalate
to the
On Wed, Jul 09, 2014 at 06:40:09PM +, KY Srinivasan wrote:
On Tue, Jul 08, 2014 at 05:46:51PM -0700, K. Y. Srinivasan wrote:
Correctly set SRB flags for all valid I/O directions. Some IHV drivers
on the Windows host require this.
What are IHV drivers?
If the target is a SAN
default:
vm_srb-data_in = UNKNOWN_TYPE;
- vm_srb-win8_extension.srb_flags = 0;
+ vm_srb-win8_extension.srb_flags |= (SRB_FLAGS_DATA_IN |
+ SRB_FLAGS_DATA_OUT);
This would usually be a command that
- .cmd_per_lun = 1,
+ .cmd_per_lun = 255,
.can_queue =STORVSC_MAX_IO_REQUESTS*STORVSC_MAX_TARGETS,
slave_configure immediately adjusts this down to STORVSC_MAX_IO_REQUESTS
(250), any reson to start out with the magic 255 here?
--
To unsubscribe from
On Mon, Jul 7, 2014 at 8:49 PM, Tomas Henzl the...@redhat.com wrote:
Instead of copying information to fw_control_context free it.
The task is forgotten thus also the reference to fw_control_context
and the completion thread takes the info from virt_ptr again.
Looks good. Thanks Tomas.
On Mon, Jul 7, 2014 at 8:50 PM, Tomas Henzl the...@redhat.com wrote:
ccb-fw_control_context is copied to local fw_control_context and
the local variable is never used later
Free ccb-fw_control_context.
The task is forgotten thus also the reference to fw_control_context
and the completion
On Mon, Jul 7, 2014 at 8:49 PM, Tomas Henzl the...@redhat.com wrote:
The driver checks the return valu, but after he tries to wait_for_completion
which might never happen.
Also the ioctlbuffer is freed at the end of the function,
so the first removal is not needed.
Looks good. Thanks Tomas.
On Wed, Jul 9, 2014 at 8:51 PM, KY Srinivasan k...@microsoft.com wrote:
-Original Message-
From: Christoph Hellwig [mailto:h...@infradead.org]
Sent: Wednesday, July 9, 2014 1:44 AM
To: KY Srinivasan
Cc: linux-ker...@vger.kernel.org; de...@linuxdriverproject.org;
oher...@suse.com;
This patch looks reasonable to me. I'd prefer if we didn't have to keep
the optional host_lock mode for the long run, but if it's important to
you for now we can keep it for a while.
And chance you could split updates into a series of updates for future
changes?
Reviewed-by: Christoph Hellwig
https://bugzilla.kernel.org/show_bug.cgi?id=79901
Bug ID: 79901
Summary: Extremely slow boot on Promise VTrak E610f due to
sd_mod RSOC usage
Product: IO/Storage
Version: 2.5
Kernel Version: 3.14.7
Hardware: x86-64
On 07/10/2014 08:43 AM, Christoph Hellwig wrote:
On Mon, Jul 07, 2014 at 05:20:01PM +0200, Tomas Henzl wrote:
The current implementation may mix the negative value returned
from pm8001_set_nvmd with with count. -(-ENOMEM) could be interpreted
as bytes programmed, this patch fixes it.
This
On Wed, Jul 09, 2014 at 11:20:40PM -0700, Christoph Hellwig wrote:
On Thu, Jul 10, 2014 at 12:53:36AM +, Elliott, Robert (Server Storage)
wrote:
the problem still occurs - fio results in low or 0 IOPS, with perf top
reporting unusual amounts of time spent in do_io_submit and io_submit.
On 2014-07-10 15:36, Benjamin LaHaise wrote:
On Wed, Jul 09, 2014 at 11:20:40PM -0700, Christoph Hellwig wrote:
On Thu, Jul 10, 2014 at 12:53:36AM +, Elliott, Robert (Server Storage)
wrote:
the problem still occurs - fio results in low or 0 IOPS, with perf top
reporting unusual amounts of
On Thu, Jul 10, 2014 at 03:39:57PM +0200, Jens Axboe wrote:
That's how fio always runs, it sets up the context with the exact queue
depth that it needs. Do we have a good enough understanding of other aio
use cases to say that this isn't the norm? I would expect it to be, it's
the way that
On 2014-07-10 15:44, Benjamin LaHaise wrote:
On Thu, Jul 10, 2014 at 03:39:57PM +0200, Jens Axboe wrote:
That's how fio always runs, it sets up the context with the exact queue
depth that it needs. Do we have a good enough understanding of other aio
use cases to say that this isn't the norm? I
This patch fixes the watermark threshold of the receive FIFO for the
APM X-Gene SATA host controller driver.
Signed-off-by: Loc Ho l...@apm.com
Signed-off-by: Suman Tripathi stripa...@apm.com
---
drivers/ata/ahci_xgene.c | 7 +++
1 file changed, 7 insertions(+)
diff --git
This patch fixes the SATA PHY clock DTS node csr-mask of the
SATA Host controller 1. This patch also fixes the status of
the PHY clock node of SATA Host Controller 1.
Signed-off-by: Loc Ho l...@apm.com
Signed-off-by: Suman Tripathi stripa...@apm.com
---
arch/arm64/boot/dts/apm-storm.dtsi | 5
This patch set contains a couple of fixes related to APM X-Gene SATA
controller driver.
v2 Change:
- Drop the Link down retry patch from this patch set.
Signed-off-by: Loc Ho l...@apm.com
Signed-off-by: Suman Tripathi stripa...@apm.com
---
Suman Tripathi (2):
ata: Fix the watermark
On Thu, Jul 10, 2014 at 03:48:10PM +0200, Jens Axboe wrote:
On 2014-07-10 15:44, Benjamin LaHaise wrote:
On Thu, Jul 10, 2014 at 03:39:57PM +0200, Jens Axboe wrote:
That's how fio always runs, it sets up the context with the exact queue
depth that it needs. Do we have a good enough
On Thu, Jul 10, 2014 at 09:36:09AM -0400, Benjamin LaHaise wrote:
There is one possible concern that could be exacerbated by other changes in
the system: if the application is running close to the bare minimum number
of requests allocated in io_setup(), the per cpu reference counters will
On 2014-07-10 15:50, Christoph Hellwig wrote:
On Thu, Jul 10, 2014 at 09:36:09AM -0400, Benjamin LaHaise wrote:
There is one possible concern that could be exacerbated by other changes in
the system: if the application is running close to the bare minimum number
of requests allocated in
On 2014-07-10 15:50, Benjamin LaHaise wrote:
On Thu, Jul 10, 2014 at 03:48:10PM +0200, Jens Axboe wrote:
On 2014-07-10 15:44, Benjamin LaHaise wrote:
On Thu, Jul 10, 2014 at 03:39:57PM +0200, Jens Axboe wrote:
That's how fio always runs, it sets up the context with the exact queue
depth that
Sounds like we need to skip REPORT SUPPORTED OPERATION CODES on this
array.
For this it needs a new BLIST_NORSOC flag added to
include/scsi/scsi_devinfo.h which sets sdev-no_report_opcodes in
scsi_add_lun, and an entry for your array in the big black list array in
drivers/scsi/scsi_devinfo.c.
2014-07-10 15:54 GMT+02:00 Christoph Hellwig h...@infradead.org:
Sounds like we need to skip REPORT SUPPORTED OPERATION CODES on this
array.
For this it needs a new BLIST_NORSOC flag added to
include/scsi/scsi_devinfo.h which sets sdev-no_report_opcodes in
scsi_add_lun, and an entry for your
-Original Message-
From: Jens Axboe [mailto:ax...@kernel.dk]
Sent: Thursday, 10 July, 2014 8:53 AM
To: Christoph Hellwig; Benjamin LaHaise
Cc: Elliott, Robert (Server Storage); dgilb...@interlog.com; James Bottomley;
Bart Van Assche; linux-scsi@vger.kernel.org;
On Thu, Jul 10, 2014 at 02:36:40PM +, Elliott, Robert (Server Storage)
wrote:
-Original Message-
From: Jens Axboe [mailto:ax...@kernel.dk]
Sent: Thursday, 10 July, 2014 8:53 AM
To: Christoph Hellwig; Benjamin LaHaise
Cc: Elliott, Robert (Server Storage);
On Thu, Jul 10, 2014 at 07:19:15PM +0530, Suman Tripathi wrote:
This patch fixes the watermark threshold of the receive FIFO for the
APM X-Gene SATA host controller driver.
Can you please explain what are the effects of these patches? Patch
descriptions should include why the specific changes
On Thu, Jul 10, 2014 at 07:19:16PM +0530, Suman Tripathi wrote:
This patch fixes the SATA PHY clock DTS node csr-mask of the
SATA Host controller 1. This patch also fixes the status of
the PHY clock node of SATA Host Controller 1.
Ditto. Before, XXX was wrong and as a result YYY didn't work
Benjamin LaHaise b...@kvack.org writes:
[ 186.339064] ioctx_alloc: nr_events=-2 aio_max_nr=65536
[ 186.339065] ioctx_alloc: nr_events=-2 aio_max_nr=65536
[ 186.339067] ioctx_alloc: nr_events=-2 aio_max_nr=65536
[ 186.339068] ioctx_alloc: nr_events=-2 aio_max_nr=65536
[ 186.339069]
-Original Message-
From: Christoph Hellwig [mailto:h...@infradead.org]
Sent: Thursday, 10 July, 2014 1:21 AM
To: Elliott, Robert (Server Storage)
Cc: Jens Axboe; dgilb...@interlog.com; Christoph Hellwig; James Bottomley;
Bart Van Assche; Benjamin LaHaise;
On Thu, Jul 10, 2014 at 03:51:44PM +, Elliott, Robert (Server Storage)
wrote:
scsi-mq.3-bisect-1 branch that is rebased to just before the merge of
the block tree
good.
and a scsi-mq.3-bisect-2 branch that is just after the merge of the
block tree to get started.
good.
It's
On Thu, Jul 10, 2014 at 09:04:22AM -0700, Christoph Hellwig wrote:
It's starting to look weird. I'll prepare another two bisect branches
around some MM changes, which seems the only other possible candidate.
I've pushed out scsi-mq.3-bisect-3 and scsi-mq.3-bisect-4 for you.
--
To unsubscribe
[+cc LKML, Greg KH for driver core async shutdown question]
On Tue, Jun 24, 2014 at 10:48:57AM -0600, Keith Busch wrote:
I'd like to do shutdowns asynchronously so I can shutdown multiple
devices in parallel, but the pci-driver disables interrupts after my
driver returns from its '.shutdown',
-Original Message-
From: Christoph Hellwig [mailto:h...@infradead.org]
Sent: Thursday, 10 July, 2014 11:15 AM
To: Elliott, Robert (Server Storage)
Cc: Jens Axboe; dgilb...@interlog.com; James Bottomley; Bart Van Assche;
Benjamin LaHaise; linux-scsi@vger.kernel.org;
On Thu, 10 Jul 2014, Bjorn Helgaas wrote:
[+cc LKML, Greg KH for driver core async shutdown question]
On Tue, Jun 24, 2014 at 10:48:57AM -0600, Keith Busch wrote:
To provide context why I want to do this asynchronously, NVM-Express has
one PCI device per controller, of which there could be
Elliott, Robert (Server Storage) elli...@hp.com writes:
-Original Message-
From: Christoph Hellwig [mailto:h...@infradead.org]
Sent: Thursday, 10 July, 2014 11:15 AM
To: Elliott, Robert (Server Storage)
Cc: Jens Axboe; dgilb...@interlog.com; James Bottomley; Bart Van Assche;
Jeff Moyer jmo...@redhat.com writes:
Hi, Rob,
Can you get sysrq-t output for me? I don't know how/why we'd continue
to get io_submits for an exiting process.
Also, do you know what sys_io_submit is returning?
--
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body
On Thu, Jul 10, 2014 at 12:53 PM, Keith Busch keith.bu...@intel.com wrote:
On Thu, 10 Jul 2014, Bjorn Helgaas wrote:
[+cc LKML, Greg KH for driver core async shutdown question]
On Tue, Jun 24, 2014 at 10:48:57AM -0600, Keith Busch wrote:
To provide context why I want to do this
On 2014-07-10 17:11, Jeff Moyer wrote:
Benjamin LaHaise b...@kvack.org writes:
[ 186.339064] ioctx_alloc: nr_events=-2 aio_max_nr=65536
[ 186.339065] ioctx_alloc: nr_events=-2 aio_max_nr=65536
[ 186.339067] ioctx_alloc: nr_events=-2 aio_max_nr=65536
[ 186.339068] ioctx_alloc: nr_events=-2
Jens Axboe ax...@kernel.dk writes:
On 2014-07-10 17:11, Jeff Moyer wrote:
Benjamin LaHaise b...@kvack.org writes:
[ 186.339064] ioctx_alloc: nr_events=-2 aio_max_nr=65536
[ 186.339065] ioctx_alloc: nr_events=-2 aio_max_nr=65536
[ 186.339067] ioctx_alloc: nr_events=-2 aio_max_nr=65536
[
On 2014-07-10 22:05, Jeff Moyer wrote:
Jens Axboe ax...@kernel.dk writes:
On 2014-07-10 17:11, Jeff Moyer wrote:
Benjamin LaHaise b...@kvack.org writes:
[ 186.339064] ioctx_alloc: nr_events=-2 aio_max_nr=65536
[ 186.339065] ioctx_alloc: nr_events=-2 aio_max_nr=65536
[ 186.339067]
-Original Message-
From: James Bottomley [mailto:jbottom...@parallels.com]
Sent: Wednesday, July 9, 2014 3:27 PM
To: KY Srinivasan
Cc: linux-ker...@vger.kernel.org; m...@mkp.net; h...@infradead.org;
de...@linuxdriverproject.org; a...@canonical.com; sta...@vger.kernel.org;
-Original Message-
From: Jeff Moyer [mailto:jmo...@redhat.com]
Sent: Thursday, 10 July, 2014 2:14 PM
To: Elliott, Robert (Server Storage)
Cc: Christoph Hellwig; Jens Axboe; dgilb...@interlog.com; James Bottomley;
Bart Van Assche; Benjamin LaHaise; linux-scsi@vger.kernel.org; linux-
-Original Message-
From: Christoph Hellwig [mailto:h...@infradead.org]
Sent: Thursday, July 10, 2014 3:25 AM
To: KY Srinivasan
Cc: linux-ker...@vger.kernel.org; de...@linuxdriverproject.org;
oher...@suse.com; jbottom...@parallels.com; h...@infradead.org;
jasow...@redhat.com;
On Thu, 2014-07-10 at 21:02 +, KY Srinivasan wrote:
-Original Message-
From: James Bottomley [mailto:jbottom...@parallels.com]
Sent: Wednesday, July 9, 2014 3:27 PM
To: KY Srinivasan
Cc: linux-ker...@vger.kernel.org; m...@mkp.net; h...@infradead.org;
-Original Message-
From: Christoph Hellwig [mailto:h...@infradead.org]
Sent: Thursday, July 10, 2014 3:17 AM
To: KY Srinivasan
Cc: Christoph Hellwig; linux-ker...@vger.kernel.org;
de...@linuxdriverproject.org; oher...@suse.com;
jbottom...@parallels.com; jasow...@redhat.com;
-Original Message-
From: Christoph Hellwig [mailto:h...@infradead.org]
Sent: Thursday, July 10, 2014 3:13 AM
To: KY Srinivasan
Cc: Christoph Hellwig; linux-ker...@vger.kernel.org;
de...@linuxdriverproject.org; oher...@suse.com;
jbottom...@parallels.com; jasow...@redhat.com;
From: Fabio Estevam fabio.este...@freescale.com
The following warning is seen when building for ARM:
drivers/scsi/arm/fas216.c:3003:3: warning: format '%d' expects argument of type
'int', but argument 4 has type 'u64' [-Wformat=]
Use %llu to print 'u64' format.
Reported-by: Olof's autobuilder
59 matches
Mail list logo
