Boot error on C200+

parisc-linux Ryan Bradetich 4 participants 7 messages Sep 2, 2000 – Sep 3, 2000

lore

Share & tools

lore

Ryan Bradetich

author

2000-09-02 22:41 UTC #0 lore raw

Hello,

I am getting the following error when I attempt to boot parisc-linux on the
C200+.

VFS: Mounted root (nfs filesystem) readonly.
execve /sbin/init c0270008 c0270030

Kernel Fault: Code=7 regs=c7f98248 (Addr=00000110)

PSW : 0004000b GR 1 : 00002000 GR 2 : 00013403 GR 3 : 00000000 GR 4 : 2001ff74 GR 5 : 00000000 GR 6 : 000777f4 GR 7 : 000010c4 GR 8 : 000011bc GR 9 : c7f98000 GR10 : c022fa78 GR11 : c0270030 GR12 : c0270008 GR13 : c022fe14 GR14 : c0270000 GR15 : 617bfdfb GR16 : c027c60c GR17 : 00000000 GR18 : c02b0000 GR19 : 00000001 GR20 : 00000037 GR21 : 00089b9c GR22 : 00089bd8 GR23 : 000010c4 GR24 : 2001ff74 GR25 : 00000001 GR26 : 00000000 GR27 : 00088f00 GR28 : b64d8e60 GR29 : b44302d0 GR30 : 20020140 GR31 : 00022d63 SR0 : 00002000 SR1 : fffd2dff SR2 : 00000000 SR3 : 00002000 SR4 : 00000000 SR5 : 00002000 SR6 : 00002000 SR7 : 00002000

IASQ : 00000000 00000000 IAOQ : 00000110 00000114 ORIG_R28 : ffdf7fff
IIR : 43ffff40 ISR : 00000000 IOR : 00000000

Paul Bame helped me start tracking this error down. I wanted to post his
analysis along with the boot message to this list for further comment. (Hopefully his analysis will help other how to start debugging these errors
as Paul helped me.)

- Kernel Fault Code 7 is an Instruction Memory Protection Trap.

- Stack Pointer (GR30) is in user space. Most of the time if the
kernel
is in kernel space GR30 will look like this: 0xcxxxxxxx.

- GR2 is often the address where a subroutine will return, so it tells where
it was called from. In this case: 00013403.

- The last two bits of GR2 are non-zero, which is consistent with a userspace program.

- Perform an objdump -d on sash and look for address 133f8.

        (GR2 & 0xfffffffc) - 0x8 (two instructions).

   133f8:       e8 47 12 b4     b,l 22d58 <__libc_fcntl>,rp
   133fc:       34 19 00 02     ldi 1,r25
   13400:       8f 9f 20 50     cmpib,<> -1,ret0,13430

<check_one_fd+0x44>
13404: 4b c2 3f 59 ldw -54(sr0,sp),rp

- Find out who/what called your kernel, by looking up the sysmbols in sash (Note the sasy binary must contain symbols):

hppa-linux-nm -n sash | grep 22d58

00022d58 W __fcntl
00022d58 T __libc_fcntl
00022d58 W fcntl

I am going to start digging around in sash and glibc to see if I can figure out
anymore information on this problem. Any help/advice is appreciated.

Thanks,

Ryan

David Huggins-Daines

2000-09-03 01:01 UTC #1 lore raw

Quoted 13 lines · Ryan Bradetich

Kernel Fault: Code=7 regs=c7f98248 (Addr=00000110)
PSW : 0004000b GR 1 : 00002000 GR 2 : 00013403 GR 3 : 00000000 GR 4 : 2001ff74 GR 5 : 00000000 GR 6 : 000777f4 GR 7 : 000010c4 GR 8 : 000011bc GR 9 : c7f98000 GR10 : c022fa78 GR11 : c0270030 GR12 : c0270008 GR13 : c022fe14 GR14 : c0270000 GR15 : 617bfdfb GR16 : c027c60c GR17 : 00000000 GR18 : c02b0000 GR19 : 00000001 GR20 : 00000037 GR21 : 00089b9c GR22 : 00089bd8 GR23 : 000010c4 GR24 : 2001ff74 GR25 : 00000001 GR26 : 00000000 GR27 : 00088f00 GR28 : b64d8e60 GR29 : b44302d0 GR30 : 20020140 GR31 : 00022d63 SR0 : 00002000 SR1 : fffd2dff SR2 : 00000000 SR3 : 00002000 SR4 : 00000000 SR5 : 00002000 SR6 : 00002000 SR7 : 00002000

Quoted 1 line

IASQ : 00000000 00000000 IAOQ : 00000110 00000114 ORIG_R28 : ffdf7fff

                           ^^^^^^^^^^^^^^^^^^^^^^^^

That is the syscall gateway page. Note that the low bits of IAOQ are clear, so you are running in kernel mode and kernel space at this point. Note also that the IAOQ points to just after the 'gate' instruction in linux_gateway_page, and from the look of the space registers, you've managed to successfully execute the instruction in the delay slot of the gate (mtsp %r0,%sr4) but nothing else.

Note that GR20 is 0x37, which is the syscall number for fcntl(), which confirms your earlier findings :-)

Quoted 1 line

IIR : 43ffff40 ISR : 00000000 IOR : 00000000

That IIR doesn't look like any instruction on the syscall page that I know of. Perhaps the gateway page is not getting mapped properly. The fact that it is trapping after the 'gate' instruction seems to support this.

Signature · 2 lines

[email protected], http://www.linuxcare.com/
Linuxcare. Support for the revolution.

Ryan Bradetich

author

2000-09-03 03:33 UTC #2 lore raw

Quoted 16 lines · David Huggins-Daines

Quoted 13 lines · Ryan Bradetich
Kernel Fault: Code=7 regs=c7f98248 (Addr=00000110)
PSW : 0004000b GR 1 : 00002000 GR 2 : 00013403 GR 3 : 00000000 GR 4 : 2001ff74 GR 5 : 00000000 GR 6 : 000777f4 GR 7 : 000010c4 GR 8 : 000011bc GR 9 : c7f98000 GR10 : c022fa78 GR11 : c0270030 GR12 : c0270008 GR13 : c022fe14 GR14 : c0270000 GR15 : 617bfdfb GR16 : c027c60c GR17 : 00000000 GR18 : c02b0000 GR19 : 00000001 GR20 : 00000037 GR21 : 00089b9c GR22 : 00089bd8 GR23 : 000010c4 GR24 : 2001ff74 GR25 : 00000001 GR26 : 00000000 GR27 : 00088f00 GR28 : b64d8e60 GR29 : b44302d0 GR30 : 20020140 GR31 : 00022d63 SR0 : 00002000 SR1 : fffd2dff SR2 : 00000000 SR3 : 00002000 SR4 : 00000000 SR5 : 00002000 SR6 : 00002000 SR7 : 00002000
Quoted 1 line
IASQ : 00000000 00000000 IAOQ : 00000110 00000114 ORIG_R28 : ffdf7fff

Quoted 8 lines

                           ^^^^^^^^^^^^^^^^^^^^^^^^
That is the syscall gateway page. Note that the low bits of IAOQ are clear, so you are running in kernel mode and kernel space at this point. Note also that the IAOQ points to just after the 'gate' instruction in linux_gateway_page, and from the look of the space registers, you've managed to successfully execute the instruction in the delay slot of the gate (mtsp %r0,%sr4) but nothing else.

I just wanted to verify I understood how you obtained this information...

hppa-linux-objdump -d vmlinux

c010d100 <linux_gateway_entry>:

c010d100:       00 00 e4 a1     mfsp sr7,r1
c010d104:       00 01 d8 20     mtsp r1,sr3
c010d108:       e8 00 20 00     b,gate c010d110 <linux_gateway_entry+0x10>,r0
c010d10c:       00 00 38 20     mtsp r0,sr4
c010d110:       00 00 78 20     mtsp r0,sr5

SR4 = 0, but SR5 != 0 ... therefore the delay slot of the gate instruction executed.

Quoted 2 lines

Note that GR20 is 0x37, which is the syscall number for fcntl(), which confirms your earlier findings :-)

David Huggins-Daines

2000-09-03 05:18 UTC #3 lore raw

Quoted 11 lines · Ryan Bradetich

Quoted 2 lines
Note that GR20 is 0x37, which is the syscall number for fcntl(), which confirms your earlier findings :-)
From arch/parisc/kernel/syscall.S
ENTRY_NAME(sys_ioctl)
ENTRY_NAME(sys_fcntl) /* 55 */
ENTRY_NAME(sys_socketpair)
55 = 0x37 .... I understand that....I don't see where GR20 is mapped to the the syscall number.... (Not really important that I know now... but curious)

A system call on PA-RISC Linux looks like this:

be,l 0x100(%sr2,%r0),%sr0,%r31
ldi <syscall number>,%r20

(with six possible arguments in %r26 - %r21)

Quoted 3 lines

From this statement, I assume it is a kernel problem and not a glibc problem ... since the kernel would perform the mapping? I'll start digging around in the kernel and see what I can find.... any hints where to start?

I think the explanation regarding the TLB miss handlers is correct, but I haven't tried on the C360 since it doesn't get to userland for me :(

Signature · 2 lines

[email protected], http://www.linuxcare.com/
Linuxcare. Support for the revolution.

[email protected]

2000-09-03 17:00 UTC #4 lore raw

In reply to David Huggins-Daines

=
= > IIR : 43ffff40 ISR : 00000000 IOR : 00000000
=
= That IIR doesn't look like any instruction on the syscall page that I = know of.

I've seen this IIR consistently (so far) on pa2.0 processors when they try to fetch an instruction from an unmapped page.

-P

Bob Pflederer

2000-09-03 02:04 UTC #5 lore raw

In reply to Ryan Bradetich

I see this on C180. It goes away if you modify entry.S to use PA2.0-style tlb inserts instead of the PA1.1-style tlb inserts. Try the attached patch. It modifies the tlb miss handlers at startup to use PA2.0 tlb inserts if you have a PA2.0 cpu. PA-8000 docs claim that PA1.1 tlb inserts are not supported, so I suspect we're hitting a case that doesn't work.

Would someone who has CVS write access be willing to commit this patch? It's the last thing I need to make C180 work.

-Bob

Quoted 72 lines · Ryan Bradetich

Hello,
I am getting the following error when I attempt to boot parisc-linux on the
C200+.
VFS: Mounted root (nfs filesystem) readonly.
execve /sbin/init c0270008 c0270030
Kernel Fault: Code=7 regs=c7f98248 (Addr=00000110)
PSW : 0004000b GR 1 : 00002000 GR 2 : 00013403 GR 3 : 00000000 GR 4 : 2001ff74 GR 5 : 00000000 GR 6 : 000777f4 GR 7 : 000010c4 GR 8 : 000011bc GR 9 : c7f98000 GR10 : c022fa78 GR11 : c0270030 GR12 : c0270008 GR13 : c022fe14 GR14 : c0270000 GR15 : 617bfdfb GR16 : c027c60c GR17 : 00000000 GR18 : c02b0000 GR19 : 00000001 GR20 : 00000037 GR21 : 00089b9c GR22 : 00089bd8 GR23 : 000010c4 GR24 : 2001ff74 GR25 : 00000001 GR26 : 00000000 GR27 : 00088f00 GR28 : b64d8e60 GR29 : b44302d0 GR30 : 20020140 GR31 : 00022d63 SR0 : 00002000 SR1 : fffd2dff SR2 : 00000000 SR3 : 00002000 SR4 : 00000000 SR5 : 00002000 SR6 : 00002000 SR7 : 00002000
IASQ : 00000000 00000000 IAOQ : 00000110 00000114 ORIG_R28 : ffdf7fff
IIR : 43ffff40 ISR : 00000000 IOR : 00000000
Paul Bame helped me start tracking this error down. I wanted to post his
analysis along with the boot message to this list for further comment. (Hopefully his analysis will help other how to start debugging these errors
as Paul helped me.)
- Kernel Fault Code 7 is an Instruction Memory Protection Trap.
- Stack Pointer (GR30) is in user space. Most of the time if the
kernel
is in kernel space GR30 will look like this: 0xcxxxxxxx.
- GR2 is often the address where a subroutine will return, so it tells where
it was called from. In this case: 00013403.
- The last two bits of GR2 are non-zero, which is consistent with a userspace program.
- Perform an objdump -d on sash and look for address 133f8.
        (GR2 & 0xfffffffc) - 0x8 (two instructions).
   133f8:       e8 47 12 b4     b,l 22d58 <__libc_fcntl>,rp
   133fc:       34 19 00 02     ldi 1,r25
   13400:       8f 9f 20 50     cmpib,<> -1,ret0,13430
<check_one_fd+0x44>
13404: 4b c2 3f 59 ldw -54(sr0,sp),rp
- Find out who/what called your kernel, by looking up the sysmbols in sash (Note the sasy binary must contain symbols):
hppa-linux-nm -n sash | grep 22d58
00022d58 W __fcntl
00022d58 T __libc_fcntl
00022d58 W fcntl
I am going to start digging around in sash and glibc to see if I can figure out
anymore information on this problem. Any help/advice is appreciated.
Thanks,

Quoted 7 lines

Ryan
---------------------------------------------------------------------------
To unsubscribe: send e-mail to [email protected] with `unsubscribe' as the subject.

Index: arch/parisc/kernel/entry.S
===================================================================
RCS file: /home/cvs/parisc/linux-2.3/arch/parisc/kernel/entry.S,v retrieving revision 1.32

entry.S +51 -0

diff -u -p -r1.32 entry.S
@@ -655,12 +655,18 @@ dtlb_miss:
 	depi		1,12,1,prot
 	extru,=         pte,_PAGE_USER_BIT,1,r0
 	depi		7,11,3,prot   /* Set for user space (1 rsvd for read) */
+	extru,= 	pte,_PAGE_GATEWAY_BIT,1,r0
+	depi		0,11,2,prot	/* If Gateway, Set PL2 to 0 */
 
 	/* Get rid of prot bits and convert to page addr for idtlba */
 
 	depi		0,31,12,pte
 	extru		pte,24,25,pte
 
+
+	/* The following may get patched with idtlb_insert_pa20 */
+	.export		idtlb_insert0,code
+idtlb_insert0:
 	mfsp		%sr1,t0  /* Save sr1 so we can use it in tlb inserts */
 	mtsp		spc,%sr1

@@ -671,6 +677,8 @@ dtlb_miss:
 
 	rfir
 	nop
+	.export		idtlb_insert0_end,code
+idtlb_insert0_end:
 
 itlb_miss:

@@ -712,6 +720,8 @@ itlb_miss_common:
 	copy            spc,prot        /* init prot with faulting space */
 	dep		pte,8,7,prot
 
+	extru,=		pte,_PAGE_NO_CACHE_BIT,1,r0
+	depi		1,12,1,prot
 	extru,=         pte,_PAGE_USER_BIT,1,r0
 	depi		7,11,3,prot   /* Set for user space (1 rsvd for read) */
 	extru,= 	pte,_PAGE_GATEWAY_BIT,1,r0

@@ -722,6 +732,9 @@ itlb_miss_common:
 	depi		0,31,12,pte
 	extru		pte,24,25,pte
 
+	/* The following may get patched with idtlb_insert_pa20 */
+	.export		iitlb_insert,code
+iitlb_insert:
 	mfsp		%sr1,t0  /* Save sr1 so we can use it in tlb inserts */
 	mtsp		spc,%sr1

@@ -732,6 +745,8 @@ itlb_miss_common:
 
 	rfir
 	nop
+	.export		iitlb_insert_end,code
+iitlb_insert_end:
 
 itlb_miss_kernel:
 	b               itlb_miss_common

@@ -773,12 +788,18 @@ dbit_trap:
 	depi		1,12,1,prot
 	extru,=         pte,_PAGE_USER_BIT,1,r0
 	depi		7,11,3,prot /* Set for user space (1 rsvd for read) */
+	extru,= 	pte,_PAGE_GATEWAY_BIT,1,r0
+	depi		0,11,2,prot	/* If Gateway, Set PL2 to 0 */
 
 	/* Get rid of prot bits and convert to page addr for idtlba */
 
 	depi		0,31,12,pte
 	extru		pte,24,25,pte
 
+
+	/* The following may get patched with idtlb_insert_pa20 */
+	.export		idtlb_insert1,code
+idtlb_insert1:
 	mfsp		%sr1,t0  /* Save sr1 so we can use it in tlb inserts */
 	mtsp		spc,%sr1

@@ -789,7 +810,37 @@ dbit_trap:
 
 	rfir
 	nop
+	.export		idtlb_insert1_end,code
+idtlb_insert1_end:
+
+	.level		2.0
+	.text
+	.export		idtlb_insert_pa20,code
+idtlb_insert_pa20:
+        depd    	%r17,31,32,%r17
+        depdi   	0,46,15,%r17
+	idtlbt		%r16,%r17
+	rfir
+	nop
+	nop
+	nop
+	.export		idtlb_insert_pa20_end,code
+idtlb_insert_pa20_end:
+
+	.export		iitlb_insert_pa20,code
+iitlb_insert_pa20:
+        depd    	%r17,31,32,%r17
+        depdi   	0,46,15,%r17
+	iitlbt		%r16,%r17
+	rfir
+	nop
+	nop
+	nop
+	.export		iitlb_insert_pa20_end,code
+iitlb_insert_pa20_end:
 
+	.level		1.1
+	.text
 	.import handle_interruption,code
 
 kernel_bad_space:

Index: arch/parisc/kernel/traps.c
===================================================================
RCS file: /home/cvs/parisc/linux-2.3/arch/parisc/kernel/traps.c,v retrieving revision 1.18

traps.c +53 -2

80 lines not on this page · raw message

Ryan Bradetich

author

2000-09-03 03:37 UTC #6 lore raw

Bob,

Testing the patch now... if it works for me ... I'll commit the patch.

Thanks for the patch!

Ryan

Quoted 11 lines · Bob Pflederer

I see this on C180. It goes away if you modify entry.S to use PA2.0-style tlb inserts instead of the PA1.1-style tlb inserts. Try the attached patch. It modifies the tlb miss handlers at startup to use PA2.0 tlb inserts if you have a PA2.0 cpu. PA-8000 docs claim that PA1.1 tlb inserts are not supported, so I suspect we're hitting a case that doesn't work.
Would someone who has CVS write access be willing to commit this patch? It's the last thing I need to make C180 work.
-Bob