Skip to contentSkip to conversation

Oops on linux 2.4.20-ac1

DISCUSSION Orion Poplawski 6 participants 11 messages Dec 10, 2002 – Dec 12, 2002

lore
Share & tools
lore
#0 lore raw

I've been having a number of issues, mostly system lockups, with a machine of ours - a dual proc athlon. I've removed some hardware and I haven't seen a hand recently. However, we got an Oops message recently. I lost that message because it wasn't written to any log (any way I can fix that?). So, I upgraded the kernel to 2.4.20-ac1. Under that I started getting Oops quite frequently. Here is my first attemp at processing the message. Note that I switched back to the previous kernel, but it's running the same module list and I tried to point ksymoops to the correct pieces. I also typed the oops message in from what I wrote down from the screen. Please let me know if I made a mistake there.

ksymoops 2.4.1 on i686 2.4.19. Options used

    -v /usr/src/linux-2.4.20-ac1/vmlinux (specified)
    -k /var/log/ksyms.1 (specified)
    -l /proc/modules (default)
    -o /lib/modules/2.4.20-ac1 (specified)
    -m /boot/System.map-2.4.20-ac1 (specified)

Error (expand_objects): cannot stat(/lib/ext3.o) for ext3
ksymoops: No such file or directory
Error (expand_objects): cannot stat(/lib/jbd.o) for jbd
ksymoops: No such file or directory
Error (expand_objects): cannot stat(/lib/sym53c8xx.o) for sym53c8xx
ksymoops: No such file or directory
Error (expand_objects): cannot stat(/lib/sd_mod.o) for sd_mod
ksymoops: No such file or directory
Error (expand_objects): cannot stat(/lib/scsi_mod.o) for scsi_mod
ksymoops: No such file or directory
Warning (read_object): no symbols in /lib/modules/2.4.20-ac1/build/net/ipv4/netfilter/netfilter.o Warning (read_object): no symbols in /lib/modules/2.4.20-ac1/build/drivers/net/fc/fc.o
Warning (read_object): no symbols in /lib/modules/2.4.20-ac1/build/drivers/sound/sounddrivers.o Warning (read_object): no symbols in /lib/modules/2.4.20-ac1/build/drivers/cdrom/driver.o
Warning (read_object): no symbols in /lib/modules/2.4.20-ac1/build/drivers/ide/raid/idedriver-raid.o Warning (read_object): no symbols in /lib/modules/2.4.20-ac1/build/drivers/ide/ppc/idedriver-ppc.o Warning (read_object): no symbols in /lib/modules/2.4.20-ac1/build/drivers/ide/legacy/idedriver-legacy.o Warning (read_object): no symbols in /lib/modules/2.4.20-ac1/build/drivers/ide/arm/idedriver-arm.o Warning (read_object): no symbols in /lib/modules/2.4.20-ac1/build/drivers/misc/misc.o
Warning (read_object): no symbols in /lib/modules/2.4.20-ac1/build/drivers/parport/driver.o
Warning (read_object): no symbols in /lib/modules/2.4.20-ac1/build/drivers/media/radio/radio.o Warning (read_object): no symbols in /lib/modules/2.4.20-ac1/build/drivers/media/video/video.o Warning (read_object): no symbols in /lib/modules/2.4.20-ac1/build/drivers/media/media.o
Warning (read_object): no symbols in /lib/modules/2.4.20-ac1/build/drivers/hotplug/vmlinux-obj.o Warning (compare_ksyms_lsmod): module 3c59x is in lsmod but not in ksyms, probably no symbols exported Warning (compare_ksyms_lsmod): module autofs is in lsmod but not in ksyms, probably no symbols exported Warning (compare_ksyms_lsmod): module binfmt_misc is in lsmod but not in ksyms, probably no symbols exported Warning (compare_ksyms_lsmod): module lockd is in lsmod but not in ksyms, probably no symbols exported Warning (compare_ksyms_lsmod): module nfs 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 sunrpc is in lsmod but not in ksyms, probably no symbols exported Warning (map_ksym_to_module): cannot match loaded module ext3 to a unique module object. Trace may not be reliable. Warning (map_ksym_to_module): cannot match loaded module jbd to a unique module object. Trace may not be reliable. Warning (map_ksym_to_module): cannot match loaded module sym53c8xx to a unique module object. Trace may not be reliable. Warning (map_ksym_to_module): cannot match loaded module sd_mod to a unique module object. Trace may not be reliable. Warning (map_ksym_to_module): cannot match loaded module scsi_mod to a unique module object. Trace may not be reliable.

Oops: 0002
CPU: 0

EIP: 0010:[<f89641eb>] Not tainted
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00010216
eax: 00000040 ebx: 00000028 ecx: 00000060 edx: f590a960
esi: f590a800 edi: f590a960 ebp: c4650ed2 esp: f4a45eb0
ds: 0018 es: 0018 ss: 0018

Stack: 0000003c 0000001f 00000000 0000b800 00000060 f590a960 f5e4d62c 00000082
      00000001 00000082 f5dd3fd8 00000001 00000086 00000001 00000086 
f5a98000
      00000000 0000000e f4a45f08 00000000 f5a4d600 f7ff0340 00000040 
c01beaff
Call Trace: [<c01beaff>] [<c0120593>] [<f896382a>]
           [<c011f92d>] [<c0109b89>] [<c0109cf8>]
Code: b8 01 30 00 00 83 c2 0e 66 ef 8b 7c 24 14 8b 87 dc 00 00 00
Quoted 1 line
Quoted 1 line

EIP; f89641eb <END_OF_CODE+10598c/????> <=====

Trace; c01beaff <netif_receive_skb+ff/130>
Trace; c0120593 <send_sig_info+73/90>
Trace; f896382a <END_OF_CODE+104fcb/????>
Trace; c011f92d <do_timer+3d/70>
Trace; c0109b89 <handle_IRQ_event+39/60>
Trace; c0109cf8 <do_IRQ+68/b0>
Code; f89641eb <END_OF_CODE+10598c/????>
00000000 <_EIP>:

Code;  f89641eb <END_OF_CODE+10598c/????>   <=====
  0:   b8 01 30 00 00            mov    $0x3001,%eax   <=====
Code;  f89641f0 <END_OF_CODE+105991/????>
  5:   83 c2 0e                  add    $0xe,%edx
Code;  f89641f3 <END_OF_CODE+105994/????>
  8:   66 ef                     out    %ax,(%dx)
Code;  f89641f5 <END_OF_CODE+105996/????>
  a:   8b 7c 24 14               mov    0x14(%esp,1),%edi
Code;  f89641f9 <END_OF_CODE+10599a/????>
  e:   8b 87 dc 00 00 00         mov    0xdc(%edi),%eax

26 warnings and 5 errors issued. Results may not be reliable.

#1 lore raw
Quoted 2 lines · Orion Poplawski

I've been having a number of issues, mostly system lockups, with a machine of ours - a dual proc athlon. I've removed some hardware and I

Random lockups on dual athlons are a notorious problem under all OS's. Start by checking it passes memtest86, that will verify the RAM is ok - and the AMD is -very- picky about RAM.

If thats ok then let me know which board you have, what is plugged into it and what PSU you are using.

#2 lore raw
Quoted 6 lines · Alan Cox

Random lockups on dual athlons are a notorious problem under all OS's. Start by checking it passes memtest86, that will verify the RAM is ok - and the AMD is -very- picky about RAM.

If thats ok then let me know which board you have, what is plugged into it and what PSU you are using.

I have two AMD MP 2000+ cpus in an ASUS A7M266-D. Even after returning my memory for new chips the store owner memtest86'd, my combo of cpus and mobo was finding the occasional error. I finally ended up resolving it by simply underclocking the bus about 6Mhz :(

Next time, I'm buying ECC memory.
---scott

#3 lore raw

Reliable hardware

Quoted 12 lines · scott thomason
Quoted 8 lines · Alan Cox

Random lockups on dual athlons are a notorious problem under all OS's. Start by checking it passes memtest86, that will verify the RAM is ok - and the AMD is -very- picky about RAM.

If thats ok then let me know which board you have, what is plugged into it and what PSU you are using.

Quoted 6 lines

I have two AMD MP 2000+ cpus in an ASUS A7M266-D. Even after returning my memory for new chips the store owner memtest86'd, my combo of cpus and mobo was finding the occasional error. I finally ended up resolving it by simply underclocking the bus about 6Mhz :(

Next time, I'm buying ECC memory.
---scott

Is there a good site for pointers towards assembling reliable Linux machines? It seems to me the trickiest part of the whole operation is choosing good hardware in the first place. I just started a new job and inherited a buch of new but flakey machines, and I'd like to avoid doing that in the future.

#9 lore raw
In reply to scott thomason
Quoted 6 lines · scott thomason

I have two AMD MP 2000+ cpus in an ASUS A7M266-D. Even after returning my memory for new chips the store owner memtest86'd, my combo of cpus and mobo was finding the occasional error. I finally ended up resolving it by simply underclocking the bus about 6Mhz :(

Next time, I'm buying ECC memory.
---scott

Underclocking has been my "solution" to these lockups as well. Would ECC memory actually help in this case though?

#4 lore raw

Re: Reliable hardware

In reply to Orion Poplawski
Quoted 5 lines · Orion Poplawski

Is there a good site for pointers towards assembling reliable Linux machines? It seems to me the trickiest part of the whole operation is choosing good hardware in the first place. I just started a new job and inherited a buch of new but flakey machines, and I'd like to avoid doing that in the future.

The AMD duals have been a disaster in my experience. Its a shame because when they do go they really are very fast boxes. The biggest factor I've found is chipsets.

#8 lore raw

Re: Reliable hardware

In reply to Orion Poplawski
Quoted 9 lines
Quoted 9 lines
Quoted 8 lines

Random lockups on dual athlons are a notorious problem under all OS's. Start by checking it passes memtest86, that will verify the RAM is ok - and the AMD is -very- picky about RAM.

If thats ok then let me know which board you have, what is plugged into it and what PSU you are using.

Quoted 6 lines
Quoted 6 lines

I have two AMD MP 2000+ cpus in an ASUS A7M266-D. Even after returning my memory for new chips the store owner memtest86'd, my combo of cpus and mobo was finding the occasional error. I finally ended up resolving it by simply underclocking the bus about 6Mhz :(

Next time, I'm buying ECC memory.

Why? ECC memory guards against a single bit error in the RAM, nothing else, (except that it also reports double bit errors).

John.

#5 lore raw

Re: Reliable hardware

In reply to Alan Cox
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line

"AC" == Alan Cox <[email protected]> writes:

AC> The AMD duals have been a disaster in my experience.

I do have a bunch of these running reliably (RH 7.3 plus the latest OpenMosix kernel). I had to go through a few combinations of motherboard and RAM (four different manufacturers of RAM) before I got something that works. Processors are MP 1900+ or 2000+, boards are Tyan S2466, memory is in PC2100 ECC registered 512MB sticks from Corsair. Case and power supply are PC Power and Cooling, mid tower, 450W PS, every fan bay filled. These machines have been rock stable for months except for a failed IBM deathstar drive and an over-temp shutdown when the room AC failed.

I still have a couple of the 760MP boards (as opposed to the MPX boards) which I just can't get to run properly with two processors.

- J<

#10 lore raw
In reply to Alan Cox
Quoted 9 lines · Alan Cox

Random lockups on dual athlons are a notorious problem under all OS's. Start by checking it passes memtest86, that will verify the RAM is ok - and the AMD is -very- picky about RAM.

If thats ok then let me know which board you have, what is plugged into it and what PSU you are using.

memtest86 completed 3 passes with no errors, so:

MB:
Asus A7M266-D w/ Dual Athlon 2100 MP and 4 x 512MB PC2100 ECC Dimms AMD 762 Chipset
RAM clocking is "normal"

Cards:
PCI 3com 3c905-TX ethernet
PCI Tekram DC-390U3W SCSI Controller PCI ATI 3d Rage II Video

1 IDE Hard disk
1 external SCSI disk

PSU is a Turbo-Cool 475 ATX-PFC (appears to be 460W)

#6 lore raw

Re: Reliable hardware

In reply to Alan Cox
Quoted 10 lines · Alan Cox
Quoted 5 lines · Orion Poplawski

Is there a good site for pointers towards assembling reliable Linux machines? It seems to me the trickiest part of the whole operation is choosing good hardware in the first place. I just started a new job and inherited a buch of new but flakey machines, and I'd like to avoid doing that in the future.

The AMD duals have been a disaster in my experience. Its a shame because when they do go they really are very fast boxes. The biggest factor I've found is chipsets.

Which chipset - the new or the old one? I've got an ASUS A7M266D (or something) that's based on the AMD 760MPX chipset and has 512MB of Registered ECC memory, and a pair of XP 1800+'s... and it works just beautifuly. Truely rock solid.

Pat
--
Purdue Universtiy ITAP/RCS
Information Technology at Purdue
Research Computing and Storage
http://www-rcd.cc.purdue.edu

#7 lore raw

Re: Reliable hardware

Quoted 4 lines · Patrick Finnegan

Which chipset - the new or the old one? I've got an ASUS A7M266D (or something) that's based on the AMD 760MPX chipset and has 512MB of Registered ECC memory, and a pair of XP 1800+'s... and it works just beautifuly. Truely rock solid.

Same board you have.