Re: Trying to DMA data from PCI bus to IDE

From: LegoGT (legoburns_at_yahoo.com)
Date: 08/20/03 

Date: 20 Aug 2003 07:55:09 -0700

Thanks, Phil,

phil@armstrong.invalid wrote in message news:<5bpb11-hju.ln1@trigger.kantaka.co.uk>...
> In article <5ff867d6.0308191032.6fc61c36@posting.google.com>,
> LegoGT <legoburns@yahoo.com> wrote:
> >I'm trying to use a PC104 IO board that utilizes the PLX PCI9080 chip
> >to handle DMA transfers across the PCI bus to the rest of the PC104
> >stack. I've been able to take the data from the IO board, DMA it to
> >memory, and then use the regular Linux functions to write it to the
> >hard drive. Even though my drive is using the highest UDMA settings
> >(ATA66 for a solid state drive) and have tweaked the hdparm, it seems
> >as if there's too much Linux file overhead involved to get it any
> >faster -- especially because I'm trying to "stream" lots of data
> >really fast for an extended time period to anywhere on the drive
> >(I'll deal with the partitions and FAT later). It seems as if Linux
> >"waits" for about 5sec before it starts to write ANYTHING to the
> >drive. Even if I turn off all of the caching settings in hdparm.
> >This tells me that it's a caching technique specific to the kernel
> >that *hopefully* I can turn off.
>
> hdparm has nothing to do with the kernel's in memory caching of disk
> buffers. Look at the values in /proc/sys/vm/ -- you can tweak these to
> make the kernel more aggressive about writing out dirty data.
>

I've been messing with tweaking /proc/sys/vm values, bdflush in
particular, and have tested all kinds of configurations. It seems
that when I set nfract and nfract_sync to zero (don't hold dirty
buffers and sync all buffer transfers to disk as they come in) There's
still a lot of overhead and some caching performed. I can watch as I
tell it to write 8-10 buffers of data (128k each) and then it pauses
for a moment while it writes to disk. This doesn't sound to me like
it's syncing data. It's still creating a buffer stack somewhere (even
if it's just cycling a buffer to a 1 level deep "dirty bin" and then
to disk).

> It sounds like you should really be using raw devices instead of
> buffered ones. Try setting up a raw device pointing to your disc
> partition and writing the data to that instead. I presume you've made
> sure that your solid state device is capable of sustained writes at
> the speed your data is coming in :)
>

As with setting up a raw device transfer, I've created a 1.5G
partition (hda2) and open that up instead of the file. When I try and
write to the drive (using the write() command) it still seems to be
governed by the bdflush parameters. That is, if I change the
percentage of caching for dirty buffers, it still lingers the same way
for a regular file. Does anyone know of how to make a direct
system/kernel call to write a buffer so that I can use the already
established UDMA driver features without the file/cache overhead
directly to disk? Otherwise, I'll have to revert back to trying to
DMA it directly to the drive by setting the IO ports and registers.

Can this be accomplished using the IDE Bus Mastering standard? I
think this feature is part of PCI 2.2 and intrinsic to the SiS630ST
chipset. If so, is this the way to go about performing a UDMA
transfer?

> >So, Does anyone know of/have ideas about a way to configure the
> >PCI9080 chip or similar chip to DMA that data to a single address in
> >memory? I've set up the drive to receive data via DMA data and write
> >it to specific sectors so then the PCI9080 would need to be "pointed
> >to" a single location in memory (0x1f0 to be exact for the primary
> >IDE). I've been trying everything, but I think there might be
> >something having to do with how Linux maps the addresses in virtual
> >memory vs. physical for the PCI9080.
> >
> >Effectively, it should be set up to pull the data from the PCI source
> >(a FIFO address on the IO board) and perform a DMA transfer to memory
> >while NOT incrementing the destination address.
>
> Er. Can't you do PCI transfers directly between the two devices? No
> memory access required then. My knowledge of PCI programming is
> pretty sketchy, so I'm not sure how feasible this is in your case.
>
> cheers,
>
> Phil

Thanks again, Phil,
Greg

Relevant Pages

  • Re: High-performance IO
    ... The size of contigious buffer is meaningfull for common buffer DMA ... I would say that for scatter-gather DMA it depends on how much memory ... I know that AWE can give the programmer a way to use ...
    (microsoft.public.win32.programmer.kernel)
  • Re: PCI bus-master and large contiguous memory buffers
    ... As soon as device reaches the end of the buffer ... Sure, I am developing both PCI adapter and device driver, so, it is ... not afford reinitializing DMA on my device after every transfer. ... x86 CPU memory management structures I never tried to dig into Windows ...
    (microsoft.public.development.device.drivers)
  • Re: 1G DMA buffer under XP - how?
    ... system memory, and what is address 0 to the controller could be something ... so only the HAL's DMA routines can allocate ... common buffer correctly in all situations. ... My card is happy with any physical address> below 4G, and I can tell this call to only allocate below the given> HighestAcceptableAddress. ...
    (microsoft.public.development.device.drivers)
  • Re: fork() (Was: Re: Will "COM for OpenVMS" be ported to Itanium
    ... >> No. Memory and devices are always consistent. ... > handing a buffer off for DMA output so that the data that the CPU ...
    (comp.os.vms)
  • Re: Trying to DMA data from PCI bus to IDE
    ... >to handle DMA transfers across the PCI bus to the rest of the PC104 ... >memory, and then use the regular Linux functions to write it to the ...
    (comp.os.linux.development.system)