Re: [PATCH] sg: increase sglist_len of the sg_scatter_hold structure
On Wed, Aug 08 2007, FUJITA Tomonori wrote: > Now only scsi-ml is changed to allocate chaining sg list > properly. Others like cciss are not converted yet, I think. It might > make sense to have the standard block layer functions to allocate > chaining sg list properly. So we could convert to potential consumers > (scsi-ml, sg, ccisss, etc) use them though I'm not sure how many non > scsi-ml needs chaining sg list. The scsi chain table allocation/freeing could be made generic. The reason I didn't do that is - as you list - that probably not many non-scsi drivers need/want it. If they do, we can put that functionality in the block layer. The cciss hardware doesn't support more than 31 segments iirc. Newer firmwares can do chaining as well, but the linux driver doesn't actually support it. Once it does, we can add sg chaining support there too. -- Jens Axboe - 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: [PATCHSET 0/5] Peaceful co-existence of scsi_sgtable and Large IO sg-chaining
On Tue, Aug 07 2007, FUJITA Tomonori wrote:
> On Tue, 7 Aug 2007 08:55:49 +0200
> Jens Axboe <[EMAIL PROTECTED]> wrote:
>
> > On Mon, Aug 06 2007, FUJITA Tomonori wrote:
> > > On Tue, 31 Jul 2007 23:12:26 +0300
> > > Boaz Harrosh <[EMAIL PROTECTED]> wrote:
> > >
> > > > The tested Kernels:
> > > >
> > > > 1. Jens's sglist-arch
> > > > I was not able to pass all tests with this Kernel. For some reason
> > > > when
> > > > bigger than 256 pages commands are queued the Machine will run out
> > > > of memory and will kill the test. After the test is killed the system
> > > > is left with 10M of memory and can hardly reboot.
> > > > I have done some prints at the queuecommand entry in scsi_debug.c
> > > > and I can see that I receive the expected large sg_count and bufflen
> > > > but unlike other tests I get a different pointer at scsi_sglist().
> > > > In other tests since nothing is happening at this machine while in
> > > > the test, the sglist pointer is always the same. commands comes in,
> > > > allocates memory, do nothing in scsi_debug, freed, and returns.
> > > > I suspect sglist leak or allocation bug.
> > >
> > > Ok, I found the leak.
> > >
> > >
> > > From 011c05c2e514d1db4834147ed83526473711b0a3 Mon Sep 17 00:00:00 2001
> > > From: FUJITA Tomonori <[EMAIL PROTECTED]>
> > > Date: Mon, 6 Aug 2007 16:16:24 +0900
> > > Subject: [PATCH] fix sg chaining leak
> > >
> > > Signed-off-by: FUJITA Tomonori <[EMAIL PROTECTED]>
> > > ---
> > > drivers/scsi/scsi_lib.c |1 -
> > > 1 files changed, 0 insertions(+), 1 deletions(-)
> > >
> > > diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c
> > > index 5884b1b..25988b9 100644
> > > --- a/drivers/scsi/scsi_lib.c
> > > +++ b/drivers/scsi/scsi_lib.c
> > > @@ -48,7 +48,6 @@ static struct scsi_host_sg_pool scsi_sg_pools[] = {
> > > SP(32),
> > > SP(64),
> > > SP(128),
> > > - SP(256),
> > > };
> > > #undef SP
> >
> > Thanks Tomo! Trying to catch up with mails, will apply this one right
> > away.
>
> You can add the following patch to your sglist branches:
>
>
> From abd73c05d5f08ee307776150e1deecac7a709b60 Mon Sep 17 00:00:00 2001
> From: FUJITA Tomonori <[EMAIL PROTECTED]>
> Date: Mon, 30 Jul 2007 23:01:32 +0900
> Subject: [PATCH] zfcp: sg chaining support
Thanks, applied!
--
Jens Axboe
-
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 1/4] zfcp: fix memory leak
From: Heiko Carstens <[EMAIL PROTECTED]>
fix memory leak.
Signed-off-by: Heiko Carstens <[EMAIL PROTECTED]>
Signed-off-by: Martin Schwidefsky <[EMAIL PROTECTED]>
Signed-off-by: Swen Schillig <[EMAIL PROTECTED]>
---
drivers/s390/scsi/zfcp_scsi.c |4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff -urpN linux-2.6/drivers/s390/scsi/zfcp_scsi.c
linux-2.6-patched/drivers/s390/scsi/zfcp_scsi.c
--- linux-2.6/drivers/s390/scsi/zfcp_scsi.c 2007-07-09 01:32:17.0
+0200
+++ linux-2.6-patched/drivers/s390/scsi/zfcp_scsi.c 2007-08-08
10:14:01.0 +0200
@@ -764,7 +764,9 @@ zfcp_reset_fc_host_stats(struct Scsi_Hos
return;
ret = zfcp_fsf_exchange_port_data(NULL, adapter, data);
- if (ret == 0) {
+ if (ret) {
+ kfree(data);
+ } else {
adapter->stats_reset = jiffies/HZ;
old_data = adapter->stats_reset_data;
adapter->stats_reset_data = data; /* finally freed in
-
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/4] zfcp: allocate gid_pn_data objects from gid_pn_cache
From: Heiko Carstens <[EMAIL PROTECTED]>
allocate gid_pn_data objects from gid_pn_cache.
Allocate gid_pn_data objects from the corresponding cache which ensures
proper alignment.
Signed-off-by: Heiko Carstens <[EMAIL PROTECTED]>
Signed-off-by: Martin Schwidefsky <[EMAIL PROTECTED]>
Signed-off-by: Swen Schillig <[EMAIL PROTECTED]>
---
drivers/s390/scsi/zfcp_aux.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff -urpN linux-2.6/drivers/s390/scsi/zfcp_aux.c
linux-2.6-patched/drivers/s390/scsi/zfcp_aux.c
--- linux-2.6/drivers/s390/scsi/zfcp_aux.c 2007-08-08 10:13:39.0
+0200
+++ linux-2.6-patched/drivers/s390/scsi/zfcp_aux.c 2007-08-08
10:14:02.0 +0200
@@ -1503,7 +1503,7 @@ zfcp_gid_pn_buffers_alloc(struct zfcp_gi
data->ct.pool = pool;
}
} else {
- data = kmalloc(sizeof(struct zfcp_gid_pn_data), GFP_ATOMIC);
+ data = kmem_cache_alloc(zfcp_data.gid_pn_cache, GFP_ATOMIC);
}
if (NULL == data)
@@ -1531,7 +1531,7 @@ static void zfcp_gid_pn_buffers_free(str
if (gid_pn->ct.pool)
mempool_free(gid_pn, gid_pn->ct.pool);
else
- kfree(gid_pn);
+ kmem_cache_free(zfcp_data.gid_pn_cache, gid_pn);
}
/**
-
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 3/4] zfcp: Avoid race condition on "link up" event
From: Christoph Schmitt <[EMAIL PROTECTED]>
Symptom: zfcp receives a response to a "status read" request
that is no longer valid in zfcp. This leads to a
kernel panic, since some memory has been overwritten
by the response reporting.
Problem: On receiving an "unsolicited status", zfcp issues a
new "status read" request. On receiving the
"unsolicited status" "link up", zfcp triggers an adapter
reopen. The new "status read" request and the reopen
can lead to a race where zfcp issues the request before
the reopen, but the hardware handles the reopen first.
Solution:Not issue the "status read" request to avoid the race
condition. The adapter reopen will enqueue 16 new
"status read" requests anyway.
Signed-off-by: Christoph Schmitt <[EMAIL PROTECTED]>
Signed-off-by: Martin Schwidefsky <[EMAIL PROTECTED]>
Signed-off-by: Swen Schillig <[EMAIL PROTECTED]>
---
drivers/s390/scsi/zfcp_fsf.c | 19 +--
1 file changed, 13 insertions(+), 6 deletions(-)
diff -urpN linux-2.6/drivers/s390/scsi/zfcp_fsf.c
linux-2.6-patched/drivers/s390/scsi/zfcp_fsf.c
--- linux-2.6/drivers/s390/scsi/zfcp_fsf.c 2007-08-08 10:13:39.0
+0200
+++ linux-2.6-patched/drivers/s390/scsi/zfcp_fsf.c 2007-08-08
10:14:03.0 +0200
@@ -33,7 +33,7 @@ static int zfcp_fsf_send_fcp_command_tas
static int zfcp_fsf_send_fcp_command_task_management_handler(
struct zfcp_fsf_req *);
static int zfcp_fsf_abort_fcp_command_handler(struct zfcp_fsf_req *);
-static int zfcp_fsf_status_read_handler(struct zfcp_fsf_req *);
+static void zfcp_fsf_status_read_handler(struct zfcp_fsf_req *);
static int zfcp_fsf_send_ct_handler(struct zfcp_fsf_req *);
static int zfcp_fsf_send_els_handler(struct zfcp_fsf_req *);
static int zfcp_fsf_control_file_handler(struct zfcp_fsf_req *);
@@ -856,10 +856,10 @@ zfcp_fsf_status_read_port_closed(struct
*
* returns:
*/
-static int
+static void
zfcp_fsf_status_read_handler(struct zfcp_fsf_req *fsf_req)
{
- int retval = 0;
+ int retval;
struct zfcp_adapter *adapter = fsf_req->adapter;
struct fsf_status_read_buffer *status_buffer =
(struct fsf_status_read_buffer *) fsf_req->data;
@@ -869,7 +869,7 @@ zfcp_fsf_status_read_handler(struct zfcp
zfcp_hba_dbf_event_fsf_unsol("dism", adapter, status_buffer);
mempool_free(status_buffer, adapter->pool.data_status_read);
zfcp_fsf_req_free(fsf_req);
- goto out;
+ return;
}
zfcp_hba_dbf_event_fsf_unsol("read", adapter, status_buffer);
@@ -1061,6 +1061,15 @@ zfcp_fsf_status_read_handler(struct zfcp
* FIXME:
* allocation failure possible? (Is this code needed?)
*/
+ /*
+* If we triggered an adapter reopen, then the reopen will also
+* enqueue new status read requests. Not issuing a status read
+* here avoids a race between the request send and the adapter
+* reopen.
+*/
+ if (status_buffer->status_type == FSF_STATUS_READ_LINK_UP)
+ return;
+
retval = zfcp_fsf_status_read(adapter, 0);
if (retval < 0) {
ZFCP_LOG_INFO("Failed to create unsolicited status read "
@@ -1076,8 +1085,6 @@ zfcp_fsf_status_read_handler(struct zfcp
zfcp_erp_adapter_reopen(adapter, 0);
}
}
- out:
- return retval;
}
/*
-
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 4/4] zfcp: fix the data buffer accessor patch
From: Heiko Carstens <[EMAIL PROTECTED]>
Fix the data buffer accessor patch.
For request without a data buffer nothing was written into
a SBALE.
Signed-off-by: Heiko Carstens <[EMAIL PROTECTED]>
Signed-off-by: Swen Schillig <[EMAIL PROTECTED]>
---
drivers/s390/scsi/zfcp_qdio.c | 10 +++---
1 file changed, 3 insertions(+), 7 deletions(-)
Index: linux_jb/drivers/s390/scsi/zfcp_qdio.c
===
--- linux_jb.orig/drivers/s390/scsi/zfcp_qdio.c
+++ linux_jb/drivers/s390/scsi/zfcp_qdio.c
@@ -640,13 +640,9 @@ int
zfcp_qdio_sbals_from_scsicmnd(struct zfcp_fsf_req *fsf_req,
unsigned long sbtype, struct scsi_cmnd *scsi_cmnd)
{
- if (scsi_sg_count(scsi_cmnd))
- return zfcp_qdio_sbals_from_sg(fsf_req, sbtype,
- scsi_sglist(scsi_cmnd),
- scsi_sg_count(scsi_cmnd),
- ZFCP_MAX_SBALS_PER_REQ);
- else
- return 0;
+ return zfcp_qdio_sbals_from_sg(fsf_req, sbtype, scsi_sglist(scsi_cmnd),
+ scsi_sg_count(scsi_cmnd),
+ ZFCP_MAX_SBALS_PER_REQ);
}
/**
-
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] Quieten down sg warnings with cdparanoia
Quieten down sg warnings
When using cdparanoia on SUSE 10.2 I get thousands of warnings.
While I'm sure the warning is something important that I just miss quieten it
down a bit to report only once for a program.
Signed-off-by: Andi Kleen <[EMAIL PROTECTED]>
Index: linux-2.6.23-rc1-misc/drivers/scsi/sg.c
===
--- linux-2.6.23-rc1-misc.orig/drivers/scsi/sg.c
+++ linux-2.6.23-rc1-misc/drivers/scsi/sg.c
@@ -605,8 +605,9 @@ sg_write(struct file *filp, const char _
* but is is possible that the app intended SG_DXFER_TO_DEV, because
there
* is a non-zero input_size, so emit a warning.
*/
- if (hp->dxfer_direction == SG_DXFER_TO_FROM_DEV)
- if (printk_ratelimit())
+ if (hp->dxfer_direction == SG_DXFER_TO_FROM_DEV) {
+ static char comm[sizeof(((struct task_struct *)0)->comm)];
+ if (printk_ratelimit() && strcmp(current->comm, comm)) {
printk(KERN_WARNING
"sg_write: data in/out %d/%d bytes for SCSI
command 0x%x--"
"guessing data in;\n" KERN_WARNING " "
@@ -614,6 +615,9 @@ sg_write(struct file *filp, const char _
old_hdr.reply_len - (int)SZ_SG_HEADER,
input_size, (unsigned int) cmnd[0],
current->comm);
+ strcpy(comm, current->comm);
+ }
+ }
k = sg_common_write(sfp, srp, cmnd, sfp->timeout, blocking);
return (k < 0) ? k : count;
}
-
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] move ULD attachment into the prep function
On Tue, 2007-08-07 at 18:01 +0300, Boaz Harrosh wrote: > James Bottomley wrote: > > One of the intents of the block prep function was to allow ULDs to use > > it for preprocessing. The original SCSI model was to have a single prep > > function and add a pointer indirect filter to build the necessary > > commands. This patch reverses that, does away with the init_command > > field of the scsi_driver structure and makes ULDs attach directly to the > > prep function instead. The value is really that it allows us to begin > > to separate the ULDs from the SCSI mid layer (as long as they don't use > > any core functions---which is hard at the moment---a ULD doesn't even > > need SCSI to bind). > > > > James > > > > Index: BUILD-2.6/drivers/scsi/scsi_lib.c > > It turns out this patch is dependent on previous > sd: disentangle barriers in SCSI (02) > > and that one is dependent on the previous-previous one: > block: add protocol discriminators to requests and queues. (01) > > but the middle one (02) does not apply it looks like there is a missing > hunk for scsi_lib.c in the first (01) > > > @@ -1596,7 +1580,6 @@ struct request_queue *scsi_alloc_queue(s > return NULL; > > blk_queue_prep_rq(q, scsi_prep_fn); > - blk_queue_issue_flush_fn(q, scsi_issue_flush_fn); > blk_queue_softirq_done(q, scsi_softirq_done); > blk_queue_protocol(q, BLK_PROTOCOL_SCSI); > return q; > > > The before last sync line: > blk_queue_protocol(q, BLK_PROTOCOL_SCSI); > is missing from (01). Any thing else I need? > > So I guess my first complain is that these should have been > a series to denote dependency. Also I think an email with > deeper explanation of where you are going with these, and > what is the motivation could be nice. Sorry they're just random dumps from my current quilt set done under the release early release often philosophy. > Apart from that: > > Ouch! ;) That patch hurts. > > What is the time frame for these changes are they for immediate > inclusion into scsi-misc and into 2.6.24 merge window? Before > scsi_data_buff, sglist, bidi, Mike's execute_async_cleanup ... ? When it's reasonably stable and mature ... like all the rest of the various patch sets. > I do not like this patch. I think that if your motivation was > to make sd/sr and other ULD's more independent of scsi-ml than > you achieved the opposite. I don't think a SCSI ULD is ever going to be independent of the SCSI mid layer. However, the point is that complex subsystems like libata need the same ULD attachment mechanics as SCSI. The idea is to demonstrate how this can be done independently of SCSI. One of the ultimate goals would be to be able to write a pure ATA disk driver as an ULD attachment that spoke only taskfiles and had no SCSI dependency at all ... feeding straight into the libata queuing function. The key requirement is to make the attachment mechanism independent of SCSI. > 5 exported functions and intimate > knowledge of scsi_lib internals. Lots of same cut and past code > in ULD's. Interdependence of scsi_lib.c with it's ULD's. Will > make it hard for scsi_lib to change without touching ULD's. > (And there are lots of scheduled changes :-)) The object isn't to reduce the points of contact, although conversely, it's not the object to increase them either. Realistically, even if libata gets separated from SCSI, it will still need sr and st to run the ATAPI devices. What we will need to do then is split out a command handler from the rest of the SCSI mid layer, so sr and st can pull in a single libscsi (or something) module and be directly attached to the ata stack. > What about below approach? > What I tried to do is keep scsi_lib private, export a more > simple API for ULD's. And keep common code common. > The code was compiled and booted but I did not do any error > injection and/or low memory condition testing. All you really did was go the other way on an issue I struggled with: how to process REQ_BLOCK_PC. Realistically, either approach is fine ... and probably neither will survive the final separation of libscsi from the mid layer. 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] sg: increase sglist_len of the sg_scatter_hold structure
FUJITA Tomonori wrote: On Tue, 07 Aug 2007 12:13:41 -0500 Mike Christie <[EMAIL PROTECTED]> wrote: FUJITA Tomonori wrote: Allocating 64K contiguous memory is not good so the next thing to do is converting sg to use the sg chaining support fully. Or it might be For LLDs like aic7xxx, I think we are stuck with a small scsi_host_template->sg_tablesize, so to continue to get large requests like before will we have to still allocate large segments? No. sg.c has: sizeof(struct scatterlist) * min(q->max_hw_segments, q->max_phys_segments) If a lld has small max_hw_segments, it doesn't allocate big contiguous memory. Are we talking about the same thing? Are you saying that it does not allocate big continuous memory for the scatterlist right? I was asking about continuous memory for the buffer sg.c copies data to/from for the IO operation. I was saying that currently for something like aic if we want to continue to support 8 MB commands (or whatever it was) like before, then because its sg_tablesize/max_hw_segments is so small we have to continue allocating large IO buffers. That did not change right? If so let me know because you save me :) Is block/scsi_ioctl.c converted to sg chaining in any tree yet? Is that in your tree or one of Jen's branches. block/scsi_ioctl.c uses the standard block layer functions, there is nothing to convert in it. sglist doesn't change the standard block layer functions much since it doesn't allocate sg list. It changes only blk_rq_map_sg. Now only scsi-ml is changed to allocate chaining sg list properly. Others like cciss are not converted yet, I think. It might make sense to have the standard block layer functions to allocate chaining sg list properly. So we could convert to potential consumers (scsi-ml, sg, ccisss, etc) use them though I'm not sure how many non scsi-ml needs chaining sg list. For drivers like sg and st, do mean the the sg list that is passed to functions like scsi_execute_async? If we kill that argument, and instead have sg.c and other scsi_execute_async callers just call blk helpers like blk_rq_map_user then we would not have to worry about drivers like sg needing to know about chaining right? I mean sg.c would not every interact with a scatterlist. It would just interact with a request and the blk helpers map data for it. The scatterlist that sg and st interact with is bogus. It gets thrown away in scsi_execute_async and is only used for book keeping. I think it would be best to either have drivers like sg and st use blk_rq helpers to map data to requests like in my patches (this way they never know about scatterlists), or have sg and st allocate and setup a scatterlist properly and then just attach that to the request like we did before (we would have to add back in those checks to scsi-ml to check for that case again for this latter idea). cciss is different right since it is doing blk_rq_map_sg and that itself. I am not getting into that :) - 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: [3/3] 2.6.23-rc2: known regressions v2
Hi all, Here is a list of some known regressions in 2.6.23-rc2. Feel free to add new regressions/remove fixed etc. http://kernelnewbies.org/known_regressions List of Aces NameRegressions fixed since 21-Jun-2007 Adrian Bunk6 Andi Kleen 4 Andrew Morton 4 Linus Torvalds 4 Al Viro3 Cornelia Huck 3 Jens Axboe 3 Tejun Heo 3 David Woodhouse2 Hugh Dickins 2 Peter Zijlstra 2 Trent Piepho 2 Power management Subject : Kconfig: 'SUSPEND_SMP' refers to undefined symbol 'HOTPLUG_CPU' References : http://lkml.org/lkml/2007/8/4/39 Last known good : ? Submitter : Meelis Roos <[EMAIL PROTECTED]> Caused-By : ? Handled-By : Rafael J. Wysocki <[EMAIL PROTECTED]> Status : unknown SCSI Subject : unable to handle kernel NULL pointer dereference in qla2x00_read_nvram_data References : http://lkml.org/lkml/2007/8/6/506 Last known good : ? Submitter : Zhang, Yanmin <[EMAIL PROTECTED]> Caused-By : ? Handled-By : ? Status : unknown USB Subject : 2.6.23-rc1: uhci_hcd. irq 4: nobody cared References : http://lkml.org/lkml/2007/7/29/75 Last known good : ? Submitter : Mark Hindley <[EMAIL PROTECTED]> Caused-By : ? Handled-By : Alan Stern <[EMAIL PROTECTED]> Status : unknown Subject : 2.6.23-rc1: USB hard disk broken References : http://lkml.org/lkml/2007/7/25/62 Last known good : ? Submitter : Tino Keitel <[EMAIL PROTECTED]> Caused-By : ? Handled-By : Oliver Neukum <[EMAIL PROTECTED]> Status : unknown Alpha Subject : -Werror compilation problem - make[1]: *** [arch/alpha/kernel/sys_titan.o] Error 1 References : http://lkml.org/lkml/2007/8/6/137 Last known good : ? Submitter : Oliver Falk <[EMAIL PROTECTED]> Caused-By : ? Handled-By : ? Status : unknown Regards, Michal -- LOG http://www.stardust.webpages.pl/log/ - 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] sg: increase sglist_len of the sg_scatter_hold structure
Mike Christie wrote: For drivers like sg and st, do mean the the sg list that is passed to functions like scsi_execute_async? If we kill that argument, and instead have sg.c and other scsi_execute_async callers just call blk helpers like blk_rq_map_user then we would not have to worry about drivers like sg needing to know about chaining right? I mean sg.c would not every interact with a scatterlist. It would just interact with a request and the blk helpers map data for it. There should be a return there. The scatterlist that sg and st interact with is bogus. It gets thrown away in scsi_execute_async and is only used for book keeping. I mean currently the scatterlist that sg and st use is bogus and gets thrown away. If we convert sg and st to use blk_rq_map_user then those drivers will not have to interact with a scatterlist at all. - 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: Mptlinux crashes on kernel 2.6.22.1
On 2007-08-02 14:16:49, Hommel, Thomas wrote:
> I am trying to use a LSI53C1020 based adapter on a PowerPC board with
> MPC8641D processor. When initializing, the driver crashes the system
> with the error message below. Kernel version is 2.6.22.1, driver
> 3.04.04. The chip on the adapter is a 53C1020, but the driver detects a
> 53C1030. Has anyone experienced similar problems already?
Try this patch out. It appears that when loading the driver, your getting a
timeout when requesting a firmware config page. The timeout results in a
diag_reset of the controller, and all the ioc_reset callbacks are called for
every registered driver. When mptspi_ioc_reset is called, the hd object has
not be initialized. The fix is to return when hd is NULL. This object will
be setup once mptspi_probe has completed calling scsi_host_alloc.
Signed-off-by: Eric Moore <[EMAIL PROTECTED]>
diff -uarpN b/drivers/message/fusion/mptspi.c a/drivers/message/fusion/mptspi.c
--- b/drivers/message/fusion/mptspi.c 2007-08-08 11:41:02.0 -0600
+++ a/drivers/message/fusion/mptspi.c 2007-08-08 11:59:56.0 -0600
@@ -1249,14 +1249,20 @@ mptspi_dv_renegotiate(struct _MPT_SCSI_H
static int
mptspi_ioc_reset(MPT_ADAPTER *ioc, int reset_phase)
{
- struct _MPT_SCSI_HOST *hd = (struct _MPT_SCSI_HOST *)ioc->sh->hostdata;
+ struct _MPT_SCSI_HOST *hd = NULL;
int rc;
rc = mptscsih_ioc_reset(ioc, reset_phase);
+ if ((ioc->bus_type != SPI) || (!rc))
+ goto out;
- if (reset_phase == MPT_IOC_POST_RESET)
- mptspi_dv_renegotiate(hd);
+ hd = (MPT_SCSI_HOST *)ioc->sh->hostdata;
+ if (!hd || !hd->ioc)
+ goto out;
+ if (ioc->active && reset_phase == MPT_IOC_POST_RESET)
+ mptspi_dv_renegotiate(hd);
+ out:
return rc;
}
-
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 0/4] Updated AN patches, now without gendisk
Hello, Here is an updated set of patches that implement Asynchronous Notification support for ATAPI devices. In this version I no longer export the AN capability through genhd, and the uevent is sent by the scsi_device instead of gendisk. I added a generic SCSI device event mechanism so that it can be expanded in the future with other types of events. Please let me know what you think. Kristen -- - 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 1/4] libata: check for AN support
Check to see if an ATAPI device supports Asynchronous Notification.
If so, enable it.
Signed-off-by: Kristen Carlson Accardi <[EMAIL PROTECTED]>
Index: 2.6-git/drivers/ata/libata-core.c
===
--- 2.6-git.orig/drivers/ata/libata-core.c
+++ 2.6-git/drivers/ata/libata-core.c
@@ -70,6 +70,7 @@ const unsigned long sata_deb_timing_long
static unsigned int ata_dev_init_params(struct ata_device *dev,
u16 heads, u16 sectors);
static unsigned int ata_dev_set_xfermode(struct ata_device *dev);
+static unsigned int ata_dev_set_AN(struct ata_device *dev, u8 enable);
static void ata_dev_xfermask(struct ata_device *dev);
static unsigned long ata_dev_blacklisted(const struct ata_device *dev);
@@ -1974,6 +1975,22 @@ int ata_dev_configure(struct ata_device
}
dev->cdb_len = (unsigned int) rc;
+ /*
+* check to see if this ATAPI device supports
+* Asynchronous Notification
+*/
+ if ((ap->flags & ATA_FLAG_AN) && ata_id_has_AN(id)) {
+ int err;
+ /* issue SET feature command to turn this on */
+ err = ata_dev_set_AN(dev, SETFEATURES_SATA_ENABLE);
+ if (err)
+ ata_dev_printk(dev, KERN_ERR,
+ "unable to set AN, err %x\n",
+ err);
+ else
+ dev->flags |= ATA_DFLAG_AN;
+ }
+
if (ata_id_cdb_intr(dev->id)) {
dev->flags |= ATA_DFLAG_CDB_INTR;
cdb_intr_string = ", CDB intr";
@@ -3948,6 +3965,42 @@ static unsigned int ata_dev_set_xfermode
}
/**
+ * ata_dev_set_AN - Issue SET FEATURES - SATA FEATURES
+ * @dev: Device to which command will be sent
+ * @enable: Whether to enable or disable the feature
+ *
+ * Issue SET FEATURES - SATA FEATURES command to device @dev
+ * on port @ap with sector count set to indicate Asynchronous
+ * Notification feature
+ *
+ * LOCKING:
+ * PCI/etc. bus probe sem.
+ *
+ * RETURNS:
+ * 0 on success, AC_ERR_* mask otherwise.
+ */
+static unsigned int ata_dev_set_AN(struct ata_device *dev, u8 enable)
+{
+ struct ata_taskfile tf;
+ unsigned int err_mask;
+
+ /* set up set-features taskfile */
+ DPRINTK("set features - SATA features\n");
+
+ ata_tf_init(dev, &tf);
+ tf.command = ATA_CMD_SET_FEATURES;
+ tf.feature = enable;
+ tf.flags |= ATA_TFLAG_ISADDR | ATA_TFLAG_DEVICE;
+ tf.protocol = ATA_PROT_NODATA;
+ tf.nsect = SATA_AN;
+
+ err_mask = ata_exec_internal(dev, &tf, NULL, DMA_NONE, NULL, 0);
+
+ DPRINTK("EXIT, err_mask=%x\n", err_mask);
+ return err_mask;
+}
+
+/**
* ata_dev_init_params - Issue INIT DEV PARAMS command
* @dev: Device to which command will be sent
* @heads: Number of heads (taskfile parameter)
Index: 2.6-git/include/linux/ata.h
===
--- 2.6-git.orig/include/linux/ata.h
+++ 2.6-git/include/linux/ata.h
@@ -217,6 +217,12 @@ enum {
SETFEATURES_SPINUP = 0x07, /* Spin-up drive */
+ SETFEATURES_SATA_ENABLE = 0x10, /* Enable use of SATA feature */
+ SETFEATURES_SATA_DISABLE = 0x90, /* Disable use of SATA feature */
+
+ /* SETFEATURE Sector counts for SATA features */
+ SATA_AN = 0x05, /* Asynchronous Notification */
+
/* ATAPI stuff */
ATAPI_PKT_DMA = (1 << 0),
ATAPI_DMADIR= (1 << 2), /* ATAPI data dir:
@@ -344,6 +350,9 @@ struct ata_taskfile {
#define ata_id_queue_depth(id) (((id)[75] & 0x1f) + 1)
#define ata_id_removeable(id) ((id)[0] & (1 << 7))
#define ata_id_has_dword_io(id)((id)[50] & (1 << 0))
+#define ata_id_has_AN(id) \
+ ( (((id)[76] != 0x) && ((id)[76] != 0x)) && \
+ ((id)[78] & (1 << 5)) )
#define ata_id_iordy_disable(id) ((id)[49] & (1 << 10))
#define ata_id_has_iordy(id) ((id)[49] & (1 << 9))
#define ata_id_u32(id,n) \
Index: 2.6-git/include/linux/libata.h
===
--- 2.6-git.orig/include/linux/libata.h
+++ 2.6-git/include/linux/libata.h
@@ -139,7 +139,8 @@ enum {
ATA_DFLAG_FLUSH_EXT = (1 << 4), /* do FLUSH_EXT instead of FLUSH */
ATA_DFLAG_ACPI_PENDING = (1 << 5), /* ACPI resume action pending */
ATA_DFLAG_ACPI_FAILED = (1 << 6), /* ACPI on devcfg has failed */
- ATA_DFLAG_CFG_MASK = (1 << 8) - 1,
+ ATA_DFLAG_AN= (1 << 7), /* device supports AN */
+ ATA_DFLAG_CFG_MASK = (1 << 12) - 1,
ATA_DFLAG_PIO = (1 << 8), /* device limited to PIO mode
[patch 2/4] scsi: expose AN support to user space
If a scsi_device supports async notification for media change, then
let user space know this capability exists by creating a new sysfs
entry "media_change_notify", which will be 1 if it is supported, and
0 if not supported. Create a routine which allows scsi devices to
send a uevent when media change events occur.
Signed-off-by: Kristen Carlson Accardi <[EMAIL PROTECTED]>
Index: 2.6-git/include/scsi/scsi_device.h
===
--- 2.6-git.orig/include/scsi/scsi_device.h
+++ 2.6-git/include/scsi/scsi_device.h
@@ -46,6 +46,16 @@ enum scsi_device_state {
* to the scsi lld. */
};
+/* must match scsi_device_event_strings in scsi_lib.c */
+enum scsi_device_event {
+ SDEV_MEDIA_CHANGE = 1, /* media has changed */
+};
+
+struct scsi_device_event_info {
+ enum scsi_device_event event;
+ struct list_head link;
+};
+
struct scsi_device {
struct Scsi_Host *host;
struct request_queue *request_queue;
@@ -126,7 +136,7 @@ struct scsi_device {
unsigned fix_capacity:1;/* READ_CAPACITY is too high by 1 */
unsigned guess_capacity:1; /* READ_CAPACITY might be too high by 1
*/
unsigned retry_hwerror:1; /* Retry HARDWARE_ERROR */
-
+ unsigned media_change_notify:1; /* dev supports async media notify */
unsigned int device_blocked;/* Device returned QUEUE_FULL. */
unsigned int max_device_blocked; /* what device_blocked counts down
from */
@@ -144,6 +154,7 @@ struct scsi_device {
struct execute_work ew; /* used to get process context on put */
enum scsi_device_state sdev_state;
+ struct list_headsdev_event_list;
unsigned long sdev_data[0];
} __attribute__((aligned(sizeof(unsigned long;
#defineto_scsi_device(d) \
@@ -275,6 +286,8 @@ extern int scsi_test_unit_ready(struct s
int retries);
extern int scsi_device_set_state(struct scsi_device *sdev,
enum scsi_device_state state);
+extern int scsi_device_event_notify(struct scsi_device *sdev,
+ enum scsi_device_event event);
extern int scsi_device_quiesce(struct scsi_device *sdev);
extern void scsi_device_resume(struct scsi_device *sdev);
extern void scsi_target_quiesce(struct scsi_target *);
Index: 2.6-git/drivers/scsi/scsi_lib.c
===
--- 2.6-git.orig/drivers/scsi/scsi_lib.c
+++ 2.6-git/drivers/scsi/scsi_lib.c
@@ -64,6 +64,11 @@ static struct scsi_host_sg_pool scsi_sg_
};
#undef SP
+/* must match scsi_device_event enum in scsi_device.h */
+static char * scsi_device_event_strings[] = {
+ "MEDIA_CHANGE=1",
+};
+
static void scsi_run_queue(struct request_queue *q);
/*
@@ -2007,6 +2012,84 @@ scsi_device_set_state(struct scsi_device
EXPORT_SYMBOL(scsi_device_set_state);
/**
+ * scsi_device_set_event - Add a new Async event to the event list
+ * @sdev: scsi_device event occurred on
+ * @event: the scsi device event
+ *
+ * Add a new scsi_device_event_info struct to the scsi_device_event_list
+ * queue. This may be called from interrupt context.
+ *
+ * Returns 0 if successful, -ENOMEM otherwise.
+ */
+static int
+scsi_device_set_event(struct scsi_device *sdev, enum scsi_device_event event)
+{
+ struct scsi_device_event_info *scsi_event;
+ unsigned long flags;
+
+ scsi_event = kzalloc(sizeof(*scsi_event), GFP_ATOMIC);
+ if (!scsi_event)
+ return -ENOMEM;
+ INIT_LIST_HEAD(&scsi_event->link);
+ scsi_event->event = event;
+ spin_lock_irqsave(&sdev->list_lock, flags);
+ list_add_tail(&scsi_event->link, &sdev->sdev_event_list);
+ spin_unlock_irqrestore(&sdev->list_lock, flags);
+ return 0;
+}
+
+/**
+ * scsi_device_event_notify_thread - send a uevent for each scsi event
+ * @work: work struct for scsi_device
+ *
+ * Traverse the queue of scsi device events, dequeue each event and
+ * send a uevent. Frees event. May not be called from interrupt.
+ */
+static void scsi_event_notify_thread(struct work_struct *work)
+{
+ struct scsi_device *sdev;
+ char *envp[] = { NULL, NULL };
+ struct list_head *tmp;
+ struct list_head *next;
+ struct scsi_device_event_info *sdev_event;
+ unsigned long flags;
+
+ sdev = container_of(work, struct scsi_device, ew.work);
+ list_for_each_safe(tmp, next, &sdev->sdev_event_list) {
+ sdev_event = list_entry(tmp, struct scsi_device_event_info,
+ link);
+ spin_lock_irqsave(&sdev->list_lock, flags);
+ list_del(&sdev_event->link);
+ spin_unlock_irqrestore(&sdev->list_lock, flags);
+ envp[0] = scsi_device_event_strings[sdev_event->event-1];
+
[patch 3/4] libata: expose AN to user space
If Asynchronous Notification of media change events is supported,
pass that information up to the SCSI layer.
Signed-off-by: Kristen Carlson Accardi <[EMAIL PROTECTED]>
Index: 2.6-git/drivers/ata/libata-scsi.c
===
--- 2.6-git.orig/drivers/ata/libata-scsi.c
+++ 2.6-git/drivers/ata/libata-scsi.c
@@ -771,6 +771,9 @@ static void ata_scsi_dev_config(struct s
blk_queue_max_hw_segments(q, q->max_hw_segments - 1);
}
+ if (dev->flags & ATA_DFLAG_AN)
+ sdev->media_change_notify = 1;
+
if (dev->flags & ATA_DFLAG_NCQ) {
int depth;
--
-
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 4/4] libata: send event when AN received
When we get an SDB FIS with the 'N' bit set, we should send
an event to user space to indicate that there has been a
media change. This will be done via the scsi device.
Signed-off-by: Kristen Carlson Accardi <[EMAIL PROTECTED]>
Index: 2.6-git/drivers/ata/ahci.c
===
--- 2.6-git.orig/drivers/ata/ahci.c
+++ 2.6-git/drivers/ata/ahci.c
@@ -1359,6 +1359,28 @@ static void ahci_port_intr(struct ata_po
return;
}
+ if (status & PORT_IRQ_SDB_FIS) {
+ /*
+* if this is an ATAPI device with AN turned on,
+* then we should interrogate the device to
+* determine the cause of the interrupt
+*
+* for AN - this we should check the SDB FIS
+* and find the I and N bits set
+*/
+ const u32 *f = pp->rx_fis + RX_FIS_SDB;
+
+ /* check the 'N' bit in word 0 of the FIS */
+ if (f[0] & (1 << 15)) {
+ int port_addr = ((f[0] & 0x0f00) >> 8);
+ struct ata_device *adev;
+ if (port_addr < ATA_MAX_DEVICES) {
+ adev = &ap->device[port_addr];
+ if (adev->flags & ATA_DFLAG_AN)
+ ata_scsi_media_change_notify(adev);
+ }
+ }
+ }
if (ap->sactive)
qc_active = readl(port_mmio + PORT_SCR_ACT);
else
Index: 2.6-git/include/linux/libata.h
===
--- 2.6-git.orig/include/linux/libata.h
+++ 2.6-git/include/linux/libata.h
@@ -737,6 +737,7 @@ extern void ata_host_init(struct ata_hos
extern int ata_scsi_detect(struct scsi_host_template *sht);
extern int ata_scsi_ioctl(struct scsi_device *dev, int cmd, void __user *arg);
extern int ata_scsi_queuecmd(struct scsi_cmnd *cmd, void (*done)(struct
scsi_cmnd *));
+extern void ata_scsi_media_change_notify(struct ata_device *atadev);
extern void ata_sas_port_destroy(struct ata_port *);
extern struct ata_port *ata_sas_port_alloc(struct ata_host *,
struct ata_port_info *, struct
Scsi_Host *);
Index: 2.6-git/drivers/ata/libata-scsi.c
===
--- 2.6-git.orig/drivers/ata/libata-scsi.c
+++ 2.6-git/drivers/ata/libata-scsi.c
@@ -3099,6 +3099,22 @@ static void ata_scsi_remove_dev(struct a
}
/**
+ * ata_scsi_media_change_notify - send media change event
+ * @atadev: Pointer to the disk device with media change event
+ *
+ * Tell the block layer to send a media change notification
+ * event.
+ *
+ * LOCKING:
+ * interrupt context, may not sleep.
+ */
+void ata_scsi_media_change_notify(struct ata_device *atadev)
+{
+ scsi_device_event_notify(atadev->sdev, SDEV_MEDIA_CHANGE);
+}
+EXPORT_SYMBOL_GPL(ata_scsi_media_change_notify);
+
+/**
* ata_scsi_hotplug - SCSI part of hotplug
* @work: Pointer to ATA port to perform SCSI hotplug on
*
--
-
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/4] libata: check for AN support
On Wed, 8 Aug 2007 12:08:10 -0700
Kristen Carlson Accardi <[EMAIL PROTECTED]> wrote:
> ===
> --- 2.6-git.orig/include/linux/libata.h
> +++ 2.6-git/include/linux/libata.h
> @@ -139,7 +139,8 @@ enum {
> ATA_DFLAG_FLUSH_EXT = (1 << 4), /* do FLUSH_EXT instead of FLUSH */
> ATA_DFLAG_ACPI_PENDING = (1 << 5), /* ACPI resume action pending */
> ATA_DFLAG_ACPI_FAILED = (1 << 6), /* ACPI on devcfg has failed */
> - ATA_DFLAG_CFG_MASK = (1 << 8) - 1,
> + ATA_DFLAG_AN= (1 << 7), /* device supports AN */
> + ATA_DFLAG_CFG_MASK = (1 << 12) - 1,
>
> ATA_DFLAG_PIO = (1 << 8), /* device limited to PIO mode */
> ATA_DFLAG_NCQ_OFF = (1 << 9), /* device limited to non-NCQ mode */
> @@ -177,6 +178,7 @@ enum {
> ATA_FLAG_IGN_SIMPLEX= (1 << 15), /* ignore SIMPLEX */
> ATA_FLAG_NO_IORDY = (1 << 16), /* controller lacks iordy */
> ATA_FLAG_ACPI_SATA = (1 << 17), /* need native SATA ACPI layout */
> + ATA_FLAG_AN = (1 << 18), /* controller supports AN */
>
It would be nice to at least get bits like this upstream.
-
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] [MEGARAID_SAS]: Remove needless memset in megasas_init
megasas_mgmt_info is a static variable, so goes to .bss thus zeroed at boot. Signed-off-by: Arnaldo Carvalho de Melo <[EMAIL PROTECTED]> --- drivers/scsi/megaraid/megaraid_sas.c |2 -- 1 files changed, 0 insertions(+), 2 deletions(-) diff --git a/drivers/scsi/megaraid/megaraid_sas.c b/drivers/scsi/megaraid/megaraid_sas.c index ebb948c..59099da 100644 --- a/drivers/scsi/megaraid/megaraid_sas.c +++ b/drivers/scsi/megaraid/megaraid_sas.c @@ -3033,8 +3033,6 @@ static int __init megasas_init(void) printk(KERN_INFO "megasas: %s %s\n", MEGASAS_VERSION, MEGASAS_EXT_VERSION); - memset(&megasas_mgmt_info, 0, sizeof(megasas_mgmt_info)); - /* * Register character device node */ -- 1.5.2.2 - 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] [MEGARAID_SAS]: Use pr_info
Signed-off-by: Arnaldo Carvalho de Melo <[EMAIL PROTECTED]>
---
drivers/scsi/megaraid/megaraid_sas.c | 14 ++
1 files changed, 6 insertions(+), 8 deletions(-)
diff --git a/drivers/scsi/megaraid/megaraid_sas.c
b/drivers/scsi/megaraid/megaraid_sas.c
index 59099da..4a8cf06 100644
--- a/drivers/scsi/megaraid/megaraid_sas.c
+++ b/drivers/scsi/megaraid/megaraid_sas.c
@@ -1341,8 +1341,7 @@ megasas_transition_to_ready(struct megasas_instance*
instance)
fw_state = instance->instancet->read_fw_status_reg(instance->reg_set) &
MFI_STATE_MASK;
if (fw_state != MFI_STATE_READY)
- printk(KERN_INFO "megasas: Waiting for FW to come to ready"
- " state\n");
+ pr_info("megasas: Waiting for FW to come to ready state\n");
while (fw_state != MFI_STATE_READY) {
@@ -1444,7 +1443,7 @@ megasas_transition_to_ready(struct megasas_instance*
instance)
return -ENODEV;
}
};
- printk(KERN_INFO "megasas: FW now in Ready state\n");
+ pr_info("megasas: FW now in Ready state\n");
return 0;
}
@@ -2277,9 +2276,9 @@ megasas_probe_one(struct pci_dev *pdev, const struct
pci_device_id *id)
/*
* Announce PCI information
*/
- printk(KERN_INFO "megasas: %#4.04x:%#4.04x:%#4.04x:%#4.04x: ",
- pdev->vendor, pdev->device, pdev->subsystem_vendor,
- pdev->subsystem_device);
+ pr_info("megasas: %#4.04x:%#4.04x:%#4.04x:%#4.04x: ",
+ pdev->vendor, pdev->device, pdev->subsystem_vendor,
+ pdev->subsystem_device);
printk("bus %d:slot %d:func %d\n",
pdev->bus->number, PCI_SLOT(pdev->devfn), PCI_FUNC(pdev->devfn));
@@ -3030,8 +3029,7 @@ static int __init megasas_init(void)
/*
* Announce driver version and other information
*/
- printk(KERN_INFO "megasas: %s %s\n", MEGASAS_VERSION,
- MEGASAS_EXT_VERSION);
+ pr_info("megasas: %s %s\n", MEGASAS_VERSION, MEGASAS_EXT_VERSION);
/*
* Register character device node
--
1.5.2.2
-
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
