[Linux-ia64] Kernel panic in dtlb_fault

[Linux-ia64] Kernel panic in dtlb_fault

[Uros Prestor]

When I try booting the new kernel on a 2xB3 BigSur running BIOS 89 I get
the following kernel panic:

     VFS: Mounted root (ext2 filesystem) readonly.
     Freeing unused kernel memory: 352kB freed
     Unable to handle kernel paging request at virtual address
     2000000000044008
     init[1]: Oops 8813272891392
     psr : 0000101008026030 ifs : 8000000000000185 ip  :
     [<e000000000500820>]
     ...
     Kernel panic: Attempted to kill init!

The IP points inside the dtlb_fault code.  Any ideas what's going on
here?  The panic happens both with SMP and UP kernels.  I have disabled
the VHPT (CONFIG_DISABLE_VHPT=y).  Anything else I am missing?

Thanks,
Uros

--
Uros Prestor
uros@turbolinux.com

Re: [Linux-ia64] Kernel panic in dtlb_fault

[Uros Prestor]

David Mosberger wrote:

>   Uros> The IP points inside the dtlb_fault code.  Any ideas what's
>   Uros> going on here?  The panic happens both with SMP and UP
>   Uros> kernels.  I have disabled the VHPT (CONFIG_DISABLE_VHPT=y).
>   Uros> Anything else I am missing?
>
> I don't think I tested the kernel with DISABLE_VHPT.

Enabling VHPT solved the problem.

Thanks,
Uros

--
Uros Prestor
uros@turbolinux.com

RE: [Linux-ia64] Kernel panic in dtlb_fault

[Mallick, Asit K]

The TLB code got re-arranged a bit and I will take a look at why the
DISABLE_VHPT is not working.

Thanks,
Asit


> -----Original Message-----
> From: Uros Prestor [mailto:uros@turbolinux.com]
> Sent: Tuesday, January 09, 2001 4:41 PM
> To: davidm@hpl.hp.com
> Cc: linux-ia64@linuxia64.org
> Subject: Re: [Linux-ia64] Kernel panic in dtlb_fault
> 
> 
> David Mosberger wrote:
> 
> >   Uros> The IP points inside the dtlb_fault code.  Any ideas what's
> >   Uros> going on here?  The panic happens both with SMP and UP
> >   Uros> kernels.  I have disabled the VHPT (CONFIG_DISABLE_VHPT=y).
> >   Uros> Anything else I am missing?
> >
> > I don't think I tested the kernel with DISABLE_VHPT.
> 
> Enabling VHPT solved the problem.
> 
> Thanks,
> Uros
> 
> --
> Uros Prestor
> uros@turbolinux.com
> 
> 
> 
> 
> _______________________________________________
> Linux-IA64 mailing list
> Linux-IA64@linuxia64.org
> http://lists.linuxia64.org/lists/listinfo/linux-ia64
> 

RE: [Linux-ia64] Kernel panic in dtlb_fault

[Mallick, Asit K]

Here is a patch to fix this problem.

Thanks,
Asit

--- linux-2.4.0/arch/ia64/kernel/ivt.S  Tue Jan  9 03:48:36 2001
+++ linux/arch/ia64/kernel/ivt.S        Wed Jan 10 06:32:56 2001
@@ -206,6 +206,7 @@
        ;;
 (p7)   ptc.l r16,r20
 #endif
+       mov b0=r29
        mov pr=r31,-1
        rfi
        ;;
@@ -241,6 +242,7 @@
        ;;
 (p7)   ptc.l r16,r20
 #endif
+       mov b0=r29
        mov pr=r31,-1
        rfi
        ;;

Re: [Linux-ia64] Kernel panic in dtlb_fault

[Uros Prestor]

I still get a kernel panic in dtlb_fault() when setting
CONFIG_DISABLE_VHPT=y.

Uros


"Mallick, Asit K" wrote:

> Here is a patch to fix this problem.
>
> Thanks,
> Asit
>
> --- linux-2.4.0/arch/ia64/kernel/ivt.S  Tue Jan  9 03:48:36 2001
> +++ linux/arch/ia64/kernel/ivt.S        Wed Jan 10 06:32:56 2001
> @@ -206,6 +206,7 @@
>         ;;
>  (p7)   ptc.l r16,r20
>  #endif
> +       mov b0=r29
>         mov pr=r31,-1
>         rfi
>         ;;
> @@ -241,6 +242,7 @@
>         ;;
>  (p7)   ptc.l r16,r20
>  #endif
> +       mov b0=r29
>         mov pr=r31,-1
>         rfi
>         ;;
>
> _______________________________________________
> Linux-IA64 mailing list
> Linux-IA64@linuxia64.org
> http://lists.linuxia64.org/lists/listinfo/linux-ia64

--
Uros Prestor
uros@turbolinux.com

Re: [Linux-ia64] Kernel panic in dtlb_fault

[David Mosberger]

>>>>> On Thu, 11 Jan 2001 11:09:22 -0800, Uros Prestor <uros@turbolinux.com> said:

  Uros> I still get a kernel panic in dtlb_fault() when setting
  Uros> CONFIG_DISABLE_VHPT=y.

Are you sure you picked up the new kernel?  Try "objdump -d" on
vmlinux and verify that itlb_fault ends with "b0" being restored.

	--david

Re: [Linux-ia64] Kernel panic in dtlb_fault

[Uros Prestor]

David Mosberger wrote:

> Are you sure you picked up the new kernel?  Try "objdump -d" on
> vmlinux and verify that itlb_fault ends with "b0" being restored.

This is the disassembly output of itlb_fault:
e000000000500400 <itlb_fault>:
e000000000500400:       00 80 00 28 24 04       [MII]       mov r16=cr20
e000000000500406:       d0 01 00 62 00 e0                   mov r29°
e00000000050040c:       03 00 cc 00                         mov r31=pr
e000000000500410:       05 88 00 32 24 44       [MLX]       mov r17=cr25
e000000000500416:       00 00 00 00 60 c0                   movl r30=0xe00000000
0500420;;
e00000000050041c:       03 02 22 68
e000000000500420:       0a 90 00 22 18 10       [MMI]       ld8 r18=[r17];;
e000000000500426:       00 00 00 02 00 c0                   nop.m 0x0
e00000000050042c:       00 90 00 50                         tbit.z p6,p0=r18,0
e000000000500430:       11 00 00 00 01 00       [MIB]       nop.m 0x0
e000000000500436:       00 00 00 02 00 03                   nop.i 0x0
e00000000050043c:       98 0c 00 41                   (p06) br.cond.spnt.many e0
000000005010c0 <page_fault>;;
e000000000500440:       0a 00 48 00 2f 04       [MMI]       itc.i r18;;
e000000000500446:       00 00 00 02 00 00                   nop.m 0x0
e00000000050044c:       d0 09 00 07                         mov b0=r29
e000000000500450:       11 00 00 00 01 00       [MIB]       nop.m 0x0
e000000000500456:       f0 ff c0 bf 05 00                   mov pr=r31,0xfffffff
ffffffffe
e00000000050045c:       00 00 20 00                         rfi;;

Seems like the b0 register is getting restored correctly.

Uros

--
Uros Prestor
uros@turbolinux.com

RE: [Linux-ia64] Kernel panic in dtlb_fault

[Mallick, Asit K]

Looks like there is another window that can cause this problem. I am looking
into the problem.

Thanks,
Asit


> -----Original Message-----
> From: David Mosberger [mailto:davidm@hpl.hp.com]
> Sent: Thursday, January 11, 2001 11:36 AM
> To: Uros Prestor
> Cc: linux-ia64@linuxia64.org
> Subject: Re: [Linux-ia64] Kernel panic in dtlb_fault
> 
> 
> >>>>> On Thu, 11 Jan 2001 11:09:22 -0800, Uros Prestor 
> <uros@turbolinux.com> said:
> 
>   Uros> I still get a kernel panic in dtlb_fault() when setting
>   Uros> CONFIG_DISABLE_VHPT=y.
> 
> Are you sure you picked up the new kernel?  Try "objdump -d" on
> vmlinux and verify that itlb_fault ends with "b0" being restored.
> 
> 	--david
> 
> _______________________________________________
> Linux-IA64 mailing list
> Linux-IA64@linuxia64.org
> http://lists.linuxia64.org/lists/listinfo/linux-ia64
> 

RE: [Linux-ia64] Kernel panic in dtlb_fault

[Mallick, Asit K]

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

Attached is a patch to fix the problem. Uros and Jenna were able to boot
with this patch. Sorry for sending the early version.

Thanks,
Asit




> -----Original Message-----
> From: Uros Prestor [mailto:uros@turbolinux.com]
> Sent: Thursday, January 11, 2001 12:13 PM
> To: davidm@hpl.hp.com
> Cc: linux-ia64@linuxia64.org
> Subject: Re: [Linux-ia64] Kernel panic in dtlb_fault
> 
> 
> David Mosberger wrote:
> 
> > Are you sure you picked up the new kernel?  Try "objdump -d" on
> > vmlinux and verify that itlb_fault ends with "b0" being restored.
> 
> This is the disassembly output of itlb_fault:
> e000000000500400 <itlb_fault>:
> e000000000500400:       00 80 00 28 24 04       [MII]       
> mov r16=cr20
> e000000000500406:       d0 01 00 62 00 e0                   mov r29=b0
> e00000000050040c:       03 00 cc 00                         mov r31=pr
> e000000000500410:       05 88 00 32 24 44       [MLX]       
> mov r17=cr25
> e000000000500416:       00 00 00 00 60 c0                   
> movl r30=0xe00000000
> 0500420;;
> e00000000050041c:       03 02 22 68
> e000000000500420:       0a 90 00 22 18 10       [MMI]       
> ld8 r18=[r17];;
> e000000000500426:       00 00 00 02 00 c0                   nop.m 0x0
> e00000000050042c:       00 90 00 50                         
> tbit.z p6,p0=r18,0
> e000000000500430:       11 00 00 00 01 00       [MIB]       nop.m 0x0
> e000000000500436:       00 00 00 02 00 03                   nop.i 0x0
> e00000000050043c:       98 0c 00 41                   (p06) 
> br.cond.spnt.many e0
> 000000005010c0 <page_fault>;;
> e000000000500440:       0a 00 48 00 2f 04       [MMI]       
> itc.i r18;;
> e000000000500446:       00 00 00 02 00 00                   nop.m 0x0
> e00000000050044c:       d0 09 00 07                         mov b0=r29
> e000000000500450:       11 00 00 00 01 00       [MIB]       nop.m 0x0
> e000000000500456:       f0 ff c0 bf 05 00                   
> mov pr=r31,0xfffffff
> ffffffffe
> e00000000050045c:       00 00 20 00                         rfi;;
> 
> Seems like the b0 register is getting restored correctly.
> 
> Uros
> 
> --
> Uros Prestor
> uros@turbolinux.com
> 
> 
> 
> 
> _______________________________________________
> Linux-IA64 mailing list
> Linux-IA64@linuxia64.org
> http://lists.linuxia64.org/lists/listinfo/linux-ia64
> 


[-- Attachment #2: ivt.diff --]
[-- Type: application/octet-stream, Size: 1073 bytes --]

--- linux-2.4.0/arch/ia64/kernel/ivt.S	Tue Jan  9 03:48:36 2001
+++ linux/arch/ia64/kernel/ivt.S	Thu Jan 11 02:30:30 2001
@@ -193,6 +193,7 @@
 	;;
 1:	ld8 r18=[r17]				// read L3 PTE
 	;;
+	mov b0=r29
 	tbit.z p6,p0=r18,_PAGE_P_BIT		// page present bit cleared?
 (p6)	br.cond.spnt.many page_fault
 	;;
@@ -228,6 +229,7 @@
 	;;
 1:	ld8 r18=[r17]				// read L3 PTE
 	;;
+	mov b0=r29
 	tbit.z p6,p0=r18,_PAGE_P_BIT		// page present bit cleared?
 (p6)	br.cond.spnt.many page_fault
 	;;
@@ -399,7 +401,6 @@
 	shr.u r18=r16,PMD_SHIFT			// shift L2 index into position
 	;;
 	ld8 r17=[r17]				// fetch the L1 entry (may be 0)
-	mov b0=r30
 	;;
 (p7)	cmp.eq p6,p7=r17,r0			// was L1 entry NULL?
 	dep r17=r18,r17,3,(PAGE_SHIFT-3)	// compute address of L2 page table entry
@@ -409,8 +410,8 @@
 	;;
 (p7)	cmp.eq.or.andcm p6,p7=r17,r0		// was L2 entry NULL?
 	dep r17=r19,r17,3,(PAGE_SHIFT-3)	// compute address of L3 page table entry
-	;;
 (p6)	br.cond.spnt.many page_fault
+	mov b0=r30
 	br.sptk.many b0				// return to continuation point
 	;;
 

Re: [Linux-ia64] Kernel panic in dtlb_fault

[Uros Prestor]

"Mallick, Asit K" wrote:

> Attached is a patch to fix the problem. Uros and Jenna were able to boot
> with this patch. Sorry for sending the early version.

Something is still not kosher if you enable CONFIG_DISABLE_VHPT=y.  If I try
recompiling the gnupro RPM the compilation breaks down immediately after the
config stage With the following error:

     # rpm -ba /usr/src/turbo/SPECS/gnupro.spec
     ...
     creating ./config.status
     creating Makefile
     Configuring utils...
     Created "Makefile" in /work/BUILD/gnupro-2.96/build/utils
     Configuring spu...
     Created "Makefile" in /work/BUILD/gnupro-2.96/build/utils/spu
     ++ perl -e 'if( -x "/usr/bin/getconf" &&  ( ($p=`/usr/bin/getconf
     _NPROCESSORS_ONLN`) >= 0 ) ){ print "$p"} else { print "1"; }'
     + make -j 2
     /bin/sh: SHELL: command not found
     /bin/sh: -c: command not found
     make: *** [all-libiberty] Error 127
     make: *** Waiting for unfinished jobs....
     Bad exit status from /var/tmp/rpm-tmp.82077 (%build)

Things become very bizarre if you try to compile by hand, ranging from
reports of missing /lib/libc.so.6.1 to internal compiler errors...  This
happens both on 2xB3 BigSur and 4xB3 Lion.  If I revert to the kernel which
enables VHPT the compilation goes just fine.

Uros

--
Uros Prestor
uros@turbolinux.com

RE: [Linux-ia64] Kernel panic in dtlb_fault

[Mallick, Asit K]

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

This is a patch that fixes the VHPT disabled kernel problems. Uros has
verified this and it is at the same level as VHPT enabled kernel on B3.

Thanks,
Asit


> -----Original Message-----
> From: Uros Prestor [mailto:uros@turbolinux.com]
> Sent: Friday, January 12, 2001 11:37 AM
> To: Mallick, Asit K
> Cc: linux-ia64@linuxia64.org
> Subject: Re: [Linux-ia64] Kernel panic in dtlb_fault
> 
> 
> "Mallick, Asit K" wrote:
> 
> > Attached is a patch to fix the problem. Uros and Jenna were 
> able to boot
> > with this patch. Sorry for sending the early version.
> 
> Something is still not kosher if you enable 
> CONFIG_DISABLE_VHPT=y.  If I try
> recompiling the gnupro RPM the compilation breaks down 
> immediately after the
> config stage With the following error:
> 
>      # rpm -ba /usr/src/turbo/SPECS/gnupro.spec
>      ...
>      creating ./config.status
>      creating Makefile
>      Configuring utils...
>      Created "Makefile" in /work/BUILD/gnupro-2.96/build/utils
>      Configuring spu...
>      Created "Makefile" in /work/BUILD/gnupro-2.96/build/utils/spu
>      ++ perl -e 'if( -x "/usr/bin/getconf" &&  ( ($p=`/usr/bin/getconf
>      _NPROCESSORS_ONLN`) >= 0 ) ){ print "$p"} else { print "1"; }'
>      + make -j 2
>      /bin/sh: SHELL: command not found
>      /bin/sh: -c: command not found
>      make: *** [all-libiberty] Error 127
>      make: *** Waiting for unfinished jobs....
>      Bad exit status from /var/tmp/rpm-tmp.82077 (%build)
> 
> Things become very bizarre if you try to compile by hand, ranging from
> reports of missing /lib/libc.so.6.1 to internal compiler 
> errors...  This
> happens both on 2xB3 BigSur and 4xB3 Lion.  If I revert to 
> the kernel which
> enables VHPT the compilation goes just fine.
> 
> Uros
> 
> --
> Uros Prestor
> uros@turbolinux.com
> 
> 
> 
> 
> _______________________________________________
> Linux-IA64 mailing list
> Linux-IA64@linuxia64.org
> http://lists.linuxia64.org/lists/listinfo/linux-ia64
> 


[-- Attachment #2: ivt.diff --]
[-- Type: application/octet-stream, Size: 2207 bytes --]

--- linux-2.4.0/arch/ia64/kernel/ivt.S	Tue Jan  9 03:48:36 2001
+++ linux/arch/ia64/kernel/ivt.S	Fri Jan 12 04:47:05 2001
@@ -184,15 +184,16 @@
 	 * mode, walk the page table, and then re-execute the L3 PTE read
 	 * and go on normally after that.
 	 */
-itlb_fault:
 	mov r16=cr.ifa				// get virtual address
 	mov r29=b0				// save b0
 	mov r31=pr				// save predicates
+itlb_fault:
 	mov r17=cr.iha				// get virtual address of L3 PTE
 	movl r30=1f				// load nested fault continuation point
 	;;
 1:	ld8 r18=[r17]				// read L3 PTE
 	;;
+	mov b0=r29
 	tbit.z p6,p0=r18,_PAGE_P_BIT		// page present bit cleared?
 (p6)	br.cond.spnt.many page_fault
 	;;
@@ -219,15 +220,16 @@
 	 * mode, walk the page table, and then re-execute the L3 PTE read
 	 * and go on normally after that.
 	 */
-dtlb_fault:
 	mov r16=cr.ifa				// get virtual address
 	mov r29=b0				// save b0
 	mov r31=pr				// save predicates
+dtlb_fault:
 	mov r17=cr.iha				// get virtual address of L3 PTE
 	movl r30=1f				// load nested fault continuation point
 	;;
 1:	ld8 r18=[r17]				// read L3 PTE
 	;;
+	mov b0=r29
 	tbit.z p6,p0=r18,_PAGE_P_BIT		// page present bit cleared?
 (p6)	br.cond.spnt.many page_fault
 	;;
@@ -261,6 +263,7 @@
 (p8)	thash r17=r16
 	;;
 (p8)	mov cr.iha=r17
+(p8)	mov r29=b0				// save b0
 (p8)	br.cond.dptk.many itlb_fault
 #endif
 	extr.u r23=r21,IA64_PSR_CPL0_BIT,2	// extract psr.cpl
@@ -296,6 +299,7 @@
 (p8)	thash r17=r16
 	;;
 (p8)	mov cr.iha=r17
+(p8)	mov r29=b0				// save b0
 (p8)	br.cond.dptk.many dtlb_fault
 #endif
 	extr.u r23=r21,IA64_PSR_CPL0_BIT,2	// extract psr.cpl
@@ -399,7 +403,6 @@
 	shr.u r18=r16,PMD_SHIFT			// shift L2 index into position
 	;;
 	ld8 r17=[r17]				// fetch the L1 entry (may be 0)
-	mov b0=r30
 	;;
 (p7)	cmp.eq p6,p7=r17,r0			// was L1 entry NULL?
 	dep r17=r18,r17,3,(PAGE_SHIFT-3)	// compute address of L2 page table entry
@@ -409,8 +412,8 @@
 	;;
 (p7)	cmp.eq.or.andcm p6,p7=r17,r0		// was L2 entry NULL?
 	dep r17=r19,r17,3,(PAGE_SHIFT-3)	// compute address of L3 page table entry
-	;;
 (p6)	br.cond.spnt.many page_fault
+	mov b0=r30
 	br.sptk.many b0				// return to continuation point
 	;;