[parisc-linux] 720 - some progress

[parisc-linux] 720 - some progress

[Jochen Friedrich]

Hi,

i created this patch for the cause 18 on the 720. Without the patch and 
fallthrough to case 26, the following program will just hang:

#include <stdio.h>

int main()
{
  int i,j,k;
  char *p;

  i=0;
  j=1;
  k=0;

  p = (char *) &j;
  p++;
  i = *(int *) p;

  printf("%d\n",i);
}

With the patch, the output is:

sh-2.05# ./unaligned
unaligned(20): unaligned access to 0xfaf002cd at ip=0x0001050f
256
                  
So the patch appears to work correctly at least for this case...

However, the user space tools ls, tar, sleep still crash for me.
This is the dmesg output:

!!die_if_kernel: ls.x(22): Privileged register - shouldn't happen! 11
     YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI
PSW: 00000000000001001111111100001111
r0-3     00000000 4019e57c 4008648f 401a057c
r4-7     401a057c 40199140 401a057c faf00318
r8-11    00000000 0001bb24 0002df58 faf000e8
r12-15   0002df58 0002df58 000c41b0 0002df58
r16-19   00000000 00000000 10350000 401cf930
r20-23   40029122 401b33f8 4019b0a0 4019fd7c
r24-27   00000000 faf00318 40199140 0002df58
r28-31   4017722c 0002f048 faf00440 40083393
sr0-3    0000002c 0000002c 00000000 0000002c
sr4-7    0000002c 0000002c 0000002c 0000002c

IASQ: 0000002c 0000002c IAOQ: 401b340f 401b3413
 IIR: 036008a4    ISR: 0000002c  IOR: 0002df58
 CPU:        0   CR30: 11b68000 CR31: 10358000
 ORIG_R28: 0002f000

Does anyone know what the cause 11 means?

Cheers,
Jochen
--- linux.orig/arch/parisc/kernel/traps.c	Wed Sep 19 12:02:30 2001
+++ linux/arch/parisc/kernel/traps.c	Thu Sep 27 00:02:23 2001
@@ -46,8 +46,12 @@
 #define PRINT_USER_FAULTS /* (turn this on if you want user faults to be */
 			 /*  dumped to the console via printk)          */
 
+#define DEBUG_CASE18
+
 void handle_unaligned(struct pt_regs *regs);
 
+unsigned long parisc_acctyp(unsigned long code, unsigned int inst);
+
 static int printbinary(char *buf, unsigned long x, int nbits)
 {
 	unsigned long mask = 1UL << (nbits - 1);
@@ -274,6 +278,11 @@
 	unsigned long fault_address = 0;
 	unsigned long fault_space = 0;
 	struct siginfo si;
+	unsigned long acc_type;
+	pte_t * pte;
+	pgd_t * pgd;
+	pmd_t * pmd;
+
 #ifdef CONFIG_KWDB
 	struct save_state ssp;
 #endif /* CONFIG_KWDB */   
@@ -322,12 +331,15 @@
 		fault_address = regs->ior;
 		parisc_terminate("Non access data tlb fault!",regs,code,fault_address);
 
+	pagefault:
+#ifdef DEBUG_CASE18
+		printk("to pagefault\n");
+#endif
 	case 15:
 	case 26:
 		fault_address = regs->ior;
 		fault_space   = regs->isr;
 		break;
-
 	case 19:
 		regs->gr[0] |= PSW_X; /* So we can single-step over the trap */
 		/* fall thru */
@@ -416,6 +428,57 @@
 		force_sig_info(SIGSEGV, &si, current);
 		return;
 
+	case 18:
+#ifdef DEBUG_CASE18
+		printk(KERN_DEBUG "got case18 -");
+#endif
+		fault_address = regs->iaoq[0];
+		fault_space = regs->iasq[0];
+
+		if (in_interrupt() || !(current->mm))
+			goto pagefault; /* shouldn't happen */
+		/* FIXME: do propper locking here */
+
+		/* page directory */
+		pgd = pgd_offset(current->mm, fault_address);
+		if (pgd_none(*pgd) || pgd_bad(*pgd))
+			goto pagefault; /* expandable stack etc */
+
+		/* middle page directory */
+		pmd = pmd_offset(pgd, fault_address);
+		if (pmd_none(*pmd) || pmd_bad(*pmd))
+		        goto pagefault; /* expandable stack etc */
+
+		/* page table entry */
+		pte = pte_offset(pmd, fault_address);
+		if (pte_none(*pte))
+		        goto pagefault; /* expandable stack etc */
+
+		if (!pte_present(*pte)) /* is this test sufficient? */
+		        goto pagefault; /* page not loaded */
+
+		acc_type = parisc_acctyp(code,regs->iir);
+
+		if ((acc_type & VM_WRITE) && (!(pte_write(*pte))))
+		        goto pagefault; /* Write protected access */
+
+		if ((acc_type & VM_READ) && (!(pte_read(*pte))))
+			goto pagefault; /* Read protected access */
+
+		if ((acc_type & VM_EXEC) && (!(pte_read(*pte))))
+		        goto pagefault; /* Exec protected access */
+
+		if (!(regs->ior & 3)) {
+#ifdef DEBUG_CASE18
+			printk("spurious? -");
+#endif
+			goto pagefault;
+		}
+		/* fall through to case 28 */
+#ifdef DEBUG_CASE18
+		printk("to unaligned\n");
+		show_regs(regs);
+#endif
 	case 28:  /* Unaligned just causes SIGBUS for now */
 		handle_unaligned(regs);
 #if 0
diff -u -r linux.orig/arch/parisc/mm/fault.c linux/arch/parisc/mm/fault.c
--- linux.orig/arch/parisc/mm/fault.c	Wed Aug 29 12:02:07 2001
+++ linux/arch/parisc/mm/fault.c	Wed Sep 26 22:54:46 2001
@@ -49,7 +49,7 @@
  *   VM_WRITE if write operation
  *   VM_EXEC  if execute operation
  */
-static unsigned long
+unsigned long
 parisc_acctyp(unsigned long code, unsigned int inst)
 {
 	if (code == 6 || code == 16)

Re: [parisc-linux] 720 - some progress

[Albert Strasheim]

[-- Attachment #1: Type: text/plain, Size: 233 bytes --]

Hello Jochen and pa-risc,

Would it help if one recompiled ls and the other "problem" tools with 
(hopefully) a simple #define DEBUG 1, so that we can see what part of
the program makes the kernel go wild?

Regards,

Albert

[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]

Re: [parisc-linux] 720 - some progress

[Jurij Smakov]

[skipped]
> !!die_if_kernel: ls.x(22): Privileged register - shouldn't happen! 11
>      YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI
> PSW: 00000000000001001111111100001111
> r0-3     00000000 4019e57c 4008648f 401a057c
> r4-7     401a057c 40199140 401a057c faf00318
> r8-11    00000000 0001bb24 0002df58 faf000e8
> r12-15   0002df58 0002df58 000c41b0 0002df58
> r16-19   00000000 00000000 10350000 401cf930
> r20-23   40029122 401b33f8 4019b0a0 4019fd7c
> r24-27   00000000 faf00318 40199140 0002df58
> r28-31   4017722c 0002f048 faf00440 40083393
> sr0-3    0000002c 0000002c 00000000 0000002c
> sr4-7    0000002c 0000002c 0000002c 0000002c
> 
> IASQ: 0000002c 0000002c IAOQ: 401b340f 401b3413
>  IIR: 036008a4    ISR: 0000002c  IOR: 0002df58
>  CPU:        0   CR30: 11b68000 CR31: 10358000
>  ORIG_R28: 0002f000
> 
> Does anyone know what the cause 11 means?
[skipped]

Hi!

Re: [parisc-linux] 720 - some progress

[Jurij Smakov]

And another (very weird) thing... I've manually decoded the instruction
(036008A4), which produces the trap 11 (hopefully, correctly :-). 
It turns out to be an MFCTL instruction to load contents of control 
register 27 into a general register 4. According to the docs for this
command ("PA-RISC 1.1 Architecture and Instruction Set Reference Manual",
Third edition, page 5-151):

"CR11, CR26 and CR 27 may be read at ANY privilege level."

So, unless I am missing something, this instruction SHOULD NOT produce
trap 11. Is it some hardware feature of 720 or my manual disassembling
skills must be improved? ;-).

Best regards,

Jurij

Re: [parisc-linux] 720 - some progress

[Jochen Friedrich]

Hi Jurij,

> Do I understand correctly, that you started seeng trap 11 only
> after applying your patch?

Nope, that was the same trap i got with the case 26 fallthrough, as well.
Apparently, ls etc doesn't have a problem with unaligned access, but it
must be something different. The PA7100LC documentation documents some
changes to the read access privileges to CR26 and CR27. Might that be the
cause for the trap 11?

The patch helps for the test case i provided, which really is an unaligned
access. The unpatched kernel doesn't trap at all with this program, but
the program will just hang.

Cheers,
Jochen

Re: [parisc-linux] 720 - some progress

[Jochen Friedrich]

Hi Jurij,

> And another (very weird) thing... I've manually decoded the instruction
> (036008A4), which produces the trap 11 (hopefully, correctly :-).
> It turns out to be an MFCTL instruction to load contents of control
> register 27 into a general register 4.

The CPU in the 720 will treat this as a priviledged instruction. The
changes "signal 18 -> signal 26, signal 27, signal 28" and "allow read
access to CR26 and CR27 for non-priviledged access" are documented as new
for the PA7100LC processor, so they are not available in the 720.

Another thing to emulate on the old 720/50 platform...

Cheers,
Jochen

Re: [parisc-linux] 720 - some progress

[Jurij Smakov]

> The CPU in the 720 will treat this as a priviledged instruction. The
> changes "signal 18 -> signal 26, signal 27, signal 28" and "allow read
> access to CR26 and CR27 for non-priviledged access" are documented as new
> for the PA7100LC processor, so they are not available in the 720.
> 
> Another thing to emulate on the old 720/50 platform...
> 
> Cheers,
> Jochen

It does not seem so complicated... Even with my rudimentary C programming
skills :-). I'll try to put something together. Is there a way to check
if we are running on a 720?

Jurij.

Re: [parisc-linux] 720 - some progress

[Albert Strasheim]

[-- Attachment #1: Type: text/plain, Size: 1344 bytes --]

Hello,

A quick glance at arch/parisc/hardware/inventory.c reveiled the
following:

long status;
unsigned int bus_id;
...
status = pdc_model_info(&model);
bus_id = (model.hversion >> (4 + 7)) & 0x1f;

switch (bus_id) {
case 0x4:               /* 720, 730, 750, 735, 755 */

I don't know if all these models have the same CPU. I'm guessing not.

I also see a parisc_get_cpu_type(...) in arch/parisc/kernnel/hardware.c.
This is probably what you want.

Regards,

Albert

On Thu, 27 Sep 2001, Jurij Smakov wrote:

> > The CPU in the 720 will treat this as a priviledged instruction. The
> > changes "signal 18 -> signal 26, signal 27, signal 28" and "allow read
> > access to CR26 and CR27 for non-priviledged access" are documented as new
> > for the PA7100LC processor, so they are not available in the 720.
> > 
> > Another thing to emulate on the old 720/50 platform...
> > 
> > Cheers,
> > Jochen
> 
> It does not seem so complicated... Even with my rudimentary C programming
> skills :-). I'll try to put something together. Is there a way to check
> if we are running on a 720?
> 
> Jurij.
> 
> 
> 
> 
> 
> _______________________________________________
> parisc-linux mailing list
> parisc-linux@lists.parisc-linux.org
> http://lists.parisc-linux.org/cgi-bin/mailman/listinfo/parisc-linux

[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]

Re: [parisc-linux] 720 - some progress

[Matthew Wilcox]

On Thu, Sep 27, 2001 at 08:23:09AM -0400, Jurij Smakov wrote:
> It does not seem so complicated... Even with my rudimentary C programming
> skills :-). I'll try to put something together. Is there a way to check
> if we are running on a 720?

There is -- but don't bother.  Check to see if the register being read is
cr26 or cr27 and perform the access if it is.  Obviously, reads of other
control registers should not be emulated.

-- 
Revolutions do not require corporate support.

Re: [parisc-linux] 720 - some progress

[Jurij Smakov]

Hi!

I hope I've got it right. It only emulates MFCTL and only when the
source control register is 27. It turns out, that pt_regs does not
have a member for cr26 and adding one does not look like an easy
task. 

Jurij.

--- linux-2.4.9-pa24/arch/parisc/kernel/traps.c Wed Sep 19 12:02:30 2001
+++ linux/arch/parisc/kernel/traps.c    Thu Sep 27 16:16:54 2001
@@ -273,6 +273,7 @@
 {
        unsigned long fault_address = 0;
        unsigned long fault_space = 0;
+       int fromcr,togr;
        struct siginfo si;
 #ifdef CONFIG_KWDB
        struct save_state ssp;
@@ -363,6 +364,17 @@
                si.si_code = ILL_PRVOPC;
                goto give_sigill;
        case 11:
+               if(!(regs->iir & 0xfc000000) && (((regs->iir & 0x1fe0)>>5) == 0x45)) {
+                 /* This is MFCTL instruction */
+                 fromcr = (regs->iir & 0x03e00000)>>21;
+                 togr = (regs->iir & 0x1f);
+                 /* Emulate the instruction if the read is from cr27 */
+                 if(fromcr == 27) {
+                   regs->gr[togr] = regs->cr27;
+                   return;
+                 }
+               }
+               /* Something else is wrong */
                die_if_kernel("Privileged register - shouldn't happen!", regs, code);
                si.si_code = ILL_PRVREG;
        give_sigill:

Re: [parisc-linux] 720 - some progress

[Jurij Smakov]

> A quick glance at arch/parisc/hardware/inventory.c reveiled the
> following:
> 
> long status;
> unsigned int bus_id;
> ...
> status = pdc_model_info(&model);
> bus_id = (model.hversion >> (4 + 7)) & 0x1f;
> 
> switch (bus_id) {
> case 0x4:               /* 720, 730, 750, 735, 755 */
> 
> I don't know if all these models have the same CPU. I'm guessing not.
> 
> I also see a parisc_get_cpu_type(...) in arch/parisc/kernnel/hardware.c.
> This is probably what you want.
> 
> Regards,
> 
> Albert

Hi Albert!

As Matthew pointed out, it is not neccessary to determine the CPU type.
"Normal" (newer) CPU's do not consider reading from cr26 and cr27 to
be privileged operations, so the condition, which is checked in the
patch will just never occur for them. Actually, did you try it? I'm
very interested in the results.

Cheers,

Jurij.

Re: [parisc-linux] 720 - some progress

[Albert Strasheim]

[-- Attachment #1: Type: text/plain, Size: 462 bytes --]

Hello,

I'll play with your patches in about 24 hours from now. Sadly, I am
attempting to get my degree during the week, so I'm not always near my
beloved 720. :-)

But I'll try them soon. And perhaps be truly dedicated and decode some
crashes like Matthew suggests. :-)

By the way, are the docs you are referring to the ones on the
parisc-linux.org site, or are they from another source? I'm interested
in starting to read up on my lil' CPU.

Regards,

Albert

[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]

Re: [parisc-linux] 720 - some progress

[Jochen Friedrich]

Hi Jurij,

using your patch, the programs ls etc don't trap anymore, but they just
hang.

> +               if(!(regs->iir & 0xfc000000) && (((regs->iir & 0x1fe0)>>5) == 0x45)) {
> +                 /* This is MFCTL instruction */
> +                 fromcr = (regs->iir & 0x03e00000)>>21;
> +                 togr = (regs->iir & 0x1f);
> +                 /* Emulate the instruction if the read is from cr27 */
> +                 if(fromcr == 27) {
> +                   regs->gr[togr] = regs->cr27;

I guess you need to advance the PC at this place. Something like:

		regs->iaoq[0] = regs->iaoq[1];
		regs->iaoq[1] = regs->iaoq[0] + 4;

> +                   return;
> +                 }
> +               }
> +               /* Something else is wrong */

If i add these instructions, ls no longer hangs but traps again with a
trap 15. Using show_regs(), it looks like there is always a 0 loaded to
the register. So my current question is:

where does regs->cr27 get written to the stack? Does the PA-RISC CPU does
this automatically on a start of a trap or does the code in entry.S need
to do this?

Cheers,
Jochen

Re: [parisc-linux] 720 - some progress

[Matthew Wilcox]

On Thu, Sep 27, 2001 at 10:42:25AM -0400, Jurij Smakov wrote:
> I hope I've got it right. It only emulates MFCTL and only when the
> source control register is 27. It turns out, that pt_regs does not
> have a member for cr26 and adding one does not look like an easy
> task. 

I think the right way to do this would be...

> @@ -363,6 +364,17 @@
>                 si.si_code = ILL_PRVOPC;
>                 goto give_sigill;
>         case 11:
> +               if(!(regs->iir & 0xfc000000) && (((regs->iir & 0x1fe0)>>5) == 0x45)) {
> +                 /* This is MFCTL instruction */
> +                 fromcr = (regs->iir & 0x03e00000)>>21;
> +                 togr = (regs->iir & 0x1f);
> +                 /* Emulate the instruction if the read is from cr27 */

		if (fromcr == 26 || fromcr == 27) {
			regs->gr[togr] = mfctl(fromcr);
			return;
		}

> +               }
> +               /* Something else is wrong */
>                 die_if_kernel("Privileged register - shouldn't happen!", regs, code);
>                 si.si_code = ILL_PRVREG;
>         give_sigill:

Can you give this a try?

-- 
Revolutions do not require corporate support.

Re: [parisc-linux] 720 - some progress

[Matthew Wilcox]

On Fri, Sep 28, 2001 at 10:49:00AM +0200, Jochen Friedrich wrote:
> If i add these instructions, ls no longer hangs but traps again with a
> trap 15. Using show_regs(), it looks like there is always a 0 loaded to
> the register. So my current question is:
> 
> where does regs->cr27 get written to the stack? Does the PA-RISC CPU does
> this automatically on a start of a trap or does the code in entry.S need
> to do this?

cr27 is only written to when doing fork/clone/vfork, iirc.  use the mfctl()
macro in place of regs->cr27 as i suggested in my other email.

-- 
Revolutions do not require corporate support.

Re: [parisc-linux] 720 - some progress

[Albert Strasheim]

[-- Attachment #1: Type: text/plain, Size: 1407 bytes --]

Hello,

I've booted my nfsroot again with 2.4.9-pa22 (I'm waiting for puffin to
come back so that I can update, and try Jurij's patches).

I mounted /proc, remounted / rw and went on my way.

I replaced ls, sleep and tar with the busybox binary from the latest
disks-hppa/current Debian root.bin.

Then I tried a mke2fs on my SCSI disk's 2nd partition (ext2), in an
attempt to get my system to boot from disk... Eek!

scsi0: istat = 04, sstat0 = 00, sstat1 = 00, dstat = 00
scsi0: dsp = 005ee038 (script[0x180e]), dsps = 005eecde, target = 0
scsi0: Failing command for ID6
scsi0: Serious error, sstat0 = 04
scsi0: Chip register contents:
 (script[0] at virt 105e8000, bus 5e8000)
 00  sien:  af  sdid:  40  scntl1:20  scntl0:d4
 04  socl:  06  sodl:  00  sxfer: 00  scid:  80
 08  sbcl:  00  sbdl:  00  sidl:  00  sfbr:  00
 0C  sstat2:06  sstat1:00  sstat0:00  dstat: 00
 10
 14  ctest3:84  ctest2:25  ctest1:0b  ctest0:00
 18  ctest7:00  ctest6:00  ctest5:00  ctest4:00
 1C  temp:  00000000
 20              ctest8:ff  istat: 06  dfifo: 00
 24  dbc:   0e000001  dnad:  005eecde  dsp:   005ee038
 30  dsps:  005eecde
 34  dmode: 80
 38  dcntl: 80  dwt:   00  dien:  1d
 3C
scsi0: Unexpected stacked interrupt, istat 06, sstat0 08, dstat 00
scsi0: Failed to handle interrupt.  Failing commands and resetting SCSI bus and chip

Anything I can do now to help the hackers debug this problem?

Regards,

Albert

[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]

Re: [parisc-linux] 720 - some progress

[Jochen Friedrich]

Hi Albert,

> Then I tried a mke2fs on my SCSI disk's 2nd partition (ext2), in an
> attempt to get my system to boot from disk... Eek!
>
> scsi0: istat = 04, sstat0 = 00, sstat1 = 00, dstat = 00
> scsi0: dsp = 005ee038 (script[0x180e]), dsps = 005eecde, target = 0
> scsi0: Failing command for ID6
> scsi0: Serious error, sstat0 = 04
> scsi0: Chip register contents:
>  (script[0] at virt 105e8000, bus 5e8000)
>  00  sien:  af  sdid:  40  scntl1:20  scntl0:d4
>  04  socl:  06  sodl:  00  sxfer: 00  scid:  80
>  08  sbcl:  00  sbdl:  00  sidl:  00  sfbr:  00
>  0C  sstat2:06  sstat1:00  sstat0:00  dstat: 00
>  10
>  14  ctest3:84  ctest2:25  ctest1:0b  ctest0:00
>  18  ctest7:00  ctest6:00  ctest5:00  ctest4:00
>  1C  temp:  00000000
>  20              ctest8:ff  istat: 06  dfifo: 00
>  24  dbc:   0e000001  dnad:  005eecde  dsp:   005ee038
>  30  dsps:  005eecde
>  34  dmode: 80
>  38  dcntl: 80  dwt:   00  dien:  1d
>  3C
> scsi0: Unexpected stacked interrupt, istat 06, sstat0 08, dstat 00
> scsi0: Failed to handle interrupt.  Failing commands and resetting SCSI bus and chip

On my installation i "fixed" this by switching off SCSI disconnects for my
disks. IIRC, this was by adding sim700=nodisc:0x70 to the kernel command
line.

I'm currently about 150 km away from my HP9000/720 during the weekend.
I'll test the proposed patch on Monday.

Cheers,
Jochen

Re: [parisc-linux] 720 - some progress

[Albert Strasheim]

[-- Attachment #1: Type: text/plain, Size: 2610 bytes --]

Hello,


On Fri, 28 Sep 2001, Matthew Wilcox wrote:

> On Thu, Sep 27, 2001 at 10:42:25AM -0400, Jurij Smakov wrote:
> > I hope I've got it right. It only emulates MFCTL and only when the
> > source control register is 27. It turns out, that pt_regs does not
> > have a member for cr26 and adding one does not look like an easy
> > task. 
> 
> I think the right way to do this would be...
> 
> > @@ -363,6 +364,17 @@
> >                 si.si_code = ILL_PRVOPC;
> >                 goto give_sigill;
> >         case 11:
> > +               if(!(regs->iir & 0xfc000000) && (((regs->iir & 0x1fe0)>>5) == 0x45)) {
> > +                 /* This is MFCTL instruction */
> > +                 fromcr = (regs->iir & 0x03e00000)>>21;
> > +                 togr = (regs->iir & 0x1f);
> > +                 /* Emulate the instruction if the read is from cr27 */
> 
> 		if (fromcr == 26 || fromcr == 27) {
> 			regs->gr[togr] = mfctl(fromcr);
> 			return;
> 		}

Making this change causes the build to fail:

make[1]: Entering directory `/tmp/.hppa/linux/arch/parisc/kernel'
hppa-linux-gcc -D__KERNEL__ -I/tmp/.hppa/linux/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fomit-frame-pointer -fno-strict-aliasing -fno-common -D__linux__ -pipe -fno-strength-reduce -mno-space-regs -mfast-indirect-calls -mdisable-fpregs -ffunction-sections -march=1.1 -mschedule=7100 -c -o traps.o traps.c
{standard input}: Assembler messages:
{standard input}:912: Error: Undefined absolute constant: 'fromcr'.
{standard input}:912: Error: Field out of range [0..31] (-1).
{standard input}:912: Error: Invalid operands
make[1]: *** [traps.o] Error 1
make[1]: Leaving directory `/tmp/.hppa/linux/arch/parisc/kernel'
make: *** [_dir_arch/parisc/kernel] Error 2

What gives?
 
> > +               }
> > +               /* Something else is wrong */
> >                 die_if_kernel("Privileged register - shouldn't happen!", regs, code);
> >                 si.si_code = ILL_PRVREG;
> >         give_sigill:
> 
> Can you give this a try?

Did. I don't think I messed it up. :-) Jurij's code compiles, so I'm
leaving it there for the moment and testing again.

Is your code functionally equivalent, or does it do something else
entirely?

Aside, I'm working on putting all the recent patches together into one
big fix720.diff.

Jochen suggested that in the case 11 handler, Jurij's

regs->gr[togr] = regs->cr27;

be replaced with

regs->iaoq[0] = regs->iaoq[1];
regs->iaoq[1] = regs->iaoq[0] + 4;

Is this right, or should I leave Jurij's code?

Regards,

Albert

[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]

Re: [parisc-linux] 720 - some progress

[Albert Strasheim]

[-- Attachment #1: Type: text/plain, Size: 998 bytes --]

Hello,

Some minor progress. I'm now netbooting a lifimage and then running my
programs from disk. The only problem is that I can't dpkg-reconfigure
the chroot I copied over to the disk after partially bootstrapping it
and nfsroot booting it because I can't install libterm-readline-gnu-perl
and related packages (currently the system seems to hang when I do a
dpkg -i libreadline4_4.2-5_hppa.deb. libc6 and a few others dpkg -i'd
fine though (running -pa22 with only the case 18: and without Jurij's
patches). I'm currently running -pa27+jurij (I had to manually apply his
2nd patch... it didn't like the traps.c I had).

Another question: shutdown doesn't seem to work? Is it because I am
running with init=/bin/sh (thus no init, and no runlevels to change), or
is something more sinister at work here? Is there some other way I can
"neatly" bring down my HP?

That's about it for now. I'm going to try booting a -pa27 without
jurij's fixes and with just the case fall-through.

Regards,

Albert

[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]

Re: [parisc-linux] 720 - some progress

[Albert Strasheim]

[-- Attachment #1: Type: text/plain, Size: 1395 bytes --]

Hello,

On Sat, 29 Sep 2001, Albert Strasheim wrote:

> Hello,
> 
> Some minor progress. I'm now netbooting a lifimage and then running my
> programs from disk. The only problem is that I can't dpkg-reconfigure
> the chroot I copied over to the disk after partially bootstrapping it
> and nfsroot booting it because I can't install libterm-readline-gnu-perl
> and related packages (currently the system seems to hang when I do a
> dpkg -i libreadline4_4.2-5_hppa.deb. libc6 and a few others dpkg -i'd
> fine though (running -pa22 with only the case 18: and without Jurij's
> patches). I'm currently running -pa27+jurij (I had to manually apply his
> 2nd patch... it didn't like the traps.c I had).

Not much luck with this one either. dpkg has just been sitting there
for more than an hour now.

Could I persuade someone with a working HP to bootstrap a new nfsroot,
please?

You probably also need to add the following packages:

busybox-static_0.60.1-1_hppa.deb
libc6_2.2.3-9_hppa.deb
libdb2_2.7.7.0-1_hppa.deb
libgdbmg1_1.7.3-27_hppa.deb
libncurses5_5.2.20010318-3_hppa.deb
libperl5.6_5.6.1-5_hppa.deb
libreadline4_4.2-5_hppa.deb
libterm-readline-gnu-perl_1.10-1_hppa.deb
perl_5.6.1-5_hppa.deb
perl-base_5.6.1-5_hppa.deb
perl-modules_5.6.1-5_all.deb

I think that should leave you with a system the 720/50 people can work
from. :-)

Regards,

Albert

[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]

Re: [parisc-linux] 720 - some progress

[Jochen Friedrich]

Hi Albert,

On Sat, 29 Sep 2001, Albert Strasheim wrote:

> > 		if (fromcr == 26 || fromcr == 27) {
> > 			regs->gr[togr] = mfctl(fromcr);
> > 			return;
> > 		}
>
> Making this change causes the build to fail:

> {standard input}:912: Error: Undefined absolute constant: 'fromcr'.
> {standard input}:912: Error: Field out of range [0..31] (-1).
> {standard input}:912: Error: Invalid operands

> Jochen suggested that in the case 11 handler, Jurij's
>
> regs->gr[togr] = regs->cr27;
>
> be replaced with
>
> regs->iaoq[0] = regs->iaoq[1];
> regs->iaoq[1] = regs->iaoq[0] + 4;

Not replaced, but added:

 		if (fromcr == 26) {
 			regs->gr[togr] = mfctl(26);
			regs->iaoq[0] = regs->iaoq[1];
			regs->iaoq[1] = regs->iaoq[0] + 4;
 			return;
 		}
 		if (fromcr == 27) {
 			regs->gr[togr] = mfctl(27);
			regs->iaoq[0] = regs->iaoq[1];
			regs->iaoq[1] = regs->iaoq[0] + 4;
 			return;
 		}

These commands:

regs->iaoq[0] = regs->iaoq[1];
regs->iaoq[1] = regs->iaoq[0] + 4;

just advance the instruction counter of the PA-RISC CPU, so after
returning from the trap, the CPU will move on instead of retrying the
failed op-code (which will, of course, trap again causing an infinite
loop)

Cheers,
Jochen

Re: [parisc-linux] 720 - some progress

[Albert Strasheim]

[-- Attachment #1.1: Type: text/plain, Size: 2289 bytes --]

Hello,

Just want to make sure I got this right. I've attached:

00-traps.c.orig
01_1-traps.c.quickfix
01_2-traps.c.case18
02-traps.c.case11
03-traps.c.jochen

00-traps.c.orig is the traps.c from -pa27. quickfix is the one that
simply adds a case 18: fall-through (and has worked quite well me for
me).

case18 is Jurij's first patch. case11 is his 2nd patch, which I had to
add in my hand. Then jochen is jochen's additions to that (please check
that I understood you correctly).

I've not included a traps.c with Matthew's code:

	...

	/* Emulate the instruction if the read is from cr27 */
	if (fromcr == 26 || fromcr == 27) {
		regs->gr[togr] = mfctl(fromcr);
		return;
	}
	/* Something else is wrong */

	...

It didn't compile for me and I'm not quite sure how to fix it and still
keep the original meaning intact. :-)

Regards,

Albert

On Sat, 29 Sep 2001, Jochen Friedrich wrote:

> Hi Albert,
> 
> On Sat, 29 Sep 2001, Albert Strasheim wrote:
> 
> > > 		if (fromcr == 26 || fromcr == 27) {
> > > 			regs->gr[togr] = mfctl(fromcr);
> > > 			return;
> > > 		}
> >
> > Making this change causes the build to fail:
> 
> > {standard input}:912: Error: Undefined absolute constant: 'fromcr'.
> > {standard input}:912: Error: Field out of range [0..31] (-1).
> > {standard input}:912: Error: Invalid operands
> 
> > Jochen suggested that in the case 11 handler, Jurij's
> >
> > regs->gr[togr] = regs->cr27;
> >
> > be replaced with
> >
> > regs->iaoq[0] = regs->iaoq[1];
> > regs->iaoq[1] = regs->iaoq[0] + 4;
> 
> Not replaced, but added:
> 
>  		if (fromcr == 26) {
>  			regs->gr[togr] = mfctl(26);
> 			regs->iaoq[0] = regs->iaoq[1];
> 			regs->iaoq[1] = regs->iaoq[0] + 4;
>  			return;
>  		}
>  		if (fromcr == 27) {
>  			regs->gr[togr] = mfctl(27);
> 			regs->iaoq[0] = regs->iaoq[1];
> 			regs->iaoq[1] = regs->iaoq[0] + 4;
>  			return;
>  		}
> 
> These commands:
> 
> regs->iaoq[0] = regs->iaoq[1];
> regs->iaoq[1] = regs->iaoq[0] + 4;
> 
> just advance the instruction counter of the PA-RISC CPU, so after
> returning from the trap, the CPU will move on instead of retrying the
> failed op-code (which will, of course, trap again causing an infinite
> loop)
> 
> Cheers,
> Jochen

[-- Attachment #1.2: traps.tar.gz --]
[-- Type: application/octet-stream, Size: 10240 bytes --]

[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]

Re: [parisc-linux] 720 - some progress

[Jochen Friedrich]

Hi Albert,

> case18 is Jurij's first patch. case11 is his 2nd patch, which I had to
> add in my hand. Then jochen is jochen's additions to that (please check
> that I understood you correctly).

Yes, it's exactly what i meant...

I'm currently re-evaluating the case 18 stuff. Maybe Jurijs proposal about
checking for unaligned access using a decoded opcode might me faster than
dereferencing 3 page tables and having to decode the opcode anyways to
check for read vs write access...

The only question that remains is if the paging code will handle a
recursive trap gracefully (i.e. when the unaligned access emulation code
traps again because of a page fault).

Cheers,
Jochen

Re: [parisc-linux] 720 - some progress

[Carlos O'Donell Jr.]

> 
> On my installation i "fixed" this by switching off SCSI disconnects for my
> disks. IIRC, this was by adding sim700=nodisc:0x70 to the kernel command
> line.
> 
> I'm currently about 150 km away from my HP9000/720 during the weekend.
> I'll test the proposed patch on Monday.
>

I usually use sim700=noneg:0xff,nodisc:0xff.
Turn it all off ;)

c. 

Re: [parisc-linux] 720 - some progress

[Michael S.Zick]

On Saturday 29 September 2001 01:00 am, Albert Strasheim wrote:
> regs->iaoq[0] = regs->iaoq[1];
> regs->iaoq[1] = regs->iaoq[0] + 4;
>
> Is this right, or should I leave Jurij's code?
>
Hello Albert,

An observation:
regs->iaoq[1] is the "following instruction" - where "following" means "in 
execution order".  So replacing the emulated instruction with this seems the 
obvious thing to do.

BUT...
Without examining the instruction (which was at iaoq[1] and is now at 
iaog[0]) I don't think it is safe to assume that the instruction following 
that one in execution order is at iaoq[1]+4 !!  (Branches, nullified 
instructions, conditional instructions, etc).

Perhaps...
Instead of trying to compute (determine) what is the next instruction in 
execution order following iaoq[1] ; iaoq[1] could be set to a value that 
would cause the hardware pipeline to fetch the correct following instruction.

Or perhaps...
A way could be found to use whatever "single step" controls are available to 
get the return made to iaoq[1] instead of iaoq[0] and leave the queues along.

Also...
What about the space register queue?  Might these instructions be in a 
different address space?

Mike

Re: [parisc-linux] 720 - some progress

[Michael S.Zick]

Albert and other 720 folks;

I have been reading the directions (please forgive me for that)...

It looks (reads) as if it possible to return to the faulting instruction
(MFCTL in this case) without executing it.  If so, then adjusting the
instruction (and space) queues within the fault handler can be avoided;
also avoiding problems with finding the correct "following instruction"
address.

In general: 
When executing a group 3 fault (MFCTL), the PSW register is
copied into the IPSW register.  The "N" bit of the PSW (now in the IPSW)
is a copy of the "nullify bit" of the instruction PRECEDING the
instruction at iaoq[0].  The nullify bit of the instruction preceding the
MFCTL instruction was "zero" (or we wouldn't be here).
So rather than trying to adjust the addresses in the instruction/space
queues, it should be possible to just set the "N" bit of the IPSW (or its
representation in the interrupted registers structure).  Then, when the
finally makes it back to a "Return from Interrupt" instruction, our faked
"N" bit will be loaded into the PSW and the processor will skip the MFCTL
instruction which gets returned to.

Having zero experience with this processor and no way to test my idea; I
have done some "cut and paste" from the documentation - perhaps somebody
could check me on this idea.

Mike

PA-RISC 1.1 Architecture and Instruction Set Reference Manual
HP Part Number: 09740-90039
Printed in U.S.A. February 1994
Third Edition

- - - -

Trap:
  Traps include two sorts of possibilities: either the function requested by 
the current instruction cannot or should not be carried out, or system 
intervention is desired by the user before or after the instruction is 
executed. Examples of the first type include arithmetic operations that 
result in signed overflow and instructions executed with insufficient 
privilege for their intended function. Such instructions are normally not
re-executed. Examples of the second type include the debugging support traps. 
Traps are synchronous with respect to the instruction stream.

- - - -

Group 3:    
6 Instruction TLB miss fault/Instruction page fault
7 Instruction memory protection trap
30 Instruction debug trap
8 Illegal instruction trap
9 Break instruction trap
10 Privileged operation trap
11 Privileged register trap
12 Overflow trap
13 Conditional trap
14 Assist exception trap
15 Data TLB miss fault/Data page fault
16 Non-access instruction TLB miss fault
17 Non-access data TLB miss fault/Non-access data page fault
26 Data memory access rights trap
27 Data memory protection ID trap
28 Unaligned data reference trap

- - - -

Name	Privileged register trap (11)

Cause	An attempt is being made to write to a privileged space register or 	
access a privileged control register without being at the most privileged 
level (priv= 0)

Parameters    	IIR ­ The instruction causing the trap
IIA Queue    	Front ­ Address of the instruction causing the trap
		Back ­ Address of the following instruction

Notes    This interruption may be caused by the MOVE TO SPACE REGISTER, 
MOVE TO CONTROL REGISTER, or MOVE FROM CONTROL REGISTER 
instructions.

- - - -

Processor state is encoded in a 32-bit register called the Processor Status 
Word (PSW). When an interruption occurs, the old value of the PSW is saved in 
the Interruption Processor Status Word (IPSW) and usually all defined PSW 
bits are set to 0. The format of the PSW is shown in Figure 2-9.
 (copy is unreadable as e-mail ... "N" is bit 10dec.)
Figure 2-9. Processor Status Word

The PSW is set to the contents of the IPSW by the RETURN FROM INTERRUPTION 
and RETURN FROM INTERRUPTION AND RESTORE instructions. The interruption 
handler may restore the original PSW, modify selected bits, or may change the 
PSW to an entirely new value.

- - - -

N    Nullify. 
The current instruction is nullified when this bit is 1. This bit is set to 1 
by an instruction that nullifies the following instruction.

- - - -
I am ignoring the other 423 pages of the manual - which might be a mistake.
_ _ _ _

All in all, the way I read it - we can emulate the effect of an instruction 
prior to the MFCTL instruction that has its "nullify" bit set by setting the 
"N" bit in the IPSW.  With the effect that when the RFI is completed, the 
hardware will just skip the MFCTL which was just emulated.

Mike

Re: [parisc-linux] 720 - some progress

[John Marvin]

> It looks (reads) as if it possible to return to the faulting instruction
> (MFCTL in this case) without executing it.  If so, then adjusting the
> instruction (and space) queues within the fault handler can be avoided;
> also avoiding problems with finding the correct "following instruction"
> address.

Using the nullify method you talk about does work, but the normal
convention is to advance the pc queue (there are some performance
advantages, particularly in the case where the instruction we are
emulating is in the delay slot of a branch).  The problem you describe
finding the following instruction doesn't exist.  You are correct about
the space queue though, but only in the case for a delay slot in the
branch to the gateway page.  The correct method of advancing the queue is
the one that has been proposed in the various patches, i.e.:

	regs->iaoq[0] = regs->iaoq[1];
	regs->iaoq[1] += 4;

To be perfectly correct, this should be added:

	regs->iasq[0] = regs->iasq[1];

But, again, that last is only necessary if someone actually puts a mfctl
in the delay slot of the branch to the gateway page (a kernel call) and
since kernel calls are already provided, we know that no such thing
actually happens, nor is it likely to happen unless someone handcodes
their own kernel call. I would put the line in though.

Here is why there is not a problem advancing the queue as above:
the only way that "regs->iaoq[1] += 4" would do the wrong thing would
be if we were emulating a branch instruction. Since we know we are
emulating a mfctl instruction, this is not the case. Note that if
someone needs to emulate a branch instruction, computing the new
value of iaoq[1] would be part of that emulation.

John Marvin
jsm@fc.hp.com

Re: [parisc-linux] 720 - some progress

[Michael S. Zick]

John;

Thanks a lot for the explanation - I am not surprised that the hardware
is more complex in its operation than the documentation tries to describe.
I have left the full text of your explanation attached so that future
readers of the mailing list archives don't get "half the story".

The ability to NOT EXECUTE the instruction returned to from a fault handler
might come in handy to somebody, someday.

What I was concerned about was the chance that the instruction addressed
by iaoq[1] was a branch (or taken conditional branch) instruction.  

Which, as you point out, could only happen if the MFCTL instruction was 
in the delay slot of a branch instruction.  (Has the compiler been told to
prohibit MFCTL in the delay slot? Not relavent here.)

With the description given in the documentation, then the queue state 
returned would have to be:

regs->iaoq[0] == branch instruction address
regs->iaoq[1] == target instruction address

I.E: That the hardware instruction address prediction was done prior to the
point in the hardware the address queue snapshot is taken on a fault.

The point you make describes instruction address prediction being done
after the point in the hardware flow that the address queue snapshot is
taken.

I.E:
regs->iaoq[0] == branch instruction address
regs->iaoq[1] == branch instruction address + 4

Is a just fine thing to do - the branch instruction will be executed with
the result that whatever was pointed to by iaoq[1] would be replaced by the 
target address (or ignored) in the process.

Certainly a complexity beyond printed documentation.
Anywho - its in the mail archives now for anyone that needs the
information.

Again, Thanks for the extra effort on these details.
Mike

> Date: Sunday, September 30, 2001 2:12 AM
> 
> > It looks (reads) as if it possible to return to the faulting instruction
> > (MFCTL in this case) without executing it.  If so, then adjusting the
> > instruction (and space) queues within the fault handler can be avoided;
> > also avoiding problems with finding the correct "following instruction"
> > address.
> 
> Using the nullify method you talk about does work, but the normal
> convention is to advance the pc queue (there are some performance
> advantages, particularly in the case where the instruction we are
> emulating is in the delay slot of a branch).  The problem you describe
> finding the following instruction doesn't exist.  You are correct about
> the space queue though, but only in the case for a delay slot in the
> branch to the gateway page.  The correct method of advancing the queue is
> the one that has been proposed in the various patches, i.e.:
> 
> 	regs->iaoq[0] = regs->iaoq[1];
> 	regs->iaoq[1] += 4;
> 
> To be perfectly correct, this should be added:
> 
> 	regs->iasq[0] = regs->iasq[1];
> 
> But, again, that last is only necessary if someone actually puts a mfctl
> in the delay slot of the branch to the gateway page (a kernel call) and
> since kernel calls are already provided, we know that no such thing
> actually happens, nor is it likely to happen unless someone handcodes
> their own kernel call. I would put the line in though.
> 
> Here is why there is not a problem advancing the queue as above:
> the only way that "regs->iaoq[1] += 4" would do the wrong thing would
> be if we were emulating a branch instruction. Since we know we are
> emulating a mfctl instruction, this is not the case. Note that if
> someone needs to emulate a branch instruction, computing the new
> value of iaoq[1] would be part of that emulation.
> 
> John Marvin
> jsm@fc.hp.com
> 
> 
> _______________________________________________
> parisc-linux mailing list
> parisc-linux@lists.parisc-linux.org
> http://lists.parisc-linux.org/cgi-bin/mailman/listinfo/parisc-linux