On Fri, Mar 02, 2007 at 03:59:42PM -0600, Mike Christie wrote:
> If scsi_execute_async is going to be limited to what is in mainline
> until I can kill it, then we may not want to merge Boaz's patch and just
> have people convert the code to use blk_get_request, blk_rq_map_kern or
> blk_rq_map_user
On Sun, Mar 04, 2007 at 12:06:36PM -0700, Dachepalli, Sudhir wrote:
> James,
>
> How about the following:
>
> 1. Cmd= Scsi_get_command( on physical device )
> 2. Clone the scsi_cmnd fields of the virtual cmnd( command received by
> failover driver) to physical cmnd (the command allocated by
No
12:14 PM
To: Dachepalli, Sudhir
Cc: Mike Christie; Benny Halevy; Jens Axboe; Boaz Harrosh;
linux-scsi@vger.kernel.org
Subject: RE: Possible bug in scsi_lib.c:scsi_req_map_sg()
On Sun, 2007-03-04 at 11:00 -0700, Dachepalli, Sudhir wrote:
> Do you think the following could work If I used blk
On Sun, 2007-03-04 at 11:00 -0700, Dachepalli, Sudhir wrote:
> Do you think the following could work If I used blk layer functions
> instead of "scsi_execute_async":
>
> Blk_get_request()
> Req->flags |= REQ_DONTPREP
There's additional complexity here: if the request isn't prepared, no
command i
AIL PROTECTED]
Sent: Sunday, March 04, 2007 11:07 AM
To: James Bottomley
Cc: Dachepalli, Sudhir; Benny Halevy; Jens Axboe; Boaz Harrosh;
linux-scsi@vger.kernel.org
Subject: Re: Possible bug in scsi_lib.c:scsi_req_map_sg()
Mike Christie wrote:
> James Bottomley wrote:
>> On Sun, 2007-03-0
Mike Christie wrote:
> James Bottomley wrote:
>> On Sun, 2007-03-04 at 10:21 -0600, Mike Christie wrote:
>>> I think they get around this and other request settings that need
>>> resetting by using scsi_execute_async. They will take the command, data
>>> direction and buffer fields from the origina
James Bottomley wrote:
> On Sun, 2007-03-04 at 10:21 -0600, Mike Christie wrote:
>> I think they get around this and other request settings that need
>> resetting by using scsi_execute_async. They will take the command, data
>> direction and buffer fields from the original scsi_cmnd, then pass thos
On Sun, 2007-03-04 at 10:21 -0600, Mike Christie wrote:
> I think they get around this and other request settings that need
> resetting by using scsi_execute_async. They will take the command, data
> direction and buffer fields from the original scsi_cmnd, then pass those
> on to scsi_ececute_async
James Bottomley wrote:
> On Sun, 2007-03-04 at 09:43 -0600, Mike Christie wrote:
>> There are trying to do a scsi level multipath driver for RDAC support.
>> And they are trying to do something similar to request based multipath
>> (route requests instead of bios but in their case they are routing
On Sun, 2007-03-04 at 09:43 -0600, Mike Christie wrote:
> There are trying to do a scsi level multipath driver for RDAC support.
> And they are trying to do something similar to request based multipath
> (route requests instead of bios but in their case they are routing
> scsi_cmnds instead of requ
James Bottomley wrote:
> On Sun, 2007-03-04 at 00:36 -0700, Dachepalli, Sudhir wrote:
>> Our driver gets called in with the following fashion through the
>> queuecommand.
>>
>> scsi_request_fn() -> scsi_dispatch_cmd() -> rtn =
>> host->hostt->queuecommand(cmd, scsi_done);
>>
>> We are using the "cm
On Sun, 2007-03-04 at 00:36 -0700, Dachepalli, Sudhir wrote:
> Our driver gets called in with the following fashion through the
> queuecommand.
>
> scsi_request_fn() -> scsi_dispatch_cmd() -> rtn =
> host->hostt->queuecommand(cmd, scsi_done);
>
> We are using the "cmd" ( scsi_cmnd) as a pass thro
ch 03, 2007 6:04 PM
To: Dachepalli, Sudhir
Cc: Benny Halevy; Jens Axboe; Boaz Harrosh; linux-scsi@vger.kernel.org;
James Bottomley
Subject: Re: Possible bug in scsi_lib.c:scsi_req_map_sg()
Dachepalli, Sudhir wrote:
> Where is the depricated warning that you mentioned about ?
> I tried to loo
Dachepalli, Sudhir wrote:
> Where is the depricated warning that you mentioned about ?
> I tried to look in scsi_lib.c and scsi_device.h
>
I meant in the first versions of the patches there was a warning. Did
you also try the workarounds mentioned in the bugzilla, to allocate
memory like sg and s
mes Bottomley
Subject: Re: Possible bug in scsi_lib.c:scsi_req_map_sg()
Mike Christie wrote:
> Dachepalli, Sudhir wrote:
>> scsi_req_map_sg::i=2,len=1024,data_len=3072,off=2048,PAGE_SIZE=4096,b
>> yte
>> s=1024,nr_vecs=0, nr_pages=0
>
>
>>
Mike Christie wrote:
> Dachepalli, Sudhir wrote:
>> scsi_req_map_sg::i=2,len=1024,data_len=3072,off=2048,PAGE_SIZE=4096,byte
>> s=1024,nr_vecs=0, nr_pages=0
>
>
>> if (bio_add_pc_page(q, bio, page, bytes, off) !=
>> bytes) {
>>
Dachepalli, Sudhir wrote:
> scsi_req_map_sg::i=2,len=1024,data_len=3072,off=2048,PAGE_SIZE=4096,byte
> s=1024,nr_vecs=0, nr_pages=0
> if (bio_add_pc_page(q, bio, page, bytes, off) !=
> bytes) {
> printk("scsi_req_
ED]
[mailto:[EMAIL PROTECTED] On Behalf Of Benny Halevy
Sent: Wednesday, November 29, 2006 3:30 AM
To: Jens Axboe
Cc: Mike Christie; Boaz Harrosh; linux-scsi@vger.kernel.org; James
Bottomley
Subject: Re: Possible bug in scsi_lib.c:scsi_req_map_sg()
Jens Axboe wrote:
> On Mon, Nov 27 2006, Mike Chris
Jens Axboe wrote:
On Mon, Nov 27 2006, Mike Christie wrote:
Mike Christie wrote:
Boaz Harrosh wrote:
Playing with some tests which I admit are not 100% orthodox I have
stumbled upon a bug that raises a serious question:
In the call to scsi_execute_async() in the use_sg case, must the
scatterl
On Mon, Nov 27 2006, Mike Christie wrote:
> Mike Christie wrote:
> > Boaz Harrosh wrote:
> >> Playing with some tests which I admit are not 100% orthodox I have
> >> stumbled upon a bug that raises a serious question:
> >>
> >> In the call to scsi_execute_async() in the use_sg case, must the
> >> s
Boaz Harrosh wrote:
> Mike Christie wrote:
>> Boaz Harrosh wrote:
>>> Playing with some tests which I admit are not 100% orthodox I have
>>> stumbled upon a bug that raises a serious question:
>>>
>>> In the call to scsi_execute_async() in the use_sg case, must the
>>> scatterlist* (pointed to by b
Mike Christie wrote:
Boaz Harrosh wrote:
Playing with some tests which I admit are not 100% orthodox I have
stumbled upon a bug that raises a serious question:
In the call to scsi_execute_async() in the use_sg case, must the
scatterlist* (pointed to by buffer) map a buffer that's contiguous in
On Mon, 2006-11-27 at 13:13 -0600, Mike Christie wrote:
> I thought they were continguous. I think James has said before that
> they
> can be disjoint. When we converted sg it did not look like sg or st
> supported disjoint. The main non dio path used a buffer from
> get_free_pages so I thought tha
On Mon, 27 Nov 2006, Mike Christie wrote:
> Mike Christie wrote:
> > Boaz Harrosh wrote:
> >> Playing with some tests which I admit are not 100% orthodox I have
> >> stumbled upon a bug that raises a serious question:
> >>
> >> In the call to scsi_execute_async() in the use_sg case, must the
> >>
Mike Christie wrote:
> Boaz Harrosh wrote:
>> Playing with some tests which I admit are not 100% orthodox I have
>> stumbled upon a bug that raises a serious question:
>>
>> In the call to scsi_execute_async() in the use_sg case, must the
>> scatterlist* (pointed to by buffer) map a buffer that's c
Boaz Harrosh wrote:
> Playing with some tests which I admit are not 100% orthodox I have
> stumbled upon a bug that raises a serious question:
>
> In the call to scsi_execute_async() in the use_sg case, must the
> scatterlist* (pointed to by buffer) map a buffer that's contiguous in
> virtual memo
Playing with some tests which I admit are not 100% orthodox I have stumbled
upon a bug that raises a serious question:
In the call to scsi_execute_async() in the use_sg case, must the scatterlist*
(pointed to by buffer) map a buffer that's contiguous in virtual memory or is
it allowed to map d
27 matches
Mail list logo
