All of lore.kernel.org
 help / color / mirror / Atom feed
From: Frank Rowand <frank_rowand@mvista.com>
To: Philipp Rumpf <prumpf@inwestnet.de>
Cc: Grant Grundler <grundler@cup.hp.com>,
	John Marvin <jsm@udlkern.fc.hp.com>,
	parisc-linux@thepuffingroup.com
Subject: Re: [parisc-linux] Linux syscall ABI
Date: Tue, 15 Feb 2000 11:15:46 -0800	[thread overview]
Message-ID: <38A9A5E2.41215D5C@mvista.com> (raw)
In-Reply-To: 20000215191858.P765@abacus.local

Philipp Rumpf wrote:
> 
> > Drivers don't map anything. The assumption for GSC/PCI drivers is the
> > address given will work with readl/writel (or inb/outb) routines.
> 
> PCI drivers call ioremap(), which is free to do the mapping (but I don't
> think it should, for PA-RISC).
> 
> > For GSC, the HPA is in the struct hp_device->hpa field and readl/writel
> > are aliases for gsc_readl/gsc_writel.
> 
> which itself will be aliased to simple volatile accesses soon.
> 
> > gsc_readl/writel take a physical address as the address parameter.
> > I would like to get away from gsc_read for one simple reason: HPMC.
> > If a driver incorrectly accesses something which isn't supposed to
> > we get either an HPMC or undefined behavior. Most likely the HPMC.
> > If the read/write routines referenced a virtual address, we have
> > much better chances of getting a data page fault and some decent
> > debugging information to track down the problem.
> 
> HPMC is good debugging information - you've got PIM.  Of course, we want
> an HPMC handler too, at some point.  The assembly part just tries to
> find out if the machine is still usable, and resets it if it's not.
> If it is, we'd like it to be treated as normal interruption, and then
> have a CPU-specific fault handler that reads the interesting registers
> and prints a nice message.
> 
>         Philipp Rumpf
> 
> ---------------------------------------------------------------------------
> To unsubscribe: send e-mail to parisc-linux-request@thepuffingroup.com with
> `unsubscribe' as the subject.

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.

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

  reply	other threads:[~2000-02-15 20:19 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2000-02-15  5:36 [parisc-linux] Linux syscall ABI John Marvin
2000-02-15  6:15 ` willy
2000-02-15 12:50 ` Philipp Rumpf
2000-02-16 14:04   ` [parisc-linux] Location of HIL protocol docs? Brian S. Julin
2000-02-16 18:42     ` Grant Grundler
2000-02-15 17:25 ` [parisc-linux] Linux syscall ABI Grant Grundler
2000-02-15 18:18   ` Philipp Rumpf
2000-02-15 19:15     ` Frank Rowand [this message]
2000-02-16  2:34     ` Grant Grundler
2000-02-16  9:33       ` Kirk Bresniker
  -- strict thread matches above, loose matches on Subject: below --
2000-02-17 14:17 John Marvin
2000-02-16 13:57 John Marvin
2000-02-16 17:41 ` Philipp Rumpf
2000-02-14  9:30 John Marvin
2000-02-14 13:34 ` Philipp Rumpf

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=38A9A5E2.41215D5C@mvista.com \
    --to=frank_rowand@mvista.com \
    --cc=frowand@mvista.com \
    --cc=grundler@cup.hp.com \
    --cc=jsm@udlkern.fc.hp.com \
    --cc=parisc-linux@thepuffingroup.com \
    --cc=prumpf@inwestnet.de \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.