From: Grant Grundler <grundler@cup.hp.com>
To: John Marvin <jsm@udlkern.fc.hp.com>
Cc: parisc-linux@thepuffingroup.com
Subject: Re: [parisc-linux] Virtual mapping of IO cards
Date: Wed, 16 Feb 2000 10:38:05 -0800 [thread overview]
Message-ID: <200002161838.KAA07528@milano.cup.hp.com> (raw)
In-Reply-To: Your message of "Wed, 16 Feb 2000 08:25:17 PST." <200002161525.IAA14558@udlkern.fc.hp.com>
John Marvin wrote:
...
> 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).
But it generally helps one tell the difference.
>
> 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.
Agreed. "not very likely" and "never" are not the same. When bringing
up new drivers, it is in fact more likely than for a mostly working
driver. So while I agree with the statement, I don't agree with the
conclusion.
> In my experience, the majority of HPMC's have been caused by VM errors.
That's cuz you work mostly on VM! :^)
For me, it's been mostly device driver bugs (drivers loosing DMA addresses)
and some I/O MMU code bugs.
> 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.
Agreed.
> 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.
I have. The driver control structure got corrupted.
I've worked on so many memory corruption problems.
I can't imagine debugging them if an errant driver were
scribbling in real mode to random places in memory.
AFAICT, the whole point of virtual mode is to avoid this.
> 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.
Very small. But I am still convinced it's worth it.
AFAIK, the processor can only HPMC if a LOAD times out.
What about processor STORE?
I know stores to I/O devices which have "gone fatal" will complete.
I don't know about stores to "unused" I/O space (no device response).
I assume stores to physical memory while in real mode will complete too.
I'd really like to avoid that. Stores from virtual mode are likely
to data page fault (not always) while in real mode I had the impression
they never would. Is this correct?
>
> 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.
ok. Fair enough.
grant
Grant Grundler
Unix Development Lab
+1.408.447.7253
next prev parent reply other threads:[~2000-02-16 19:37 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2000-02-16 15:25 [parisc-linux] Virtual mapping of IO cards John Marvin
2000-02-16 18:38 ` Grant Grundler [this message]
2000-02-17 18:49 ` Frank Rowand
2000-02-16 21:45 ` Frank Rowand
-- strict thread matches above, loose matches on Subject: below --
2000-02-17 14:37 John Marvin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200002161838.KAA07528@milano.cup.hp.com \
--to=grundler@cup.hp.com \
--cc=jsm@udlkern.fc.hp.com \
--cc=parisc-linux@thepuffingroup.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox