headers
Mike Christie | 1 Jun 2009 04:25
Picon
Favicon

Re: [SCSI] cxgb3i: Include net/dst.h for struct dst_cache

ccing cxgb3i driver maitainer.

Herbert Xu wrote:
> Hi:
> 
> [SCSI] cxgb3i: Include net/dst.h for struct dst_cache
> 
> This driver needs dst_cache->dev so it should include net/dst.h
> to ensure that it builds.  While net/tcp.h probably includes it
> already, we shouldn't rely on that since there is no guarantee
> that this won't change in future.
> 
> Signed-off-by: Herbert Xu <herbert <at> gondor.apana.org.au>
> 
> diff --git a/drivers/scsi/cxgb3i/cxgb3i_iscsi.c b/drivers/scsi/cxgb3i/cxgb3i_iscsi.c
> index 9212400..8b49731 100644
> --- a/drivers/scsi/cxgb3i/cxgb3i_iscsi.c
> +++ b/drivers/scsi/cxgb3i/cxgb3i_iscsi.c
>  <at>  <at>  -13,6 +13,7  <at>  <at> 
>  
>  #include <linux/inet.h>
>  #include <linux/crypto.h>
> +#include <net/dst.h>
>  #include <net/tcp.h>
>  #include <scsi/scsi_cmnd.h>
>  #include <scsi/scsi_device.h>
> 

Looks ok.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Martin K. Petersen | 1 Jun 2009 07:08
Picon
Favicon

Re: [PATCH 02/13] block: Use accessor functions for queue limits

>>>>> "Bart" == Bartlomiej Zolnierkiewicz <bzolnier <at> gmail.com> writes:

>> Convert all external users of queue limits to using wrapper functions
>> instead of poking the request queue variables directly.

Did bisect this?

The patch you mention didn't touch the bounce limits at all.  One of my
other patches moved portions of the queue limits to an embedded struct.
However, it was purely variable renaming.  I have not touched anything
related to memory allocations.

[...]

Bart>  init_emergency_isa_pool+0x22/0x42 [<c0221e26>]
Bart>  blk_queue_bounce_limit+0x2c/0x41 [<c0309813>]

[...]

--

-- 
Martin K. Petersen	Oracle Linux Engineering
--
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply | 0 comments |
headers
Jens Axboe | 1 Jun 2009 07:15
Picon
Favicon

Re: [PATCH 02/13] block: Use accessor functions for queue limits

On Mon, Jun 01 2009, Martin K. Petersen wrote:
> >>>>> "Bart" == Bartlomiej Zolnierkiewicz <bzolnier <at> gmail.com> writes:
> 
> >> Convert all external users of queue limits to using wrapper functions
> >> instead of poking the request queue variables directly.
> 
> Did bisect this?
> 
> The patch you mention didn't touch the bounce limits at all.  One of my
> other patches moved portions of the queue limits to an embedded struct.
> However, it was purely variable renaming.  I have not touched anything
> related to memory allocations.

It replaces

        q->bounce_pfn = t->limits.bounce_pfn;

with

        blk_queue_bounce_limit(q, t->limits.bounce_pfn);

which are definitely not a functionally equivalent change.

--

-- 
Jens Axboe

--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
(Continue reading)

Permalink | Reply | 0 comments |
headers
Martin K. Petersen | 1 Jun 2009 07:28
Picon
Favicon

Re: [PATCH 02/13] block: Use accessor functions for queue limits

>>>>> "Jens" == Jens Axboe <jens.axboe <at> oracle.com> writes:

Jens> It replaces

Jens> q-> bounce_pfn = t->limits.bounce_pfn;

Jens> with

Jens>         blk_queue_bounce_limit(q, t->limits.bounce_pfn);

Jens> which are definitely not a functionally equivalent change.

Ah, now I see it.  Yeah, that's a bug.  I must have thought
blk_queue_bounce_limit() was one of my wrapper functions when I made
that change.  It follows the same naming scheme.

Will fix.

--

-- 
Martin K. Petersen	Oracle Linux Engineering
--
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply | 0 comments |
headers
Rob Mueller | 1 Jun 2009 17:51
Gravatar

mtp fusion "MID not found" and "DMA Error" under high streaming load with 2.6.27 and 2.6.29

We have an IBM x3550 server with 32G of RAM that has an LSI53C1030 card 
connected to two external SATA-to-SCSI units. This server has been running 
fine with modest load for several *years* with the exact same hardware and 
various 2.6.x kernel versions (regularly upgraded) with no problems. 
Generally IO on this machine is lots of small random IOs to many millions of 
files (an email server).

Yesterday we used the server to unpack a multi-gigabyte data file to a 
partition, causing a huge streaming IO run. This repeatedly caused the mtp 
fusion driver/scsi bus to get confused, causing various batches of errors 
such as:

[1853281.761689] mptbase: ioc0: LogInfo(0x11070000): F/W: DMA Error
[1853281.761719] mptbase: ioc0: LogInfo(0x11070000): F/W: DMA Error
[1853281.761748] mptbase: ioc0: LogInfo(0x11070000): F/W: DMA Error

[1861597.029169] mptscsih: ioc0: attempting task abort! 
(sc=ffff88031d71d200)
[1861597.029203] sd 1:0:0:1: [sdc] CDB: cdb[0]=0x28: 28 00 0b 7a 3d 7d 00 00 
08 00
[1861597.029272] mptscsih: ioc0: task abort: SUCCESS (sc=ffff88031d71d200)

[1862303.900733] lost page write due to I/O error on sdh2
[1862303.900774] sd 2:0:0:3: rejecting I/O to offline device
[1862303.900809] sd 2:0:0:3: [sdi] Unhandled error code
[1862303.900834] sd 2:0:0:3: [sdi] Result: hostbyte=0x01 driverbyte=0x00
[1862303.900863] end_request: I/O error, dev sdi, sector 1936592578
[1862303.900891] Buffer I/O error on device sdi4, logical block 22349051
[1862303.900919] lost page write due to I/O error on sdi4
[1862313.681008] mptbase: ioc0: ERROR - Wait IOC_READY state timeout(15)!
(Continue reading)

Permalink | Reply | 0 comments |
headers
Takahiro Yasui | 1 Jun 2009 18:46
Picon
Favicon

[PATCH] scsi_devinfo: update Hitachi entries

Hi,

This is scsi_devinfo flag updates for the Hitachi storages.

Three models, OPEN-/DF400/DF500, can handle REPORT_LUN, and
the BLIST_REPORTLUN2 flag needs to be set. DF600 returns
ANSI 03h (SPC) and no flag is required.

Thanks,
---
Takahiro Yasui
Hitachi Computer Products (America), Inc.

Signed-off-by: Takahiro Yasui <tyasui <at> redhat.com>
---
 drivers/scsi/scsi_devinfo.c |    7 +++----
 1 file changed, 3 insertions(+), 4 deletions(-)

Index: linux-2.6.30-rc7/drivers/scsi/scsi_devinfo.c
===================================================================
--- linux-2.6.30-rc7.orig/drivers/scsi/scsi_devinfo.c
+++ linux-2.6.30-rc7/drivers/scsi/scsi_devinfo.c
 <at>  <at>  -161,11 +161,10  <at>  <at>  static struct {
 	{"Generic", "USB SD Reader", "1.00", BLIST_FORCELUN | BLIST_INQUIRY_36},
 	{"Generic", "USB Storage-SMC", "0180", BLIST_FORCELUN | BLIST_INQUIRY_36},
 	{"Generic", "USB Storage-SMC", "0207", BLIST_FORCELUN | BLIST_INQUIRY_36},
-	{"HITACHI", "DF400", "*", BLIST_SPARSELUN},
-	{"HITACHI", "DF500", "*", BLIST_SPARSELUN},
-	{"HITACHI", "DF600", "*", BLIST_SPARSELUN},
+	{"HITACHI", "DF400", "*", BLIST_REPORTLUN2},
(Continue reading)

Permalink | Reply | 5 comments |
headers
James Bottomley | 1 Jun 2009 18:54

Re: [PATCH] scsi_devinfo: update Hitachi entries

On Mon, 2009-06-01 at 12:46 -0400, Takahiro Yasui wrote:
>  	{"HITACHI", "DISK-SUBSYSTEM", "*", BLIST_ATTACH_PQ3 | BLIST_SPARSELUN | BLIST_LARGELUN},
> -	{"HITACHI", "OPEN-E", "*", BLIST_ATTACH_PQ3 | BLIST_SPARSELUN | BLIST_LARGELUN},
> +	{"HITACHI", "OPEN-", "*", BLIST_REPORTLUN2},

Can we drop the BLIST_ATTACH_PQ3?  It was there for not only to get the
sequential scan to work, but also so LUN0 would be registered with the
OS (I think for some control purpose) which would no longer happen.

James

--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply | 4 comments |
headers
Takahiro Yasui | 1 Jun 2009 19:38
Picon
Favicon

Re: [PATCH] scsi_devinfo: update Hitachi entries

James Bottomley wrote:
> On Mon, 2009-06-01 at 12:46 -0400, Takahiro Yasui wrote:
>>  	{"HITACHI", "DISK-SUBSYSTEM", "*", BLIST_ATTACH_PQ3 | BLIST_SPARSELUN | BLIST_LARGELUN},
>> -	{"HITACHI", "OPEN-E", "*", BLIST_ATTACH_PQ3 | BLIST_SPARSELUN | BLIST_LARGELUN},
>> +	{"HITACHI", "OPEN-", "*", BLIST_REPORTLUN2},
> 
> Can we drop the BLIST_ATTACH_PQ3?  It was there for not only to get the
> sequential scan to work, but also so LUN0 would be registered with the
> OS (I think for some control purpose) which would no longer happen.

BLIST_ATTACH_PQ3 was added to "OPEN-E" in the following commit:
  commit: 13f7e5acc8b329080672c13f05f252ace5b79825

---
Unfortunately, SANs exist that are SCSI-2 and do NOT support REPORT_LUNS, but
report a unknown device with PQ 3 on LUN 0. We still need to scan them, and
most probably we even need BLIST_SPARSELUN (and BLIST_LARGELUN). See the bug
reference for an infamous example.
---

According to the commit, "OPEN-E" does not support REPORT_LUNS, but
"OPEN-E" can handle REPORT_LUNS. In addition, other "OPEN-" models
can do as well.

I would like to know in which case BLIST_ATTACH_PQ3 is required.

Thanks,
---
Takahiro Yasui
Hitachi Computer Products (America), Inc.
(Continue reading)

Permalink | Reply | 3 comments |
headers
Robert Love | 1 Jun 2009 19:49
Picon
Favicon

[PATCH 0/6] Open-FCoE Features for 2.6.31

The following series consists of logging improvements, watchdog and locking
optimizations and the move of the FIP protocol definition to a more appropriate
header file.

These patches apply to scsi-misc-post-merge with net-next-2.6 merged in. Some
fcoe/ code was touched by a net-next change (storage MAC address addition and
usage) and since the logging changes touch so many lines it created this
dependency.

These patches may or may not depend on the other five outstanding Open-FCoE
fixes as discussed on linux-scsi. Those five patches were in the tree that
this code was tested on before this submission.

---

Robert Love (4):
      libfc: Add runtime debugging with debug_logging module parameter
      libfcoe: Add runtime debugging with module param debug_logging
      fcoe: Add runtime debug logging with module parameter debug_logging
      net, libfcoe: Add the FCoE Initialization Protocol ethertype

Vasu Dev (2):
      fcoe: removes fcoe_watchdog
      fcoe: reduces lock cost when adding a new skb to fcoe_pending_queue

 drivers/scsi/fcoe/fcoe.c      |  195 ++++++++++++++++++-----------------------
 drivers/scsi/fcoe/fcoe.h      |   25 +++++
 drivers/scsi/fcoe/libfcoe.c   |   94 +++++++++++---------
 drivers/scsi/libfc/fc_disc.c  |   83 +++++++----------
 drivers/scsi/libfc/fc_exch.c  |   58 +++++-------
(Continue reading)

Permalink | Reply | 5 comments |
headers
Robert Love | 1 Jun 2009 19:49
Picon
Favicon

[PATCH 1/6] fcoe: reduces lock cost when adding a new skb to fcoe_pending_queue

From: Vasu Dev <vasu.dev <at> intel.com>

Currently fcoe_pending_queue.lock held twice for every new skb
adding to this queue when already least one pkt is pending in this
queue and that is not uncommon once skb pkts starts getting queued
here upon fcoe_start_io => dev_queue_xmit failure.

This patch moves most fcoe_pending_queue logic to fcoe_check_wait_queue
function, this new logic grabs fcoe_pending_queue.lock only once to
add a new skb instead twice as used to be.

I think after this patch call flow around fcoe_check_wait_queue
calling in fcoe_xmit is bit simplified with modified
fcoe_check_wait_queue function taking care of adding and
removing pending skb in one function.

Signed-off-by: Vasu Dev <vasu.dev <at> intel.com>
---

 drivers/scsi/fcoe/fcoe.c |   37 +++++++++++++++----------------------
 1 files changed, 15 insertions(+), 22 deletions(-)

diff --git a/drivers/scsi/fcoe/fcoe.c b/drivers/scsi/fcoe/fcoe.c
index b77c466..c946048 100644
--- a/drivers/scsi/fcoe/fcoe.c
+++ b/drivers/scsi/fcoe/fcoe.c
 <at>  <at>  -71,7 +71,7  <at>  <at>  static struct fc_lport *fcoe_hostlist_lookup(const struct net_device *);
 static int fcoe_hostlist_add(const struct fc_lport *);
 static int fcoe_hostlist_remove(const struct fc_lport *);
(Continue reading)

Permalink | Reply | 0 comments |

Gmane