Skip to contentSkip to conversation

Kernel panic in dtlb_fault

Linux-ia64 Uros Prestor 3 participants 11 messages Jan 9, 2001 – Jan 15, 2001

lore
Share & tools
lore

Uros Prestor

author
#0 lore raw

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
[email protected]

author
#1 lore raw
Quoted 6 lines · David Mosberger

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
[email protected]

#2 lore raw
In reply to Uros Prestor

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

Thanks,
Asit

Quoted 34 lines

-----Original Message-----
From: Uros Prestor [mailto:[email protected]]
Sent: Tuesday, January 09, 2001 4:41 PM
To: [email protected]
Cc: [email protected]
Subject: Re: [Linux-ia64] Kernel panic in dtlb_fault

Quoted 6 lines · David Mosberger

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
[email protected]

_______________________________________________
Linux-IA64 mailing list
[email protected]
http://lists.linuxia64.org/lists/listinfo/linux-ia64

#3 lore raw
In reply to Uros Prestor

Here is a patch to fix this problem.

Thanks,
Asit

arch/ia64/kernel/ivt.S Wed Jan 10 06:32:56 2001 renamed from arch/ia64/kernel/ivt.S Tue Jan 9 03:48:36 2001 +2 -0
@@ -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
        ;;
author
#4 lore raw
In reply to Uros Prestor

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

Uros

Quoted 24 lines · Asit K

Here is a patch to fix this problem.

Thanks,
Asit

arch/ia64/kernel/ivt.S Wed Jan 10 06:32:56 2001 renamed from arch/ia64/kernel/ivt.S Tue Jan 9 03:48:36 2001 +2 -0
@@ -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
        ;;
Quoted 4 lines

_______________________________________________
Linux-IA64 mailing list
[email protected]
http://lists.linuxia64.org/lists/listinfo/linux-ia64

--
Uros Prestor
[email protected]

#5 lore raw
In reply to Uros Prestor
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line · Uros Prestor

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
author
#6 lore raw
In reply to Uros Prestor
Quoted 2 lines · David Mosberger

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
[email protected]

#7 lore raw
In reply to Uros Prestor

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

Thanks,
Asit

Quoted 24 lines

-----Original Message-----
From: David Mosberger [mailto:[email protected]]
Sent: Thursday, January 11, 2001 11:36 AM
To: Uros Prestor
Cc: [email protected]
Subject: Re: [Linux-ia64] Kernel panic in dtlb_fault

Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line

On Thu, 11 Jan 2001 11:09:22 -0800, Uros Prestor

<[email protected]> 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
[email protected]
http://lists.linuxia64.org/lists/listinfo/linux-ia64

#8 lore raw
In reply to Uros Prestor

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

Quoted 56 lines

-----Original Message-----
From: Uros Prestor [mailto:[email protected]]
Sent: Thursday, January 11, 2001 12:13 PM
To: [email protected]
Cc: [email protected]
Subject: Re: [Linux-ia64] Kernel panic in dtlb_fault

Quoted 2 lines · David Mosberger

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
[email protected]

Quoted 5 lines

_______________________________________________
Linux-IA64 mailing list
[email protected]
http://lists.linuxia64.org/lists/listinfo/linux-ia64

arch/ia64/kernel/ivt.S +3 -2
@@ -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
 	;;
author
#9 lore raw
In reply to Uros Prestor
Quoted 2 lines · Asit K

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
[email protected]

#10 lore raw
In reply to Uros Prestor

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

Quoted 53 lines

-----Original Message-----
From: Uros Prestor [mailto:[email protected]]
Sent: Friday, January 12, 2001 11:37 AM
To: Mallick, Asit K
Cc: [email protected]
Subject: Re: [Linux-ia64] Kernel panic in dtlb_fault

Quoted 1 line · Asit K

Attached is a patch to fix the problem. Uros and Jenna were

able to boot

Quoted 1 line

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
[email protected]

Quoted 5 lines

_______________________________________________
Linux-IA64 mailing list
[email protected]
http://lists.linuxia64.org/lists/listinfo/linux-ia64

arch/ia64/kernel/ivt.S +7 -4
@@ -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
 	;;