Hi.
When running 'tar cvIf <file> /' or 'tar cvzf <file> /' (but sometimes not
with 'plain' tar, i.e., without compression) I get an oops after some
time. This is reproducible. The oops below is from a 'tar cvIf' run.
I get this also with 2.2.17pre10 (which was what I was running before
encountering this) but not with the stock RH 6.2 kernel (2.2.14-5.0).
Unless I get other suggestions I'm going to try with the latest 2.2.18pre
and 2.2.16 tomorrow.
Since I had just experienced RAM problems on another machine I put in
some new RAM after testing it with memtest86, but that did not solve
the problem (neither did the old RAM show any errors when I memtested
it afterwards).
I'm not sure about the warning. Is it fatal? And what should I do to get
rid of it?
Comments appreciated and info willingly given :)
ksymoops 0.7c on i586 2.2.17. Options used
-V (default)
-k /proc/ksyms (default)
-l /proc/modules (default)
-o /lib/modules/2.2.17/ (default)
-m /boot/System.map (specified)
Warning (compare_maps): ksyms_base symbol module_list_R__ver_module_list not found in System.map. Ignoring ksyms_base entry
Nov 13 18:15:05 firewall kernel: Unable to handle kernel NULL pointer dereference at virtual address 00000004
Nov 13 18:15:05 firewall kernel: current->tss.cr3 = 07259000, %cr3 = 07259000
Nov 13 18:15:05 firewall kernel: *pde = 00000000
Nov 13 18:15:05 firewall kernel: Oops: 0002
Nov 13 18:15:05 firewall kernel: CPU: 0
Nov 13 18:15:05 firewall kernel: EIP: 0010:[<c0121b43>]
Using defaults from ksymoops -t elf32-i386 -a i386
Nov 13 18:15:05 firewall kernel: EFLAGS: 00010087
Nov 13 18:15:05 firewall kernel: eax: 00000000 ebx: 00000001 ecx: 00000000 edx: 00000000
Nov 13 18:15:05 firewall kernel: esi: c02009f0 edi: 00001000 ebp: c022a790 esp: c725bd4c
Nov 13 18:15:05 firewall kernel: ds: 0018 es: 0018 ss: 0018
Nov 13 18:15:05 firewall kernel: Process bzip2 (pid: 1327, process nr: 23, stackpage=c725b000)
Nov 13 18:15:05 firewall kernel: Stack: 00001000 00000306 00000001 0000000a 00000202 00000000 00000306 000016cf
Nov 13 18:15:05 firewall kernel: 00001000 c0126ff4 00000003 00000000 00001000 00000306 00000002 c10fd3c0
Nov 13 18:15:05 firewall kernel: c06c1000 c01261e8 00001000 000016cf 00001000 00000306 00000002 c10fd3c0
Nov 13 18:15:05 firewall kernel: Call Trace: [<c0126ff4>] [<c01261e8>] [<c01263c5>] [<c0125f01>] [<c013f74c>] [<c013fdc2>] [<c014011b>]
Nov 13 18:15:05 firewall kernel: [<c01264ff>] [<c013e23e>] [<c011130e>] [<c011ae20>] [<c011157e>] [<c0111573>] [<c010a103>] [<c01249cf>]
Nov 13 18:15:05 firewall kernel: [<c012483c>] [<c010923d>] [<c0109104>]
Nov 13 18:15:05 firewall kernel: Code: 89 70 04 89 e8 2b 05 ec da 1d c0 8d 04 40 89 c2 c1 e2 04 01
>>EIP; c0121b43 <__get_free_pages+1eb/2b8> <=====
Trace; c0126ff4 <grow_buffers+40/f8>
Trace; c01261e8 <refill_freelist+10/44>
Trace; c01263c5 <getblk+139/164>
Trace; c0125f01 <get_hash_table+1d/2c>
Trace; c013f74c <ext2_alloc_block+74/178>
Trace; c013fdc2 <block_getblk+156/2a0>
Trace; c014011b <ext2_getblk+20f/21c>
Trace; c01264ff <__brelse+13/64>
Trace; c013e23e <ext2_file_write+226/5bc>
Trace; c011130e <update_wall_time+12/48>
Trace; c011ae20 <handle_mm_fault+c8/13c>
Trace; c011157e <timer_bh+d2/3a0>
Trace; c0111573 <timer_bh+c7/3a0>
Trace; c010a103 <do_8259A_IRQ+8f/9c>
Trace; c01249cf <sys_write+c3/e8>
Trace; c012483c <sys_read+0/d0>
Trace; c010923d <error_code+2d/40>
Trace; c0109104 <system_call+34/40>
Code; c0121b43 <__get_free_pages+1eb/2b8>
00000000 <_EIP>:
Code; c0121b43 <__get_free_pages+1eb/2b8> <=====
0: 89 70 04 mov %esi,0x4(%eax) <=====
Code; c0121b46 <__get_free_pages+1ee/2b8>
3: 89 e8 mov %ebp,%eax
Code; c0121b48 <__get_free_pages+1f0/2b8>
5: 2b 05 ec da 1d c0 sub 0xc01ddaec,%eax
Code; c0121b4e <__get_free_pages+1f6/2b8>
b: 8d 04 40 lea (%eax,%eax,2),%eax
Code; c0121b51 <__get_free_pages+1f9/2b8>
e: 89 c2 mov %eax,%edx
Code; c0121b53 <__get_free_pages+1fb/2b8>
10: c1 e2 04 shl $0x4,%edx
Code; c0121b56 <__get_free_pages+1fe/2b8>
13: 01 00 add %eax,(%eax)
1 warning issued. Results may not be reliable.
--
Regards,
Rasmus([email protected])
Without censorship, things can get terribly confused in the
public mind. -General William Westmoreland, during the war in Viet Nam
> I get this also with 2.2.17pre10 (which was what I was running before
> encountering this) but not with the stock RH 6.2 kernel (2.2.14-5.0).
> Unless I get other suggestions I'm going to try with the latest 2.2.18pre
> and 2.2.16 tomorrow.
>
OK, I tried with 2.2.16 and 2.2.18pre21 compiled with egcs-2.91.66
(the kernels reported yesterday were compiled with 2.95.2).
2.2.16 oopsed faithfully (I could not get hold of the oops as several
scrolled by and none made it to the log). 2.2.18pre21 does not oops.
Bzip2 core dumps, but gzip makes it through. So it seems that my
problem has been solved already and proactively :)
Regards,
Rasmus
>
> OK, I tried with 2.2.16 and 2.2.18pre21 compiled with egcs-2.91.66
> (the kernels reported yesterday were compiled with 2.95.2).
>
> 2.2.16 oopsed faithfully (I could not get hold of the oops as several
> scrolled by and none made it to the log). 2.2.18pre21 does not oops.
> Bzip2 core dumps, but gzip makes it through. So it seems that my
> problem has been solved already and proactively :)
>
Eeek. Apparently I was a bit too early with the champagne... I was
away for an hour or so and when I came back it (2.2.18pre21) had
oopsed with multiple oops (i.e. the first offscreen) and hardlocked.
I'm now running 2.2.14-5 again, doing the exact same stuff and it
seems to hold up... (knock wood).
Barring someine suggestin a better solution I'll try to compile
a kernel with serial console and capture an oops that way.
Regards
Rasmus