Linux PARISC architecture development
 help / color / mirror / Atom feed
From: John Marvin <jsm@udlkern.fc.hp.com>
To: parisc-linux@lists.parisc-linux.org
Subject: Re: [parisc-linux] kernel panic using cpio from cdrom to disk.
Date: Fri, 20 Apr 2001 15:50:16 -0600 (MDT)	[thread overview]
Message-ID: <200104202150.PAA17555@udlkern.fc.hp.com> (raw)

> Unexpected Interruption!: Code=0 regs=1027a080 (Addr=00000000)

Oops. It looks like you are getting an HPMC, however, when I recently
changed the interruption handlers to use shadow registers rather than
temporary control registers, I changed the convention for passing in
the trap "code". It looks like I missed changing the appropriate
code in the hpmc handler, so code got passed as 0, instead of
transferring the real hpmc trap data from pim, it reported what
was in the ipr's at the time the Q bit was last turned off.

> Like Ryans crash, PSW has only the Q bit set - data translation is
> turned off.  I guess that means the IAOQ values are real addresses, so I
> added 0x10000000 before looking them up in System.map.  In my case, it
> died on the "rsm 8,r0" under os_hpmc_5 in arch/parisc/kernel/hpmc.S.

It didn't die there. The Q bit was turned off there, so that was the
last place that the ipr's (iasq/iaoq/ipsw etc) tracked what was going
on. In fact the hpmc handler worked properly with the exception of
passing in a "1" for code, so you got some output. If the hpmc handler
hadn't worked, you would not have gotten anything.

Try applying the following patch to hpmc.S and you should get a little
more useful output:

--- hpmc.S.old	Fri Apr 20 15:22:02 2001
+++ hpmc.S	Fri Apr 20 15:24:13 2001
@@ -264,8 +264,7 @@ os_hpmc_5:
 	tovirt_r1 %r30      /* make sp virtual */
 
 	rsm 8,%r0           /* Clear Q bit */
-	ldi     1,%r1
-	mtctl   %r1,%cr29   /* Set trap code to "1" for HPMC */
+	ldi     1,%r8       /* Set trap code to "1" for HPMC */
 	mtctl   %r0,%cr30   /* Force interruptions to use hpmc stack */
 	ldil    L%PA(intr_save), %r1
 	ldo     R%PA(intr_save)(%r1), %r1

Let me know if the patch fixes the hpmc handler bug.

Note, your real problem is that you got an hpmc. Also note that the
hpmc handler only reports the hpmc pim information that is common to
all machines. There is a lot of machine specific hpmc information that
you can get once you reboot and type "ser pim 0 hpmc" at the boot
console prompt. Of course, decoding it can be difficult.

John

             reply	other threads:[~2001-04-20 21:50 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-04-20 21:50 John Marvin [this message]
  -- strict thread matches above, loose matches on Subject: below --
2001-04-14  6:52 [parisc-linux] kernel panic using cpio from cdrom to disk Ryan Bradetich
2001-04-20 16:22 ` Richard Hirst
2001-04-20 16:57 ` Richard Hirst
2001-04-20 18:07   ` Grant Grundler

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=200104202150.PAA17555@udlkern.fc.hp.com \
    --to=jsm@udlkern.fc.hp.com \
    --cc=parisc-linux@lists.parisc-linux.org \
    /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