Re: [PATCH] use the cmd_type of a leading request for scsi_init_sgtable
[EMAIL PROTECTED] wrote on Fri, 25 Jan 2008 20:05 -0600: > On Sat, 2008-01-26 at 09:57 +0900, FUJITA Tomonori wrote: > > This is against the scsi-bidi tree. > > > > We need to use the cmd_type of a leading request for scsi_init_sgtable > > to set up scsi_data_buffer:length of a bidi request properly. > > > > An alternative approach is setting the cmd_type of a leading request > > and its bidi request (*1). But the block layer and scsi-ml don't > > expect that the leading request and its sub-requests have the > > different command types. > > > > Note that scsi_debug's XDWRITEREAD_10 support is fine without this > > patch since req->nr_sectors works for it but req->nr_sectors doesn't > > work for everyone. > > > > (*1) > > > > http://www.mail-archive.com/linux-scsi@vger.kernel.org/msg12669.html > > > > = > > From: FUJITA Tomonori <[EMAIL PROTECTED]> > > Subject: [PATCH] use the cmd_type of a leading request for scsi_init_sgtable > > > > We need to use the cmd_type of a leading request for scsi_init_sgtable > > to set up scsi_data_buffer:length of its bidi request properly. > > This seems to be a very convoluted work around for the fact that we > forgot to set the cmd_type on the subordinate request. > > Wouldn't this be a better fix? > > James > > --- > > diff --git a/block/bsg.c b/block/bsg.c > index 69b0a9d..8917c51 100644 > --- a/block/bsg.c > +++ b/block/bsg.c > @@ -279,6 +279,7 @@ bsg_map_hdr(struct bsg_device *bd, struct sg_io_v4 *hdr) > goto out; > } > rq->next_rq = next_rq; > + next_rq->cmd_type = rq->cmd_type; > > dxferp = (void*)(unsigned long)hdr->din_xferp; > ret = blk_rq_map_user(q, next_rq, dxferp, hdr->din_xfer_len); > > Agree. I did essentially the same thing in: http://marc.info/?l=linux-scsi&m=11983623270 Tomo, you may want to have a look at all the bsg patches I sent back in Dec 2007. Boaz has the minimum required for bidi in his tree. There are a few more here too, if you want to see what we need for OSD: http://git.osc.edu/?p=linux.git;a=summary -- 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] use the cmd_type of a leading request for scsi_init_sgtable
On Sat, 26 Jan 2008 11:22:47 +0900 FUJITA Tomonori <[EMAIL PROTECTED]> wrote: > On Fri, 25 Jan 2008 20:05:55 -0600 > James Bottomley <[EMAIL PROTECTED]> wrote: > > > On Sat, 2008-01-26 at 09:57 +0900, FUJITA Tomonori wrote: > > > This is against the scsi-bidi tree. > > > > > > We need to use the cmd_type of a leading request for scsi_init_sgtable > > > to set up scsi_data_buffer:length of a bidi request properly. > > > > > > An alternative approach is setting the cmd_type of a leading request > > > and its bidi request (*1). But the block layer and scsi-ml don't > > > expect that the leading request and its sub-requests have the > > > different command types. > > > > > > Note that scsi_debug's XDWRITEREAD_10 support is fine without this > > > patch since req->nr_sectors works for it but req->nr_sectors doesn't > > > work for everyone. > > > > > > (*1) > > > > > > http://www.mail-archive.com/linux-scsi@vger.kernel.org/msg12669.html > > > > > > = > > > From: FUJITA Tomonori <[EMAIL PROTECTED]> > > > Subject: [PATCH] use the cmd_type of a leading request for > > > scsi_init_sgtable > > > > > > We need to use the cmd_type of a leading request for scsi_init_sgtable > > > to set up scsi_data_buffer:length of its bidi request properly. > > > > This seems to be a very convoluted work around for the fact that we > > forgot to set the cmd_type on the subordinate request. > > > > Wouldn't this be a better fix? > > I'm fine with this. I have no big preference in this issue. > > Acked-by: FUJITA Tomonori <[EMAIL PROTECTED]> > > > I just thought that the approach (the block layer and scsi-ml look at > only the type of a leading request) show better how the block layer > and scsi-ml see a leading request and its subordinate requests (all > the requests need to have the same command type). I meant that the block layer and scsi-ml use its subordinate requests just to hook data buffer. Anyway, I'm fine with your patch. - 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] use the cmd_type of a leading request for scsi_init_sgtable
On Fri, 25 Jan 2008 20:05:55 -0600 James Bottomley <[EMAIL PROTECTED]> wrote: > On Sat, 2008-01-26 at 09:57 +0900, FUJITA Tomonori wrote: > > This is against the scsi-bidi tree. > > > > We need to use the cmd_type of a leading request for scsi_init_sgtable > > to set up scsi_data_buffer:length of a bidi request properly. > > > > An alternative approach is setting the cmd_type of a leading request > > and its bidi request (*1). But the block layer and scsi-ml don't > > expect that the leading request and its sub-requests have the > > different command types. > > > > Note that scsi_debug's XDWRITEREAD_10 support is fine without this > > patch since req->nr_sectors works for it but req->nr_sectors doesn't > > work for everyone. > > > > (*1) > > > > http://www.mail-archive.com/linux-scsi@vger.kernel.org/msg12669.html > > > > = > > From: FUJITA Tomonori <[EMAIL PROTECTED]> > > Subject: [PATCH] use the cmd_type of a leading request for scsi_init_sgtable > > > > We need to use the cmd_type of a leading request for scsi_init_sgtable > > to set up scsi_data_buffer:length of its bidi request properly. > > This seems to be a very convoluted work around for the fact that we > forgot to set the cmd_type on the subordinate request. > > Wouldn't this be a better fix? I'm fine with this. I have no big preference in this issue. Acked-by: FUJITA Tomonori <[EMAIL PROTECTED]> I just thought that the approach (the block layer and scsi-ml look at only the type of a leading request) show better how the block layer and scsi-ml see a leading request and its subordinate requests (all the requests need to have the same command type). > James > > --- > > diff --git a/block/bsg.c b/block/bsg.c > index 69b0a9d..8917c51 100644 > --- a/block/bsg.c > +++ b/block/bsg.c > @@ -279,6 +279,7 @@ bsg_map_hdr(struct bsg_device *bd, struct sg_io_v4 *hdr) > goto out; > } > rq->next_rq = next_rq; > + next_rq->cmd_type = rq->cmd_type; > > dxferp = (void*)(unsigned long)hdr->din_xferp; > ret = blk_rq_map_user(q, next_rq, dxferp, hdr->din_xfer_len); > > > - > 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 - 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] use the cmd_type of a leading request for scsi_init_sgtable
On Sat, 2008-01-26 at 09:57 +0900, FUJITA Tomonori wrote: > This is against the scsi-bidi tree. > > We need to use the cmd_type of a leading request for scsi_init_sgtable > to set up scsi_data_buffer:length of a bidi request properly. > > An alternative approach is setting the cmd_type of a leading request > and its bidi request (*1). But the block layer and scsi-ml don't > expect that the leading request and its sub-requests have the > different command types. > > Note that scsi_debug's XDWRITEREAD_10 support is fine without this > patch since req->nr_sectors works for it but req->nr_sectors doesn't > work for everyone. > > (*1) > > http://www.mail-archive.com/linux-scsi@vger.kernel.org/msg12669.html > > = > From: FUJITA Tomonori <[EMAIL PROTECTED]> > Subject: [PATCH] use the cmd_type of a leading request for scsi_init_sgtable > > We need to use the cmd_type of a leading request for scsi_init_sgtable > to set up scsi_data_buffer:length of its bidi request properly. This seems to be a very convoluted work around for the fact that we forgot to set the cmd_type on the subordinate request. Wouldn't this be a better fix? James --- diff --git a/block/bsg.c b/block/bsg.c index 69b0a9d..8917c51 100644 --- a/block/bsg.c +++ b/block/bsg.c @@ -279,6 +279,7 @@ bsg_map_hdr(struct bsg_device *bd, struct sg_io_v4 *hdr) goto out; } rq->next_rq = next_rq; + next_rq->cmd_type = rq->cmd_type; dxferp = (void*)(unsigned long)hdr->din_xferp; ret = blk_rq_map_user(q, next_rq, dxferp, hdr->din_xfer_len); - 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] use the cmd_type of a leading request for scsi_init_sgtable
This is against the scsi-bidi tree.
We need to use the cmd_type of a leading request for scsi_init_sgtable
to set up scsi_data_buffer:length of a bidi request properly.
An alternative approach is setting the cmd_type of a leading request
and its bidi request (*1). But the block layer and scsi-ml don't
expect that the leading request and its sub-requests have the
different command types.
Note that scsi_debug's XDWRITEREAD_10 support is fine without this
patch since req->nr_sectors works for it but req->nr_sectors doesn't
work for everyone.
(*1)
http://www.mail-archive.com/linux-scsi@vger.kernel.org/msg12669.html
=
From: FUJITA Tomonori <[EMAIL PROTECTED]>
Subject: [PATCH] use the cmd_type of a leading request for scsi_init_sgtable
We need to use the cmd_type of a leading request for scsi_init_sgtable
to set up scsi_data_buffer:length of its bidi request properly.
Signed-off-by: FUJITA Tomonori <[EMAIL PROTECTED]>
---
drivers/scsi/scsi_lib.c | 23 ++-
1 files changed, 14 insertions(+), 9 deletions(-)
diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c
index e1c7eeb..61093ea 100644
--- a/drivers/scsi/scsi_lib.c
+++ b/drivers/scsi/scsi_lib.c
@@ -1001,8 +1001,9 @@ void scsi_io_completion(struct scsi_cmnd *cmd, unsigned
int good_bytes)
scsi_end_request(cmd, -EIO, this_count, !result);
}
-static int scsi_init_sgtable(struct request *req, struct scsi_data_buffer *sdb,
-gfp_t gfp_mask)
+static int scsi_init_sgtable(struct request *req,
+enum rq_cmd_type_bits cmd_type,
+struct scsi_data_buffer *sdb, gfp_t gfp_mask)
{
int count;
@@ -1015,12 +1016,12 @@ static int scsi_init_sgtable(struct request *req,
struct scsi_data_buffer *sdb,
}
req->buffer = NULL;
- if (blk_pc_request(req))
+ if (cmd_type == REQ_TYPE_BLOCK_PC)
sdb->length = req->data_len;
else
sdb->length = req->nr_sectors << 9;
- /*
+ /*
* Next, walk the list, and fill in the addresses and sizes of
* each segment.
*/
@@ -1043,21 +1044,25 @@ static int scsi_init_sgtable(struct request *req,
struct scsi_data_buffer *sdb,
*/
int scsi_init_io(struct scsi_cmnd *cmd, gfp_t gfp_mask)
{
- int error = scsi_init_sgtable(cmd->request, &cmd->sdb, gfp_mask);
+ int error;
+ enum rq_cmd_type_bits cmd_type = cmd->request->cmd_type;
+
+ error = scsi_init_sgtable(cmd->request, cmd_type, &cmd->sdb, gfp_mask);
if (error)
goto err_exit;
if (blk_bidi_rq(cmd->request)) {
- struct scsi_data_buffer *bidi_sdb = kmem_cache_zalloc(
- scsi_bidi_sdb_cache, GFP_ATOMIC);
+ struct scsi_data_buffer *bidi_sdb;
+
+ bidi_sdb = kmem_cache_zalloc(scsi_bidi_sdb_cache, GFP_ATOMIC);
if (!bidi_sdb) {
error = BLKPREP_DEFER;
goto err_exit;
}
cmd->request->next_rq->special = bidi_sdb;
- error = scsi_init_sgtable(cmd->request->next_rq, bidi_sdb,
- GFP_ATOMIC);
+ error = scsi_init_sgtable(cmd->request->next_rq, cmd_type,
+ bidi_sdb, GFP_ATOMIC);
if (error)
goto err_exit;
}
--
1.5.3.4
-
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
[GIT PATCH] SCSI updates for 2.6.24 (part 1)
We have a difficult merge this time; the SCSI tree is split between components that can go now and pieces that are waiting on other trees. Part 1 is the components that can go now ... you'll be getting part 2 towards the end of the merge window. There's misc driver updates, the accessor conversions (peparation for large scatterlists) and tons of other misc updates. There are also some sysfs changes (with Greg's ack) because of the way the dependencies thread through SCSI. The patch is available here: master.kernel.org:/pub/scm/linux/kernel/git/jejb/scsi-misc-2.6.git The short changelog is: Adrian Bunk (4): qla2xxx: Code cleanups. megaraid: add __devexit annotation lpfc: minor cleanups 53c7xx: fix removal fallout Alan Cox (1): aacraid: fix security weakness Andi Kleen (1): sg: Only print SCSI data direction warning once for a command Andrew Morton (1): sgiwd93: export sgiwd93_reset() Andrew Vasquez (13): qla2xxx: Update version number to 8.02.00-k7. qla2xxx: Correct late-memset() of EFT buffer. qla2xxx: Add Fibre Channel Event (FCE) tracing support. qla2xxx: Trace-Control naming cleanups. qla2xxx: Don't schedule the DPC routine to perform an issue-lip request. qla2xxx: Restrict MSI/MSI-X enablement on select ISP2432-type HBAs. qla2xxx: Wait for FLASH write-protection to complete after a write. qla2xxx: Fix for 32-bit platforms with 64-bit resources. qla2xxx: Retrieve additional HBA port statistics from recent ISPs. qla2xxx: Consolidate duplicate sense-data handling codes. qla2xxx: Update version number to 8.02.00-k6. qla2xxx: Correct NPIV support for recent ISPs. qla2xxx: Don't explicitly read mbx registers while processing a system-err Boaz Harrosh (26): libiscsi,iser: patch for AHS support iscsi_tcp, libiscsi: initial AHS Support iscsi: Prettify resid handling and some extra checks imm: convert to accessors and !use_sg cleanup ppa: convert to accessors and !use_sg cleanup NCR5380 family: convert to accessors & !use_sg cleanup wd7000: proper fix for boards without sg support atp870u: convert to accessors and !use_sg cleanup scsi_debug: convert to use the data buffer accessors isd200: use one-element sg list in issuing commands usb: transport - convert to accessors and !use_sg code path removal usb: shuttle_usbat - convert to accessors and !use_sg code path removal usb: freecom & sddr09 - convert to accessors and !use_sg cleanup usb: protocol - convert to accessors and !use_sg code path removal seagate: Remove driver psi240i: remove driver in2000: convert to accessors and !use_sg cleanup qlogicpti: convert to accessors and !use_sg cleanup wd33c93: convert to accessors and !use_sg cleanup fd_mcs: convert to accessors and !use_sg cleanup aha1542: convert to accessors and !use_sg cleanup a3000: convert to accessors and !use_sg cleanup a2091: convert to accessors and !use_sg cleanup eata_pio: convert to accessors and !use_sg cleanup nsp_cs: convert to data accessors and !use_sg cleanup aha152x: Use scsi_eh API for REQUEST_SENSE invocation Brian King (1): ibmvscsi: Set default command timeout Christof Schmitt (11): zfcp: Hold queue lock when checking port/unit handle for task management c zfcp: Hold queue lock when checking port/unit handle for FCP command zfcp: Hold queue lock when checking port handle for ELS command zfcp: Hold queue lock when checking port/unit handle for abort command zfcp: Fix evaluation of port handles in abort handler zfcp: Reduce flood on hba trace zfcp: Fix deadlock when adding invalid LUN zfcp: Remove SCSI devices when removing complete adapter zfcp: Specify waiting times in ERP in seconds zfcp: Use also port and adapter to identify unit in messages. zfcp: Remove unnecessary eh_bus_reset_handler callback Christoph Hellwig (1): aacraid: don't assign cpu_to_le32(int) to u8 Darrick J. Wong (2): libsas: Fix various sparse complaints libsas: Convert sas_proto users to sas_protocol Denis Cheng (1): ipr: use LIST_HEAD instead of LIST_HEAD_INIT Erez Zilber (1): IB/iSER: add logical unit reset support FUJITA Tomonori (13): ch: remove forward declarations ch: fix device minor number management bug ch: handle class_device_create failure properly use dynamically allocated sense buffer sg: handle class_device_create failure properly sg: set class_data after success replace sizeof sense_buffer with SCSI_SENSE_BUFFERSIZE aic7xxx_old, eata_pio, ips, libsas: don't zero out sense_buffer in queueco libsas: fix sense_buffer overrun fix scsi_setup_command_freelist failure path race mpt fusion: make mptsas_smp_handler update resid iscsi_tcp: update
Re: [PATCH] Marvell 6440 SAS/SATA driver
James Bottomley wrote: The lack of interrupt enable looks potentially fatal... See my comments on this specific issue, in this thread, for the reason why that function isn't used... Jeff - 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
On Sat, 2008-01-26 at 00:43 +0800, Ke Wei wrote: > The attached is Marvell 6440 SAS/SATA driver. I will try to send email > by git-send-email. > > Changelog : > Merged from Jeff's branch to James's branch. > > Signed-off-by: Ke Wei <[EMAIL PROTECTED]> A compile test of this seems to show some problems: drivers/scsi/mvsas.c:2126: warning: 'mvs_read_port_irq_mask' defined but not used drivers/scsi/mvsas.c:796: warning: 'mvs_hba_interrupt_enable' defined but not used drivers/scsi/mvsas.c:1349: warning: 'mvs_free_reg_set' defined but not used The lack of interrupt enable looks potentially fatal...except that you have an open coded interrupt enable in mvs_hw_init(). 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
On Sat, 2008-01-26 at 00:43 +0800, Ke Wei wrote:
> struct mvs_phy {
> struct mvs_port *port;
> struct asd_sas_phy sas_phy;
> + struct sas_identify identify;
> + __le32 dev_info;
> + __le64 dev_sas_addr;
> + __le32 att_dev_info;
> + __le64 att_dev_sas_addr;
> + u32 type;
> + __le32 phy_status;
> + __le32 irq_status;
> + u8 wide_port_phymap;
> + u32 frame_rcvd_size;
> + u8 frame_rcvd[32];
>
> - u8 frame_rcvd[24 + 1024];
> };
These __le quantites don't look right ... they're all read in by readl,
which will convert little endian to CPU anyway.
> @@ -437,27 +586,55 @@ struct mvs_info {
> dma_addr_t rx_dma;
> u32 rx_cons;/* RX consumer idx */
>
> - __le32 *rx_fis;/* RX'd FIS area */
> + void*rx_fis;/* RX'd FIS area */
Now the received FIS, on the other hand, provided you're storing it in
wire format (which you look to be) *is* little endian data by definition
in the ATA spec.
> -static void mvs_tag_clear(struct mvs_info *mvi, unsigned int tag)
> +static void mvs_tag_clear(struct mvs_info *mvi, u32 tag)
> {
> - mvi->tags[tag / sizeof(unsigned long)] &=
> - ~(1UL << (tag % sizeof(unsigned long)));
> + mvi->tag_in = (mvi->tag_in + 1) & (MVS_SLOTS - 1);
> + mvi->tags[mvi->tag_in] = tag;
> }
>
> -static void mvs_tag_set(struct mvs_info *mvi, unsigned int tag)
> +static void mvs_tag_free(struct mvs_info *mvi, u32 tag)
> {
> - mvi->tags[tag / sizeof(unsigned long)] |=
> - (1UL << (tag % sizeof(unsigned long)));
> + mvi->tag_out = (mvi->tag_out - 1) & (MVS_SLOTS - 1);
> }
>
> -static bool mvs_tag_test(struct mvs_info *mvi, unsigned int tag)
> +static int mvs_tag_alloc(struct mvs_info *mvi, u32 *tag_out)
> {
> - return mvi->tags[tag / sizeof(unsigned long)] &
> - (1UL << (tag % sizeof(unsigned long)));
> + if (mvi->tag_out != mvi->tag_in) {
> + *tag_out = mvi->tags[mvi->tag_out];
> + mvi->tag_out = (mvi->tag_out + 1) & (MVS_SLOTS - 1);
> + return 0;
> + }
> + return -EBUSY;
I really don't think you should be doing this. That single ring governs
all the potential tag slots for everything in this device. If you do a
simple head tail allocation, what can happen is that you get a slow tag
(attached to a format command, or a tape command) and then the ring head
will hit the slow tag and the entire device will halt. I think you need
a bitmap based allocation algorithm to ensure that if you have a free
tag anywhere, you'll use it.
If you look at the aic94xx index functions in aic94xx_hwi.h you'll see
asd_tc_index_get() and asd_tc_index_release() doing exactly what you
want with the native linux bitmap functions (the aic also uses a single
issue queue with indexes into it).
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
Grant Grundler wrote: On Jan 25, 2008 8:43 AM, Ke Wei <[EMAIL PROTECTED]> wrote: The attached is Marvell 6440 SAS/SATA driver. I will try to send email by git-send-email. I know this isn't part of this patch: #define mr32(reg) readl(regs + MVS_##reg) #define mw32(reg,val) writel((val), regs + MVS_##reg) But can "regs" be declared a parameter to the macro? This is a common technique in drivers (especially net drivers), eliminating the redundant-across-the-entire-driver argument passed to each register read or write. The result is infinitely more readable and compact. val = mr32(IRQ_STAT); immediately communicates all the necessary information you need. + MODE_AUTO_DET_PORT7 = (1U << 15), /* port0 SAS/SATA autodetect */ + MODE_AUTO_DET_PORT6 = (1U << 14), + MODE_AUTO_DET_PORT5 = (1U << 13), + MODE_AUTO_DET_PORT4 = (1U << 12), + MODE_AUTO_DET_PORT3 = (1U << 11), + MODE_AUTO_DET_PORT2 = (1U << 10), + MODE_AUTO_DET_PORT1 = (1U << 9), + MODE_AUTO_DET_PORT0 = (1U << 8), These really aren't needed. Like James noted, without public docs, we don't want to be removing any hardware definitions. Have to stop for now...but I'm wonder how this driver ever worked given the number of HW register bits that were changed (assuming they were wrong before this patch). And this driver looks _alot_ better than the previous Marvell drivers I've looked at. Please keep up the good work! :) Before this patch, the driver did not work. As I do with all other drivers I write, I write the entire driver from the datasheet before testing anything. Jeff - 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: sd incorrectly reports write cache disabled on cache-capable drives/controllers
On Friday 25 January 2008 22:33:21 James Bottomley wrote: > Just because the inquiry strings say it doesn't have a cache doesn't > really mean it's not using one but not telling anyone. Thank you for explaining this to me. I have been stuck on this for close to six months, and you solved it in less than 15 minutes. I greatly appreciate you taking the time to explain to a beginner. Got to love the linux spirit. Have a great weekend! - 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: sd incorrectly reports write cache disabled on cache-capable drives/controllers
On Fri, 2008-01-25 at 22:28 +0100, Halim Issa wrote: > Thank you so much for the quick reply - I risk asking one follow-up question. > > On Friday 25 January 2008 22:15:20 James Bottomley wrote: > > The "cache" hear would be referring to the RAID controller cache, not > > the disk cache. Likewise DPO and FUA refer to what the RAID controller > > can support, not the disk. > > Would it be safe to assume that the problem thus lies within the mptfusion > driver, since a) the LSI Logic controller in question does indeed have > hardware cache capabilities; and b) an older kernel version as well as > Windows Server, correctly loads with the correct cache parameters at boot? I don't think it would be correct to assume that there actually is a problem. Most RAID controllers habitually lie about having a cache in their INQUIRY strings because they don't want to deal with the kernel sending SYNCHRONIZE_CACHE commands down. Just because the inquiry strings say it doesn't have a cache doesn't really mean it's not using one but not telling anyone. 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: sd incorrectly reports write cache disabled on cache-capable drives/controllers
Thank you so much for the quick reply - I risk asking one follow-up question. On Friday 25 January 2008 22:15:20 James Bottomley wrote: > The "cache" hear would be referring to the RAID controller cache, not > the disk cache. Likewise DPO and FUA refer to what the RAID controller > can support, not the disk. Would it be safe to assume that the problem thus lies within the mptfusion driver, since a) the LSI Logic controller in question does indeed have hardware cache capabilities; and b) an older kernel version as well as Windows Server, correctly loads with the correct cache parameters at boot? What would be the correct path forward to trouble-shoot this further in order to get the driver to utilize the maximum hardware capabilities in the generic kernel.org kernels? Thanks again, and I apologize in advance if my questions are too basic for this list. - 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
On Wed, 2008-01-23 at 18:54 +0800, Ke Wei wrote: > Attachment is a patch file for 6440 driver. I will have to spend more > time on setting my mail client. Yesterday I used mutt tool. But Look > like the problem still exists. By default, unfortunately, I think no email tool nowadays inserts plain text ... they all assume you want it nicely formatted with proper line breaks. There's a guide to inserting plain text patches inline with some email tools in the kernel Documentation directory: Documentation/email-clients.txt The current attachment is fine for a patch application, 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
Re: sd incorrectly reports write cache disabled on cache-capable drives/controllers
On Fri, 2008-01-25 at 21:59 +0100, Halim Issa wrote: > This is my first post to any of the vger lists. I have tried to comply with > the list recommendations and be specific while to the point. If anything is > missing, kindly let me know. > > I am having trouble getting the scsi-subsystem on an IBM x336 eServer with > LSI > Logic53c1030 SCSI RAID controller to recognize the write cache on my > harddrives/controller. It reports: > > sd 0:0:0:0: [sda] Write cache: disabled, read cache: enabled, doesn't support > DPO or FUA. This statement is really simply reporting what the INQUIRY data of the device is telling it ... we don't actually massage the data in any way. However ... The INQUIRY strings for this device are: scsi 0:0:0:0: Direct-Access LSILOGIC 1030 IM 1000 PQ: 0 ANSI: 2 So it's basically a RAID-1 volume manufactured by the LSI, not your actual device. The INQUIRY strings returned by such RAID volumes usually bear no relation to the underlying devices. The "cache" hear would be referring to the RAID controller cache, not the disk cache. Likewise DPO and FUA refer to what the RAID controller can support, not the disk. 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
[PATCH] [SCSI] make SPI DV data pattern "d" match T10
The T10 SCSI domain validation draft sdv-r08b.pdf section 5.4 describes
data pattern "d" like this:
d) shifting bit (h, FFFEh, h, FFFDh, ... then h, 0001h,
h, 0002h, ...)
The current code in scsi_transport_spi.c produces the following data
pattern:
FF FF 00 00 | FE FF 01 00 | FC FF 03 00 | F8 FF 07 00
F0 FF 0F 00 | E0 FF 1F 00 | C0 FF 3F 00 | 80 FF 7F 00
(other patterns here)
00 FF FF 00 | 00 FE FF 01 | 00 FC FF 03 | 00 F8 FF 07
00 F0 FF 0F | 00 E0 FF 1F | 00 C0 FF 3F | 00 80 FF 7F
(other patterns here)
00 00 FF FF | 01 00 FE FF | 03 00 FC FF | 07 00 F8 FF
0F 00 F0 FF | 1F 00 E0 FF | 3F 00 C0 FF | 7F 00 80 FF
(other patterns here)
FF 00 00 FF | FF 01 00 FE | FF 03 00 FC | FF 07 00 F8
FF 0F 00 F0 | FF 1F 00 E0 | FF 3F 00 C0 | FF 7F 00 80
This patch changes the data pattern to match sdv-r08b.pdf, like this:
00 00 FF FE | 00 00 FF FD | 00 00 FF FB | 00 00 FF F7
00 00 FF EF | 00 00 FF DF | 00 00 FF BF | 00 00 FF 7F
00 00 FE FF | 00 00 FD FF | 00 00 FB FF | 00 00 F7 FF
00 00 EF FF | 00 00 DF FF | 00 00 BF FF | 00 00 7F FF
FF FF 00 01 | FF FF 00 02 | FF FF 00 04 | FF FF 00 08
FF FF 00 10 | FF FF 00 20 | FF FF 00 40 | FF FF 00 80
FF FF 01 00 | FF FF 02 00 | FF FF 04 00 | FF FF 08 00
FF FF 10 00 | FF FF 20 00 | FF FF 40 00 | FF FF 80 00
This data pattern tests simultaneously turning on or off all bits but
one.
Signed-off-by: Tony Battersby <[EMAIL PROTECTED]>
---
--- linux-2.6.24/drivers/scsi/scsi_transport_spi.c.orig 2008-01-25
15:16:15.0 -0500
+++ linux-2.6.24/drivers/scsi/scsi_transport_spi.c 2008-01-25
15:30:20.0 -0500
@@ -559,7 +559,6 @@ spi_dv_device_echo_buffer(struct scsi_de
{
int len = ptr - buffer;
int j, k, r, result;
- unsigned int pattern = 0x;
struct scsi_sense_hdr sshdr;
const char spi_write_buffer[] = {
@@ -594,12 +593,18 @@ spi_dv_device_echo_buffer(struct scsi_de
}
k = j;
/* fill with shifting bits (test d) */
- for ( ; j < min(len, k + 32); j += 4) {
- u32 *word = (unsigned int *)&buffer[j];
- u32 roll = (pattern & 0x8000) ? 1 : 0;
-
- *word = pattern;
- pattern = (pattern << 1) | roll;
+ for ( ; j < min(len, k + 64); j += 4) {
+ u32 *word = (u32 *)&buffer[j];
+ int bit = (j - k) >> 2;
+
+ *word = cpu_to_be32(0x & ~(1 << bit));
+ }
+ k = j;
+ for ( ; j < min(len, k + 64); j += 4) {
+ u32 *word = (u32 *)&buffer[j];
+ int bit = (j - k) >> 2;
+
+ *word = cpu_to_be32(0x | (1 << bit));
}
/* don't bother with random data (test e) */
}
-
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: INITIO scsi driver fails to work properly
On 1/25/08, James Bottomley <[EMAIL PROTECTED]> wrote: > > Actually, I suspect your issues should be fixed by this patch: > > http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=e2d435ea4084022ab88efa74214accb45b1f9e92 > > Could you download 2.6.24 and try it out to see if they are? > > Thanks, > > James > Well, 2.6.24 fixes the problem. Thanks to all of you! - 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
sd incorrectly reports write cache disabled on cache-capable drives/controllers
This is my first post to any of the vger lists. I have tried to comply with the list recommendations and be specific while to the point. If anything is missing, kindly let me know. I am having trouble getting the scsi-subsystem on an IBM x336 eServer with LSI Logic53c1030 SCSI RAID controller to recognize the write cache on my harddrives/controller. It reports: sd 0:0:0:0: [sda] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA. Both the drives and controller do indeed support caching and Disable Page Out + Force Unit Access. The system works well with caching on "other" operating systems as well as with linux kernel version 2.6.16 (to which I do not have access to the .config unfortunately). What I have noticed is that with the other OS/older kernel, the scsi controller appears to be moved from GSI 28 to IRQ193, while in 2.6.22 and later (currently 2.6.24) it remains on IRQ 28... I also appear to be able to turn this on manually by typing: sdparm -s WCE=1 /dev/sg2 (and same with sg3, the other disk in the RAID), so it doesn't make sense to me that I can turn it on manually, but the driver/modules doesn't do it themselves on system boot/driver load. If anyone could kindly point me in the right direction on how to get this working I would greatly appreciate it, as several months of googling + trying to understand how sd.c gets the WCE parameter has left me blank. What exactly controls how the sd.c driver reads the write and read cache capability of the LSI Logic controller/IBM harddrives, and what could be missing causing the sd.c driver to incorrectly believe that it's not capable? The full kernel configuration, dmesg output, lspci -vv and lsscsi -vv, interrupts, lsdev and lsmod and much more system information is available at www.hiawata.com/linux. The system is not (yet) in production, and can as such be experimented with. Thank you in advance for any insight! Hardware spec: > SCSI Controller (lspci -vv): 04:01.0 SCSI storage controller: LSI Logic / Symbios Logic 53c1030 PCI-X Fusion- MPT Dual Ultra320 SCSI (rev 08) Subsystem: IBM Unknown device 026d Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr+ Step ping- SERR+ FastB2B- Status: Cap+ 66MHz+ UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- SERR- SCSI drives (lsscsi -vv): sysfsroot: /sys [0:0:0:0]diskLSILOGIC 1030 IM 1000 /dev/sda dir: /sys/bus/scsi/devices/0:0:0:0 [/sys/devices/pci:00/:00:04.0/:03:00.0/:04:01.0/host0/target0:0:0/0:0:0:0] [0:0:8:0]process IBM 25P3495a S320 1 1 - dir: /sys/bus/scsi/devices/0:0:8:0 [/sys/devices/pci:00/:00:04.0/:03:00.0/:04:01.0/host0/target0:0:8/0:0:8:0] [0:1:0:0]diskIBM-ESXS ST373453LCFN B85D - dir: /sys/bus/scsi/devices/0:1:0:0 [/sys/devices/pci:00/:00:04.0/:03:00.0/:04:01.0/host0/target0:1:0/0:1:0:0] [0:1:1:0]diskIBM-ESXS ST373453LCFN B85D - dir: /sys/bus/scsi/devices/0:1:1:0 [/sys/devices/pci:00/:00:04.0/:03:00.0/:04:01.0/host0/target0:1:1/0:1:1:0] ===> Modules loaded (lsmod) : Module Size Used by ipt_ULOG9992 2 ipt_REJECT 5120 2 ipt_recent 9760 5 xt_limit3968 2 xt_tcpudp 4608 20 nf_conntrack_ipv4 16144 17 xt_state3456 17 nf_conntrack 58352 2 nf_conntrack_ipv4,xt_state xt_pkttype 3072 1 iptable_filter 3840 1 ip_tables 19240 1 iptable_filter x_tables 16520 8 ipt_ULOG,ipt_REJECT,ipt_recent,xt_limit,xt_tcpudp,xt_state,xt_pkttype,ip_tables nfs 130488 1 lockd 65968 2 nfs sunrpc176648 8 nfs,lockd ide_scsi 15112 0 ide_cd 39072 0 tg3 114180 0 rtc_cmos 0 cdrom 36904 1 ide_cd i2c_i801 10012 0 evdev 11392 2 rtc_core 17804 1 rtc_cmos serio_raw 7172 0 button 8608 0 pcspkr 3968 0 rtc_lib 4224 1 rtc_core i2c_core 21632 1 i2c_i801 iTCO_wdt 13264 0 sg 31384 0 iTCO_vendor_support 4740 1 iTCO_wdt dm_mod 53360 0 mptspi 19088 5 mptscsih 35968 1 mptspi mptbase76260 2 mptspi,mptscsih scsi_transport_spi 26624 1 mptspi sd_mod 24576 6 scsi_mod 139568 6 ide_scsi,sg,mptspi,mptscsih,scsi_transport_spi,sd_mod ===> dmesg output (edited for space, made effort to keep relevant parts): Linux version 2.6.24 ([EMAIL PROTECTED]) (gcc version 4.1.2) #1 SMP Fri Jan 25 19:51:00 CET 2008 Command line: BOOT_IMAGE=Linux.test ro root=801 BIOS-provided physical RAM map: BIOS-e820: - 0009d400 (usable) BIOS
Re: PATCH: usb-storage-set-last-sector-bug-flag.patch
ACKed-by: Matthew Dharm <[EMAIL PROTECTED]> Matt On Fri, Jan 25, 2008 at 11:12:21AM -0600, James Bottomley wrote: > On Thu, 2008-01-24 at 09:21 -0800, Greg KH wrote: > > On Thu, Jan 24, 2008 at 06:07:00PM +0100, Stefan Richter wrote: > > > Greg KH wrote: > > > > I just am worried that we are > > > > now suddenly keeping access from the last sector for devices that > > > > currently did work just fine. > > > > > > This new workaround doesn't prevent access to the last sector. It only > > > breaks up a multi-sector access which would also reach the last sector > > > into several (two? I'm too lazy to look back in the mail thread) > > > accesses, in order to access the last sector in a dedicated > > > single-sector access. > > > > > > So that's very differently to the fix-capacity workaround. The > > > fix-capacity workaround manipulates the READ CAPACITY parameter data. > > > Therefore the fix-capacity workaround is unsafe for non-buggy devices. > > > > > > The last-sector-(access-)bug workaround _only_ modifies the command > > > stream which is sent to the device. A dangerous command is replaced by > > > equivalent safe commands. These commands are luckily safe for _all_ > > > devices, buggy and non-buggy ones. The only cost of this workaround is > > > (1.) the code, (2.) the runtime/ bandwidth/ latency overhead for > > > accesses which reach the last sector. > > > > Ok, thanks for explaining it better. I have no objection to this change > > anymore. > > So, for forms sake to take this through the SCSI tree I need at least > one USB person to ack it ... > > James > -- Matthew Dharm Home: [EMAIL PROTECTED] Maintainer, Linux USB Mass Storage Driver It was a new hope. -- Dust Puppy User Friendly, 12/25/1998 pgpqFii90rEvw.pgp Description: PGP signature
[RFC] aic7xxx - ahc_done check SCB_ACTIVE for tagged transactions
Hannes,
Does ahc_done need to check the SCB_ACTIVE flag only if the SCB
is not in the untagged queue before panic?
If the driver is in error recovery, you may end panic'ing
on a TUR that is in the untagged queue.
Attempting to queue an ABORT message
CDB: 0x0 0x0 0x0 0x0 0x0 0x0
SCB 3 done'd twice
This patch is included in Adaptec's 6.3.11 driver on their
website.
Thank you,
David
--- scsi-misc-2.6.git/drivers/scsi/aic7xxx/aic7xxx_osm.c.abort
+++ scsi-misc-2.6.git/drivers/scsi/aic7xxx/aic7xxx_osm.c
@@ -1658,9 +1658,12 @@ ahc_done(struct ahc_softc *ahc, struct s
untagged_q = &(ahc->untagged_queues[target_offset]);
TAILQ_REMOVE(untagged_q, scb, links.tqe);
BUG_ON(!TAILQ_EMPTY(untagged_q));
- }
-
- if ((scb->flags & SCB_ACTIVE) == 0) {
+ } else if ((scb->flags & SCB_ACTIVE) == 0) {
+ /*
+* Transactions aborted from the untagged queue may
+* not have been dispatched to the controller, so
+* only check the SCB_ACTIVE flag for tagged transactions.
+*/
printf("SCB %d done'd twice\n", scb->hscb->tag);
ahc_dump_card_state(ahc);
panic("Stopping for safety");
-
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
On Fri, 2008-01-25 at 09:24 -0800, Grant Grundler wrote: > On Jan 25, 2008 8:43 AM, Ke Wei <[EMAIL PROTECTED]> wrote: > > The attached is Marvell 6440 SAS/SATA driver. I will try to send email > > by git-send-email. > > I know this isn't part of this patch: > #define mr32(reg)readl(regs + MVS_##reg) > #define mw32(reg,val)writel((val), regs + MVS_##reg) > > But can "regs" be declared a parameter to the macro? > And the one letter difference in the name is just asking for trouble. > Better to call it "mmio_base" or something a bit longer that won't > likely collide with other stuff. > > +/* offset for D2H FIS in the Received FIS List Structure */ > +#define SATA_RECEIVED_D2H_FIS(reg_set) \ > + (mvi->rx_fis + 0x400 + 0x100 * reg_set + 0x40) > > Ditto. > > + MODE_AUTO_DET_PORT7 = (1U << 15), /* port0 SAS/SATA autodetect */ > + MODE_AUTO_DET_PORT6 = (1U << 14), > + MODE_AUTO_DET_PORT5 = (1U << 13), > + MODE_AUTO_DET_PORT4 = (1U << 12), > + MODE_AUTO_DET_PORT3 = (1U << 11), > + MODE_AUTO_DET_PORT2 = (1U << 10), > + MODE_AUTO_DET_PORT1 = (1U << 9), > + MODE_AUTO_DET_PORT0 = (1U << 8), > > These really aren't needed. > > #define MODE_AUTO_DET_EN (0xff << 8)/* enable auto detect on all > 8 ports */ > > > Ditto for MODE_SAS_SATA. Given that we don't have public docs for this driver, having register bit definitions in the driver, even if they aren't used anywhere can be incredibly helpful, so please don't remove them. Even more useful would be additional comments saying what they actually do ... 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
On Jan 25, 2008 8:43 AM, Ke Wei <[EMAIL PROTECTED]> wrote: > The attached is Marvell 6440 SAS/SATA driver. I will try to send email > by git-send-email. > Sorry, just saw some more issues in +static void mvs_hba_interrupt_enable(struct mvs_info *mvi, int enable) Three comments here: 1) This routine is slightly misnamed since it can both enable and disable the interrupt. I _suggest_ to not pass in "enable" parameter and add a mvs_hba_interrupt_disable() to deal with (2) and (3) below. 2) On interrupt disable, MMIO write posting _could_ be a problem here. ie interrupts could be generated after calling this routine since it doesn't force the MMIO write to the PCI device with an MMIO read. (For more info on this see chapter 4 of http://iou.parisc-linux.org/ols_2002/ ) 3) Even after fixing (2), interrupts can already be in-flight and not yet delivered. Higher level code needs to make sure it can tolerate a "late arriving" IRQ. One MMIO read should mostly solve this for MSI but not for Line-based IRQ. (MMIO Read-return will flush inflight MSI). hth, grant - 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
On Jan 25, 2008 8:43 AM, Ke Wei <[EMAIL PROTECTED]> wrote:
> The attached is Marvell 6440 SAS/SATA driver. I will try to send email
> by git-send-email.
I know this isn't part of this patch:
#define mr32(reg) readl(regs + MVS_##reg)
#define mw32(reg,val) writel((val), regs + MVS_##reg)
But can "regs" be declared a parameter to the macro?
And the one letter difference in the name is just asking for trouble.
Better to call it "mmio_base" or something a bit longer that won't
likely collide with other stuff.
+/* offset for D2H FIS in the Received FIS List Structure */
+#define SATA_RECEIVED_D2H_FIS(reg_set) \
+ (mvi->rx_fis + 0x400 + 0x100 * reg_set + 0x40)
Ditto.
+ MODE_AUTO_DET_PORT7 = (1U << 15), /* port0 SAS/SATA autodetect */
+ MODE_AUTO_DET_PORT6 = (1U << 14),
+ MODE_AUTO_DET_PORT5 = (1U << 13),
+ MODE_AUTO_DET_PORT4 = (1U << 12),
+ MODE_AUTO_DET_PORT3 = (1U << 11),
+ MODE_AUTO_DET_PORT2 = (1U << 10),
+ MODE_AUTO_DET_PORT1 = (1U << 9),
+ MODE_AUTO_DET_PORT0 = (1U << 8),
These really aren't needed.
#define MODE_AUTO_DET_EN (0xff << 8)/* enable auto detect on all
8 ports */
Ditto for MODE_SAS_SATA.
+ /* Port n Attached Device Info */
Groups bits defined have a comment preceeding a group of bits (which
is a good thing). If multiple registers are being defined in one enum
declaration, can you please add either the register offset
to the comment or include the constant that defines the
offset (e.g. MVS_P0_CFG_ADDR)?
Have to stop for now...but I'm wonder how this driver ever worked
given the number of HW register bits that were changed (assuming
they were wrong before this patch). And this driver looks _alot_
better than the previous Marvell drivers I've looked at. Please keep
up the good work! :)
hth,
grant
> Changelog :
> Merged from Jeff's branch to James's branch.
>
> Signed-off-by: Ke Wei <[EMAIL PROTECTED]>
>
>
>
> On Jan 23, 2008 7:41 PM, Jeff Garzik <[EMAIL PROTECTED]> wrote:
> > Ke Wei wrote:
> > > Attachment is a patch file for 6440 driver. I will have to spend more
> > > time on setting my mail client. Yesterday I used mutt tool. But Look
> > > like the problem still exists.
> > > I fixed all issues which you mentioned , but
> >
> > The changes look good, thanks!
> >
> > In terms of engineering process, I should have been more clear: when
> > revising your submission, you should make the revisions and then
> > regenerate your original patch.
> >
> > To use a silly example, if you needed to fix a 1-character typo in a
> > 1,000-line patch, you would need to make your revision, re-generate the
> > 1,000-line patch, and email that new patch.
> >
> > So, to move forward, please create one single patch with the latest
> > mvsas, diff'd against the 'mvsas' branch of
> > git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi-misc-2.6
> >
> > I will "ack" that patch (indicate my approval), and unless other
> > objections surface, James will merge your patch into the 'mvsas' branch.
> > That will get the driver on the road to be included in 2.6.25.
> >
> >
> > >>> @@ -666,11 +970,53 @@ static int mvs_nvram_read(struct mvs_info *mvi,
> > >>> unsigned
> > >>> int addr,
> > >>> err_out:
> > >>>dev_printk(KERN_ERR, &mvi->pdev->dev, "%s", msg);
> > >>>return rc;
> > >>> +#else
> > >>> + memcpy(buf, "\x50\x05\x04\x30\x11\xab\x00\x00", 8);
> > >>> + return 0;
> > >>> +#endif
> > >>
> > >> what happens if two adapters are used, with the same SAS address? That
> > >> causes problems...
> > >>
> > >>
> > > Our bios can write SAS Address per port when system boot , so I think
> > > we don't need read or configure address.
> >
> > It is standard Linux policy to reduce or eliminate BIOS dependencies as
> > much as possible.
> >
> > This is because there are several common scenarios where BIOS may not
> > run, or otherwise not be available:
> >
> > * suspend/resume
> > * controller hotplug
> > * non-x86 PCI platforms such as POWER
> >
> > Thus, we need the driver to obtain these addresses -- hopefully reading
> > them from a BIOS data table somewhere, if NVRAM is not available.
> >
> > This is a highly common scenario -- obtaining unique identifying
> > information in the absence of BIOS.
> >
> >
> >
> > Similarly, we cannot rely on BIOS to perform any global reset or errata
> > workaround duties for us. That must be coded into the driver also.
> >
> >
> > > And I reserved hexdump funciton if you don't care. Only debugging.
> >
> > It is not an important matter, but it would be nice to clean that up
> > eventually.
> >
> > Also, FWIW, we have a standard method of debug output:
> >
> >struct pci_dev *pdev;
> >
> >dev_dbg(&pdev->dev, KERN_INFO,
> >"this is debug message number %d", 2);
> >
> > which will only be compiled into the driver when DEBUG is defined.
> >
> >
> > >>> +static int mvs_abort_task(struct sas_task *task)
> > >>> +{
> > >>> + /*FIXME*/
> >
Re: PATCH: usb-storage-set-last-sector-bug-flag.patch
On Thu, 2008-01-24 at 09:21 -0800, Greg KH wrote: > On Thu, Jan 24, 2008 at 06:07:00PM +0100, Stefan Richter wrote: > > Greg KH wrote: > > > I just am worried that we are > > > now suddenly keeping access from the last sector for devices that > > > currently did work just fine. > > > > This new workaround doesn't prevent access to the last sector. It only > > breaks up a multi-sector access which would also reach the last sector > > into several (two? I'm too lazy to look back in the mail thread) > > accesses, in order to access the last sector in a dedicated > > single-sector access. > > > > So that's very differently to the fix-capacity workaround. The > > fix-capacity workaround manipulates the READ CAPACITY parameter data. > > Therefore the fix-capacity workaround is unsafe for non-buggy devices. > > > > The last-sector-(access-)bug workaround _only_ modifies the command > > stream which is sent to the device. A dangerous command is replaced by > > equivalent safe commands. These commands are luckily safe for _all_ > > devices, buggy and non-buggy ones. The only cost of this workaround is > > (1.) the code, (2.) the runtime/ bandwidth/ latency overhead for > > accesses which reach the last sector. > > Ok, thanks for explaining it better. I have no objection to this change > anymore. So, for forms sake to take this through the SCSI tree I need at least one USB person to ack it ... 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: INITIO scsi driver fails to work properly
On Tue, 2008-01-22 at 19:50 +0200, Filippos Papadopoulos wrote: > I get the following: > SAH > SSH > SCB Q > SCB EXEC > SCB EXEC DONE Actually, I suspect your issues should be fixed by this patch: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=e2d435ea4084022ab88efa74214accb45b1f9e92 Could you download 2.6.24 and try it out to see if they are? 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
Re: [UPDATED PATCH] SGIWD93: use cached memory access to make driver work on IP28
On Fri, 2008-01-25 at 17:32 +0100, Thomas Bogendoerfer wrote:
> SGI IP28 machines would need special treatment (enable adding addtional
> wait states) when accessing memory uncached. To avoid this pain I
> changed the driver to use only cached access to memory.
>
> Signed-off-by: Thomas Bogendoerfer <[EMAIL PROTECTED]>
> ---
>
> Changes to last version:
>
> - added Kconfig change to make selection for similair SGI boxes easier
>
> drivers/scsi/Kconfig |2 +-
> drivers/scsi/sgiwd93.c | 64 +--
> 2 files changed, 40 insertions(+), 26 deletions(-)
>
> diff --git a/drivers/scsi/Kconfig b/drivers/scsi/Kconfig
> index a6676be..2a071b0 100644
> --- a/drivers/scsi/Kconfig
> +++ b/drivers/scsi/Kconfig
> @@ -345,7 +345,7 @@ config ISCSI_TCP
>
> config SGIWD93_SCSI
> tristate "SGI WD93C93 SCSI Driver"
> - depends on SGI_IP22 && SCSI
> + depends on SGI_HAS_WD93 && SCSI
> help
> If you have a Western Digital WD93 SCSI controller on
> an SGI MIPS system, say Y. Otherwise, say N.
> diff --git a/drivers/scsi/sgiwd93.c b/drivers/scsi/sgiwd93.c
> index eef8275..e64ddee 100644
> --- a/drivers/scsi/sgiwd93.c
> +++ b/drivers/scsi/sgiwd93.c
> @@ -33,10 +33,9 @@
>
> struct ip22_hostdata {
> struct WD33C93_hostdata wh;
> - struct hpc_data {
> - dma_addr_t dma;
> - void*cpu;
> - } hd;
> + dma_addr_t dma;
> + void *cpu;
> + void *dev;
This should be struct device *dev; shouldn't it (that seems to be how
it's always used)?
> };
>
> #define host_to_hostdata(host) ((struct ip22_hostdata *)((host)->hostdata))
> @@ -46,6 +45,11 @@ struct hpc_chunk {
> u32 _padding; /* align to quadword boundary */
> };
>
> +/* space for hpc dma descriptors */
> +#define HPC_DMA_SIZE PAGE_SIZE
> +
> +#define DMA_DIR(d) ((d == DATA_OUT_DIR) ? DMA_TO_DEVICE : DMA_FROM_DEVICE)
> +
> static irqreturn_t sgiwd93_intr(int irq, void *dev_id)
> {
> struct Scsi_Host * host = dev_id;
> @@ -59,15 +63,17 @@ static irqreturn_t sgiwd93_intr(int irq, void *dev_id)
> }
>
> static inline
> -void fill_hpc_entries(struct hpc_chunk *hcp, struct scsi_cmnd *cmd, int
> datainp)
> +void fill_hpc_entries(struct ip22_hostdata *hd, struct scsi_cmnd *cmd, int
> din)
> {
> unsigned long len = cmd->SCp.this_residual;
> void *addr = cmd->SCp.ptr;
> dma_addr_t physaddr;
> unsigned long count;
> + struct hpc_chunk *hcp;
>
> - physaddr = dma_map_single(NULL, addr, len, cmd->sc_data_direction);
> + physaddr = dma_map_single(hd->dev, addr, len, DMA_DIR(din));
> cmd->SCp.dma_handle = physaddr;
> + hcp = hd->cpu;
>
> while (len) {
> /*
> @@ -89,6 +95,9 @@ void fill_hpc_entries(struct hpc_chunk *hcp, struct
> scsi_cmnd *cmd, int datainp)
>*/
> hcp->desc.pbuf = 0;
> hcp->desc.cntinfo = HPCDMA_EOX;
> + dma_cache_sync(hd->dev, hd->cpu,
> +(unsigned long)(hcp + 1) - (unsigned long)hd->cpu,
> +DMA_TO_DEVICE);
> }
>
> static int dma_setup(struct scsi_cmnd *cmd, int datainp)
> @@ -96,9 +105,8 @@ static int dma_setup(struct scsi_cmnd *cmd, int datainp)
> struct ip22_hostdata *hdata = host_to_hostdata(cmd->device->host);
> struct hpc3_scsiregs *hregs =
> (struct hpc3_scsiregs *) cmd->device->host->base;
> - struct hpc_chunk *hcp = (struct hpc_chunk *) hdata->hd.cpu;
>
> - pr_debug("dma_setup: datainp<%d> hcp<%p> ", datainp, hcp);
> + pr_debug("dma_setup: datainp<%d> hcp<%p> ", datainp, hdata->cpu);
>
> hdata->wh.dma_dir = datainp;
>
> @@ -111,12 +119,12 @@ static int dma_setup(struct scsi_cmnd *cmd, int datainp)
> if (cmd->SCp.ptr == NULL || cmd->SCp.this_residual == 0)
> return 1;
>
> - fill_hpc_entries(hcp, cmd, datainp);
> + fill_hpc_entries(hdata, cmd, datainp);
>
> pr_debug(" HPCGO\n");
>
> /* Start up the HPC. */
> - hregs->ndptr = hdata->hd.dma;
> + hregs->ndptr = hdata->dma;
> if (datainp)
> hregs->ctrl = HPC3_SCTRL_ACTIVE;
> else
> @@ -134,6 +142,9 @@ static void dma_stop(struct Scsi_Host *instance, struct
> scsi_cmnd *SCpnt,
> if (!SCpnt)
> return;
>
> + if (SCpnt->SCp.ptr == NULL || SCpnt->SCp.this_residual == 0)
> + return;
> +
> hregs = (struct hpc3_scsiregs *) SCpnt->device->host->base;
>
> pr_debug("dma_stop: status<%d> ", status);
> @@ -145,8 +156,9 @@ static void dma_stop(struct Scsi_Host *instance, struct
> scsi_cmnd *SCpnt,
> barrier();
> }
> hregs->ctrl = 0;
> - dma_unmap_single(NULL, SCpnt->SCp.dma_handle, SCpnt->SCp.this_residual,
> - SCpnt->sc_data_direction);
> + dma_unmap_single(hdata->dev, SCpnt->SCp.dma_handle,
> + SCpnt->SCp.this_residual,
> + DMA_DIR(hda
[UPDATED PATCH] SGIWD93: use cached memory access to make driver work on IP28
SGI IP28 machines would need special treatment (enable adding addtional
wait states) when accessing memory uncached. To avoid this pain I
changed the driver to use only cached access to memory.
Signed-off-by: Thomas Bogendoerfer <[EMAIL PROTECTED]>
---
Changes to last version:
- added Kconfig change to make selection for similair SGI boxes easier
drivers/scsi/Kconfig |2 +-
drivers/scsi/sgiwd93.c | 64 +--
2 files changed, 40 insertions(+), 26 deletions(-)
diff --git a/drivers/scsi/Kconfig b/drivers/scsi/Kconfig
index a6676be..2a071b0 100644
--- a/drivers/scsi/Kconfig
+++ b/drivers/scsi/Kconfig
@@ -345,7 +345,7 @@ config ISCSI_TCP
config SGIWD93_SCSI
tristate "SGI WD93C93 SCSI Driver"
- depends on SGI_IP22 && SCSI
+ depends on SGI_HAS_WD93 && SCSI
help
If you have a Western Digital WD93 SCSI controller on
an SGI MIPS system, say Y. Otherwise, say N.
diff --git a/drivers/scsi/sgiwd93.c b/drivers/scsi/sgiwd93.c
index eef8275..e64ddee 100644
--- a/drivers/scsi/sgiwd93.c
+++ b/drivers/scsi/sgiwd93.c
@@ -33,10 +33,9 @@
struct ip22_hostdata {
struct WD33C93_hostdata wh;
- struct hpc_data {
- dma_addr_t dma;
- void*cpu;
- } hd;
+ dma_addr_t dma;
+ void *cpu;
+ void *dev;
};
#define host_to_hostdata(host) ((struct ip22_hostdata *)((host)->hostdata))
@@ -46,6 +45,11 @@ struct hpc_chunk {
u32 _padding; /* align to quadword boundary */
};
+/* space for hpc dma descriptors */
+#define HPC_DMA_SIZE PAGE_SIZE
+
+#define DMA_DIR(d) ((d == DATA_OUT_DIR) ? DMA_TO_DEVICE : DMA_FROM_DEVICE)
+
static irqreturn_t sgiwd93_intr(int irq, void *dev_id)
{
struct Scsi_Host * host = dev_id;
@@ -59,15 +63,17 @@ static irqreturn_t sgiwd93_intr(int irq, void *dev_id)
}
static inline
-void fill_hpc_entries(struct hpc_chunk *hcp, struct scsi_cmnd *cmd, int
datainp)
+void fill_hpc_entries(struct ip22_hostdata *hd, struct scsi_cmnd *cmd, int din)
{
unsigned long len = cmd->SCp.this_residual;
void *addr = cmd->SCp.ptr;
dma_addr_t physaddr;
unsigned long count;
+ struct hpc_chunk *hcp;
- physaddr = dma_map_single(NULL, addr, len, cmd->sc_data_direction);
+ physaddr = dma_map_single(hd->dev, addr, len, DMA_DIR(din));
cmd->SCp.dma_handle = physaddr;
+ hcp = hd->cpu;
while (len) {
/*
@@ -89,6 +95,9 @@ void fill_hpc_entries(struct hpc_chunk *hcp, struct scsi_cmnd
*cmd, int datainp)
*/
hcp->desc.pbuf = 0;
hcp->desc.cntinfo = HPCDMA_EOX;
+ dma_cache_sync(hd->dev, hd->cpu,
+ (unsigned long)(hcp + 1) - (unsigned long)hd->cpu,
+ DMA_TO_DEVICE);
}
static int dma_setup(struct scsi_cmnd *cmd, int datainp)
@@ -96,9 +105,8 @@ static int dma_setup(struct scsi_cmnd *cmd, int datainp)
struct ip22_hostdata *hdata = host_to_hostdata(cmd->device->host);
struct hpc3_scsiregs *hregs =
(struct hpc3_scsiregs *) cmd->device->host->base;
- struct hpc_chunk *hcp = (struct hpc_chunk *) hdata->hd.cpu;
- pr_debug("dma_setup: datainp<%d> hcp<%p> ", datainp, hcp);
+ pr_debug("dma_setup: datainp<%d> hcp<%p> ", datainp, hdata->cpu);
hdata->wh.dma_dir = datainp;
@@ -111,12 +119,12 @@ static int dma_setup(struct scsi_cmnd *cmd, int datainp)
if (cmd->SCp.ptr == NULL || cmd->SCp.this_residual == 0)
return 1;
- fill_hpc_entries(hcp, cmd, datainp);
+ fill_hpc_entries(hdata, cmd, datainp);
pr_debug(" HPCGO\n");
/* Start up the HPC. */
- hregs->ndptr = hdata->hd.dma;
+ hregs->ndptr = hdata->dma;
if (datainp)
hregs->ctrl = HPC3_SCTRL_ACTIVE;
else
@@ -134,6 +142,9 @@ static void dma_stop(struct Scsi_Host *instance, struct
scsi_cmnd *SCpnt,
if (!SCpnt)
return;
+ if (SCpnt->SCp.ptr == NULL || SCpnt->SCp.this_residual == 0)
+ return;
+
hregs = (struct hpc3_scsiregs *) SCpnt->device->host->base;
pr_debug("dma_stop: status<%d> ", status);
@@ -145,8 +156,9 @@ static void dma_stop(struct Scsi_Host *instance, struct
scsi_cmnd *SCpnt,
barrier();
}
hregs->ctrl = 0;
- dma_unmap_single(NULL, SCpnt->SCp.dma_handle, SCpnt->SCp.this_residual,
-SCpnt->sc_data_direction);
+ dma_unmap_single(hdata->dev, SCpnt->SCp.dma_handle,
+SCpnt->SCp.this_residual,
+DMA_DIR(hdata->wh.dma_dir));
pr_debug("\n");
}
@@ -160,22 +172,23 @@ void sgiwd93_reset(unsigned long base)
hregs->ctrl = 0;
}
-static inline void init_hpc_chain(struct hpc_data *hd)
+static inline void init_hpc_chain(void *dev, struct ip22_hostdata *hdata)
{
- struct hpc_chunk *hc
Scsi error : device overrun on Adaptec AIC-7902B
Hi, I am experiencing odd error messages on a server and can't sort out if it is a software or hardware problem. Server is running linux 2.6.22 kernel from Ubuntu server distro (2.6.22-14-server) on a bi-AMD64 Opteron machine. The SCSI board is listed as follows by lspci : 0a:07.0 SCSI storage controller: Adaptec AIC-7902B U320 (rev 10) Subsystem: Adaptec Unknown device 005e Flags: bus master, 66MHz, slow devsel, latency 72, IRQ 28 I/O ports at 3400 [disabled] [size=256] Memory at df30 (64-bit, non-prefetchable) [size=8K] I/O ports at 3000 [disabled] [size=256] [virtual] Expansion ROM at c210 [disabled] [size=512K] Capabilities: [dc] Power Management version 2 Capabilities: [a0] Message Signalled Interrupts: Mask- 64bit+ Queue=0/1 Enable- Capabilities: [94] PCI-X non-bridge device 0a:07.1 SCSI storage controller: Adaptec AIC-7902B U320 (rev 10) Subsystem: Adaptec Unknown device 005e Flags: bus master, 66MHz, slow devsel, latency 72, IRQ 29 I/O ports at 3c00 [disabled] [size=256] Memory at df302000 (64-bit, non-prefetchable) [size=8K] I/O ports at 3800 [disabled] [size=256] [virtual] Expansion ROM at c218 [disabled] [size=512K] Capabilities: [dc] Power Management version 2 Capabilities: [a0] Message Signalled Interrupts: Mask- 64bit+ Queue=0/1 Enable- Capabilities: [94] PCI-X non-bridge device First SCSI chain has 4 Ultra320 harddrives, and second one (scsi5) has 4 Ultra320 harddrives and a 160 tape reader. Regularely, we have a bunch of such errors in /var/log/messages (every 10 minutes or so, when the machine is active, plus a detailed card dump) : Jan 24 12:20:37 pariou kernel: [64896.014316] scsi5: Transmission error detected Jan 24 12:20:37 pariou kernel: [64896.014347] scsi5: Dumping Card State at program address 0x257 Mode 0x0 Jan 24 12:20:37 pariou kernel: [64896.014651] scsi5: FIFO0 Active, LONGJMP == 0x252, SCB 0x7b Jan 24 12:20:37 pariou kernel: [64896.014722] scsi5: FIFO1 Free, LONGJMP == 0x81f7, SCB 0x62 Jan 24 12:20:37 pariou kernel: [64896.014808] scsi5: LQISTATE = 0x2b, LQOSTATE = 0x0, OPTIONMODE = 0x52 Jan 24 12:20:37 pariou kernel: [64896.014812] scsi5: OS_SPACE_CNT = 0x20 MAXCMDCNT = 0x1 Jan 24 12:20:37 pariou kernel: [64896.014815] scsi5: SAVED_SCSIID = 0x0 SAVED_LUN = 0x0 Jan 24 12:20:37 pariou kernel: [64896.014834] scsi5: REG0 == 0x7d60, SINDEX = 0x158, DINDEX = 0x10a Jan 24 12:20:37 pariou kernel: [64896.014842] scsi5: SCBPTR == 0x7b, SCB_NEXT == 0xff00, SCB_NEXT2 == 0x79 Jan 24 12:20:37 pariou kernel: [64896.015374] scsi5: Returning to Idle Loop Jan 24 12:20:37 pariou kernel: [64896.015438] scsi5: device overrun (status a) on 0:3:0 Smartctl on /dev/sdj (scsi5 0:3:0) says : smartctl version 5.37 [x86_64-unknown-linux-gnu] Copyright (C) 2002-6 Bruce Allen Home page is http://smartmontools.sourceforge.net/ Device: HITACHI HUS151436VL3600 Version: S3C0 Serial number: J3WE8KLA Device type: disk Transport protocol: Parallel SCSI (SPI-4) Local Time is: Thu Jan 24 13:25:08 2008 CET Device supports SMART and is Enabled Temperature Warning Enabled SMART Health Status: OK Current Drive Temperature: 40 C Drive Trip Temperature:85 C Manufactured in week 08 of year 2006 Recommended maximum start stop count: 5 times Current start stop count: 105 times Elements in grown defect list: 0 Vendor (Seagate) cache information Blocks sent to initiator = 300818938986496 Error counter log: Errors Corrected by Total Correction GigabytesTotal ECC rereads/errors algorithm processeduncorrected fast | delayed rewrites corrected invocations [10^9 bytes] errors read: 11032593424 0110325956340.501 0 write: 328450 0 32845 0316.122 0 Non-medium error count:0 No self-tests have been logged Long (extended) Self Test duration: 607 seconds [10.1 minutes] But yesterday, we had a worse problem, where half our disks went offline, with the following log (one card dump for each of the four disks). SO, any tip on what might be going wrong ?? Thanks in advance, Franck [452353.991582] sd 5:0:1:0: [sdg] Attempting to queue an ABORT message:CDB: 0x0 0x0 0x0 0x0 0x0 0x0 [452353.992109] scsi5: At time of recovery, card was not paused [452353.992116] >> Dump Card State Begins < [452353.992118] scsi5: Dumping Card State at program address 0x6 Mode 0x33 [452353.992121] Card was paused [452353.992123] INTSTAT[0x0] SELOID[0x2] SELID[0x10] [452353.992132] HS_MAILBOX[0x0] INTCTL[0xc0]:(SWTMINTEN|SWTMINTMASK) [452353.992140] SEQINTSTAT[0x0] SAVED_MODE[0x0] [452353.992146] DFFSTAT[0x33]:(CURRFIFO_NONE|FIFO0FREE|FIFO1FREE) [452353.992153] SCSISIGI[0x0]:(P_DATAOUT) SCSIPHASE[0x0] [452353.992160] SCSIBUS[0x0] LASTPHASE[0x1]:(P_DATAOUT|P_BUSFR
[PATCH 1/2] destroy scsi_bidi_sdb_cache in scsi_exit_queue
This patchset is against the scsi-bidi tree.
=
From: FUJITA Tomonori <[EMAIL PROTECTED]>
Subject: [PATCH 1/2] destroy scsi_bidi_sdb_cache in scsi_exit_queue
Needs to call kmem_cache_destroy for scsi_bidi_sdb_cache in
scsi_exit_queue.
Signed-off-by: FUJITA Tomonori <[EMAIL PROTECTED]>
---
drivers/scsi/scsi_lib.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c
index e1c7eeb..7bfec7e 100644
--- a/drivers/scsi/scsi_lib.c
+++ b/drivers/scsi/scsi_lib.c
@@ -1712,6 +1712,7 @@ void scsi_exit_queue(void)
int i;
kmem_cache_destroy(scsi_io_context_cache);
+ kmem_cache_destroy(scsi_bidi_sdb_cache);
for (i = 0; i < SG_MEMPOOL_NR; i++) {
struct scsi_host_sg_pool *sgp = scsi_sg_pools + i;
--
1.5.3.4
-
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 2/2] handle scsi_init_queue failure properly
scsi_init_queue is expected to clean up allocated things when it
fails.
Signed-off-by: FUJITA Tomonori <[EMAIL PROTECTED]>
---
drivers/scsi/scsi_lib.c | 18 +-
1 files changed, 17 insertions(+), 1 deletions(-)
diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c
index 7bfec7e..b12fb31 100644
--- a/drivers/scsi/scsi_lib.c
+++ b/drivers/scsi/scsi_lib.c
@@ -1682,7 +1682,7 @@ int __init scsi_init_queue(void)
0, 0, NULL);
if (!scsi_bidi_sdb_cache) {
printk(KERN_ERR "SCSI: can't init scsi bidi sdb cache\n");
- return -ENOMEM;
+ goto cleanup_io_context;
}
for (i = 0; i < SG_MEMPOOL_NR; i++) {
@@ -1694,6 +1694,7 @@ int __init scsi_init_queue(void)
if (!sgp->slab) {
printk(KERN_ERR "SCSI: can't init sg slab %s\n",
sgp->name);
+ goto cleanup_bidi_sdb;
}
sgp->pool = mempool_create_slab_pool(SG_MEMPOOL_SIZE,
@@ -1701,10 +1702,25 @@ int __init scsi_init_queue(void)
if (!sgp->pool) {
printk(KERN_ERR "SCSI: can't init sg mempool %s\n",
sgp->name);
+ goto cleanup_bidi_sdb;
}
}
return 0;
+
+cleanup_bidi_sdb:
+ for (i = 0; i < SG_MEMPOOL_NR; i++) {
+ struct scsi_host_sg_pool *sgp = scsi_sg_pools + i;
+ if (sgp->pool)
+ mempool_destroy(sgp->pool);
+ if (sgp->slab)
+ kmem_cache_destroy(sgp->slab);
+ }
+ kmem_cache_destroy(scsi_bidi_sdb_cache);
+cleanup_io_context:
+ kmem_cache_destroy(scsi_io_context_cache);
+
+ return -ENOMEM;
}
void scsi_exit_queue(void)
--
1.5.3.4
-
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
