All of lore.kernel.org
 help / color / mirror / Atom feed
From: rbrad@beavis.ybsoft.com (Ryan Bradetich)
To: Grant Grundler <grundler@puffin.external.hp.com>
Cc: parisc-linux@lists.parisc-linux.org
Subject: Re: [parisc-linux] help debuging HMPC
Date: Sun, 15 Jul 2001 21:31:57 -0600	[thread overview]
Message-ID: <20010715213157.A13729@beavis.ybsoft.com> (raw)
In-Reply-To: <200107140620.AAA28577@puffin.external.hp.com>

On Sat, Jul 14, 2001 at 12:20:00AM -0600, Grant Grundler wrote:

> > This is the instruction that causes the HPMC (IAOQ address - 8):
> > 	ldwa  r0(r26),r26
> 
> Given the IOAQ data below, I'm pretty sure GR26 is garbage.
> 
> Anyway, the IO port address is most likely still in GR24
> since it's the third arg to dino_inX. The call to gsc_readX
> won't (shouldn't) clobber that.

Just a quick clarification:

I macro expanded dino_in32 into this:
	static u32 dino_in32 (struct pci_hba_data *d, u16 addr);

dino_in32 only takes two arguments, so I should check GR25 and manually
perform the calculations in the dino_in32 to get the proper address
passed to the _gsc_readl function, correct?  


> The stack is just a temporary storage space for code to save registers.
> IOAQ reflects the state of the CPU and has nothing to do with stack.

Doh .. ok.  This makes sense to me now. *sigh*

> > 		running the astk command from the build-tools also does
> > 		not show the dino_in32 or the _gsc_readl addresses in
> > 		the stack trace either.
> 
> right - only time you'll see a function address (which was part
> of the call chain) is when GR02 gets saved.
> gsc_readX is a "leaf" routine and thus doesn't save GR02.
> The last thing on the stack should be the caller to dino_inX().

This also make sense to me.  Thanks for your time and explaination Grant!

- Ryan

> grant
> 
> Grant Grundler
> parisc-linux {PCI|IOMMU|SMP} hacker
> +1.408.447.7253
> 
> 
> _______________________________________________
> parisc-linux mailing list
> parisc-linux@lists.parisc-linux.org
> http://lists.parisc-linux.org/cgi-bin/mailman/listinfo/parisc-linux
> 

-- 

  reply	other threads:[~2001-07-16  3:32 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-07-13 17:01 [parisc-linux] help debuging HMPC Ryan Bradetich
2001-07-14  6:20 ` Grant Grundler
2001-07-16  3:31   ` Ryan Bradetich [this message]
2001-07-16 13:38     ` Grant Grundler
2001-07-17  3:39       ` Ryan Bradetich

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=20010715213157.A13729@beavis.ybsoft.com \
    --to=rbrad@beavis.ybsoft.com \
    --cc=grundler@puffin.external.hp.com \
    --cc=parisc-linux@lists.parisc-linux.org \
    --cc=rbradetich@uswest.net \
    /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.