PCI Driver port Win XP 32 to Win 7 64 RRS feed

  • Question

  • I am currently involved in porting a driver from Win XP 32 bit to Win 7 64 bit

    We have a bespoke card using PLX 9056 PCI interface

    Two modes of access set up as follows

    1. Scatter/Gather DMA
      • C# App creates User  RAM buffers
        • Buffer pinned using GCHandle
        • Address of object taken using AddrOfPinnedObject
        • Address passed to driver via IOCTOL call
      • In IOCTL dispatch
        • Create MDL for each buffer
        • MmProbeAndLock for each MDL
      • Driver uses Scatter/Gather DMA to transfer from card to buffers
    1. Bus Master DMA
      • C# App creates a Direct X surface
        • User Virtual address along with size of surface passed to driver via IOCTL call
      • In IOCTL dispatch
        • Physical Address of the surface is passed to the card via DMPBAM & DMRR registers
          • Create MDL for surface User Virtual Address
          • MmProbeAndLock MDL
          • Get Physical Address using Scatter/Gather callback function; SGL 1<sup>st</sup> list entry (Data is assumed contiguous from base address )
          • Ensure that the Base address and range satisfy DMPBAM and DMRR criteria
      • Card may randomly access the surface

    The Scatter/Gather DMA seems to work correctly on both Windows XP 32 bit and Windows 7 64 bit but the Bus Master DMA gives us problems. We have two graphics cards that have previously been supported but now we are getting different results as follows.

    • Windows XP 32 bit
      • ATI Radeon HD4350
        • Bus Master DMA – correct operation
      • ASUS EAH5450
        • Bus Master DMA  - Correct operation

     Windows 7 64 bit

      • ATI Radeon HD4350
        • Bus Master DMA – correct operation
      • ASUS EAH5450
        • Bus Master DMA  - BSOD with no consistent cause reported (looks like random RAM is being trashed)


    1. Is using the Scatter/gather callback the correct way of getting the Physical Address of the surface?
    2. If not, is there a better way?
    3. As the driver model has changed for Win 7
      1. Can we no longer rely on the MDL describing the “real” surface?
      2. Is the assumption of contiguous data from the surface incorrect?
      3. Is there a known general strategy to cope with this?
    Wednesday, March 11, 2015 11:37 AM

All replies

  • Data is assumed contiguous from base address - why? 

    "Random ram being thrashed" would fit NOT(data contiguous).

    Mark Roddy Windows Driver and OS consultant

    Wednesday, March 11, 2015 4:52 PM
  • Hi,

    Thanks for the response to a relative newb; you seem to be confirming what I suspected.

    The board and driver are legacy and have been through a few incarnations (indeed there is a similarity to the tin of pineapple chunks in "Three Men in a Boat").

    The initial assumption appears to be that that the texture base address passed in was the guranteed to be the start of a contiguous array of physical pages that could be handed off to the card. This has obviously worked in the past but I'm guessing that there is no guarantee.

    The more I read about the subject the more the contiguity assumption seems to be fallacious. Indeed with the new display driver models there is much more of a move towards virtualization (rightly so, and for very good reasons).

    So plan B would be to try and get a physically contiguous buffer some other way to satisfy the card. I'm not sure how, as the surface is too big for common buffer allocation from AllocateCommonBuffer. Also this approach seems to subvert the whole point of virtual addressing :)

    Plan C is to go to the hardware engineer who's been "gifted" the caretakership of the FPGA design and see if we can bring things more up to date.

    Any thoughts on plan B (good or bad) would be appreciated.


    Thursday, March 12, 2015 9:20 AM