On Mon, Dec 10 2007, Daniel Phillips wrote:
On Monday 10 December 2007 05:30, Jens Axboe wrote:
On Mon, Dec 10 2007, Daniel Phillips wrote:
Let me close with perhaps the most relevant remarks: the attached
code has been in heavy testing and in production for months now.
Thus
up
losely). I'm still not a big fan of the indirect stuff, but that's
minor.
You can get fio by doing a
$ git clone git://git.kernel.dk/fio.git
or just grabbing the latest snapshot from
http://brick.kernel.dk/snaps/fio-git-latest.tar.gz
--
Jens Axboe
--
To unsubscribe from this list: send
done.
--
Jens Axboe
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
On Tue, Dec 11 2007, Daniel Phillips wrote:
On Tuesday 11 December 2007 05:15, Jens Axboe wrote:
On Mon, Dec 10 2007, Daniel Phillips wrote:
Now about that block writeout deadlock... it doesn't just affect my
code, it basically breaks Linux as a storage platform, among other
things
On Wed, Dec 12 2007, Tejun Heo wrote:
Jens Axboe wrote:
On Wed, Dec 05 2007, Tejun Heo wrote:
Use msecs_to_jiffies() and jiffies_to_msecs() in scsi_ioctl().
Sometimes callers use very large values for e.g. vendor specific media
clear command and calculation can overflow.
Thanks Tejun
of rq-cmd_flags is __REQ_FAILFAST
so maybe we are getting FAILFAST in the wrong places?
But that's actually on purpose, though the comment is pretty much crap.
We don't want to be retrying readahead requests, those should always
just be tossable.
--
Jens Axboe
--
To unsubscribe from this list
! Assume -R? [n]
This is 2.6.24-rc5 (pretty close to at least, no changes to ll_rw_blk.c
from that version). Are you using quilt and forgot to refresh, or
something like that?
--
Jens Axboe
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL
. I've applied your patch, thanks.
--
Jens Axboe
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
data
having changed.
Why not just bisect it?
--
Jens Axboe
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
On Thu, Dec 13 2007, Mark Lord wrote:
Jens Axboe wrote:
On Thu, Dec 13 2007, Mark Lord wrote:
Matthew Wilcox wrote:
On Thu, Dec 13, 2007 at 01:48:18PM -0500, Mark Lord wrote:
Problem confirmed. 2.6.23.8 regularly generates segments up to 64KB
for libata,
but 2.6.24 uses only 4KB segments
On Thu, Dec 13 2007, Mark Lord wrote:
Mark Lord wrote:
Jens Axboe wrote:
On Thu, Dec 13 2007, Mark Lord wrote:
Matthew Wilcox wrote:
On Thu, Dec 13, 2007 at 01:48:18PM -0500, Mark Lord wrote:
Problem confirmed. 2.6.23.8 regularly generates segments up to
64KB for libata,
but 2.6.24 uses
On Thu, Dec 13 2007, Mark Lord wrote:
Jens Axboe wrote:
On Thu, Dec 13 2007, Mark Lord wrote:
Mark Lord wrote:
Jens Axboe wrote:
On Thu, Dec 13 2007, Mark Lord wrote:
Matthew Wilcox wrote:
On Thu, Dec 13, 2007 at 01:48:18PM -0500, Mark Lord wrote:
Problem confirmed. 2.6.23.8 regularly
On Thu, Dec 13 2007, Jens Axboe wrote:
On Thu, Dec 13 2007, Mark Lord wrote:
Jens Axboe wrote:
On Thu, Dec 13 2007, Mark Lord wrote:
Mark Lord wrote:
Jens Axboe wrote:
On Thu, Dec 13 2007, Mark Lord wrote:
Matthew Wilcox wrote:
On Thu, Dec 13, 2007 at 01:48:18PM -0500, Mark Lord
On Thu, Dec 13 2007, Mark Lord wrote:
Jens Axboe wrote:
On Thu, Dec 13 2007, Mark Lord wrote:
Jens Axboe wrote:
On Thu, Dec 13 2007, Mark Lord wrote:
Mark Lord wrote:
Jens Axboe wrote:
On Thu, Dec 13 2007, Mark Lord wrote:
Matthew Wilcox wrote:
On Thu, Dec 13, 2007 at 01:48:18PM -0500
On Thu, Dec 13 2007, Mark Lord wrote:
Jens Axboe wrote:
On Thu, Dec 13 2007, Jens Axboe wrote:
On Thu, Dec 13 2007, Mark Lord wrote:
Jens Axboe wrote:
On Thu, Dec 13 2007, Mark Lord wrote:
Mark Lord wrote:
Jens Axboe wrote:
On Thu, Dec 13 2007, Mark Lord wrote:
Matthew Wilcox wrote
On Thu, Dec 13 2007, Mark Lord wrote:
Jens Axboe wrote:
On Thu, Dec 13 2007, Mark Lord wrote:
Jens Axboe wrote:
On Thu, Dec 13 2007, Jens Axboe wrote:
On Thu, Dec 13 2007, Mark Lord wrote:
Jens Axboe wrote:
On Thu, Dec 13 2007, Mark Lord wrote:
Mark Lord wrote:
Jens Axboe wrote:
On Thu
descriptors than they do at present. That shouldn't matter.
I don't think that is a concern in this case :)
--
Jens Axboe
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo
On Thu, Dec 13 2007, Andrew Morton wrote:
On Thu, 13 Dec 2007 21:09:59 +0100
Jens Axboe [EMAIL PROTECTED] wrote:
OK, it's a vm issue,
cc linux-mm and probable culprit.
I have tens of thousand backward pages after a
boot - IOW, bvec-bv_page is the page before bvprv-bv_page
and addressed a panic after a umount reported by Sebastian Siewior. Was
this addressed in some other way?
Yes, the below wasn't a proposal for inclusion, the problem got fixed
differently by commit 51fd77bd9f512ab6cc9df0733ba1caaab89eb957
--
Jens Axboe
--
To unsubscribe from this list: send the line
that end_request() works. The kerneldoc comment for that
function also tells you NOT to use this in new code. Use
end_dequeued_request() and get rid of the requeue, and streamline 'err'
so you can just pass it directly in.
The locking otherwise looks fine to me.
--
Jens Axboe
--
To unsubscribe from
On Thu, Oct 25 2007, FUJITA Tomonori wrote:
On Wed, 24 Oct 2007 21:38:30 +0530
Kamalesh Babulal [EMAIL PROTECTED] wrote:
FUJITA Tomonori wrote:
On Wed, 24 Oct 2007 12:54:36 +0100
Andy Whitcroft [EMAIL PROTECTED] wrote:
On Tue, Oct 23, 2007 at 08:44:20PM +0200, Jens Axboe wrote
dma_map_cont(struct scatterlist *start,
int nelems,
{
if (!need) {
BUG_ON(nelems != 1);
- *sout = *start;
+ sout-dma_address = start-dma_address;
sout-dma_length = start-length;
return 0;
}
--
1.5.2.4
--
Jens Axboe
;
cmd-lun = lun;
--
1.5.2.4
Yep looks good, thanks Tomo!
--
Jens Axboe
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http
, there might be arches on which using dma_addr_t there
actually does the wrong thing - I don't think so, but I know too
little about it.
dma_addr_t would seem OK to me, given the lack of phys_addr_t.
--
Jens Axboe
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body
On Thu, Oct 25 2007, Amit Shah wrote:
On 25/10/2007, Jens Axboe [EMAIL PROTECTED] wrote:
On Thu, Oct 25 2007, Amit Shah wrote:
I get a kernel panic at gart_map_sg+0x201/0x470, which is around here:
...
Tomo already nailed this one, see below.
From: FUJITA Tomonori [EMAIL PROTECTED
--
Jens Axboe
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
On Thu, Oct 25 2007, Rolf Eike Beer wrote:
Jens Axboe wrote:
On Thu, Oct 25 2007, Rolf Eike Beer wrote:
Am Donnerstag, 25. Oktober 2007 schrieb Arjan van de Ven:
Signed-off-by: Hugh Dickins [EMAIL PROTECTED]
---
Whether this is a complete patch, suitable for all architectures
;
+ prv[prv_nents].page_link = (unsigned long) sgl | 0x01;
}
We definitely should clear any other markers, that makes sense.
--
Jens Axboe
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http
On Thu, Oct 25 2007, Rolf Eike Beer wrote:
Jens Axboe wrote:
On Thu, Oct 25 2007, Rolf Eike Beer wrote:
Jens Axboe wrote:
On Thu, Oct 25 2007, Rolf Eike Beer wrote:
Am Donnerstag, 25. Oktober 2007 schrieb Arjan van de Ven:
Signed-off-by: Hugh Dickins [EMAIL PROTECTED
On Fri, Oct 26 2007, Jens Axboe wrote:
On Fri, Oct 26 2007, Sebastian Siewior wrote:
After umount of
/dev/md/1 on /mnt/sec type xfs (rw,nosuid,nodev,noatime,nodiratime)
I end up with [1] on v2.6.24-rc1. It worked fine with v2.6.23. Bisec
came to conclusion
|commit fd5d806266935179deda1502101624832eacd01f
|Author: Jens Axboe [EMAIL PROTECTED]
|Date: Tue Oct 16 11:05:02 2007 +0200
|
|block: convert blkdev_issue_flush() to use empty barriers
|
|Then we can get rid of -issue_flush_fn() and all the driver private
|implementations
On Fri, Oct 26 2007, Sebastian Siewior wrote:
* Jens Axboe | 2007-10-26 11:32:42 [+0200]:
On Fri, Oct 26 2007, Jens Axboe wrote:
I hope this was usefull. Now, I'm going to rebuild my raid now
Thanks a lot, a full report on this issue. Will get this fixed up asap.
No problem
allocated */
}
Thanks, applied!
--
Jens Axboe
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
(void *address, struct scatterlist *list)
+zfcp_address_to_sg(void *address, struct scatterlist *list, unsigned int size)
{
- sg_set_buf(list, address, 0);
+ sg_set_buf(list, address, size);
}
#define REQUEST_LIST_SIZE 128
--
Jens Axboe
-
To unsubscribe from this list: send
to gart_unmap_sg.
Signed-off-by: FUJITA Tomonori [EMAIL PROTECTED]
Thanks Tomo, applied!
--
Jens Axboe
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read
, you could also get away with just doing that
sg_init_table() on qc init/alloc.
--
Jens Axboe
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read
.
--
Jens Axboe
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
think that a lot of
people really do need the sg count when you can just loop over the table
until it returns NULL.
--
Jens Axboe
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org
, added for swift inclusion.
--
Jens Axboe
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
On Sat, Oct 27 2007, Sebastian Siewior wrote:
* Jens Axboe | 2007-10-26 13:42:30 [+0200]:
[2] http://download.breakpoint.cc/bug/bug_rc1_patch_reboot.jpeg 171 KiB
Ah, second BUG() for same issue. Try this one. This?
diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c
index
);
return ireq;
}
Note that I also don't like your solution, no need to change this to be
a constructor setup and you definitely should not guard sg_init_table()
with CONFIG_DEBUG_SG. It needs to be done always.
--
Jens Axboe
-
To unsubscribe from this list: send the line unsubscribe linux
On Mon, Oct 29 2007, Russell King wrote:
On Mon, Oct 29, 2007 at 09:59:36AM +0100, Jens Axboe wrote:
On Sat, Oct 27 2007, Russell King wrote:
On Sat, Oct 27, 2007 at 07:44:04PM +0100, Al Viro wrote:
Signed-off-by: Al Viro [EMAIL PROTECTED]
---
diff --git a/drivers/scsi/arm
);
SCpnt-SCp.this_residual = SCpnt-SCp.buffer-length;
SCpnt-SCp.phase = SCpnt-request_bufflen;
Russell, will you be merging this yourself or do you want me to include
it in the sg fixup branch?
--
Jens Axboe
-
To unsubscribe from this list: send the line
On Mon, Oct 29 2007, Al Viro wrote:
On Mon, Oct 29, 2007 at 10:12:06AM +0100, Jens Axboe wrote:
Russell, will you be merging this yourself or do you want me to include
it in the sg fixup branch?
It's already merged into the ARM git tree as of Friday. Waiting for
ack's from
On Mon, Oct 29 2007, Kamalesh Babulal wrote:
On Fri, Oct 26, 2007 at 01:54:30PM +0200, Jens Axboe wrote:
On Fri, Oct 26 2007, Kamalesh Babulal wrote:
Hi Jens,
sg_set_buf(list, address, 0);
snip
}
That's not quite right, it should be:
diff --git a/drivers/s390/scsi
On Mon, Oct 29 2007, Kamalesh Babulal wrote:
Jens Axboe wrote:
On Mon, Oct 29 2007, Kamalesh Babulal wrote:
On Fri, Oct 26, 2007 at 01:54:30PM +0200, Jens Axboe wrote:
On Fri, Oct 26 2007, Kamalesh Babulal wrote:
Hi Jens,
sg_set_buf(list, address, 0);
snip
}
That's
this on?
--
Jens Axboe
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
I don't consider the 'magic'
values a problem. The use of the bits is supposed to be scatterlist.h
private and the values are documented at the top of that include file.
--
Jens Axboe
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL
On Mon, Oct 29 2007, Cyrill Gorcunov wrote:
Could you please give a link to that explanation? It seems I've missed
it somehow. Thanks.
(don't top post)
It was on linux-kernel, message id:
Message-ID: [EMAIL PROTECTED]
--
Jens Axboe
-
To unsubscribe from this list: send the line unsubscribe
buflen)
+{
+ sg_init_table(sg, 1);
+ sg_set_buf(sg, buf, buflen);
+}
+
+/**
* sg_phys - Return physical address of an sg entry
* @sg: SG entry
*
--
Jens Axboe
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL
On Tue, Oct 30 2007, Herbert Xu wrote:
On Mon, Oct 29, 2007 at 09:16:27PM +0100, Jens Axboe wrote:
On Fri, Oct 26 2007, Herbert Xu wrote:
[CRYPTO] tcrypt: Move sg_init_table out of timing loops
This patch moves the sg_init_table out of the timing loops for hash
algorithms so
*list, unsigned int len)
{
- sg_set_buf(list, address, 0);
+ sg_set_buf(list, address, len);
}
#define REQUEST_LIST_SIZE 128
Patch for that was merged yesterday.
--
Jens Axboe
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message
? This one should be -ENOMEM.
IIRC, Al recently vetoed a similar patch. As far as I'm concerned, with
the correct return values, the patch then looks fine to me.
--
Jens Axboe
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More
On Tue, Oct 30 2007, Boaz Harrosh wrote:
On Mon, Oct 29 2007 at 22:16 +0200, Jens Axboe [EMAIL PROTECTED] wrote:
On Fri, Oct 26 2007, Herbert Xu wrote:
[CRYPTO] tcrypt: Move sg_init_table out of timing loops
This patch moves the sg_init_table out of the timing loops for hash
algorithms
On Mon, Oct 29 2007, Adrian Bunk wrote:
On Mon, Oct 29, 2007 at 02:13:01PM +0100, Jens Axboe wrote:
On Mon, Oct 29 2007, Adrian Bunk wrote:
Not architecture specific code should not #include asm/scatterlist.h.
This patch therefore either replaces them with
#include linux
by the documentation.
1+2 are no brainers, applied.
Patch 3 changes batch start points to resolve a disparity in
latency and bandwidth between high- and low-sector requests.
This one makes a lot of sense, applied as well.
Thanks!
--
Jens Axboe
-
To unsubscribe from this list: send the line
On Tue, Oct 30 2007, Herbert Xu wrote:
On Tue, Oct 30, 2007 at 06:50:58AM +0100, Jens Axboe wrote:
How so? The reason you changed it to sg_init_table() + sg_set_buf() is
exactly because sg_init_one() didn't properly init the entry (as they
name promised).
For one of the cases yes
if you queue_head is empty AND elevator_dispatch_fn returns 0, then
no request is given to the driver. IF elevator_dispatch_fn returns
non-zero, then it MUST have put request on the queue_head list.
--
Jens Axboe
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body
the excess away, which I think is the
sane way to do this.
--
Jens Axboe
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http
On Wed, Oct 31 2007, Jeff Garzik wrote:
Jens Axboe wrote:
On Wed, Oct 31 2007, Alan Cox wrote:
On Tue, 30 Oct 2007 19:21:29 +
Daniel Drake [EMAIL PROTECTED] wrote:
Alan Cox wrote:
I would guess Brasero is issuing a command with the length of data
wrongly set. In the old code that might
On Wed, Oct 31 2007, Jeff Garzik wrote:
Jens Axboe wrote:
Right, that's of course problematic... There has to be a way to recover
that situation though, or you can't export any user command issue
facility.
You cannot hope to handle all possible effects arising from an app
providing
://devzero.co.uk/~alistair/oops-20071031/
I went back to -rc1 and it still happens there too. If you need any more
information or want me to bisect it, please let me know.
I do, I'll post a patch shortly. Just need to test it first.
--
Jens Axboe
-
To unsubscribe from this list: send the line
Hi,
My x60 stopped suspending about two days ago. It just freezes after
printing
Suspending console(s)
where it would normally turn everything off and the 'moon' light would
go on. Posting this message in case somebody else knows what is up, if
not I'll do a bisect on it tomorrow.
--
Jens
On Wed, Oct 31 2007, Jens Axboe wrote:
Hi,
My x60 stopped suspending about two days ago. It just freezes after
printing
Suspending console(s)
where it would normally turn everything off and the 'moon' light would
go on. Posting this message in case somebody else knows what is up
On Thu, Nov 01 2007, Jens Axboe wrote:
On Wed, Oct 31 2007, Jens Axboe wrote:
Hi,
My x60 stopped suspending about two days ago. It just freezes after
printing
Suspending console(s)
where it would normally turn everything off and the 'moon' light would
go on. Posting
On Thu, Nov 01 2007, Jens Axboe wrote:
On Thu, Nov 01 2007, Jens Axboe wrote:
On Wed, Oct 31 2007, Jens Axboe wrote:
Hi,
My x60 stopped suspending about two days ago. It just freezes after
printing
Suspending console(s)
where it would normally turn everything off
;
+ }
ret = q-make_request_fn(q, bio);
} while (ret);
--
Jens Axboe
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http
On Thu, Nov 01 2007, Jeff Garzik wrote:
Jens Axboe wrote:
Reverting just the default AHCI flags makes it work again. IOW, with the
below patch I can suspend properly with current -git.
diff --git a/drivers/ata/ahci.c b/drivers/ata/ahci.c
index ed9b407..77f7631 100644
--- a/drivers/ata/ahci.c
On Thu, Nov 01 2007, Jeff Garzik wrote:
Jens Axboe wrote:
On Thu, Nov 01 2007, Jeff Garzik wrote:
Jens Axboe wrote:
Reverting just the default AHCI flags makes it work again. IOW, with the
below patch I can suspend properly with current -git.
diff --git a/drivers/ata/ahci.c b/drivers/ata
On Wed, Oct 17 2007, Jens Axboe wrote:
On Wed, Oct 17 2007, Jens Axboe wrote:
On Wed, Oct 17 2007, Linus Torvalds wrote:
On Wed, 17 Oct 2007, Ingo Molnar wrote:
Jens, just got this crash on a testbox:
The code in question is:
mov%edx,0xc(%esp
On Wed, Oct 17 2007, Jens Axboe wrote:
On Wed, Oct 17 2007, Jens Axboe wrote:
On Wed, Oct 17 2007, Jens Axboe wrote:
On Wed, Oct 17 2007, Linus Torvalds wrote:
On Wed, 17 Oct 2007, Ingo Molnar wrote:
Jens, just got this crash on a testbox:
The code
On Wed, Oct 17 2007, Ingo Molnar wrote:
* Jens Axboe [EMAIL PROTECTED] wrote:
- sg = next_sg;
- next_sg = sg_next(sg);
+ if (!sg)
+ sg = sglist;
+ else
+ sg
On Wed, Oct 17 2007, Ingo Molnar wrote:
* Jens Axboe [EMAIL PROTECTED] wrote:
OK, it is fine, as long as the sglist is cleared initially. And I
don't think there's anyway around that, clearly I didn't think long
enough before including the memset() removal from Tomo.
Ingo, please
using the chain helpers anyway.
There seems to be some automatic inlining involved here, it must be
dying inside ata_sg_setup().
--
Jens Axboe
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http
On Wed, Oct 17 2007, Linus Torvalds wrote:
On Wed, 17 Oct 2007, Jens Axboe wrote:
OK, it is fine, as long as the sglist is cleared initially. And I don't
think there's anyway around that, clearly I didn't think long enough
before including the memset() removal from Tomo.
Ok, I
On Wed, Oct 17 2007, Linus Torvalds wrote:
On Wed, 17 Oct 2007, Jens Axboe wrote:
OK, the below should actually be safe, I don't know why I talked myself
into the next_sg stuff in the beginning. It's always safe to zero sg,
since it's a valid entry - nothing to save in -page. Ingo
On Wed, Oct 17 2007, Jens Axboe wrote:
On Wed, Oct 17 2007, Ingo Molnar wrote:
ok, here's a different but similar crash that triggers on the testbox:
[ 233.438890] BUG: unable to handle kernel paging request at virtual
address 7d93e000
[ 233.446390] printing eip: 784e9480 *pde
On Wed, Oct 17 2007, Linus Torvalds wrote:
On Wed, 17 Oct 2007, Jens Axboe wrote:
- remove the memset() you had added earlier. It's bogus. It cannot be
the right thing. If the sg list wasn't initialized correctly much
earlier, trying to initialize it late is pointless
On Wed, Oct 17 2007, Linus Torvalds wrote:
On Wed, 17 Oct 2007, Jens Axboe wrote:
So avoiding the sg_next() on the last entry is pointless.
Yeah, I didn't quite understand why if sg was valid, why dereferencing
*(sg + 1)-page would crap out :/
Actually, I take that back
On Wed, Oct 17 2007, Jens Axboe wrote:
On Wed, Oct 17 2007, Ingo Molnar wrote:
ok, here's a different but similar crash that triggers on the testbox:
[ 233.438890] BUG: unable to handle kernel paging request at virtual
address 7d93e000
[ 233.446390] printing eip: 784e9480 *pde
the
whole thing again. I don't think Ingo is hitting that either, though.
--
Jens Axboe
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http
On Wed, Oct 17 2007, Linus Torvalds wrote:
On Wed, 17 Oct 2007, Jens Axboe wrote:
For the chain elements - yes, definitely! But we also want to clear dma
mapping output values, at least sparc64 wants that. You could argue that
the IOMMU code should be fixed up, but I don't think we
in
this function
drivers/scsi/scsi_lib.c:708: note: 'index' was declared here
not sure it matters.
Hmm, I don't see them here (gcc 4.2.1). Must be the BUG(), does it go
away if you add a index = -1 in the default: case? Just to be absolutely
sure...
--
Jens Axboe
-
To unsubscribe from this list: send
On Wed, Oct 17 2007, Ingo Molnar wrote:
* Jens Axboe [EMAIL PROTECTED] wrote:
On Wed, Oct 17 2007, Ingo Molnar wrote:
btw., i get the following build warning:
drivers/scsi/scsi_lib.c: In function 'scsi_free_sgtable':
drivers/scsi/scsi_lib.c:708: warning: 'index' may be used
, and
without your other fix patch as well. I'm using gcc 4.2.2. (Do you get
the warning if you pick up the config i sent you earlier today?)
btw., i changed the initialization to -1 and the crash still occurs
(as expected).
Would think so, thanks for checking though.
--
Jens Axboe
a higher order allocation.
*/
-#define SCSI_MAX_SG_SEGMENTS 128
+#define SCSI_MAX_SG_SEGMENTS 129
struct scsi_host_sg_pool {
size_t size;
--
Jens Axboe
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More
On Wed, Oct 17 2007, Jens Axboe wrote:
On Wed, Oct 17 2007, Linus Torvalds wrote:
On Wed, 17 Oct 2007, Ingo Molnar wrote:
nope, this did not help. First bootup went fine, second bootup crashed
again (see below), without hitting the BUG_ON().
I think you'll always hit
proposed sg chaining, I
shied away from it because I thought it would seem huge and too
invasive. Ah well. I'll get digging on this.
--
Jens Axboe
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http
On Wed, Oct 17 2007, Linus Torvalds wrote:
On Wed, 17 Oct 2007, Jens Axboe wrote:
OK, I think you have a very good point here. Ingo, can you verify it
goes away if apply the below? I have to tend to Other Life stuff but
will take this up again tomorrow morning and fix the sg_next
On Wed, Oct 17 2007, Jens Axboe wrote:
On Wed, Oct 17 2007, Linus Torvalds wrote:
On Wed, 17 Oct 2007, Jens Axboe wrote:
OK, I think you have a very good point here. Ingo, can you verify it
goes away if apply the below? I have to tend to Other Life stuff but
will take this up
On Wed, Oct 17 2007, Linus Torvalds wrote:
On Wed, 17 Oct 2007, Jens Axboe wrote:
So until that is fixed up, how about this? Should cover all block
devices, and I don't think sg_next()/for_each_sg() has spread outside of
that yet.
Heh. Not good. There are drivers that set max phys
not cause any
bugs at least.
--
Jens Axboe
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
the device then chokes on)
Do you know if this poop involves the segment padding that sometimes
goes on in libata?
--
Jens Axboe
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org
On Thu, Oct 18 2007, Ingo Molnar wrote:
* Jens Axboe [EMAIL PROTECTED] wrote:
--- a/drivers/scsi/scsi_lib.c
+++ b/drivers/scsi/scsi_lib.c
@@ -39,7 +39,7 @@
* (unless chaining is used). Should ideally fit inside a single page, to
* avoid a higher order allocation
= len;
- sg.page = frag-page;
+ sg_set_page(sg, frag-page);
sg.offset = frag-page_offset + offset-start;
sg.length = copy;
--
Jens Axboe
-
To unsubscribe from this list: send the line unsubscribe
On Thu, Oct 18 2007, Jeff Garzik wrote:
Ingo Molnar wrote:
* Jens Axboe [EMAIL PROTECTED] wrote:
--- a/drivers/scsi/scsi_lib.c
+++ b/drivers/scsi/scsi_lib.c
@@ -39,7 +39,7 @@
* (unless chaining is used). Should ideally fit inside a single page,
to
* avoid a higher order allocation
On Thu, Oct 18 2007, Jeff Garzik wrote:
Jens Axboe wrote:
index 4df8311..b858183 100644
--- a/drivers/ata/sata_mv.c
+++ b/drivers/ata/sata_mv.c
@@ -1139,6 +1139,7 @@ static void mv_fill_sg(struct ata_queued_cmd *qc)
struct mv_port_priv *pp = qc-ap-private_data;
struct scatterlist
On Thu, Oct 18 2007, Jeff Garzik wrote:
Jens Axboe wrote:
The sata_mv construct looks a bit odd. Does this work? That last
The sata_mv construct worked just fine before sg chaining :)
Yes I know, but I'm trying to works towards getting rid of sg_last() and
ata_sg_is_last() anyway
On Thu, Oct 18 2007, Jeff Garzik wrote:
Jens Axboe wrote:
That should work as well. WRT ata_sg_is_last(), if we go ahead with my
recent sg chaining updates, we can keep the test as it would be a single
conditional and not require any looping.
Let me know when you have tested this!
The patch
On Thu, Oct 18 2007, Ingo Molnar wrote:
* Jens Axboe [EMAIL PROTECTED] wrote:
Of course, this doesn't explain why ata_sg_is_last() was broken, but
since it's working _and_ slightly more efficient, I don't really
care :)
Tomo and I agreed to kill sg_last() a few days ago
601 - 700 of 10937 matches
Mail list logo
