scsi_sg_copy_from_buffer( ) variant for initiator LLDD

[va stg2010 <va.storage2010@xxxxxxxxx>]

Hi ,
For  scsi READ CDB, my initiator mode HBA receives data from target in
fragments for example a  64K READ will   arrive in  31568 + 1200 +
31568 + 1200  fragments.
I  am trying to implement  scsi_sg_copy_from_buffer_variant()  variant
which can "START/STOP at will" because READ datacomes in fragments
from target.

I looked into scsi_sg_copy_from_buffer implementation and based on
that, scsi_sg_copy_from_buffer_VARIANT()  does   this:

Step 1) Call once sg_miter_start () - whennew scsi command comes in.
Step 2) Keep calling  sg_miter_next() - everytime when interrupt
handler posts that fragment of  READ data is available.
Step 3) Call once  sg_miter_stop() - All the READ data rcvd in HBA
LLDD  from target for this scsi command, now safe to call scsi_done().

The step 2 algorithm is following:
static size_t sg_copy_buffer_variant(struct scatterlist *sgl, void
*src_data_address, size_t src_len,   struct sg_mapping_iter *miter)
{
       unsigned int offset = 0;
       unsigned long flags;


       printk("START sg iterator \n");

       local_irq_save(flags);

       while (offset < src_len) {
               unsigned int len;

               if (sg_miter_next(miter)) {
                  miter->consumed = 0;
               }
               else
                    BUG_ON(1);
               len = min(miter->length, src_len - offset);
               miter->consumed = len;
               memcpy(miter->addr, src_data_address + offset, len);
               flush_kernel_dcache_page(miter->page);
               offset += len;
               }

       local_irq_restore(flags);
}

My kernel is 2.6.27.7.  Can someone please review this and tell what
is wrong with above implementation (or easier alternative ways)
because at the end of step3, I start seeing  these messages:

sg_miter_stop:404
sg_miter_stop:406
BUG: scheduling while atomic: swapper/0/0xffffffff
Modules linked in: my_scsi_lld
Call Trace:
[<ffffffff8150188c>] dump_stack+0x8/0x34
[<ffffffff815024e0>] schedule+0x4c0/0x908
BUG: scheduling while atomic: swapper/0/0x00000001
Modules linked in: my_scsi_lld
Call Trace:
[<ffffffff8150188c>] dump_stack+0x8/0x34
[<ffffffff815024e0>] schedule+0x4c0/0x908
[<ffffffff81134318>] cpu_idle+0x48/0x50

BUG: scheduling while atomic: swapper/0/0x00000001
Modules linked in: my_scsi_lld
Call Trace:
[<ffffffff8150188c>] dump_stack+0x8/0x34
[<ffffffff815024e0>] schedule+0x4c0/0x908
[<ffffffff81134318>] cpu_idle+0x48/0x50

BUG: scheduling while atomic: swapper/0/0x00000001
Modules linked in: my_scsi_lld
Call Trace:
[<ffffffff8150188c>] dump_stack+0x8/0x34
[<ffffffff815024e0>] schedule+0x4c0/0x908
[<ffffffff81134318>] cpu_idle+0x48/0x50
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html