[parisc-linux] Boot error on C200+

[parisc-linux] Boot error on C200+

[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,

Ryan

Re: [parisc-linux] Boot error on C200+

[David Huggins-Daines]

Ryan Bradetich <rbradetich@uswest.net> writes:

> 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
                           ^^^^^^^^^^^^^^^^^^^^^^^^

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 :-)

>  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.

-- 
dhd@linuxcare.com, http://www.linuxcare.com/
Linuxcare. Support for the revolution.

Re: [parisc-linux] Boot error on C200+

[Bob Pflederer]

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

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

On Sat, Sep 02, 2000 at 04:41:46PM -0600, Ryan Bradetich wrote:
> 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
> 
> 
> 
> ---------------------------------------------------------------------------
> To unsubscribe: send e-mail to parisc-linux-request@thepuffingroup.com with
> `unsubscribe' as the subject.

[-- Attachment #2: tlb.patch --]
[-- Type: text/plain, Size: 5528 bytes --]

Index: arch/parisc/kernel/entry.S
===================================================================
RCS file: /home/cvs/parisc/linux-2.3/arch/parisc/kernel/entry.S,v
retrieving revision 1.32
diff -u -p -r1.32 entry.S
--- entry.S	2000/08/30 22:28:35	1.32
+++ entry.S	2000/09/02 04:20:06
@@ -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
diff -u -p -r1.18 traps.c
--- traps.c	2000/08/28 20:16:11	1.18
+++ traps.c	2000/09/02 04:20:06
@@ -29,6 +29,7 @@
 #include <asm/atomic.h>
 
 #include <asm/smp.h>
+#include <asm/pgalloc.h>
 
 static inline void console_verbose(void)
 {
@@ -350,8 +351,7 @@ extern void fault_vector(void);
 
 int __init check_ivt(char * iva)
 {
-	int i;
-	u32 check = 0, *p;
+	u32 *p;
 
 	if(strcmp(iva, "cows can fly"))
 		return -1;
@@ -375,7 +375,55 @@ int __init check_ivt(char * iva)
 
 	return 0;
 }
+
+extern void iitlb_insert(), idtlb_insert0(), idtlb_insert1();
+extern void iitlb_insert_end(), idtlb_insert0_end(), idtlb_insert1_end();
+extern void iitlb_insert_pa20(), idtlb_insert_pa20();
+extern void iitlb_insert_pa20_end(), idtlb_insert_pa20_end();
+
+static inline void
+flush_kernel_icache_range(unsigned long start, unsigned long size)
+{
+	register unsigned long end = start + size;
+	register unsigned long i;
+
+	for (i = start; i <= end; i += L1_CACHE_BYTES) {
+		asm volatile("fic 0(%%sr0, %0)" : : "r" (i));
+	}
+}
+
+void
+trap_patch_tlb_inserts()
+{
+	int ilen = iitlb_insert_pa20_end-iitlb_insert_pa20;
+	int dlen = idtlb_insert_pa20_end-idtlb_insert_pa20;
 	
+	if(ilen != (iitlb_insert_end-iitlb_insert)) {
+		panic("trap_patch_tlb_inserts: iitlb_insert_pa20 bad size");
+	}
+	if(dlen != (idtlb_insert0_end-idtlb_insert0)) {
+		panic("trap_patch_tlb_inserts: idtlb_insert_pa20 bad size");
+	}
+	if(dlen != (idtlb_insert0_end-idtlb_insert0)) {
+		panic("trap_patch_tlb_inserts: idtlb_insert_pa20 bad size");
+	}
+
+	memcpy (iitlb_insert, iitlb_insert_pa20, ilen);
+	memcpy (idtlb_insert0, idtlb_insert_pa20, dlen);
+	memcpy (idtlb_insert1, idtlb_insert_pa20, dlen);
+
+	flush_kernel_dcache_range((unsigned long)iitlb_insert, ilen);
+	flush_kernel_dcache_range((unsigned long)idtlb_insert0, dlen);
+	flush_kernel_dcache_range((unsigned long)idtlb_insert1, dlen);
+
+	flush_kernel_icache_range((unsigned long)iitlb_insert, ilen);
+	flush_kernel_icache_range((unsigned long)idtlb_insert0, dlen);
+	flush_kernel_icache_range((unsigned long)idtlb_insert1, dlen);
+
+        asm volatile("sync");
+
+}
+
 void __init trap_init(void)
 {
 	volatile long eiem;
@@ -385,6 +433,9 @@ void __init trap_init(void)
 	
 	if(check_ivt((void *)fault_vector))
 		panic("IVT invalid");
+	if(boot_cpu_data.cpu_type >= pcxu) {
+		trap_patch_tlb_inserts();
+	}
 
 	mtctl(__pa(&fault_vector), 14);
 	mtctl(0, 30);

Re: [parisc-linux] Boot error on C200+

[Ryan Bradetich]

David Huggins-Daines wrote:

> Ryan Bradetich <rbradetich@uswest.net> writes:
>
> > 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
>                            ^^^^^^^^^^^^^^^^^^^^^^^^
>
> 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.

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

Re: [parisc-linux] Boot error on C200+

[Ryan Bradetich]

Bob,

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

Thanks for the patch!

Ryan


Bob Pflederer wrote:

> 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

[parisc-linux] Boot error on C200+

[John Marvin]

Bob Pflederer wrote:

> 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.

Please don't anyone do this.  I've got another fix in progress.  Bob is
correct that we shouldn't be using the PA1.1 inserts.  But he was fooled
by redundant code in trap_init(), thinking that we haven't gone virtual
yet.  Code in trap_init() sets the iva, but it should be removed (which I
will do).  We actually set the iva (and install a small set of mappings)
very early in real/head.S and go virtual before calling start_parisc().
We never run any C code in real mode.  Bob's patch means that we would
still run 1.1 inserts for a while, and then it would be patching the tlb
miss handlers WHILE THEY ARE POTENTIALLY BEING USED!

My fix will do a simple 3-4 assembly instruction test for PA2.0 in
head.S, and then install the appropriate iva. This wastes 2K of memory
having two iva's, but is a lot simpler to do in assembly very early
in the boot process. I'll try to get this done by Tuesday morning
(I work throughout the night Monday).

John Marvin
jsm@fc.hp.com

Re: [parisc-linux] Boot error on C200+

[David Huggins-Daines]

Ryan Bradetich <rbradetich@uswest.net> writes:

> > 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)

> 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 :(

-- 
dhd@linuxcare.com, http://www.linuxcare.com/
Linuxcare. Support for the revolution.

Re: [parisc-linux] Boot error on C200+

[bame]

= 
= >  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

Re: [parisc-linux] Boot error on C200+

[Bob Pflederer]

I noticed that John committed something this morning, so I tried it out
on my C180, and it works!  For the first time, the CVS kernel boots 
un-modified on my C180.  Odds are good that it will also work in C200+.

Thanks, John.

> 
> My fix will do a simple 3-4 assembly instruction test for PA2.0 in
> head.S, and then install the appropriate iva. This wastes 2K of memory
> having two iva's, but is a lot simpler to do in assembly very early
> in the boot process. I'll try to get this done by Tuesday morning
> (I work throughout the night Monday).
> 
> John Marvin
> jsm@fc.hp.com
> 

Re: [parisc-linux] Boot error on C200+

[Ryan Bradetich]

Bob and John,

I have the latest CVS kernel on booting on the C200+ and a 755.
They both booted to an ash prompt without any modifications!

Just wanted to let everyone know the changes John made are
working great for me in PARISC 1.1 and PARISC 2.0 land!

Thanks,

Ryan

P.S. It is a great feeling to see my C200+ finally boot linux!

Bob Pflederer wrote:

> I noticed that John committed something this morning, so I tried it out
> on my C180, and it works!  For the first time, the CVS kernel boots
> un-modified on my C180.  Odds are good that it will also work in C200+.
>
> Thanks, John.
>
> >
> > My fix will do a simple 3-4 assembly instruction test for PA2.0 in
> > head.S, and then install the appropriate iva. This wastes 2K of memory
> > having two iva's, but is a lot simpler to do in assembly very early
> > in the boot process. I'll try to get this done by Tuesday morning
> > (I work throughout the night Monday).
> >
> > John Marvin
> > jsm@fc.hp.com
> >
>
> ---------------------------------------------------------------------------
> To unsubscribe: send e-mail to parisc-linux-request@thepuffingroup.com with
> `unsubscribe' as the subject.