Re: [parisc-linux] Virtual mapping of IO cards

[Frank Rowand <frank_rowand@mvista.com>]

John Marvin wrote:
> 
> Note: I've changed the subject, because I think this issue is mostly
> separate from the Linux syscall issue.
> 
> > An HPMC may be delayed, relative to the instruction that caused it.  The
> > worst case is that a context switch _could_ occur before the HPMC occurs
> > (and yes, we did see this problem with our HP-UX and HP-RT VME systems
> > when a VME time-out was long enough).  This can make it more difficult to
> > figure out what instruction was issued to cause the HPMC.  The advantage
> > of the page fault is that you know exactly what instruction caused the
> > fault.
> 
> But this doesn't help make your case.  You got the HPMC anyway because the
> card failed to respond in time.  The virtual mapping didn't help you.
> 
> Virtually mapping the card doesn't help with HPMC's caused by dma buffer
> mismanagement (i.e. the card causes the HPMC while mastering the bus).
> 
> Drivers for memory mapped register only cards, i.e. cards without any
> type of onboard memory (i.e. framebuffers, script memory, etc.) are
> not very likely to ever run into a bug of this type, since register
> pointers are usually set up once and never changed.
> 
> In my experience, the majority of HPMC's have been caused by VM errors.
> Then comes the two cases mentioned above (card not responding, dma
> errors).  In my experience, the majority of driver page faults were caused
> by memory references (i.e. mismanaging memory buffers), not IO space
> references.  I can't say I've ever seen a driver page fault bug (i.e. one
> that would have HPMC'd in the current Linux implementation) that was
> caused by the driver mismanaging a pointer to its virtually mapped card
> space.  That is my experience.  YMMV.
> 
> What percentage of the bugs that are caused by a driver mismanaging a
> pointer to its card space would be significantly helped by page faulting,
> rather than HPMC'ing? Although an HPMC can be delayed, I've found in
> the majority of the cases it was either right on, or one instruction off.


Yes, an HPMC caused by a read will behave as you describe.  It's the
case of a write that may be delayed by passing through one or more queues.


> I'm not trying to argue against virtually mapping the card (although I
> would be all for avoiding mapping a large graphics frame buffer in the
> kernel address space). I just want to be sure we do it for the right
> reasons.
> 
> John Marvin
> jsm@fc.hp.com
> 
> ---------------------------------------------------------------------------
> To unsubscribe: send e-mail to parisc-linux-request@thepuffingroup.com with
> `unsubscribe' as the subject.

-Frank
-- 
MontaVista Software, Inc
frank_rowand@mvista.com