my apologies for the cross-posting ... but since that matter is urgent for
me and noone on the smp mailinglist have answered so far, i hope that i
will find somebody on this list who can give me advice :)
thanks!
---------- Forwarded Message ----------
Date: 10/05/00 00:19:53 +0200
From: Matthias Weidle <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Subject: OOPS after upgrading CPU's ...
hi there!
there is some strange stuff going on here and after checking all sources of
information (without success) i hope that one of you may have the answer
... :)
ok, here is the problem:
i'm running a smp server machine (mostly doing file server stuff) which was
running pretty stable with 2 celeron-400 cpu's. i got about 60 days uptime
without problems - even under heavy load! a few weeks ago i decided to
upgrade the celeron cpu's to some older p3's (those with 512kb cache, no
coppermine) and did not expect any complications with that upgrade. but
since then i can't get the machine up for more than a couple of days
(depending on the load). sooner or later it locks with the following kernel
oops message:
ksymoops 2.3.4 on i686 2.2.15pre19ext3. Options used
-v /usr/src/linux/vmlinux (specified)
-k /proc/ksyms (default)
-l /proc/modules (default)
-o /lib/modules/2.2.15pre19ext3/ (default)
-m /usr/src/linux/System.map (default)
Warning (compare_ksyms_lsmod): module i2c-isa is in lsmod but not in ksyms,
probably no symbols exported Warning (compare_ksyms_lsmod): module
i2c-piix4 is in lsmod but not in ksyms, probably no symbols exported
Warning (compare_ksyms_lsmod): module nfsd is in lsmod but not in ksyms,
probably no symbols exported Warning (compare_ksyms_lsmod): module w83781d
is in lsmod but not in ksyms, probably no symbols exported Unable to handle
kernel NULL pointer dereference at virtual address 00000013
current->tss.cr3 = 00101000, %cr3 = 00101000
*pde = 00000000
Oops: 0002
CPU: 1
EIP: 0010:[<c01100c5>]
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00010006
eax: 00000013 ebx: 00000260 ecx: cc100480 edx: cbffa000
esi: cbffa000 edi: 00000013 ebp: cbffbf74 esp: cbffbf4c
ds: 0018 es: 0018 ss: 0018
Process swapper (pid: 0, process nr: 1, stackpage=cbffb000)
Stack: 00000013 c01104c1 00000013 cbffbf7c cbffa000 c0226020 c010b850
00000013 cbffbf7c cbffa000 00000000 c010a328 cbffa000 cbffa000 cbffa000
cbffa000 c0226020 00000000 00000080 00000018 cbff0018 ffffff13
c0107b15 00000010 Call Trace: [<c01104c1>] [<c010b850>]
[<c010a328>] [<c0107b15>] [<c019c875>] [<c01166b7>]
Code: e0 28 21 c0 8b 04 85 e4 28 21 c0 83 f8 ff 74 53 bf 00 e0 ff
>>EIP; c01100c5 <mask_IO_APIC_irq+d/84> <=====
Trace; c01104c1 <do_level_ioapic_IRQ+21/98>
Trace; c010b850 <do_IRQ+38/58>
Trace; c010a328 <common_interrupt+18/20>
Trace; c0107b15 <cpu_idle+3d/50>
Trace; c019c875 <vt_console_print+2fd/314>
Trace; c01166b7 <printk+177/184>
Code; c01100c5 <mask_IO_APIC_irq+d/84>
00000000 <_EIP>:
Code; c01100c5 <mask_IO_APIC_irq+d/84> <=====
0: e0 28 loopne 2a <_EIP+0x2a> c01100ef
<mask_IO_APIC_irq+37/84> <===== Code; c01100c7 <mask_IO_APIC_irq+f/84>
2: 21 c0 andl %eax,%eax
Code; c01100c9 <mask_IO_APIC_irq+11/84>
4: 8b 04 85 e4 28 21 c0 movl 0xc02128e4(,%eax,4),%eax
Code; c01100d0 <mask_IO_APIC_irq+18/84>
b: 83 f8 ff cmpl $0xffffffff,%eax
Code; c01100d3 <mask_IO_APIC_irq+1b/84>
e: 74 53 je 63 <_EIP+0x63> c0110128
<mask_IO_APIC_irq+70/84> Code; c01100d5 <mask_IO_APIC_irq+1d/84>
10: bf 00 e0 ff 00 movl $0xffe000,%edi
Kernel panic: Attempted to kill the idle task!
4 warnings issued. Results may not be reliable.
there have been 4-5 lockups since the upgrade and it was always the same
oops message.
for the record some additional data about the server box:
soltek sl-68a dual slot1 motherboard (with latest h4 bios)
2 p3-550 with 512kb cache
promise udma66 controler
intel etherexpress nic
64 + 128 mb ram (pc100)
6 hdd's (maxtor and ibm drives)
kernel: 2.2.15pre20 (thats pretty much 2.2.16 i guess)
+ ide patch
+ ext3 patch
+ ppdd patch
if you need any additional data please don't hesitate to contact me for
that!
is it really possible to break the stability of a box by simply upgrading
to a better cpu? my first idea was bad ram ... because it is running at 100
mhz now (66 with the celerons). but then i realized that this would be
pretty unlikely considering the same oops message all the time.
is there somebody out there who can help me?
best regards,
matt.
---------- End Forwarded Message ----------
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
