Ooops with 2.4.12-preX and acX
I have an Ultra 1E which I'm having trouble with.
I've tried various pre's with and without the ac patches. I have the
sunhme patch compiled in.
For example I'm currently running:
Linux larder 2.4.21-pre4-spc64s0131-a #1 SMP Fri Jan 31 23:42:45
GMT 2003 sparc64 sun4u TI UltraSparc I (SpitFire) GNU/Linux
Here is the oopsym output:
ksymoops 2.4.6 on sparc64 2.4.21-pre4-spc64s0131-a. Options used
-V (default)
-k /proc/ksyms (default)
-l /proc/modules (default)
-o /lib/modules/2.4.21-pre4-spc64s0131-a/ (default)
-m /boot/System.map-2.4.21-pre4-spc64s0131-a (default)
Warning: You did not tell me where to find symbol information. I will
assume that the log matches the kernel and modules that are running
right now and I'll use the default options above for symbol resolution.
If the current kernel and/or modules do not match the log, you can get
more accurate output by telling me the kernel version and where to find
map, modules, ksyms etc. ksymoops -h explains the options.
Unable to handle kernel NULL pointer dereference
tsk->{mm,active_mm}->context = 0000000000000401
tsk->{mm,active_mm}->pgd = fffff8000020a000
\|/ ____ \|/
"@'/ .. \`@"
/_| \__/ |_\
\__U_/
swapper(0): Oops
CPU[0]: local_irq_count[1] irqs_running[1]
TSTATE: 0000004480f09607 TPC: 00000000005935c4 TNPC: 00000000005935c8 Y:
07000000 Tainted: P
Using defaults from ksymoops -t elf32-sparc -a sparc
g0: 0000000000698400 g1: 0000000000000001 g2: 70000b0000000028 g3:
0000000048000000
g4: fffff80000000000 g5: 0000000000000080 g6: 0000000000414000 g7:
0000000000000040
o0: 00000000000001e8 o1: fffff800268e12a0 o2: 0000000000000040 o3:
0000000000000080
o4: 0000000000000080 o5: 0000000000593360 sp: 00000000004171d1 ret_pc:
000000000200e5a0
l0: fffff800268e1240 l1: 0000000000000000 l2: 000000000000004a l3:
fffff800002100c0
l4: fffff80000210100 l5: 000000000000004a l6: fffff800262d1348 l7:
0000000000000007
i0: 0000000000000000 i1: 00000000004fb840 i2: 00000000005d36b0 i3:
0000000000000000
i4: 0000000000000000 i5: 0000000000007000 i6: 0000000000417291 i7:
000000000200e678
Caller[000000000200e678]
Caller[000000000041f424]
Caller[00000000004088f4]
Caller[000000000041a5fc]
Caller[0000000000418068]
Caller[00000000005f87d8]
Caller[0000000000404638]
Caller[0000000000000000]
Instruction DUMP: c4da7fc0 c6da7fc8 87832000 <c4a23fc4> 8b30b020
caa23fc0 c6a23fcc 9b30f020 daa23fc8
>>PC; 005935c4 <__memcpy_entry+290/3a0> <=====
>>g0; 00698400 <tv2+3e8/408>
>>g6; 00414000 <init_task_union+0/4000>
>>o5; 00593360 <__memcpy_entry+2c/3a0>
>>sp; 004171d1 <init_task_union+31d1/4000>
>>ret_pc; 0200e5a0 <[qlogicpti]qlogicpti_intr_handler+120/1e0>
>>i1; 004fb840 <scsi_old_done+0/660>
>>i2; 005d36b0 <io_request_lock+0/4>
>>i6; 00417291 <init_task_union+3291/4000>
>>i7; 0200e678 <[qlogicpti]qpti_intr+18/80>
Trace; 0200e678 <[qlogicpti]qpti_intr+18/80>
Trace; 0041f424 <handler_irq+144/340>
Trace; 004088f4 <tl0_irq7+14/40>
Trace; 0041a5fc <cpu_idle+3c/80>
Trace; 00418068 <rest_init+48/60>
Trace; 005f87d8 <start_kernel+1d8/200>
Trace; 00404638 <tlb_fixup_done+54/5c>
Trace; 00000000 Before first symbol
Code; 005935b8 <__memcpy_entry+284/3a0>
00000000 <_PC>:
Code; 005935b8 <__memcpy_entry+284/3a0>
0: c4 da 7f c0 unknown
Code; 005935bc <__memcpy_entry+288/3a0>
4: c6 da 7f c8 unknown
Code; 005935c0 <__memcpy_entry+28c/3a0>
8: 87 83 20 00 mov %o4, %asr3
Code; 005935c4 <__memcpy_entry+290/3a0> <=====
c: c4 a2 3f c4 unknown <=====
Code; 005935c8 <__memcpy_entry+294/3a0>
10: 8b 30 b0 20 unknown
Code; 005935cc <__memcpy_entry+298/3a0>
14: ca a2 3f c0 unknown
Code; 005935d0 <__memcpy_entry+29c/3a0>
18: c6 a2 3f cc unknown
Code; 005935d4 <__memcpy_entry+2a0/3a0>
1c: 9b 30 f0 20 unknown
Code; 005935d8 <__memcpy_entry+2a4/3a0>
20: da a2 3f c8 unknown
Kernel panic: Aiee, killing interrupt handler!
1 warning issued. Results may not be reliable.
Any ideas?
Reply to: