From: Rusty Russell <[EMAIL PROTECTED]>
Date: Thu, 20 Dec 2007 18:53:48 +1100
> Manipulating the magic chains is horrible; it looks simple to the
> places which simply want to iterate through it, but it's awful for
> code which wants to create them.
I'm not saying complexity is inherent in this s
On Thursday 20 December 2007 18:07:41 FUJITA Tomonori wrote:
> On Thu, 20 Dec 2007 16:45:18 +1100
>
> Rusty Russell <[EMAIL PROTECTED]> wrote:
> > OK, some fixes since last time, as I wade through more SCSI drivers.
> > Some drivers use "use_sg" as a flag to know whether the request_buffer is
> >
From: FUJITA Tomonori <[EMAIL PROTECTED]>
Date: Thu, 20 Dec 2007 16:06:31 +0900
> On Thu, 20 Dec 2007 16:49:30 +1100
> Rusty Russell <[EMAIL PROTECTED]> wrote:
>
> > +/**
> > + * dma_map_sg_ring - Map an entire sg ring
> > + * @dev: Device to free noncoherent memory for
> > + * @sg: The sg_ring
>
On Thu, 20 Dec 2007 18:22:54 +1100
Rusty Russell <[EMAIL PROTECTED]> wrote:
> Hi Alan,
>
> Was looking through initio.c to convert it to sg_ring, and noticed this
> code:
>
> initio_build_scb() around 2616:
> sg = &cblk->sglist[0];
> scsi_for_each_sg(cmnd, sgli
On Thu, Dec 20 2007 at 9:22 +0200, Rusty Russell <[EMAIL PROTECTED]> wrote:
> Hi Alan,
>
> Was looking through initio.c to convert it to sg_ring, and noticed this
> code:
>
> initio_build_scb() around 2616:
> sg = &cblk->sglist[0];
> scsi_for_each_sg(cmnd, sglis
Hi Alan,
Was looking through initio.c to convert it to sg_ring, and noticed this
code:
initio_build_scb() around 2616:
sg = &cblk->sglist[0];
scsi_for_each_sg(cmnd, sglist, cblk->sglen, i) {
sg->data = cpu_to_le32((u32)sg_dma_addres
On Thu, 20 Dec 2007 16:45:18 +1100
Rusty Russell <[EMAIL PROTECTED]> wrote:
> OK, some fixes since last time, as I wade through more SCSI drivers. Some
> drivers use "use_sg" as a flag to know whether the request_buffer is a
> scatterlist: I don't need the counter, but I still need the flag, so
On Thu, 20 Dec 2007 16:49:30 +1100
Rusty Russell <[EMAIL PROTECTED]> wrote:
> Obvious counterpart to dma_map_sg. Note that this is arch-independent
> code; sg_rings are backwards compatible with simple sg arrays.
>
> Signed-off-by: Rusty Russell <[EMAIL PROTECTED]>
> ---
> drivers/base/dma-mapp
Douglas Gilbert pointed out that converting scsi_debug would be a good
demonstration of the conversion required for other SCSI devices.
Details of the changes:
1) ->use_sg is replaced by ->sg, which if non-NULL, contains the sg_ring.
2) ->request_buffer can be NULL (it's only relevent if ->sg isn'
(Update: explicit sg member to replace use_sg indicating it's a scatter gather)
Details:
1) The use_sg (and __use_sg) fields are removed: sg_rings contain their own
count, and it's confusing to have two.
2) use_sg used to do double duty: if non-zero, it meant that the request_buffer
actually
Obvious counterpart to blk_rq_map_sg.
Signed-off-by: Rusty Russell <[EMAIL PROTECTED]>
diff --git a/block/ll_rw_blk.c b/block/ll_rw_blk.c
--- a/block/ll_rw_blk.c
+++ b/block/ll_rw_blk.c
@@ -31,6 +31,7 @@
#include
#include
#include
+#include
/*
* for max sense size
@@ -1364,6 +1365,68
Obvious counterpart to dma_map_sg. Note that this is arch-independent
code; sg_rings are backwards compatible with simple sg arrays.
Signed-off-by: Rusty Russell <[EMAIL PROTECTED]>
---
drivers/base/dma-mapping.c | 13 +
include/linux/dma-mapping.h |4
2 files changed, 17
(Updates since last time: const-safe iterators and sg_ring_num helper for
counting scatterlist entries across entire ring).
This patch introduces 'struct sg_ring', a layer on top of scatterlist
arrays. It meshes nicely with routines which expect a simple array of
'struct scatterlist' because it i
OK, some fixes since last time, as I wade through more SCSI drivers. Some
drivers use "use_sg" as a flag to know whether the request_buffer is a
scatterlist: I don't need the counter, but I still need the flag, so I fixed
that in a more intuitive way (an explicit ->sg pointer in the cmd).
Also
smp_utils is a package of command line utilities for invoking
SMP functions to monitor and manage SAS expanders. SMP is the
Serial Attached SCSI (SAS) Management Protocol (SMP). A SAS Host
Bus Adapter (HBA) includes a SMP initiator (along with a SSP and
STP initiator). A SAS expander contains a SMP
On Dec 20, 2007 2:20 PM, FUJITA Tomonori <[EMAIL PROTECTED]> wrote:
>
> On Thu, 20 Dec 2007 14:13:15 +1100
> "Julian Calaby" <[EMAIL PROTECTED]> wrote:
>
> > On Dec 20, 2007 1:44 PM, FUJITA Tomonori <[EMAIL PROTECTED]> wrote:
> > > --- a/drivers/message/fusion/mptsas.c
> > > +++ b/drivers/message/f
On Thu, 20 Dec 2007 14:13:15 +1100
"Julian Calaby" <[EMAIL PROTECTED]> wrote:
> On Dec 20, 2007 1:44 PM, FUJITA Tomonori <[EMAIL PROTECTED]> wrote:
> > --- a/drivers/message/fusion/mptsas.c
> > +++ b/drivers/message/fusion/mptsas.c
> > @@ -1343,6 +1343,8 @@ static int mptsas_smp_handler(struct Scs
On Dec 20, 2007 1:44 PM, FUJITA Tomonori <[EMAIL PROTECTED]> wrote:
> --- a/drivers/message/fusion/mptsas.c
> +++ b/drivers/message/fusion/mptsas.c
> @@ -1343,6 +1343,8 @@ static int mptsas_smp_handler(struct Scsi_Host *shost,
> struct sas_rphy *rphy,
> smprep = (SmpPassthroughRepl
Doug pointed out that SMP passthrough support via bsg doesn't update
din_resid or dout_resid. It's confusing for user-space tools like
smp_utils.
This patch fixes mptsas_smp_handler (for sas fusion) and libsas'
sas_smp_handler to update both din_resid or dout_resid on success.
Signed-off-by: FUJI
On Tue, Dec 18 2007, Nick Piggin wrote:
> On Tue, Dec 18, 2007 at 08:44:40AM +0100, Jens Axboe wrote:
> > On Sat, Dec 15 2007, Nick Piggin wrote:
> > > Hi,
> > >
> > > This is just an idea I had, which might make request processing a little
> > > bit cheaper depending on queue behaviour. For examp
On Tue, Dec 18, 2007 at 11:27:49AM +0530, Saquib Imam wrote:
> In which case EWOULDBLOCK / EAGAIN is set while a write operation ?
From write(2):
ERRORS
EAGAIN Non-blocking I/O has been selected using O_NONBLOCK and the
write would block.
Erik
--
They're all fools. D
On Wed, Dec 19, 2007 at 10:50:40AM -0600, James Bottomley wrote:
> So, to get the best of both worlds, file a bugzilla and note the bugid.
> Then email a complete report to the relevant list, but add [BUG ]
> to the subject line and cc [EMAIL PROTECTED] If you do
> this, bugzilla will keep track o
On Wed, 2007-12-19 at 06:29 -0700, Matthew Wilcox wrote:
> On Wed, Dec 19, 2007 at 10:48:27AM +0200, Filippos Papadopoulos wrote:
> > Would it be better to open a bug report at bugzilla?
>
> No, it wouldn't. Bugzilla is a place where bug reports go to be
> ignored. Witness 9370 where despite my
This patch series is a sequence of late arriving bug fixes, mainly in
drivers but also one debugging scatterlist BUG_ON() in the tape ULD.
The initio bug fixes are definitely required, we just don't have
confirmation that they're the whole fix yet, so an additional fix for
initio may be necessary.
On Wed, Dec 19, 2007 at 10:48:27AM +0200, Filippos Papadopoulos wrote:
> Would it be better to open a bug report at bugzilla?
No, it wouldn't. Bugzilla is a place where bug reports go to be
ignored. Witness 9370 where despite my best efforts to move discussion
to the mailing list, it's been thor
On Wed, Dec 19 2007 at 10:48 +0200, "Filippos Papadopoulos" <[EMAIL PROTECTED]>
wrote:
> On Dec 17, 2007 2:18 PM, Boaz Harrosh <[EMAIL PROTECTED]> wrote:
>> I have found one problem. Please try patch [2] below and report.
>> If it still fails try to enable debugging by setting with patch [1]
>> th
On Dec 17, 2007 2:18 PM, Boaz Harrosh <[EMAIL PROTECTED]> wrote:
> I have found one problem. Please try patch [2] below and report.
> If it still fails try to enable debugging by setting with patch [1]
> these values at top of drivers/scsi/initio.c. And send dmsgs.
>
> Boaz
>
I tried patch[2] (ad
27 matches
Mail list logo
