About sg_tablesize in 2.6 kernel

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi All,

I am not sure if this is the right place to ask these questions. I am new to this list. Does this list offer any help to device driver developers? I appreciate if any one could give an answer to these questions.

1. In 2.6 kernel, even if I set the sg_tablesize to SG_NONE, the mid-layer is still queuing commands with use_sg=1. There is no way to disable this SG at all? I do not need a sg_table as I do not use any DMA or anything else. With SG_NONE, the use_sg is always set to 1 and the IO size queued by mid layer is only 512 bytes and decreases the throughput very badly.

2. One of the challenge I am facing is that the scatterlist structure is changed. There is no virtual address, but they replaced this with a page and offset fields. Since I need only the virtual addresses for the actual buffer (No DMA), I am using the following method to calculate the virtual address.

address=page_address(sg[i].page) + sg[i].offset;

Is this the right way? I am assuming that sg[i].page will be mapped in to kernel address space as this address is created by SCSI mid-layer. Is that right? Or do I have to use kmap? I tried replacing page_address with kmap/kunmap. But as soon as call kunmap to unmap, the kernal panics! Any thoughts?

3. Do I have to disable bottom halves before calling scsi_done()? It seems that the kernel panics when I call scsi_done if I use spin_lock instead of spin_lock_bh(). This is one of my spin_locks created for protecting a data structure.


Thanks in advance,

Aboo

-
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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [SCSI Target Devel]     [Linux SCSI Target Infrastructure]     [Kernel Newbies]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Linux IIO]     [Samba]     [Device Mapper]
  Powered by Linux