.
--
Jens Axboe
diff -urN --exclude-from /home/axboe/cdrom/exclude
/opt/kernel/linux-2.4.4-pre2/drivers/scsi/sr.c linux/drivers/scsi/sr.c
--- /opt/kernel/linux-2.4.4-pre2/drivers/scsi/sr.c Mon Feb 19 19:25:17 2001
+++ linux/drivers/scsi/sr.c Mon Apr 9 09:18:46 2001
@@ -262,7 +262,7
On Fri, Jul 20 2001, Linus Torvalds wrote:
On Fri, 20 Jul 2001, Jens Axboe wrote:
The paging stuff doesn't use any of this. The paging stuff use the page
cache lock bit, and always has.
Paging still hits a request, I assumed that's what the (really really)
old comment meant
reverse_ordering:1;
/*
+* ordered write support
+*/
+ unsigned ordered_flush:1;
+ unsigned ordered_tag:1;
+
+ /*
* Host has rejected a command because it was busy.
*/
unsigned int host_blocked;
--
Jens Axboe
-
To unsubscribe from this list
On Thu, Jan 27 2005, Jeff Garzik wrote:
Doug Maxey wrote:
On Thu, 27 Jan 2005 13:02:48 +0100, Jens Axboe wrote:
Hi,
For the longest time, only the old PATA drivers supported barrier writes
with journalled file systems. This patch adds support for the same type
of cache flushing barriers
On Thu, Jan 27 2005, Doug Maxey wrote:
On Thu, 27 Jan 2005 13:02:48 +0100, Jens Axboe wrote:
Hi,
For the longest time, only the old PATA drivers supported barrier writes
with journalled file systems. This patch adds support for the same type
of cache flushing barriers that PATA uses
On Fri, Jan 28 2005, Jeff Garzik wrote:
Jens Axboe wrote:
On Thu, Jan 27 2005, Jeff Garzik wrote:
Doug Maxey wrote:
On Thu, 27 Jan 2005 13:02:48 +0100, Jens Axboe wrote:
Hi,
For the longest time, only the old PATA drivers supported barrier writes
with journalled file systems
On Fri, Jan 28 2005, Jens Axboe wrote:
On Fri, Jan 28 2005, Jeff Garzik wrote:
Jens Axboe wrote:
On Thu, Jan 27 2005, Jeff Garzik wrote:
Doug Maxey wrote:
On Thu, 27 Jan 2005 13:02:48 +0100, Jens Axboe wrote:
Hi,
For the longest time, only the old PATA drivers supported
On Mon, Jan 31 2005, Douglas Gilbert wrote:
Jens Axboe wrote:
On Mon, Jan 31 2005, Douglas Gilbert wrote:
Jens Axboe wrote:
On Mon, Jan 31 2005, Fabio Coatti wrote:
Alle 09:00, lunedì 31 gennaio 2005, Jens Axboe ha scritto:
At this point k3b is stuck in D stat, needs reboot.
I
On Mon, Feb 21 2005, Greg Stark wrote:
Jens Axboe [EMAIL PROTECTED] writes:
For the longest time, only the old PATA drivers supported barrier writes
with journalled file systems.
What about for fsync(2)? One of the most frequent sources of data loss on the
postgres mailing list has
On Tue, Feb 22 2005, Greg Stark wrote:
Jens Axboe [EMAIL PROTECTED] writes:
fsync has been working all along, since the initial barrier support for
ide. only ext3 and reiserfs support it.
Really? That's huge news. Since what kernel version(s) is that?
Since 2.6.9.
What about a non
;
+ virt_array += DC395x_MAX_SG_LISTENTRY;
+ }
+
return 0;
}
-
To unsubscribe from this list: send the line unsubscribe bk-commits-head in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Jens Axboe
-
To unsubscribe from
On Wed, Mar 16 2005, James Bottomley wrote:
On Wed, 2005-03-16 at 08:58 +0100, Jens Axboe wrote:
Guys, who reviewed this? It looks completely bogus, using kmap() for tha
entire sg list is just wrong and can deadlock easily. The proper way is
of course to skip the virtual address requirement
to non-highmem pages. That would
remove the need to add any work arounds in the driver.
--
Jens Axboe
-
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wed, Mar 16 2005, Matthew Wilcox wrote:
On Wed, Mar 16, 2005 at 05:04:47PM +0100, Jens Axboe wrote:
The kmap() isn't just inefficient, it's a problem to iterate over the sg
list and kmap all the pages. That is illegal.
But it's not so tricky to get right, if the punting just happens
On Wed, Mar 16 2005, Guennadi Liakhovetski wrote:
Hi
Thanks for reviewing this patch!
On Wed, 16 Mar 2005, Jens Axboe wrote:
On Wed, Mar 16 2005, James Bottomley wrote:
...
I agree the kmap is inefficient. The efficient alternative is to do
dma_map_sg() and use kmap_atomic
On Wed, Mar 16 2005, [EMAIL PROTECTED] wrote:
Jens Axboe wrote:
On Wed, Mar 16 2005, [EMAIL PROTECTED] wrote:
Hayes, Stuart wrote:
This patch will map the sg buffers to kernel virtual memory space in
the functions idescsi_input_buffers() and idescsi_output_buffers().
Without this patch
On Thu, Mar 17 2005, [EMAIL PROTECTED] wrote:
Jens Axboe wrote:
On Wed, Mar 16 2005, [EMAIL PROTECTED] wrote:
Jens Axboe wrote:
On Wed, Mar 16 2005, [EMAIL PROTECTED] wrote:
Hayes, Stuart wrote:
This patch will map the sg buffers to kernel virtual memory space
in the functions
On Thu, Mar 17 2005, Jens Axboe wrote:
On Thu, Mar 17 2005, [EMAIL PROTECTED] wrote:
Jens Axboe wrote:
On Wed, Mar 16 2005, [EMAIL PROTECTED] wrote:
Jens Axboe wrote:
On Wed, Mar 16 2005, [EMAIL PROTECTED] wrote:
Hayes, Stuart wrote:
This patch will map the sg buffers to kernel
On Thu, Mar 17 2005, [EMAIL PROTECTED] wrote:
Jens Axboe wrote:
On Thu, Mar 17 2005, Jens Axboe wrote:
On Thu, Mar 17 2005, [EMAIL PROTECTED] wrote:
Jens Axboe wrote:
On Wed, Mar 16 2005, [EMAIL PROTECTED] wrote:
Jens Axboe wrote:
On Wed, Mar 16 2005, [EMAIL PROTECTED] wrote:
Hayes
is to kill the sdev
reference in the queue when the sdev is freed. On invocation of
scsi_request_fn(), kill io to this device.
Signed-off-by: Jens Axboe [EMAIL PROTECTED]
= drivers/scsi/scsi_lib.c 1.151 vs edited =
--- 1.151/drivers/scsi/scsi_lib.c 2005-02-17 20:17:22 +01:00
+++ edited
On Sun, Mar 20 2005, Guennadi Liakhovetski wrote:
On Sun, 20 Mar 2005, Christoph Hellwig wrote:
On Wed, Mar 16, 2005 at 06:04:17PM +0100, Jens Axboe wrote:
On Wed, Mar 16 2005, Christoph Hellwig wrote:
On Wed, Mar 16, 2005 at 05:53:39PM +0100, Jens Axboe wrote:
The list doesn't
On Mon, Mar 21 2005, [EMAIL PROTECTED] wrote:
On Mon, 21 Mar 2005, Jens Axboe wrote:
On Sun, Mar 20 2005, Guennadi Liakhovetski wrote:
char *kmap_atomic_sg(struct scatterlist *sg, unsigned int offset, int
*mapped);
void kunmap_atomic_sg(struct scatterlist *sg, int mapped
Hi,
scsi_allocate_request() doesn't hold a reference to the device that it
points to, that is not good. This patch fixes that up.
Signed-off-by: Jens Axboe [EMAIL PROTECTED]
= drivers/scsi/scsi.c 1.157 vs edited =
--- 1.157/drivers/scsi/scsi.c 2005-03-03 09:22:17 +01:00
+++ edited
On Fri, Mar 18 2005, Jens Axboe wrote:
Hi,
There is a problem with the way sdev is freed currently. The reason is
really that there is a circular referencing problem: the sdev needs to
hold on to the queue, but the queue (through the request function) also
needs to hold on to the sdev
On Mon, Mar 21 2005, James Bottomley wrote:
On Mon, 2005-03-21 at 15:59 +0100, Jens Axboe wrote:
This is not even enough, since the queue lock is embedded in sdev
structure. Guys, this is a serious issue. Oopsing a kernel is trivial
with a hotplug device like a usb stick.
Do you have
On Mon, Mar 21 2005, James Bottomley wrote:
On Mon, 2005-03-21 at 14:26 +0100, Jens Axboe wrote:
scsi_allocate_request() doesn't hold a reference to the device that it
points to, that is not good. This patch fixes that up.
Actually, I don't think this is correct. The reference is taken
On Tue, Mar 22 2005, Tejun Heo wrote:
Hello, Jens.
Hello, James.
On Mon, Mar 21, 2005 at 05:57:52PM +0100, Jens Axboe wrote:
On Mon, Mar 21 2005, James Bottomley wrote:
On Mon, 2005-03-21 at 14:26 +0100, Jens Axboe wrote:
scsi_allocate_request() doesn't hold a reference
and it is the drivers responsibility to reinvoke the request handler.
--
Jens Axboe
-
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wed, Mar 23 2005, James Bottomley wrote:
On Wed, 2005-03-23 at 08:19 +0100, Jens Axboe wrote:
It is not the oops I am getting. When I get a few minutes today, I'll
reproduce with vanilla and post it here.
Well, I have news too. Unfortunately, the python script I posted is
hanging in D
to be bounced in the scsi layer for isa host adapters. I bet that
is still true.
--
Jens Axboe
-
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tue, Mar 29 2005, Chris Rankin wrote:
(please don't top post)
--- Jens Axboe [EMAIL PROTECTED] wrote:
On Sun, Mar 27 2005, Chris Rankin wrote:
[gcc-3.4.3, Linux-2.6.11-SMP, Dual P4 Xeon with HT enabled]
Hi,
My Linux 2.6.11 box oopsed when I tried to logout. I have switched
On Tue, Mar 29 2005, Chris Rankin wrote:
I have one IDE hard disc, but I was using a USB memory stick at one
point. (Notice the usb-storage and vfat modules in my list.) Could
that be the troublesome SCSI device?
--- Jens Axboe [EMAIL PROTECTED] wrote:
Yes, it probably is. What
On Tue, Mar 29 2005, Jens Axboe wrote:
On Tue, Mar 29 2005, Chris Rankin wrote:
I have one IDE hard disc, but I was using a USB memory stick at one
point. (Notice the usb-storage and vfat modules in my list.) Could
that be the troublesome SCSI device?
--- Jens Axboe [EMAIL
On Wed, Apr 06 2005, James Bottomley wrote:
On Tue, 2005-03-29 at 14:03 +0200, Jens Axboe wrote:
It is quite a serious problem, not just for CFQ. SCSI referencing is
badly broken there.
OK ... I accept that with regard to the queue lock.
It is much deeper than that. The recent hack
On Wed, Apr 06 2005, Tejun Heo wrote:
Jens Axboe wrote:
On Wed, Apr 06 2005, Arjan van de Ven wrote:
@@ -324,6 +334,7 @@
issue_flush_fn *issue_flush_fn;
prepare_flush_fn*prepare_flush_fn;
end_flush_fn*end_flush_fn;
+ release_queue_data_fn
On Wed, Apr 06 2005, James Bottomley wrote:
On Wed, 2005-04-06 at 19:58 +0200, Jens Axboe wrote:
I rather like the queue lock being a pointer, so you can share at
whatever level you want. Lets not grow the request_queue a full lock
just to work around a bug elsewhere.
I'm not proposing
On Wed, Apr 06 2005, James Bottomley wrote:
On Wed, 2005-04-06 at 21:08 +0200, Jens Axboe wrote:
I think the correct model for all of this is that the block driver
shouldn't care (or be tied to) the scsi one. Thus, as long as SCSI can
reject requests from a queue whose device has been
On Thu, Apr 07 2005, James Bottomley wrote:
On Thu, 2005-04-07 at 08:49 +0200, Jens Axboe wrote:
On Wed, Apr 06 2005, James Bottomley wrote:
My proposal is to correct this by moving the data back to the correct
object, and make any object using it hold a reference, so this would
make
On Thu, Apr 07 2005, James Bottomley wrote:
On Thu, 2005-04-07 at 15:32 +0200, Jens Axboe wrote:
I think Christophs point is that why add sdev_lock as a pointer, instead
of just killing it? It's only used in one location, so it's not really
that confusing (and a comment could fix
the io schedulers don't have to do anything specific to handle it.
I have no problem with removing the requeue stuff from
blk_insert_request(). That function is horribly weird as it is, it is
supposed to look generic but is really just a scsi special case.
--
Jens Axboe
-
To unsubscribe from
On Tue, Apr 19 2005, James Bottomley wrote:
On Tue, 2005-04-19 at 14:34 +0200, Jens Axboe wrote:
On Mon, Apr 18 2005, Tejun Heo wrote:
And, James, regarding REQ_SOFTBARRIER, if the REQ_SOFTBARRIER thing can
be removed from SCSI midlayer, do you agree to change REQ_SPECIAL to
mean
On Tue, Apr 19 2005, Jens Axboe wrote:
On Tue, Apr 19 2005, James Bottomley wrote:
On Tue, 2005-04-19 at 14:34 +0200, Jens Axboe wrote:
On Mon, Apr 18 2005, Tejun Heo wrote:
And, James, regarding REQ_SOFTBARRIER, if the REQ_SOFTBARRIER thing can
be removed from SCSI midlayer, do you
-last_merge)
q-last_merge = NULL;
Do it on requeue, please - not on the initial spotting of the request.
--
Jens Axboe
-
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http
On Wed, Apr 20 2005, Tejun Heo wrote:
Nick Piggin wrote:
On Wed, 2005-04-20 at 16:40 +0900, Tejun Heo wrote:
Hello, Jens.
On Wed, Apr 20, 2005 at 08:30:10AM +0200, Jens Axboe wrote:
Do it on requeue, please - not on the initial spotting of the request.
This is the reworked
, please detail exactly what behaviour you want documented :)
--
Jens Axboe
-
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wed, Apr 20 2005, Nick Piggin wrote:
Jens Axboe wrote:
On Wed, Apr 20 2005, Nick Piggin wrote:
I guess this could be one use of 'reordering' after a requeue.
Yeah, or perhaps the io scheduler might determine that a request has
higher prio than a requeued one. I'm not sure what
this request, only to call scsi_run_queue() -
blk_run_queue() - issue same request. If the point really is to reissue
the request immediately, I can think of many ways more efficient than
this :-)
--
Jens Axboe
-
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body
(virt_to_page(virt), KM_BIO_SRC_IRQ);
+}
Please remember to test this with highmem debug. The above is buggy,
kunmap_atomic() takes the mapped pointer, not the page structure.
--
Jens Axboe
-
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to [EMAIL
On Thu, Apr 21 2005, James Bottomley wrote:
On Thu, 2005-04-21 at 08:10 +0200, Jens Axboe wrote:
I wondered about this action recently myself. What is the point in
requeueing this request, only to call scsi_run_queue() -
blk_run_queue() - issue same request. If the point really
* 32,
Reasoning? I agree, just wondering... How big is the allocated area now?
--
Jens Axboe
-
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
);
extern int blk_execute_rq(request_queue_t *, struct gendisk *,
--
Jens Axboe
-
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
they are or should be done in a more
generic way?
Right, that was never the intention of the bio. To have the kind of
'support' for generic commands in struct bio that we have in struct
request, would easily double or tripple its size.
--
Jens Axboe
-
To unsubscribe from this list: send the line
-
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Jens Axboe
-
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message
know if anything else comes up.
Looks good so far.
Thanks for fixing it so quickly, Tejun! I'll be on vacation next week,
can you make sure it gets to Andrew?
--
Jens Axboe
-
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to [EMAIL PROTECTED]
More
for this, as it has nothing to do with running out of memory.
Would probably be best to return the correct error pointer from
blk_get_request(), as you would otherwise have to assume this knowledge
in the callers.
--
Jens Axboe
--
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body
perspective. Can you re-shuffle the REQ_PM
change, just do a separate patch for that. I'll get it queued up for
3.10 then.
--
Jens Axboe
--
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
in SCSI layer, suggested by Jens Axboe.
Thanks Aaron, I've applied 1, and 3-4. I'll leave 2 and 5 for James to
pickup. James, if you want me to carry them, just let me know.
--
Jens Axboe
--
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to majord
allocation
I have added the signers to cc. I can resend the patch if it is
necessary
Can you resend the patch? The above is mangled for me.
--
Jens Axboe
--
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to majord...@vger.kernel.org
More majordomo
fall through with this patch, we bump
bi_phys_segments even if the segments are physicall contig and
mergeable.
What happens when the segment is physically mergeable, but the resulting
merged segment is too large (bigger than q-limits.max_segment_size)?
--
Jens Axboe
--
To unsubscribe from
On Mon, Mar 25 2013, Jan Vesely wrote:
51506edc5741209311913
On Mon 25 Mar 2013 15:24:57 CET, Jens Axboe wrote:
On Mon, Mar 25 2013, Jan Vesely wrote:
v2: changed a comment
The original behavior was to refuse all pages after the maximum number of
segments has been reached. However
waited for a long time
Jens?
Sorry, travel ended up getting in the way. Will ship it out today.
--
Jens Axboe
--
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
) or it needs to
be nicer in when it gives up and goes back to irq driven IO.
--
Jens Axboe
--
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
wants to give up those 5us
of work time just spinning on the completion of important IO. You
obviously can't steal the time of others.
--
Jens Axboe
--
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
.
Which is why I like the polling. If we can get sufficiently close, then
we can shut some of that up.
--
Jens Axboe
--
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
, 2013 at 05:23:32PM -0700, Nicholas A. Bellinger wrote:
Drilling down the work items ahead of a real mainline push is high on
priority list for discussion.
The parties to be included in such a discussion are:
- Jens Axboe (blk-mq author)
- James Bottomley (scsi
() for this.
--
Jens Axboe
--
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
that it gets bounced properly... blk_mq_execute_rq() assumes a
fully complete request, so it wont bounce anything.
--
Jens Axboe
--
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
the non mq code
and has the block layer free the bios.
Thanks Mike, looks good, applied.
--
Jens Axboe
--
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 Fri, Jul 19 2013, Ric Wheeler wrote:
down the work items ahead of a real mainline push is high on
priority list for discussion.
The parties to be included in such a discussion are:
- Jens Axboe (blk-mq author)
- James Bottomley (scsi maintainer)
- Christoph Hellwig (scsi
eliminated from I/O fast path.
Nice!
--
Jens Axboe
--
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
, the bitmap should
definitely go.
--
Jens Axboe
--
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
there is support for reserving X number
of error handling / emergency tags.
--
Jens Axboe
--
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
) {
+ kfree(ap);
+ return NULL;
+ }
This should be blk_mq_init_tags(ATA_MAX_QUEUE - 1, 1, ...) since the
total depth is normal_tags + reserved_tags. Apart from that, I think it
looks alright based on a cursory look.
--
Jens Axboe
--
To unsubscribe from this list: send the line
On 08/09/2013 09:07 AM, Alexander Gordeev wrote:
On Fri, Aug 09, 2013 at 08:24:38AM -0600, Jens Axboe wrote:
On 08/09/2013 02:23 AM, Alexander Gordeev wrote:
+ ap-qc_tags = blk_mq_init_tags(ATA_MAX_QUEUE, 1, NUMA_NO_NODE);
+ if (!ap-qc_tags) {
+ kfree(ap);
+ return
On 08/09/2013 10:46 AM, Alexander Gordeev wrote:
On Fri, Aug 09, 2013 at 09:52:19AM -0600, Jens Axboe wrote:
On 08/09/2013 09:07 AM, Alexander Gordeev wrote:
diff --git a/block/blk-mq-tag.c b/block/blk-mq-tag.c
index dcbc2a4..b131a48 100644
--- a/block/blk-mq-tag.c
+++ b/block/blk-mq-tag.c
=f6be4fb4bcb396fc3b1c134b7863351972de081f
since I ran into the same thing on nvme. Either approach is fine with
me, as they both allow override of the timeout before insertion. But
we've always done the rq-timeout = 0 init, so I think we should just
reinstate that behavior.
--
Jens Axboe
--
To unsubscribe from
, and no ill effects
seen. On top of that, Christophs patches are nicely separated and have
general benefits even for the non-blk-mq cases. Time to shove them into
the queue for the next merge window?
--
Jens Axboe
--
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body
.
--
Jens Axboe
--
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
scheduling a workqueue on I/O completions when no queues
are congested
In addition to the patches in this thread there also is a git available at:
git://git.infradead.org/users/hch/scsi.git scsi-mq.2
You can add my acked/reviewed-by to the series.
--
Jens Axboe
--
To unsubscribe from
On 06/25/2014 10:50 PM, Jens Axboe wrote:
On 2014-06-25 10:51, Christoph Hellwig wrote:
This is the second post of the scsi-mq series.
At this point the code is ready for merging and use by developers and
early
adopters. The core blk-mq code isn't that suitable for slow devices
yet, mostly
to another report and added Jens to the
Cc list. As the block maintainer he need to review and merge it.
Which patch is this?
--
Jens Axboe
--
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
On 2014-07-08 11:56, Christoph Hellwig wrote:
On Tue, Jul 08, 2014 at 11:54:14AM +0200, Jens Axboe wrote:
I've posted the patch in reply to another report and added Jens to the
Cc list. As the block maintainer he need to review and merge it.
Which patch is this?
This one:
---
From
On 2014-07-08 13:25, Hans de Goede wrote:
Hi,
On 07/08/2014 12:35 PM, Jens Axboe wrote:
On 2014-07-08 11:56, Christoph Hellwig wrote:
On Tue, Jul 08, 2014 at 11:54:14AM +0200, Jens Axboe wrote:
I've posted the patch in reply to another report and added Jens to the
Cc list. As the block
(in that order) and see if that changes anything.
--
Jens Axboe
--
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
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 the API would most obviously be used.
--
Jens Axboe
--
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to majord
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
need to look
elsewhere for the culprit.
Rob, let me know what scsi_debug setup you use, and I can try and
reproduce it here as well.
--
Jens Axboe
--
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
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
(and broken) user ring.
--
Jens Axboe
--
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 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
On 2014-07-21 10:15, Hans de Goede wrote:
Hi,
On 07/08/2014 01:25 PM, Hans de Goede wrote:
Hi,
On 07/08/2014 12:35 PM, Jens Axboe wrote:
On 2014-07-08 11:56, Christoph Hellwig wrote:
On Tue, Jul 08, 2014 at 11:54:14AM +0200, Jens Axboe wrote:
I've posted the patch in reply to another
to
'!atomic_read(sdev-device_busy)' fixes the problem.
Cc: Christoph Hellwig h...@lst.de
Cc: Hannes Reinecke h...@suse.de
Cc: Webb Scales web...@hp.com
Cc: Jens Axboe ax...@kernel.dk
Signed-off-by: Guenter Roeck li...@roeck-us.net
---
drivers/scsi/scsi_lib.c | 2 +-
1 file changed, 1 insertion(+), 1
On 2014-08-15 12:22, Guenter Roeck wrote:
ping ... the problem fixed by this patch still affects the upstream kernel
(v3.16-11383-gc9d2642) as well as -next (20140815).
James, could you upstream this one in time for -rc1?
--
Jens Axboe
--
To unsubscribe from this list: send the line
On 09/07/2014 10:29 AM, Christoph Hellwig wrote:
On Thu, Aug 28, 2014 at 02:10:49PM -0600, Jens Axboe wrote:
On 08/28/2014 01:31 PM, Martin K. Petersen wrote:
This is the data integrity patch series originally submitted for 3.16
and 3.17. It has been rebased on top of block/for-3.18/core
into hctx, I will try to figure out one patch to
do that.
I had not thought of that, but seems like a great way to clean this up a
lot. It just never felt like the right thing to do.
--
Jens Axboe
--
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message
to
blk_alloc_flush_queue() and blk_free_flush_queue().
--
Jens Axboe
--
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
, please don't mix up the REQ_END and -queue_rq() changes with the
changed start_request API.
--
Jens Axboe
--
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
On 09/10/2014 12:09 PM, Christoph Hellwig wrote:
On Wed, Sep 10, 2014 at 10:47:49AM -0600, Jens Axboe wrote:
BTW, please don't mix up the REQ_END and -queue_rq() changes with the
changed start_request API.
I have to. It's set by start_request, so we need to pass down the last
argument
On 09/10/2014 12:40 PM, Christoph Hellwig wrote:
On Wed, Sep 10, 2014 at 12:26:57PM -0600, Jens Axboe wrote:
I have to. It's set by start_request, so we need to pass down the last
argument to keep the old behavior. And once we pass the argument we
can just it directly.
It could still
scsi_log_completion-0x4
28cc:83 bd 54 01 00 00 ff cmpl $0x,0x154(%rbp)
This would be more useful if you had DEBUGINFO enabled. At least it
would save use some time :-)
--
Jens Axboe
--
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message
1 - 100 of 692 matches
Mail list logo
