Re: Performance of SCST versus STGT

[Bart Van Assche]

On Jan 17, 2008 6:45 PM, Pete Wyckoff <[EMAIL PROTECTED]> wrote:
> There's nothing particularly stunning here.  Suspect Bart has
> configuration issues if not even IPoIB will do > 100 MB/s.

Regarding configuration issues: the systems I ran the test on probably
communicate via PCI-e x4 with the InfiniBand HCA's. With other systems
with identical software and with PCI-e x8 HCA's on the same InfiniBand
network I reach a throughput of 934 MB/s instead of 675 MB/s (PCI-e
x4). This is something I only found out today, otherwise I would have
run all tests on the systems with PCI-e x8 HCA's.

So the relative utilization of the InfiniBand network is as follows:
* STGT + iSER, PCI-e x4 HCA: 324/675 = 48% (measured myself)
* STGT + iSER, PCI-e x8 HCA: 550/934 = 59%
(http://www.osc.edu/~pw/papers/wyckoff-iser-snapi07-talk.pdf)
* SCST + SRP, PCI-e x4 HCA: 600/675 = 89% (measured myself)

Or: SCST uses the InfiniBand network much more effectively than STGT.

Bart.
-
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

Re: Performance of SCST versus STGT

[Vladislav Bolkhovitin]

Pete Wyckoff wrote:

I have performed a test to compare the performance of SCST and STGT.
Apparently the SCST target implementation performed far better than
the STGT target implementation. This makes me wonder whether this is
due to the design of SCST or whether STGT's performance can be
improved to the level of SCST ?

Test performed: read 2 GB of data in blocks of 1 MB from a target (hot
cache -- no disk reads were performed, all reads were from the cache).
Test command: time dd if=/dev/sde of=/dev/null bs=1M count=2000

STGT read SCST read
 performance (MB/s)   performance (MB/s)
Ethernet (1 Gb/s network)7789
IPoIB (8 Gb/s network)   82   229
SRP (8 Gb/s network)N/A   600
iSER (8 Gb/s network)80   N/A

These results show that SCST uses the InfiniBand network very well
(effectivity of about 88% via SRP), but that the current STGT version
is unable to transfer data faster than 82 MB/s. Does this mean that
there is a severe bottleneck  present in the current STGT
implementation ?



I don't know about the details but Pete said that he can achieve more
than 900MB/s read performance with tgt iSER target using ramdisk.

http://www.mail-archive.com/[EMAIL PROTECTED]/msg4.html


Please don't confuse multithreaded latency insensitive workload with 
single threaded, hence latency sensitive one.


Seems that he can get good performance with single threaded workload:

http://www.osc.edu/~pw/papers/wyckoff-iser-snapi07-talk.pdf

But I don't know about the details so let's wait for Pete to comment
on this.


Page 16 is pretty straight forward.  One command outstanding from
the client.  It is an OSD read command.  Data on tmpfs. 


Hmm, I wouldn't say it's pretty straight forward. It has data for 
"InfiniBand" and it's unclear if it's using iSER or some IB performance 
test tool. I would rather interpret those data as for IB, not iSER.



500 MB/s is
pretty easy to get on IB.

The other graph on page 23 is for block commands.  600 MB/s ish.
Still single command; so essentially a "latency" test.  Dominated by
the memcpy time from tmpfs to pinned IB buffer, as per page 24.

Erez said:



We didn't run any real performance test with tgt, so I don't have
numbers yet. I know that Pete got ~900 MB/sec by hacking sgp_dd, so all
data was read/written to the same block (so it was all done in the
cache). Pete - am I right?


Yes (actually just 1 thread in sg_dd).  This is obviously cheating.
Take the pread time to zero in SCSI Read analysis on page 24 to show
max theoretical.  It's IB theoretical minus some initiator and stgt
overheads.


Yes, that's obviously cheating and its result can't be compared with 
what Bart had. Full data footprint on target fit in the CPU cache, so 
you had rather results for NULLIO (SCST term).


So, seems I understood your slides correctly: the more valuable data for 
our SCST SRP vs STGT iSER comparison should be on page 26 for 1 command 
read (~480MB/s, i.e. ~60% from Bart's result on the equivalent hardware).



The other way to get more read throughput is to throw multiple
simultaneous commands at the server.

There's nothing particularly stunning here.  Suspect Bart has
configuration issues if not even IPoIB will do > 100 MB/s.

-- Pete




-
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

Re: [PATCH] SCSI: fix isa/pcmcia compile problem

[James Bottomley]

On Fri, 2008-01-18 at 16:20 +0900, Tejun Heo wrote:
> aha152x.c and fdomain are built twice - once for the isa driver and
> once for the PCMCIA one.  Through #ifdefs, the compiled codes are
> slightly different; thus, global symbols need to be given different
> names depending on which flavor is being built.  This patch adds
> GLOBAL() macro to aha152x.h and fdomain.h which change the symbol
> depending on PCMCIA.
> 
> This bug has always existed but has been masked by the fact the
> drivers/scsi/pcmcia used subdir-(y|m) instead of obj-(y|m) which made
> drivers/scsi/pcmcia/built_in.o not linked into the kernel and thus
> avoided the duplicate symbols during compilation.
> 
> Signed-off-by: Tejun Heo <[EMAIL PROTECTED]>
> ---
> Ah... missed that one.  Here's the updated version.

Actually, isn't the better fix just to return to the original behaviour?

As you pointed out, using the subdir instead of obj meant that although
the modules were built, the drivers were never linked into the main
kernel.  According to the records, this has been the default forever, so
there can be no-one anywhere relying on these drivers being built in.
Actually, as old style pcmcia drivers, I'm not sure there's much value
building them into the kernel anyway.

So just modify scsi/pcmcia/Kconfig to make them all depend on m.

James


-
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

Re: [PATCH] Marvell 6440 SAS/SATA driver (draft)

[James Bottomley]

On Thu, 2008-01-10 at 02:21 -0500, Jeff Garzik wrote:
> Jeff Garzik wrote:
> > 1) To make it easier for people to review and test the driver, I would 
> > suggest posting a diff against 2.6.24-rc7 (or 2.6.23), ignoring my 
> > original code.  Thus, it would result in a patch
> 
> Er, that sentence was incomplete.  Continuing...
> 
> 
> Thus it would result in a patch that adds a new file 
> drivers/scsi/mvsas.c to the 2.6.24-rc7 kernel, and modifies 
> drivers/scsi/Makefile and drivers/scsi/Kconfig to enable this new driver.
> 
> That is the format that developers and users are most familiar with, 
> when reviewing (and testing) a new driver.
> 
> But of course this is a draft, so these guidelines are certainly loose...

OK, in order to try to expedite this, I've created a mvsas branch in

git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi-misc-2.6.git

I think the first patch (the infrastructure change) is safe to go in
immediately.  Unfortunately, I can't put the marvell update in because
the emailed patch is corrupt (it looks like the mailer has added line
breaks).

Ke, If you can't get your email tool to insert plain text (as a lot of
microsoft based one's can't), you can add the patch as an attachment; I
can apply it from that (Although in line plain text is by far the
preferred method for review if you can do it, we have a bunch of other
driver writers who have problematic email tools, so we're reasonably
used to this).

Thanks,

James


-
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

Megaraid: Use of outb_p

[Alan Cox]

I notice the MegaRAID driver uses outb_p. Can someone at LSI confirm that
the delays between each I/O are required, and if so how long they must be.

I'm trying to sort out the use of in/outb_p and where it is unneccessary
or used for non ISA devices.

(Please cc me on the reply)
Alan

-
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

Re: [PATCH] SCSI: fix isa/pcmcia compile problem

[Tejun Heo]

James Bottomley wrote:
>> I'm just a bit reluctant to touch these drivers, since they're all
>> incredibly ancient.  We don't have good luck with simple transformation
>> patches on the older drivers ... and it seems to take months before
>> anyone notices there's a problem.
> 
> This is the patch that will return them to their original behaviour.
> 
> James
> 
> ---
> diff --git a/drivers/scsi/pcmcia/Kconfig b/drivers/scsi/pcmcia/Kconfig
> index fa481b5..53857c6 100644
> --- a/drivers/scsi/pcmcia/Kconfig
> +++ b/drivers/scsi/pcmcia/Kconfig
> @@ -6,7 +6,8 @@ menuconfig SCSI_LOWLEVEL_PCMCIA
>   bool "PCMCIA SCSI adapter support"
>   depends on SCSI!=n && PCMCIA!=n
>  
> -if SCSI_LOWLEVEL_PCMCIA && SCSI && PCMCIA
> +# drivers have problems when build in, so require modules
> +if SCSI_LOWLEVEL_PCMCIA && SCSI && PCMCIA && m
>  
>  config PCMCIA_AHA152X
>   tristate "Adaptec AHA152X PCMCIA support"
> 
> 

Looks good to me.

-- 
tejun
-
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

Re: [PATCH] SCSI: fix isa/pcmcia compile problem

[James Bottomley]

On Fri, 2008-01-18 at 17:32 -0600, James Bottomley wrote:
> On Sat, 2008-01-19 at 08:27 +0900, Tejun Heo wrote:
> > James Bottomley wrote:
> > > On Fri, 2008-01-18 at 16:20 +0900, Tejun Heo wrote:
> > >> aha152x.c and fdomain are built twice - once for the isa driver and
> > >> once for the PCMCIA one.  Through #ifdefs, the compiled codes are
> > >> slightly different; thus, global symbols need to be given different
> > >> names depending on which flavor is being built.  This patch adds
> > >> GLOBAL() macro to aha152x.h and fdomain.h which change the symbol
> > >> depending on PCMCIA.
> > >>
> > >> This bug has always existed but has been masked by the fact the
> > >> drivers/scsi/pcmcia used subdir-(y|m) instead of obj-(y|m) which made
> > >> drivers/scsi/pcmcia/built_in.o not linked into the kernel and thus
> > >> avoided the duplicate symbols during compilation.
> > >>
> > >> Signed-off-by: Tejun Heo <[EMAIL PROTECTED]>
> > >> ---
> > >> Ah... missed that one.  Here's the updated version.
> > > 
> > > Actually, isn't the better fix just to return to the original behaviour?
> > > 
> > > As you pointed out, using the subdir instead of obj meant that although
> > > the modules were built, the drivers were never linked into the main
> > > kernel.  According to the records, this has been the default forever, so
> > > there can be no-one anywhere relying on these drivers being built in.
> > > Actually, as old style pcmcia drivers, I'm not sure there's much value
> > > building them into the kernel anyway.
> > > 
> > > So just modify scsi/pcmcia/Kconfig to make them all depend on m.
> > 
> > Yeap, there is no problem if you don't allow them to be linked into the
> > kernel.  If that's how you want it, please go ahead.
> > 
> > I personally think it's a bit odd to disallow building into kernel
> > because of the peculiarity of the implementation (including c files and
> > compiling them slightly differently) and also no one reporting doesn't
> > necessarily mean no one has attempted it and failed.
> 
> Heh ... I'll make you a deal.  Find just one user of one of these
> drivers who can make use of them built in, and I'll apply the patch.  
> 
> I'm just a bit reluctant to touch these drivers, since they're all
> incredibly ancient.  We don't have good luck with simple transformation
> patches on the older drivers ... and it seems to take months before
> anyone notices there's a problem.

This is the patch that will return them to their original behaviour.

James

---
diff --git a/drivers/scsi/pcmcia/Kconfig b/drivers/scsi/pcmcia/Kconfig
index fa481b5..53857c6 100644
--- a/drivers/scsi/pcmcia/Kconfig
+++ b/drivers/scsi/pcmcia/Kconfig
@@ -6,7 +6,8 @@ menuconfig SCSI_LOWLEVEL_PCMCIA
bool "PCMCIA SCSI adapter support"
depends on SCSI!=n && PCMCIA!=n
 
-if SCSI_LOWLEVEL_PCMCIA && SCSI && PCMCIA
+# drivers have problems when build in, so require modules
+if SCSI_LOWLEVEL_PCMCIA && SCSI && PCMCIA && m
 
 config PCMCIA_AHA152X
tristate "Adaptec AHA152X PCMCIA support"


-
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

Re: [PATCH] SCSI: fix isa/pcmcia compile problem

[Tejun Heo]

James Bottomley wrote:
>> I personally think it's a bit odd to disallow building into kernel
>> because of the peculiarity of the implementation (including c files and
>> compiling them slightly differently) and also no one reporting doesn't
>> necessarily mean no one has attempted it and failed.
> 
> Heh ... I'll make you a deal.  Find just one user of one of these
> drivers who can make use of them built in, and I'll apply the patch.  

I don't think I can.  I didn't even know they were isa ones before
actually looking at the code.

> I'm just a bit reluctant to touch these drivers, since they're all
> incredibly ancient.  We don't have good luck with simple transformation
> patches on the older drivers ... and it seems to take months before
> anyone notices there's a problem.

Alright then, please go ahead and disallow built-in.

Thanks.

-- 
tejun
-
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

Re: [PATCH] SCSI: fix isa/pcmcia compile problem

[James Bottomley]

On Sat, 2008-01-19 at 08:27 +0900, Tejun Heo wrote:
> James Bottomley wrote:
> > On Fri, 2008-01-18 at 16:20 +0900, Tejun Heo wrote:
> >> aha152x.c and fdomain are built twice - once for the isa driver and
> >> once for the PCMCIA one.  Through #ifdefs, the compiled codes are
> >> slightly different; thus, global symbols need to be given different
> >> names depending on which flavor is being built.  This patch adds
> >> GLOBAL() macro to aha152x.h and fdomain.h which change the symbol
> >> depending on PCMCIA.
> >>
> >> This bug has always existed but has been masked by the fact the
> >> drivers/scsi/pcmcia used subdir-(y|m) instead of obj-(y|m) which made
> >> drivers/scsi/pcmcia/built_in.o not linked into the kernel and thus
> >> avoided the duplicate symbols during compilation.
> >>
> >> Signed-off-by: Tejun Heo <[EMAIL PROTECTED]>
> >> ---
> >> Ah... missed that one.  Here's the updated version.
> > 
> > Actually, isn't the better fix just to return to the original behaviour?
> > 
> > As you pointed out, using the subdir instead of obj meant that although
> > the modules were built, the drivers were never linked into the main
> > kernel.  According to the records, this has been the default forever, so
> > there can be no-one anywhere relying on these drivers being built in.
> > Actually, as old style pcmcia drivers, I'm not sure there's much value
> > building them into the kernel anyway.
> > 
> > So just modify scsi/pcmcia/Kconfig to make them all depend on m.
> 
> Yeap, there is no problem if you don't allow them to be linked into the
> kernel.  If that's how you want it, please go ahead.
> 
> I personally think it's a bit odd to disallow building into kernel
> because of the peculiarity of the implementation (including c files and
> compiling them slightly differently) and also no one reporting doesn't
> necessarily mean no one has attempted it and failed.

Heh ... I'll make you a deal.  Find just one user of one of these
drivers who can make use of them built in, and I'll apply the patch.  

I'm just a bit reluctant to touch these drivers, since they're all
incredibly ancient.  We don't have good luck with simple transformation
patches on the older drivers ... and it seems to take months before
anyone notices there's a problem.

James


-
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

Re: [PATCH] SCSI: fix isa/pcmcia compile problem

[Tejun Heo]

Tejun Heo wrote:
> James Bottomley wrote:
>> On Fri, 2008-01-18 at 16:20 +0900, Tejun Heo wrote:
>>> aha152x.c and fdomain are built twice - once for the isa driver and
>>> once for the PCMCIA one.  Through #ifdefs, the compiled codes are
>>> slightly different; thus, global symbols need to be given different
>>> names depending on which flavor is being built.  This patch adds
>>> GLOBAL() macro to aha152x.h and fdomain.h which change the symbol
>>> depending on PCMCIA.
>>>
>>> This bug has always existed but has been masked by the fact the
>>> drivers/scsi/pcmcia used subdir-(y|m) instead of obj-(y|m) which made
>>> drivers/scsi/pcmcia/built_in.o not linked into the kernel and thus
>>> avoided the duplicate symbols during compilation.
>>>
>>> Signed-off-by: Tejun Heo <[EMAIL PROTECTED]>
>>> ---
>>> Ah... missed that one.  Here's the updated version.
>> Actually, isn't the better fix just to return to the original behaviour?
>>
>> As you pointed out, using the subdir instead of obj meant that although
>> the modules were built, the drivers were never linked into the main
>> kernel.  According to the records, this has been the default forever, so
>> there can be no-one anywhere relying on these drivers being built in.
>> Actually, as old style pcmcia drivers, I'm not sure there's much value
>> building them into the kernel anyway.
>>
>> So just modify scsi/pcmcia/Kconfig to make them all depend on m.
> 
> Yeap, there is no problem if you don't allow them to be linked into the
> kernel.  If that's how you want it, please go ahead.
> 
> I personally think it's a bit odd to disallow building into kernel
> because of the peculiarity of the implementation (including c files and
> compiling them slightly differently) and also no one reporting doesn't
> necessarily mean no one has attempted it and failed.

Actually what's better would be to make all symbols static and include
the c file directly into the stub file.  How about that?

-- 
tejun
-
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

[Bug 9775] HOST_MSG_LOOP invalid SCB ff

[bugme-daemon]

http://bugzilla.kernel.org/show_bug.cgi?id=9775





--- Comment #7 from [EMAIL PROTECTED]  2008-01-18 14:36 ---
Duh! I mean boot with it off, power it up and rescan.


-- 
Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.
-
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

[Bug 9775] HOST_MSG_LOOP invalid SCB ff

[bugme-daemon]

http://bugzilla.kernel.org/show_bug.cgi?id=9775





--- Comment #6 from [EMAIL PROTECTED]  2008-01-18 14:35 ---
Thanks, I've just done some more testing.
There are no tapes in the drives.
Normally, there is the L80 and a DLT8000 on channel B
and a DLT8000 on channel A

Both busses have external terminators.

If Ch B is used alone the system is fine!
If Ch A is used alone it will fail.

If you you are thinking of some hardware problem, its possible to boot with the
L80 off, cause the scsi bus to rescan and have everything work fine.
Regards,
john


-- 
Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.
-
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

[PATCH RESEND] libata: eliminate the home grown dma padding in favour of that provided by the block layer

[James Bottomley]

ATA requires that all DMA transfers begin and end on word boundaries.
Because of this, a large amount of machinery grew up in ide to adjust
scatterlists on this basis.  However, as of 2.5, the block layer has a
dma_alignment variable which ensures both the beginning and length of a
DMA transfer are aligned on the dma_alignment boundary.  Although the
block layer does adjust the beginning of the transfer to ensure this
happens, it doesn't actually adjust the length, it merely makes sure
that space is allocated for transfers beyond the declared length.  The
upshot of this is that scatterlists may be padded to any size between
the actual length and the length adjusted to the dma_alignment safely
knowing that memory is allocated in this region.

Right at the moment, SCSI takes the default dma_aligment which is on a
512 byte boundary.  Note that this aligment only applies to transfers
coming in from user space.  However, since all kernel allocations are
automatically aligned on a minimum of 32 byte boundaries, it is safe to
adjust them in this manner as well.

Signed-off-by: James Bottomley <[EMAIL PROTECTED]>
---
 drivers/ata/ahci.c|5 --
 drivers/ata/libata-core.c |  146 +---
 drivers/ata/libata-scsi.c |   16 +
 drivers/ata/pata_icside.c |8 --
 drivers/ata/sata_fsl.c|   17 +
 drivers/ata/sata_mv.c |5 --
 drivers/ata/sata_sil24.c  |5 --
 drivers/scsi/ipr.c|4 +-
 drivers/scsi/libsas/sas_ata.c |4 +-
 include/linux/libata.h|   28 +
 10 files changed, 28 insertions(+), 210 deletions(-)

diff --git a/drivers/ata/ahci.c b/drivers/ata/ahci.c
index 49761bc..9b363ea 100644
--- a/drivers/ata/ahci.c
+++ b/drivers/ata/ahci.c
@@ -1964,16 +1964,11 @@ static int ahci_port_start(struct ata_port *ap)
struct ahci_port_priv *pp;
void *mem;
dma_addr_t mem_dma;
-   int rc;
 
pp = devm_kzalloc(dev, sizeof(*pp), GFP_KERNEL);
if (!pp)
return -ENOMEM;
 
-   rc = ata_pad_alloc(ap, dev);
-   if (rc)
-   return rc;
-
mem = dmam_alloc_coherent(dev, AHCI_PORT_PRIV_DMA_SZ, &mem_dma,
  GFP_KERNEL);
if (!mem)
diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c
index 06ff781..9802fe3 100644
--- a/drivers/ata/libata-core.c
+++ b/drivers/ata/libata-core.c
@@ -60,6 +60,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 #include 
 #include 
 #include 
@@ -4476,30 +4478,13 @@ void ata_sg_clean(struct ata_queued_cmd *qc)
struct ata_port *ap = qc->ap;
struct scatterlist *sg = qc->sg;
int dir = qc->dma_dir;
-   void *pad_buf = NULL;
 
WARN_ON(sg == NULL);
 
-   VPRINTK("unmapping %u sg elements\n", qc->mapped_n_elem);
+   VPRINTK("unmapping %u sg elements\n", qc->n_elem);
 
-   /* if we padded the buffer out to 32-bit bound, and data
-* xfer direction is from-device, we must copy from the
-* pad buffer back into the supplied buffer
-*/
-   if (qc->pad_len && !(qc->tf.flags & ATA_TFLAG_WRITE))
-   pad_buf = ap->pad + (qc->tag * ATA_DMA_PAD_SZ);
-
-   if (qc->mapped_n_elem)
-   dma_unmap_sg(ap->dev, sg, qc->mapped_n_elem, dir);
-   /* restore last sg */
-   if (qc->last_sg)
-   *qc->last_sg = qc->saved_last_sg;
-   if (pad_buf) {
-   struct scatterlist *psg = &qc->extra_sg[1];
-   void *addr = kmap_atomic(sg_page(psg), KM_IRQ0);
-   memcpy(addr + psg->offset, pad_buf, qc->pad_len);
-   kunmap_atomic(addr, KM_IRQ0);
-   }
+   if (qc->n_elem)
+   dma_unmap_sg(ap->dev, sg, qc->n_elem, dir);
 
qc->flags &= ~ATA_QCFLAG_DMAMAP;
qc->sg = NULL;
@@ -4765,97 +4750,6 @@ void ata_sg_init(struct ata_queued_cmd *qc, struct 
scatterlist *sg,
qc->cursg = qc->sg;
 }
 
-static unsigned int ata_sg_setup_extra(struct ata_queued_cmd *qc,
-  unsigned int *n_elem_extra,
-  unsigned int *nbytes_extra)
-{
-   struct ata_port *ap = qc->ap;
-   unsigned int n_elem = qc->n_elem;
-   struct scatterlist *lsg, *copy_lsg = NULL, *tsg = NULL, *esg = NULL;
-
-   *n_elem_extra = 0;
-   *nbytes_extra = 0;
-
-   /* needs padding? */
-   qc->pad_len = qc->nbytes & 3;
-
-   if (likely(!qc->pad_len))
-   return n_elem;
-
-   /* locate last sg and save it */
-   lsg = sg_last(qc->sg, n_elem);
-   qc->last_sg = lsg;
-   qc->saved_last_sg = *lsg;
-
-   sg_init_table(qc->extra_sg, ARRAY_SIZE(qc->extra_sg));
-
-   if (qc->pad_len) {
-   struct scatterlist *psg = &qc->extra_sg[1];
-   void *pad_buf = ap->pad + (qc->tag * ATA_DMA_PAD_SZ);
-   unsigned int offset;
-
-   WARN_ON(qc->dev->class != ATA_DEV_ATAPI);
-

[Bug 9775] HOST_MSG_LOOP invalid SCB ff

[James Bottomley]

> Latest working kernel version:
> Earliest failing kernel version: 
> Distribution: Gentoo
> Hardware Environment: ML150G3, (2Core cpu, 64Bit)  AHA3944AUWD card, 
> Storagetek
> L80 +2x DLT8000
> Software Environment: gentoo
> Problem Description: kernel panic 
> 
> Steps to reproduce:
> Panic if the L80 is powered up when the kernel boots. 100% on any failing
> kernel.
> Not all kernels fail but most do.
> Git Bisect across linus's tree did not produce a convincing patch.
> Originally filed here: http://bugs.gentoo.org/show_bug.cgi?id=200708
> I have joined the linux-scsi list and will
> 
> The event that brought the problem to light was the installation of a
> secondhand Storagetek L80
> tape library. This has two DLT8000 drives on a HV-Differential bus.
> This needed special card, an adaptec 3944AUWD.
> The kernel I was running at that time was 2.6.22-gentoo-r8.
> It worked fine. Then when -r9 came out and this error manifested, the
> assumption
> was that -r9 was broken.
> 
> I no longer think this to be the case.
> 
> I think they are _ALL_ broken, possibly going way back toward the start of the
> 2.6 series.
> I think that the bug may or may not manifest depending on the internal layout
> of data in the kernel
> --A true heisenbug--
> 
> All that the git bisect did was to change the internal layout, not add/remove 
> a
> bad patch.
> 
> This explains why I could take the 2.6.23.8 kernel and compile for SMP and 
> have
> it fail.
> Compile it for UP and have it work. Initially I thought that meant a locking 
> or
> race issue.
> Now I think its was just another case of altering the internal kernel layout.

Actually, I'd investigate either your tapes or the SCSI bus.

The message is produced deep in the heart of the aic7xxx driver.  It
happens when the driver gets reselected with a tag that doesn't exist.
However, in this case, I think your device is untagged, in which case
this is some handling issue with SCB_LIST_NULL (the value 0xff).

James


-
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

[Kernel Bug Tracker] Your account linux-scsi@vger.kernel.org is being impersonated

[bugme-admin]

Martin J. Bligh <[EMAIL PROTECTED]> has used the 'sudo' feature to access 
Kernel Bug Tracker using your account.

Martin J. Bligh <[EMAIL PROTECTED]> did not provide a reason for doing this.

If you feel that this action was inappropiate, please contact 
[EMAIL PROTECTED]  For more information on this feature, 
visit .
-
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

Re: Megaraid: Use of outb_p

[Alan Cox]

On Fri, 18 Jan 2008 13:32:12 -0700
"Yang, Bo" <[EMAIL PROTECTED]> wrote:

> Alan, 
> 
> The in/outb_p in MegaRAID scsi driver is used for our old io mapped
> megaraid controller.  There are still some customers are using those old
> controller.  Please keep them.

Do they need the I/O delays. If they need a delay they should use outb
and a udelay() of the correct length. If they do not need a delay they
should use outb()

Which is the correct change to make ?

Alan
-
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

RE: Megaraid: Use of outb_p

[Yang, Bo]

Alan, 

The in/outb_p in MegaRAID scsi driver is used for our old io mapped
megaraid controller.  There are still some customers are using those old
controller.  Please keep them.
 
Thanks.
 
Bo Yang  

-Original Message-
From: Alan Cox [mailto:[EMAIL PROTECTED]
Sent: Friday, January 18, 2008 7:36 AM
To: linux-scsi@vger.kernel.org; DL-MegaRAID Linux
Subject: Megaraid: Use of outb_p


I notice the MegaRAID driver uses outb_p. Can someone at LSI confirm
that the delays between each I/O are required, and if so how long they
must be.

I'm trying to sort out the use of in/outb_p and where it is unneccessary
or used for non ISA devices.

(Please cc me on the reply)
Alan

-
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

Re: [PATCH] SCSI: fix isa/pcmcia compile problem

[Tejun Heo]

James Bottomley wrote:
> On Fri, 2008-01-18 at 16:20 +0900, Tejun Heo wrote:
>> aha152x.c and fdomain are built twice - once for the isa driver and
>> once for the PCMCIA one.  Through #ifdefs, the compiled codes are
>> slightly different; thus, global symbols need to be given different
>> names depending on which flavor is being built.  This patch adds
>> GLOBAL() macro to aha152x.h and fdomain.h which change the symbol
>> depending on PCMCIA.
>>
>> This bug has always existed but has been masked by the fact the
>> drivers/scsi/pcmcia used subdir-(y|m) instead of obj-(y|m) which made
>> drivers/scsi/pcmcia/built_in.o not linked into the kernel and thus
>> avoided the duplicate symbols during compilation.
>>
>> Signed-off-by: Tejun Heo <[EMAIL PROTECTED]>
>> ---
>> Ah... missed that one.  Here's the updated version.
> 
> Actually, isn't the better fix just to return to the original behaviour?
> 
> As you pointed out, using the subdir instead of obj meant that although
> the modules were built, the drivers were never linked into the main
> kernel.  According to the records, this has been the default forever, so
> there can be no-one anywhere relying on these drivers being built in.
> Actually, as old style pcmcia drivers, I'm not sure there's much value
> building them into the kernel anyway.
> 
> So just modify scsi/pcmcia/Kconfig to make them all depend on m.

Yeap, there is no problem if you don't allow them to be linked into the
kernel.  If that's how you want it, please go ahead.

I personally think it's a bit odd to disallow building into kernel
because of the peculiarity of the implementation (including c files and
compiling them slightly differently) and also no one reporting doesn't
necessarily mean no one has attempted it and failed.

Thanks.

-- 
tejun
-
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

Re: Megaraid: Use of outb_p

[Matthew Wilcox]

On Fri, Jan 18, 2008 at 01:32:12PM -0700, Yang, Bo wrote:
> Alan, 
> 
> The in/outb_p in MegaRAID scsi driver is used for our old io mapped
> megaraid controller.  There are still some customers are using those old
> controller.  Please keep them.

Hi Bo,

I think you've misunderstood the question.  The '_p' versions of
inb/outb introduce a delay after each access.  The current Linux
implementation of _p provokes bugs on some chipsets, so Alan is looking
for alternatives.  Let's ask the question like this:

Replacing outb_p() with outb(); udelay(x);
How large does 'x' need to be for these megaraid controllers?

> Thanks.
>  
> Bo Yang  
> 
> -Original Message-
> From: Alan Cox [mailto:[EMAIL PROTECTED]
> Sent: Friday, January 18, 2008 7:36 AM
> To: linux-scsi@vger.kernel.org; DL-MegaRAID Linux
> Subject: Megaraid: Use of outb_p
> 
> 
> I notice the MegaRAID driver uses outb_p. Can someone at LSI confirm
> that the delays between each I/O are required, and if so how long they
> must be.
> 
> I'm trying to sort out the use of in/outb_p and where it is unneccessary
> or used for non ISA devices.
> 
> (Please cc me on the reply)
> Alan
> 
> -
> 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

-- 
Intel are signing my paycheques ... these opinions are still mine
"Bill, look, we understand that you're interested in selling us this
operating system, but compare it to ours.  We can't possibly take such
a retrograde step."
-
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

Re: [PATCH] Marvell 6440 SAS/SATA driver (draft)

[James Bottomley]

On Thu, 2008-01-10 at 14:53 +0800, Ke Wei wrote:
> The 88SE6440 driver :
> 
> The driver is based on bare code from Jeff Garzik. And it can work
> under linux kernel 2.6.23.
> By far, Can discover and find SAS HDD, but SATA is currently
> unsupported. Command queue depth can be above 1.
> Most error handling, and some phy handling code is notably missing.
> 
> 
> contains the following updates:
> 
> --- mvsas_orig.c  2007-12-06 19:21:32.0 -0500
> +++ mvsas.c   2008-01-09 04:53:14.0 -0500
[...]
> +#define MVS_BIT(x) (1L << (x))
> +
> +#define PORT_TYPE_SATAMVS_BIT(0)
> +#define PORT_TYPE_SAS MVS_BIT(1)
> +
> +#define READ_PORT_CONFIG_DATA(i) \
> + ((i>3)?mr32(P4_CFG_DATA+(i-4)*8):mr32(P0_CFG_DATA+i*8))
> +#define WRITE_PORT_CONFIG_DATA(i,tmp) \
> + {if(i>3)mw32(P4_CFG_DATA+(i-4)*8,tmp);else mw32(P0_CFG_DATA+i*8,tmp);}
> +#define WRITE_PORT_CONFIG_ADDR(i,tmp) \
> + {if(i>3)mw32(P4_CFG_ADDR+(i-4)*8,tmp);else mw32(P0_CFG_ADDR+i*8,tmp);}
> +
> +#define READ_PORT_PHY_CONTROL(i) \
> +   ((i>3)?mr32(P4_SER_CTLSTAT+(i-4)*4):mr32(P0_SER_CTLSTAT+i*4))
> +#define WRITE_PORT_PHY_CONTROL(i,tmp) \
> +   {if(i>3)mw32(P4_SER_CTLSTAT+(i-4)*4,tmp);else
> mw32(P0_SER_CTLSTAT+i*4,tmp);}

This is an example of where you mailer has broken a line (which causes
the patch not to apply).

> +
> +#define READ_PORT_VSR_DATA(i) \
> +   ((i>3)?mr32(P4_VSR_DATA+(i-4)*8):mr32(P0_VSR_DATA+i*8))
> +#define WRITE_PORT_VSR_DATA(i,tmp) \
> +   {if(i>3)mw32(P4_VSR_DATA+(i-4)*8,tmp);else mw32(P0_VSR_DATA+i*8,tmp);}
> +#define WRITE_PORT_VSR_ADDR(i,tmp) \
> +   {if(i>3)mw32(P4_VSR_ADDR+(i-4)*8,tmp);else mw32(P0_VSR_ADDR+i*8,tmp);}
> +
> +#define READ_PORT_IRQ_STAT(i) \
> +   ((i>3)?mr32(P4_INT_STAT+(i-4)*8):mr32(P0_INT_STAT+i*8))
> +#define WRITE_PORT_IRQ_STAT(i,tmp) \
> +   {if(i>3)mw32(P4_INT_STAT+(i-4)*8,tmp);else mw32(P0_INT_STAT+i*8,tmp);}
> +#define READ_PORT_IRQ_MASK(i) \
> +   ((i>3)?mr32(P4_INT_MASK+(i-4)*8):mr32(P0_INT_MASK+i*8))
> +#define WRITE_PORT_IRQ_MASK(i,tmp) \
> +   {if(i>3)mw32(P4_INT_MASK+(i-4)*8,tmp);else mw32(P0_INT_MASK+i*8,tmp);}
> +
>  /* driver compile-time configuration */
>  enum driver_configuration {
> - MVS_TX_RING_SZ  = 1024, /* TX ring size (12-bit) */
> + MVS_TX_RING_SZ  = 512,  /* TX ring size (12-bit) */
>   MVS_RX_RING_SZ  = 1024, /* RX ring size (12-bit) */
>   /* software requires power-of-2
>  ring size */
> @@ -89,7 +125,7 @@
>   MVS_GBL_CTL = 0x04,  /* global control */
>   MVS_GBL_INT_STAT= 0x08,  /* global irq status */
>   MVS_GBL_PI  = 0x0C,  /* ports implemented bitmask */
> - MVS_GBL_PORT_TYPE   = 0x00,  /* port type */
> + MVS_GBL_PORT_TYPE   = 0xa0,  /* port type */
> 
>   MVS_CTL = 0x100, /* SAS/SATA port configuration */
>   MVS_PCS = 0x104, /* SAS/SATA port control/status */
> @@ -102,11 +138,12 @@
>   MVS_TX_LO   = 0x124, /* TX (delivery) ring addr */
>   MVS_TX_HI   = 0x128,
> 
> - MVS_RX_PROD_IDX = 0x12C, /* RX producer pointer */
> - MVS_RX_CONS_IDX = 0x130, /* RX consumer pointer (RO) */
> + MVS_TX_PROD_IDX = 0x12C, /* TX producer pointer */
> + MVS_TX_CONS_IDX = 0x130, /* TX consumer pointer (RO) */
>   MVS_RX_CFG  = 0x134, /* RX configuration */
>   MVS_RX_LO   = 0x138, /* RX (completion) ring addr */
>   MVS_RX_HI   = 0x13C,
> + MVS_RX_CONS_IDX = 0x140, /* RX consumer pointer (RO) */ 
> 
>   MVS_INT_COAL= 0x148, /* Int coalescing config */
>   MVS_INT_COAL_TMOUT  = 0x14C, /* Int coalescing timeout */
> @@ -117,9 +154,12 @@
>/* ports 1-3 follow after this */
>   MVS_P0_INT_STAT = 0x160, /* port0 interrupt status */
>   MVS_P0_INT_MASK = 0x164, /* port0 interrupt mask */
> + MVS_P4_INT_STAT = 0x200, /* Port 4 interrupt status */
> + MVS_P4_INT_MASK = 0x204, /* Port 4 interrupt enable/disable 
> mask */
> 
>/* ports 1-3 follow after this */
>   MVS_P0_SER_CTLSTAT  = 0x180, /* port0 serial control/status */
> + MVS_P4_SER_CTLSTAT  = 0x220, /* port4 serial control/status */
> 
>   MVS_CMD_ADDR= 0x1B8, /* Command register port (addr) */
>   MVS_CMD_DATA= 0x1BC, /* Command register port (data) */
> @@ -127,6 +167,14 @@
>/* ports 1-3 follow after this */
>   MVS_P0_CFG_ADDR = 0x1C0, /* port0 phy register address */
>   MVS_P0_CFG_DATA = 0x1C4, /* port0 phy register data */
> + MVS_P4_CFG_ADDR = 0x230, /* Port 4 config address */
> + MVS_P4_CFG_DATA = 0x234, /* Port 4 conf

[Bug 9775] HOST_MSG_LOOP invalid SCB ff

[bugme-daemon]

http://bugzilla.kernel.org/show_bug.cgi?id=9775





--- Comment #5 from [EMAIL PROTECTED]  2008-01-18 14:27 ---
Reply-To: [EMAIL PROTECTED]


> Latest working kernel version:
> Earliest failing kernel version: 
> Distribution: Gentoo
> Hardware Environment: ML150G3, (2Core cpu, 64Bit)  AHA3944AUWD card, 
> Storagetek
> L80 +2x DLT8000
> Software Environment: gentoo
> Problem Description: kernel panic 
> 
> Steps to reproduce:
> Panic if the L80 is powered up when the kernel boots. 100% on any failing
> kernel.
> Not all kernels fail but most do.
> Git Bisect across linus's tree did not produce a convincing patch.
> Originally filed here: http://bugs.gentoo.org/show_bug.cgi?id=200708
> I have joined the linux-scsi list and will
> 
> The event that brought the problem to light was the installation of a
> secondhand Storagetek L80
> tape library. This has two DLT8000 drives on a HV-Differential bus.
> This needed special card, an adaptec 3944AUWD.
> The kernel I was running at that time was 2.6.22-gentoo-r8.
> It worked fine. Then when -r9 came out and this error manifested, the
> assumption
> was that -r9 was broken.
> 
> I no longer think this to be the case.
> 
> I think they are _ALL_ broken, possibly going way back toward the start of the
> 2.6 series.
> I think that the bug may or may not manifest depending on the internal layout
> of data in the kernel
> --A true heisenbug--
> 
> All that the git bisect did was to change the internal layout, not add/remove 
> a
> bad patch.
> 
> This explains why I could take the 2.6.23.8 kernel and compile for SMP and 
> have
> it fail.
> Compile it for UP and have it work. Initially I thought that meant a locking 
> or
> race issue.
> Now I think its was just another case of altering the internal kernel layout.

Actually, I'd investigate either your tapes or the SCSI bus.

The message is produced deep in the heart of the aic7xxx driver.  It
happens when the driver gets reselected with a tag that doesn't exist.
However, in this case, I think your device is untagged, in which case
this is some handling issue with SCB_LIST_NULL (the value 0xff).

James


-- 
Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.
-
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

Re: [PATCH 1/8] firewire: ieee1394: Move away from SG_ALL

[Stefan Richter]

Stefan Richter wrote:
> My guess is that there won't be conflicts of this with linux1394-2.6.git
> anytime soon, so taking it into any other tree should be fine.

Wrong, there should already be a (trivial) conflict due to a patch from
December.  Another (trivially) conflicting patch was sent to
linux1394-devel a few hours ago.  Both patches will land in Linus' tree
early during the next merge window.  So either refresh the patch when
it's time, or give it to me.  (Whatever, try not to add to akpm's pain.)
-- 
Stefan Richter
-=-==--- ---= =--==
http://arcgraph.de/sr/
-
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