Skip to contentSkip to conversation

Panic in linuxrc (2.4.7)

Linux-ia64 richard offer 4 participants 8 messages Aug 1, 2001 – Aug 2, 2001

lore
Share & tools
lore
#0 lore raw

I've just got my first (secondhand) IA64 box, and I'm trying to get 2.4.7 running so port some other kernel code (loadable security modules) to the IA64.

Taking a vanilla 2.4.7, applying the 0726 patch (#2) and the suggested compiler fix as I'm using stock RedHat 7.1, I get...

Freeing initrd memory: 736kB freed
VFS: Mounted root (ext2 filesystem).
linuxrc[8]: IA-64 Illegal operation fault 0

psr : 0000101008026018 ifs : 800000000000050c ip : [<e000000004721ee0>]
unat: 0000000000000000 pfs : 0000000000000000 rsc : 0000000000000000
rnat: 0000000000000000 bsps: 0000000000000000 pr : 000000000000445b
ldrs: 0000000000000000 ccv : 0000000000000001 fpsr: 0009804c0270033f b0 : e00000000440ef90 b6 : e000000004482060 b7 : e00000000440f810 f6 : 1003e0000000000001940 f7 : 1003e0000000000000040
f8 : 1003e0000000000000001 f9 : 1003efffffffffffffe08
r1 : e000000004927000 r2 : e0000000048be800 r3 : e0000000047798a9 r8 : 0000000000000000 r9 : 000000000000048c r10 : 0000000000000000 r11 : 000000000000038a r12 : 800000ffffffde80 r13 : e00000003f090000 r14 : 0000000000000100 r15 : 0000000000000409 r16 : 0000000000000806 r17 : 0000000000000100 r18 : e00000003f09f8d0 r19 : e00000003f0b2530 r20 : e00000003f0b24f0 r21 : e00000003f0b2538 r22 : 0000000000000001 r23 : 0000000000000001 r24 : e000000004bd14f0 r25 : e000000000023198 r26 : e000000000022fe8 r27 : e000000000023010 r28 : e000000004bd1488 r29 : e00000003e728000 r30 : e000000004be0000 r31 : 0000000000000c9c r32 : 0000000000000000 r33 : 0000000000000000 r34 : 0000000000000000 r35 : 0000000000000000 r36 : 0000000000000000 r37 : 0000000000000000 r38 : 0000000000000000 r39 : 0000000000000000 r40 : 0000000000000000 r41 : 0000000000000000 r42 : 0000000000000000 r43 : 0000000000000000

Call Trace: [<e0000000044140b0>] sp=0x800000ffffffd9c0

bsp=0xe00000003f090d70

Running this through ksymoops gave

Warning (Oops_read): Code line not seen, dumping what data is available

Quoted 3 lines
Quoted 3 lines
IP;  e000000004721ee0 <long_do_clear+70/110>   <==>>b0;  e00000000440ef90 <do_linuxrc+d0/100>
b6;  e000000004482060 <generic_file_mmap+0/1a0>
b7;  e00000000440f810 <ia64_switch_to+b0/120>

Trace; e0000000044140b0 <show_stack+50/c0>

1 warning issued. Results may not be reliable.

Any clues ?

thanks

richard.

PS
[ acid 2.4.3-#1 ] cat /proc/cpuinfo
processor : 0
vendor : GenuineIntel
family : IA-64
model : Itanium
revision : 2
archrev : 0
features : standard
cpu number : 0
cpu regs : 4
cpu MHz : 666.713040
itc MHz : 666.713040
BogoMIPS : 664.79

#1 lore raw

Do you have CONFIG_PERFMON enabled? If not, try turning it on.

We are investigating the problem. It looks to be a Heisenbug: the problem gets triggered depending on what the exact code layout is. Adding or removing a single bundle in the right place seems to make the difference...

We'll keep you posted.

	--david
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line · richard offer

Richard> I've just got my first (secondhand) IA64 box, and I'm Richard> trying to get 2.4.7 running so port some other kernel code Richard> (loadable security modules) to the IA64.

Richard> Taking a vanilla 2.4.7, applying the 0726 patch (#2) and Richard> the suggested compiler fix as I'm using stock RedHat 7.1, I Richard> get...

Richard> Freeing initrd memory: 736kB freed VFS: Mounted root (ext2 Richard> filesystem). linuxrc[8]: IA-64 Illegal operation fault 0

Richard> psr : 0000101008026018 ifs : 800000000000050c ip :
Richard> [<e000000004721ee0>] unat: 0000000000000000 pfs :
Richard> 0000000000000000 rsc : 0000000000000000 rnat:
Richard> 0000000000000000 bsps: 0000000000000000 pr :
Richard> 000000000000445b ldrs: 0000000000000000 ccv :
Richard> 0000000000000001 fpsr: 0009804c0270033f b0 :
Richard> e00000000440ef90 b6 : e000000004482060 b7 :
Richard> e00000000440f810 f6 : 1003e0000000000001940 f7 :
Richard> 1003e0000000000000040 f8 : 1003e0000000000000001 f9 :
Richard> 1003efffffffffffffe08 r1 : e000000004927000 r2 :
Richard> e0000000048be800 r3 : e0000000047798a9 r8 :
Richard> 0000000000000000 r9 : 000000000000048c r10 :
Richard> 0000000000000000 r11 : 000000000000038a r12 :
Richard> 800000ffffffde80 r13 : e00000003f090000 r14 :
Richard> 0000000000000100 r15 : 0000000000000409 r16 :
Richard> 0000000000000806 r17 : 0000000000000100 r18 :
Richard> e00000003f09f8d0 r19 : e00000003f0b2530 r20 :
Richard> e00000003f0b24f0 r21 : e00000003f0b2538 r22 :
Richard> 0000000000000001 r23 : 0000000000000001 r24 :
Richard> e000000004bd14f0 r25 : e000000000023198 r26 :
Richard> e000000000022fe8 r27 : e000000000023010 r28 :
Richard> e000000004bd1488 r29 : e00000003e728000 r30 :
Richard> e000000004be0000 r31 : 0000000000000c9c r32 :
Richard> 0000000000000000 r33 : 0000000000000000 r34 :
Richard> 0000000000000000 r35 : 0000000000000000 r36 :
Richard> 0000000000000000 r37 : 0000000000000000 r38 :
Richard> 0000000000000000 r39 : 0000000000000000 r40 :
Richard> 0000000000000000 r41 : 0000000000000000 r42 :
Richard> 0000000000000000 r43 : 0000000000000000

Richard> Call Trace: [<e0000000044140b0>] sp=0x800000ffffffd9c0 Richard> bsp=0xe00000003f090d70

Richard> Running this through ksymoops gave

Richard> Warning (Oops_read): Code line not seen, dumping what data Richard> is available

Quoted 4 lines
Quoted 4 lines
Quoted 4 lines

IP; e000000004721ee0 <long_do_clear+70/110> <=== b0; e00000000440ef90 <do_linuxrc+d0/100> b6; e000000004482060 <generic_file_mmap+0/1a0> b7; e00000000440f810 <ia64_switch_to+b0/120>

Richard> Trace; e0000000044140b0 <show_stack+50/c0>

Richard> 1 warning issued. Results may not be reliable.

Richard> Any clues ?

Richard> thanks

Richard> richard.

Richard> PS [ acid 2.4.3-#1 ] cat /proc/cpuinfo processor : 0 vendor Richard> : GenuineIntel family : IA-64 model : Itanium revision : 2 Richard> archrev : 0 features : standard cpu number : 0 cpu regs : 4 Richard> cpu MHz : 666.713040 itc MHz : 666.713040 BogoMIPS : 664.79

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

#2 lore raw
In reply to richard offer

My guess is that you are using a B1 processor. ( Revision 2 )

You HAVE to use kernel 2.4.4 in my experience to stop the panics.

2.5.5 is good on B3's and C0's I ssume 2.4.7 would be fine here too.

--ken

-----Original Message-----
From: richard offer [mailto:[email protected]]
Sent: Wednesday, August 01, 2001 4:06 PM
To: [email protected]
Subject: [Linux-ia64] Panic in linuxrc (2.4.7)

I've just got my first (secondhand) IA64 box, and I'm trying to get 2.4.7 running so port some other kernel code (loadable security modules) to the IA64.

Taking a vanilla 2.4.7, applying the 0726 patch (#2) and the suggested compiler fix as I'm using stock RedHat 7.1, I get...

Freeing initrd memory: 736kB freed
VFS: Mounted root (ext2 filesystem).
linuxrc[8]: IA-64 Illegal operation fault 0

psr : 0000101008026018 ifs : 800000000000050c ip : [<e000000004721ee0>]
unat: 0000000000000000 pfs : 0000000000000000 rsc : 0000000000000000
rnat: 0000000000000000 bsps: 0000000000000000 pr : 000000000000445b
ldrs: 0000000000000000 ccv : 0000000000000001 fpsr: 0009804c0270033f b0 : e00000000440ef90 b6 : e000000004482060 b7 : e00000000440f810 f6 : 1003e0000000000001940 f7 : 1003e0000000000000040
f8 : 1003e0000000000000001 f9 : 1003efffffffffffffe08
r1 : e000000004927000 r2 : e0000000048be800 r3 : e0000000047798a9 r8 : 0000000000000000 r9 : 000000000000048c r10 : 0000000000000000 r11 : 000000000000038a r12 : 800000ffffffde80 r13 : e00000003f090000 r14 : 0000000000000100 r15 : 0000000000000409 r16 : 0000000000000806 r17 : 0000000000000100 r18 : e00000003f09f8d0 r19 : e00000003f0b2530 r20 : e00000003f0b24f0 r21 : e00000003f0b2538 r22 : 0000000000000001 r23 : 0000000000000001 r24 : e000000004bd14f0 r25 : e000000000023198 r26 : e000000000022fe8 r27 : e000000000023010 r28 : e000000004bd1488 r29 : e00000003e728000 r30 : e000000004be0000 r31 : 0000000000000c9c r32 : 0000000000000000 r33 : 0000000000000000 r34 : 0000000000000000 r35 : 0000000000000000 r36 : 0000000000000000 r37 : 0000000000000000 r38 : 0000000000000000 r39 : 0000000000000000 r40 : 0000000000000000 r41 : 0000000000000000 r42 : 0000000000000000 r43 : 0000000000000000

Call Trace: [<e0000000044140b0>] sp=0x800000ffffffd9c0

bsp=0xe00000003f090d70

Running this through ksymoops gave

Warning (Oops_read): Code line not seen, dumping what data is available

Quoted 3 lines
Quoted 3 lines
IP;  e000000004721ee0 <long_do_clear+70/110>   <==>>b0;  e00000000440ef90 <do_linuxrc+d0/100>
b6;  e000000004482060 <generic_file_mmap+0/1a0>
b7;  e00000000440f810 <ia64_switch_to+b0/120>

Trace; e0000000044140b0 <show_stack+50/c0>

1 warning issued. Results may not be reliable.

Any clues ?

thanks

richard.

PS
[ acid 2.4.3-#1 ] cat /proc/cpuinfo
processor : 0
vendor : GenuineIntel
family : IA-64
model : Itanium
revision : 2
archrev : 0
features : standard
cpu number : 0
cpu regs : 4
cpu MHz : 666.713040
itc MHz : 666.713040
BogoMIPS : 664.79

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

#3 lore raw
In reply to richard offer

* frm [email protected] "08/01/01 16:16:23 -0700" | sed '1,$s/^/* /' *
* My guess is that you are using a B1 processor. ( Revision 2 ) *
* You HAVE to use kernel 2.4.4 in my experience to stop the panics. *
* 2.5.5 is good on B3's and C0's I ssume 2.4.7 would be fine here too. *
*

Thanks for the quick turnaround, its always better to know that you can't get there from here :-)

I need a working 2.4.7 so I guess I'll just have to find another machine.

*
* --ken

richard.

-----------------------------------------------------------------------
Richard Offer Technical Lead, Trust Technology, SGI
"Specialization is for insects"
_______________________________________________________________________

#4 lore raw
In reply to richard offer
Quoted 18 lines

I've just got my first (secondhand) IA64 box, and I'm trying to get 2.4.7
running so port some other kernel code (loadable security modules) to the
IA64.

Taking a vanilla 2.4.7, applying the 0726 patch (#2) and the suggested compiler fix as I'm using stock RedHat 7.1, I get...

Freeing initrd memory: 736kB freed
VFS: Mounted root (ext2 filesystem).
linuxrc[8]: IA-64 Illegal operation fault 0

Running this through ksymoops gave

Warning (Oops_read): Code line not seen, dumping what data is available

Quoted 6 lines
Quoted 3 lines
Quoted 3 lines
IP;  e000000004721ee0 <long_do_clear+70/110>   <==> >>b0;  e00000000440ef90 <do_linuxrc+d0/100>
b6;  e000000004482060 <generic_file_mmap+0/1a0>
b7;  e00000000440f810 <ia64_switch_to+b0/120>

Trace; e0000000044140b0 <show_stack+50/c0>

Any clues ?

I sent an email about this on 7/28, but didn't get a reply (but you sent more info than I did):

I tried upgrading to 2.4.7+IA64-010726, but when I did that, "init" dies:
init[1]: IA-64 Illegal operation fault 0
[...]

    Kernel panic: Attempted to kill init!

The 2.4.5 kernel boots with the 6/26 patches, but I'd like to run a newer kernel too :-)

Kevin

#5 lore raw
In reply to richard offer
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line · David Mosberger

David> Do you have CONFIG_PERFMON enabled? If not, try turning it David> on. We are investigating the problem. It looks to be a David> Heisenbug: the problem gets triggered depending on what the David> exact code layout is. Adding or removing a single bundle in David> the right place seems to make the difference...

OK, this turns out to be due to an assembler bug: the assembler fails to put a stop bit in front of an "alloc" instruction if the "alloc" is preceded by a .align directive and the directive inserts one or more "nop" bundles. ;-(

This bug was difficult to track down because it got triggered while psr.ic was cleared, which means that the IP reported in the tombstone is all wrong and there is no easy way to find out at which address the real fault occurred. Well, at least the workaround is easy:

ia64/kernel/entry.S renamed from ia64/kernel/entry.S-orig +1 -1
@@ -687,7 +687,7 @@
 	shladd in0=loc1,3,r17
 	mov in1=0
 	;;
-	.align 32
+//	.align 32
 rse_clear_invalid:
 	// cycle 0
  { .mii

Please try again with this patch applied.

	--david
#6 lore raw
In reply to richard offer
Quoted 22 lines

OK, this turns out to be due to an assembler bug: the assembler fails to put a stop bit in front of an "alloc" instruction if the "alloc" is preceded by a .align directive and the directive inserts one or more "nop" bundles. ;-(

This bug was difficult to track down because it got triggered while psr.ic was cleared, which means that the IP reported in the tombstone is all wrong and there is no easy way to find out at which address the real fault occurred. Well, at least the workaround is easy:

ia64/kernel/entry.S renamed from ia64/kernel/entry.S-orig +1 -1
@@ -687,7 +687,7 @@
 	shladd in0=loc1,3,r17
 	mov in1=0
 	;;
-	.align 32
+//	.align 32
 rse_clear_invalid:
 	// cycle 0
  { .mii
Quoted 1 line

Please try again with this patch applied.

It boots fine! Thanks!!! Is there a bug-report for the gas bug?

Kevin

#7 lore raw
In reply to richard offer

* frm [email protected] "08/01/01 18:13:14 -0700" | sed '1,$s/^/* /' *
*>>>>> On Wed, 1 Aug 2001 16:15:43 -0700, David Mosberger *>>>>> <[email protected]> said:
*

*   David> Do you have CONFIG_PERFMON enabled?  If not, try turning it
*   David> on.  We are investigating the problem.  It looks to be a
*   David> Heisenbug: the problem gets triggered depending on what the
*   David> exact code layout is.  Adding or removing a single bundle in
*   David> the right place seems to make the difference...

*
* OK, this turns out to be due to an assembler bug: the assembler fails
* to put a stop bit in front of an "alloc" instruction if the "alloc" is
* preceded by a .align directive and the directive inserts one or more
* "nop" bundles. ;-(
*
* This bug was difficult to track down because it got triggered while
* psr.ic was cleared, which means that the IP reported in the tombstone
* is all wrong and there is no easy way to find out at which address the
* real fault occurred. Well, at least the workaround is easy:
*

[snip]

* Please try again with this patch applied.

That seems to have done the trick, although I enabled PERFMON at the same time.

Thanks.

*
* --david

richard.

-----------------------------------------------------------------------
Richard Offer Technical Lead, Trust Technology, SGI
"Specialization is for insects"
_______________________________________________________________________