Tony Chung wrote:
>
> >
> >
> > Please note that I am not *ever* inclined to include such a wasteful change
> > into my driver. Furthermore, you need to also change the code in
> > aic7xxx_alloc_scb() to go along with this change (or at least verify that
> > allocation sizes are still reasonable).
>
> May be not that wasteful if AIC7XXX_MAX_SG is a changable module paramteter?
>
> The scatter_gather/segments concept is due to a limitation of x86 platform that
> only
> allow DMA up to a 4K boundary.
> So a virtual memory buffer is splitted into segments of real physcal addresses
> of 4K each
> with the first and last segments less than or equal to 4K.
Tony,
I am not able to try this but a utility I wrote for sg
based on the "dd" command may be able to solve your
problem. It tries to get 32KByte chunks for each scatter
gather element so the limit is 254*32KB (around 8MB) on
a single transfer.
The utility is called sg_dd512 and can be found at
http://www.torque.net/sg [follow utilities link]
You will need to change a #define in the source called
BLOCKS_PER_WBUFF to a suitable number. If this approach
looks hopeful and you need further information then
contact me.
> >From /var/log/messages, current st parameters are:
> st: bufsize 32768, wrt 30720, max buffers 4, s/g segs 16.
> So the current 32k bufsize must have split into 16 segments of 4K each.
> The segments list is then transfered to the adaptor card for DMA.
>
> I know currently st/sg drivers DMA to kernel space first and then copy
> to user space later.
> Can current linux support direct DMA to user space? If Yes, then it is not that
> resource
> demanding but can Linux locked/pinned over 1MB of physical memory for a user?
Some recent work by Stephen Tweedie associated with raw devices
opens up direct DMA possibilities for drivers like sg. This
work has appeared recently in the 2.3 series of development
kernels. I am looking at changing sg to allow direct IO and
thus move this thorny kernel buffer management problem to
the user space.
> >
> > I'm in complete agreement with Gerard Roudier that any piece of hardware that
> > needs this kind of change to work efficiently is in need of a good firmware
> > author to get things fixed in the hardware, which is where the obvious problem
> > is.
>
> It is a tape drive versus a hard disk which may support
> linked/taged/overlap/non-sequential processing.
> I also agree that our firmware can be improved.
> However, there are real customers that require large tape block size (1MB) which
> is allowable by SCSI-II standard
> and supported on other UNIX platforms and tape drive vendors.
> It will be bad if a tape created by NT or Solaris cannot be read by Linux. If
> you only read 32K on
> a 1MB tape block, you can only get 32K data and then the next 32K scsi read will
> start on the next 1MB block.
> So you cannot get back that (1MB-32K) data!
>
Doug Gilbert
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
