Re: PCI bus operations and driver design

Tech-Archive recommends: Repair Windows Errors & Optimize Windows Performance

From: Mark Roddy (markr_at_hollistech.com)
Date: 10/04/04 

Date: Mon, 4 Oct 2004 19:36:48 -0400

In article <#$MhvXlqEHA.3760@TK2MSFTNGP09.phx.gbl>,
dwight.holman.SPAM@xtra.co.nz says...
> Yes, this is another question from a newbie :-)
>
> I have been investigating an issue relating to our 'working' PCI
> device driver (part of the product developed by my company). This NT
> device driver uses memory mapped IO to read/write to DPRAM on a PCI card.
>
> The existing code assumes that such writes to this memory (over the
> PCI bus) will always succeed.
>
> Coming from a background including lots of things *other* than writing
> device drivers, I am suspicious that this assumption may not be the
> case... and that writes may sometimes fail.
>
> So, is it possible for a write to memory mapped DPRAM to occasionally
> fail?
>

Yes, but on most platforms these failures are catastrophic and global and not
the concern of individual device drivers. On some platforms you could
experience a 'hot unplug' (aka surprise removal) of your pci device as a result
of such a catastrophic event, so it is a good idea to correctly implement your
surprise removal path and to prevent endless loops in your hardware access
routines. There is a white paper on driver hardening on the microsoft web site.
It was by a certain Simon Graham and it was presented at winhec a few years
back and it covers the basics.

> Can anybody out there share their experience of the possible failure
> scenarios when performing such operations over a PCI bus?
>
> What strategies are required to ensure that writes to such memory
> (over a PCI bus) occur reliably?

It is up to the platform hardware to manage the bus and its reliability, not
your device driver.

>
> I guess the answer is 'it depends', so ok... Lets assume that we must
> either succeed in writing the memory, or know clearly that the
> operation failed.
>
> To me the simple (intuitive) answer is that after writing the memory,
> the driver should read it back to verify the operation worked.
>
Don't do that unless you have gobs of excess bandwidth that you desperately
need to consume :-)

Assume that the transaction succeeded. If it doesn't either the system will
crash (standard PC architecture) or your device will suddenly disappear (high
end HA server platforms.) 

-- 
=====================
Mark Roddy DDK MVP
Windows 2003/XP/2000 Consulting
Hollis Technology Solutions 603-321-1032
www.hollistech.com
markr@hollistech.com

Relevant Pages

  • Re: PCI Driver - Read/Write to Base Address
    ... I get this message in the kernel log: ... register, reading PCI memory, and writing PCI memory code out of the ... After the device driver ...
    (comp.os.linux.development.system)
  • PCI bus operations and driver design
    ... I have been investigating an issue relating to our 'working' PCI ... device driver uses memory mapped IO to read/write to DPRAM on a PCI card. ... Coming from a background including lots of things *other* than writing ...
    (microsoft.public.development.device.drivers)
  • Re: Persuading PCI memory writes to write as a burst
    ... then writing a few resulting chunks of memory (each ... encourage PCI bridgeto do write combining. ... The PCI card has BAR0 declaring memory with prefetch (but, sadly, not fast ... posted writes in the same application + device driver setup. ...
    (microsoft.public.development.device.drivers)
  • mmap
    ... I'm developing a PCI card, which supports the memory read and write PCI ... In my application, which communicates with the device driver, I think I ... how does the bar1 value from the mmap function get ...
    (comp.os.linux.development.system)
  • RE: [PATCH] fix PCI interrupt setting for ia64
    ... I think PCI IRQ should be unmasked by device driver, ... >>are generated repeatedly because these interrupt requests are never ...
    (Linux-Kernel)