Hi,
I'm getting regular oopses that can be easily reproduced with a
[dd if=/dev/zero of=~/boo bs=4096 count=100000] on my
Compaq Armada M700/PIII/750MHZ with 256MB RAM with more than 3GB free
on /home. /home is on ext2, /tmp on tmpfs, with a 500 MB swap partition.
This is with the 2.4.19 stock kernel.
Regards,
Sapan
Unable to handle kernel NULL pointer dereference at virtual address 00000100
00000100
*pde = 00000000
Oops: 0000
CPU: 0
EIP: 0010:[<00000100>] Not tainted
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00010202
eax: 00000001 ebx: c0315420 ecx: 00000001 edx: d081c000
esi: 00000001 edi: 0000001e ebp: 00002480 esp: c12f5f28
ds: 0018 es: 0018 ss: 0018
Process kswapd (pid: 4, stackpage=c12f5000)
Stack: c108eff0 c012a313 c0315420 00000000 c12f4000 00000172 000001d0 c02b6e54
c12c72f0 caa9e028 c12c5420 00000000 00000020 000001d0 00000006 0001bcd8
c012a498 00000006 00000000 c02b6e54 00000006 000001d0 c02b6e54 00000000
Call Trace: [<c012a313>] [<c012a498>] [<c012a4fc>] [<c012a5a1>] [<c012a616>]
[<c012a751>] [<c012a6b0>] [<c010708b>]
Code: Bad EIP value.
>>EIP; 00000100 Before first symbol <=====
>>ebx; c0315420 <swap_info+0/700>
>>edx; d081c000 <_end+104e3f3c/10525f3c>
>>ebp; 00002480 Before first symbol
>>esp; c12f5f28 <_end+fbde64/10525f3c>
Trace; c012a313 <shrink_cache+2c3/300>
Trace; c012a498 <shrink_caches+58/80>
Trace; c012a4fc <try_to_free_pages+3c/60>
Trace; c012a5a1 <kswapd_balance_pgdat+51/a0>
Trace; c012a616 <kswapd_balance+26/40>
Trace; c012a751 <kswapd+a1/c0>
Trace; c012a6b0 <kswapd+0/c0>
Trace; c010708b <kernel_thread+2b/40>
<1>Unable to handle kernel NULL pointer dereference at virtual address 00000200
00000200
*pde = 00000000
Oops: 0000
CPU: 0
EIP: 0010:[<00000200>] Not tainted
EFLAGS: 00010202
eax: 00000001 ebx: c0315420 ecx: 00000002 edx: d081c000
esi: 00000002 edi: 00000020 ebp: 000024f7 esp: cabdfe70
ds: 0018 es: 0018 ss: 0018
Process bunzip2 (pid: 792, stackpage=cabdf000)
Stack: c11e6988 c012a313 c0315420 00000000 cabde000 0000018d 000001d2 c02b6e54
c12c72f0 cd0f7034 c12c71a0 00000001 00000020 000001d2 00000006 0001c110
c012a498 00000006 00000000 c02b6e54 00000006 000001d2 c02b6e54 00000000
Call Trace: [<c012a313>] [<c012a498>] [<c012a4fc>] [<c012ae89>] [<c012b11b>]
[<c01267bf>] [<c010cfa1>] [<c0130ba6>] [<c01182dd>] [<c0109dbe>] [<c0108857>]
Code: Bad EIP value.
>>EIP; 00000200 Before first symbol <=====
>>ebx; c0315420 <swap_info+0/700>
>>edx; d081c000 <_end+104e3f3c/10525f3c>
>>ebp; 000024f7 Before first symbol
>>esp; cabdfe70 <_end+a8a7dac/10525f3c>
Trace; c012a313 <shrink_cache+2c3/300>
Trace; c012a498 <shrink_caches+58/80>
Trace; c012a4fc <try_to_free_pages+3c/60>
Trace; c012ae89 <balance_classzone+59/1d0>
Trace; c012b11b <__alloc_pages+11b/180>
Trace; c01267bf <generic_file_write+42f/730>
Trace; c010cfa1 <timer_interrupt+71/120>
Trace; c0130ba6 <sys_write+96/f0>
Trace; c01182dd <do_softirq+4d/90>
Trace; c0109dbe <do_IRQ+9e/b0>
Trace; c0108857 <system_call+33/38>
<1>Unable to handle kernel paging request at virtual address 00006c00
00006c00
*pde = 00000000
Oops: 0000
CPU: 0
EIP: 0010:[<00006c00>] Not tainted
EFLAGS: 00010202
eax: 00000001 ebx: c0315420 ecx: 0000006c edx: d081c000
esi: 0000006c edi: 00000006 ebp: 00002504 esp: c9c83e70
ds: 0018 es: 0018 ss: 0018
Process bunzip2 (pid: 831, stackpage=c9c83000)
Stack: c12056a4 c012a313 c0315420 00000073 c9c82000 000001c5 000001d2 c02b6e54
c0132beb 00000306 c12c7520 00000000 00000020 000001d2 00000006 0001c086
c012a498 00000006 00000000 c02b6e54 00000006 000001d2 c02b6e54 00000000
Call Trace: [<c012a313>] [<c0132beb>] [<c012a498>] [<c012a4fc>] [<c012ae89>]
[<c012b11b>] [<c01267bf>] [<c0130ba6>] [<c0108857>]
Code: Bad EIP value.
>>EIP; 00006c00 Before first symbol <=====
>>ebx; c0315420 <swap_info+0/700>
>>edx; d081c000 <_end+104e3f3c/10525f3c>
>>ebp; 00002504 Before first symbol
>>esp; c9c83e70 <_end+994bdac/10525f3c>
Trace; c012a313 <shrink_cache+2c3/300>
Trace; c0132beb <unmap_underlying_metadata+1b/60>
Trace; c012a498 <shrink_caches+58/80>
Trace; c012a4fc <try_to_free_pages+3c/60>
Trace; c012ae89 <balance_classzone+59/1d0>
Trace; c012b11b <__alloc_pages+11b/180>
Trace; c01267bf <generic_file_write+42f/730>
Trace; c0130ba6 <sys_write+96/f0>
Trace; c0108857 <system_call+33/38>
Just in case this had someone wondering, the problem was swap
corruption. I did an mkswap on the swap partition, and it doesn't
OOPS anymore.
The OOPS was at vmscan.c:506 (Bad EIP=200)
On Tue, Sep 03, 2002 at 07:07:26PM +0200, [email protected] wrote:
> Hi,
>
> I'm getting regular oopses that can be easily reproduced with a
> [dd if=/dev/zero of=~/boo bs=4096 count=100000] on my
> Compaq Armada M700/PIII/750MHZ with 256MB RAM with more than 3GB free
> on /home. /home is on ext2, /tmp on tmpfs, with a 500 MB swap partition.
>
> This is with the 2.4.19 stock kernel.
>
> Regards,
> Sapan
>
>
> Unable to handle kernel NULL pointer dereference at virtual address 00000100
> 00000100
> *pde = 00000000
> Oops: 0000
> CPU: 0
> EIP: 0010:[<00000100>] Not tainted
> Using defaults from ksymoops -t elf32-i386 -a i386
> EFLAGS: 00010202
> eax: 00000001 ebx: c0315420 ecx: 00000001 edx: d081c000
> esi: 00000001 edi: 0000001e ebp: 00002480 esp: c12f5f28
> ds: 0018 es: 0018 ss: 0018
> Process kswapd (pid: 4, stackpage=c12f5000)
> Stack: c108eff0 c012a313 c0315420 00000000 c12f4000 00000172 000001d0 c02b6e54
> c12c72f0 caa9e028 c12c5420 00000000 00000020 000001d0 00000006 0001bcd8
> c012a498 00000006 00000000 c02b6e54 00000006 000001d0 c02b6e54 00000000
> Call Trace: [<c012a313>] [<c012a498>] [<c012a4fc>] [<c012a5a1>] [<c012a616>]
> [<c012a751>] [<c012a6b0>] [<c010708b>]
> Code: Bad EIP value.
>
>
> >>EIP; 00000100 Before first symbol <=====
>
> >>ebx; c0315420 <swap_info+0/700>
> >>edx; d081c000 <_end+104e3f3c/10525f3c>
> >>ebp; 00002480 Before first symbol
> >>esp; c12f5f28 <_end+fbde64/10525f3c>
>
> Trace; c012a313 <shrink_cache+2c3/300>
> Trace; c012a498 <shrink_caches+58/80>
> Trace; c012a4fc <try_to_free_pages+3c/60>
> Trace; c012a5a1 <kswapd_balance_pgdat+51/a0>
> Trace; c012a616 <kswapd_balance+26/40>
> Trace; c012a751 <kswapd+a1/c0>
> Trace; c012a6b0 <kswapd+0/c0>
> Trace; c010708b <kernel_thread+2b/40>
>
> <1>Unable to handle kernel NULL pointer dereference at virtual address 00000200
> 00000200
> *pde = 00000000
> Oops: 0000
> CPU: 0
> EIP: 0010:[<00000200>] Not tainted
> EFLAGS: 00010202
> eax: 00000001 ebx: c0315420 ecx: 00000002 edx: d081c000
> esi: 00000002 edi: 00000020 ebp: 000024f7 esp: cabdfe70
> ds: 0018 es: 0018 ss: 0018
> Process bunzip2 (pid: 792, stackpage=cabdf000)
> Stack: c11e6988 c012a313 c0315420 00000000 cabde000 0000018d 000001d2 c02b6e54
> c12c72f0 cd0f7034 c12c71a0 00000001 00000020 000001d2 00000006 0001c110
> c012a498 00000006 00000000 c02b6e54 00000006 000001d2 c02b6e54 00000000
> Call Trace: [<c012a313>] [<c012a498>] [<c012a4fc>] [<c012ae89>] [<c012b11b>]
> [<c01267bf>] [<c010cfa1>] [<c0130ba6>] [<c01182dd>] [<c0109dbe>] [<c0108857>]
> Code: Bad EIP value.
>
>
> >>EIP; 00000200 Before first symbol <=====
>
> >>ebx; c0315420 <swap_info+0/700>
> >>edx; d081c000 <_end+104e3f3c/10525f3c>
> >>ebp; 000024f7 Before first symbol
> >>esp; cabdfe70 <_end+a8a7dac/10525f3c>
>
> Trace; c012a313 <shrink_cache+2c3/300>
> Trace; c012a498 <shrink_caches+58/80>
> Trace; c012a4fc <try_to_free_pages+3c/60>
> Trace; c012ae89 <balance_classzone+59/1d0>
> Trace; c012b11b <__alloc_pages+11b/180>
> Trace; c01267bf <generic_file_write+42f/730>
> Trace; c010cfa1 <timer_interrupt+71/120>
> Trace; c0130ba6 <sys_write+96/f0>
> Trace; c01182dd <do_softirq+4d/90>
> Trace; c0109dbe <do_IRQ+9e/b0>
> Trace; c0108857 <system_call+33/38>
>
> <1>Unable to handle kernel paging request at virtual address 00006c00
> 00006c00
> *pde = 00000000
> Oops: 0000
> CPU: 0
> EIP: 0010:[<00006c00>] Not tainted
> EFLAGS: 00010202
> eax: 00000001 ebx: c0315420 ecx: 0000006c edx: d081c000
> esi: 0000006c edi: 00000006 ebp: 00002504 esp: c9c83e70
> ds: 0018 es: 0018 ss: 0018
> Process bunzip2 (pid: 831, stackpage=c9c83000)
> Stack: c12056a4 c012a313 c0315420 00000073 c9c82000 000001c5 000001d2 c02b6e54
> c0132beb 00000306 c12c7520 00000000 00000020 000001d2 00000006 0001c086
> c012a498 00000006 00000000 c02b6e54 00000006 000001d2 c02b6e54 00000000
> Call Trace: [<c012a313>] [<c0132beb>] [<c012a498>] [<c012a4fc>] [<c012ae89>]
> [<c012b11b>] [<c01267bf>] [<c0130ba6>] [<c0108857>]
> Code: Bad EIP value.
>
>
> >>EIP; 00006c00 Before first symbol <=====
>
> >>ebx; c0315420 <swap_info+0/700>
> >>edx; d081c000 <_end+104e3f3c/10525f3c>
> >>ebp; 00002504 Before first symbol
> >>esp; c9c83e70 <_end+994bdac/10525f3c>
>
> Trace; c012a313 <shrink_cache+2c3/300>
> Trace; c0132beb <unmap_underlying_metadata+1b/60>
> Trace; c012a498 <shrink_caches+58/80>
> Trace; c012a4fc <try_to_free_pages+3c/60>
> Trace; c012ae89 <balance_classzone+59/1d0>
> Trace; c012b11b <__alloc_pages+11b/180>
> Trace; c01267bf <generic_file_write+42f/730>
> Trace; c0130ba6 <sys_write+96/f0>
> Trace; c0108857 <system_call+33/38>
>
>
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
On Wed, Sep 04, 2002 at 08:11:55PM +0200, [email protected] wrote:
> Just in case this had someone wondering, the problem was swap
> corruption. I did an mkswap on the swap partition, and it doesn't
> OOPS anymore.
make sense.
The reason of the corruption could be from hardware fault to whatever
buggy application that played with the devices, so unless you can
reproduce I'd ignore this on the kernel side, at least on 2.4 (kernel
trusts metadata, the fs does too, kernel assumes if the data is
corrupted an I/O error has to be generated by the hardware, we can add
some check to make it more robust but it's not a 2.4 matter).
Andrea
Hi,
The problem just came back. I got a couple of identical oopses.
They all fail _immediately_ after returning from swap_free().
badblocks -w ran fine on the swap partition, and to my knowlege
I'm not running any applications that might be playing with the disk.
What else could be causing it?
Swap is about 530MB. /tmp is on tmpfs.
Regards,
Sapan
Code: 6e 23 c1 40 64 2b c0 00 02 00 00 34 3d 20 c1 02 00 00 00 59
Code; 00000000 Before first symbol
00000000 <_EIP>:
Code; 00000000 Before first symbol
0: 6e outsb %ds:(%esi),(%dx)
Code; 00000001 Before first symbol
1: 23 c1 and %ecx,%eax
Code; 00000003 Before first symbol
3: 40 inc %eax
Code; 00000004 Before first symbol
4: 64 fs
Code; 00000005 Before first symbol
5: 2b c0 sub %eax,%eax
Code; 00000007 Before first symbol
7: 00 02 add %al,(%edx)
Code; 00000009 Before first symbol
9: 00 00 add %al,(%eax)
Code; 0000000b Before first symbol
b: 34 3d xor $0x3d,%al
Code; 0000000d Before first symbol
d: 20 c1 and %al,%cl
Code; 0000000f Before first symbol
f: 02 00 add (%eax),%al
Code; 00000011 Before first symbol
11: 00 00 add %al,(%eax)
Code; 00000013 Before first symbol
13: 59 pop %ecx
00009900
*pde = 00000000
Oops: 0000
CPU: 0
EIP: 0010:[<00009900>] Not Tainted
EFLAGS: 00010202
eax: 00000002 ebx: c0316420 ecx: 00000099 edx: d081e000
esi: 00000099 edi: cc94fffc ebp: cd591500 esp: c834be50
ds: 0018 es: 0018 ss: 0018
Process ps (pid: 1942, stackpage=c834b000)
Stack: c11f6948 c0121a16 c0316420 00000001 bffffe62 00000000 cd591500 cc99e2a0
c0121d5b cd591500 cc99e2a0 bffffe62 cc94fffc 00009900 00000000 c390b600
cb4e4000 ffffffea cffbd468 cd591500 bffffe62 c0122adc cd591500 cc99e2a0
Call Trace: [<c0121a16>] [<c0121d5b>] [<c0122adc>] [<c0120dd2>] [<c011ac0d>]
[<c014affa>] [<c014afb0>] [<c014b30e>] [<c0130ab6>] [<c01391be>] [<c01305d7>]
[<c0108857>]
Code: Bad EIP value
>>EIP; 00009900 Before first symbol <=====
>>ebx; c0316420 <swap_info+0/700>
>>edx; d081e000 <_end+104e4dfc/10528dfc>
>>edi; cc94fffc <_end+c616df8/10528dfc>
>>ebp; cd591500 <_end+d2582fc/10528dfc>
>>esp; c834be50 <_end+8012c4c/10528dfc>
Trace; c0121a16 <do_swap_page+86/f0>
Trace; c0121d5b <handle_mm_fault+6b/c0>
Trace; c0122adc <find_extend_vma+1c/b0>
Trace; c0120dd2 <get_user_pages+82/1a0>
Trace; c011ac0d <access_process_vm+11d/160>
Trace; c014affa <proc_pid_cmdline+4a/e0>
Trace; c014afb0 <proc_pid_cmdline+0/e0>
Trace; c014b30e <proc_info_read+4e/110>
Trace; c0130ab6 <sys_read+96/f0>
Trace; c01391be <getname+5e/a0>
Trace; c01305d7 <sys_open+57/80>
Trace; c0108857 <system_call+33/38>
On Wed, Sep 04, 2002 at 08:22:23PM +0200, Andrea Arcangeli wrote:
> On Wed, Sep 04, 2002 at 08:11:55PM +0200, [email protected] wrote:
> > Just in case this had someone wondering, the problem was swap
> > corruption. I did an mkswap on the swap partition, and it doesn't
> > OOPS anymore.
>
> make sense.
>
> The reason of the corruption could be from hardware fault to whatever
> buggy application that played with the devices, so unless you can
> reproduce I'd ignore this on the kernel side, at least on 2.4 (kernel
> trusts metadata, the fs does too, kernel assumes if the data is
> corrupted an I/O error has to be generated by the hardware, we can add
> some check to make it more robust but it's not a 2.4 matter).
>
> Andrea
> -
Hi,
Just in case this might shed some more light on the problem...
I recompiled the kernel with frame pointers about a week ago, and I
didn't face a single oops till today morning, when I recompiled the
kernel without frame-pointers and I've been getting the same
oopses all day.
Kind regards,
Sapan
On Thu, Sep 05, 2002 at 10:32:33PM +0200, [email protected] wrote:
> Hi,
>
> The problem just came back. I got a couple of identical oopses.
>
> They all fail _immediately_ after returning from swap_free().
> badblocks -w ran fine on the swap partition, and to my knowlege
> I'm not running any applications that might be playing with the disk.
> What else could be causing it?
>
> Swap is about 530MB. /tmp is on tmpfs.
>
> Regards,
> Sapan
>
>
> Code: 6e 23 c1 40 64 2b c0 00 02 00 00 34 3d 20 c1 02 00 00 00 59
>
> Code; 00000000 Before first symbol
> 00000000 <_EIP>:
> Code; 00000000 Before first symbol
> 0: 6e outsb %ds:(%esi),(%dx)
> Code; 00000001 Before first symbol
> 1: 23 c1 and %ecx,%eax
> Code; 00000003 Before first symbol
> 3: 40 inc %eax
> Code; 00000004 Before first symbol
> 4: 64 fs
> Code; 00000005 Before first symbol
> 5: 2b c0 sub %eax,%eax
> Code; 00000007 Before first symbol
> 7: 00 02 add %al,(%edx)
> Code; 00000009 Before first symbol
> 9: 00 00 add %al,(%eax)
> Code; 0000000b Before first symbol
> b: 34 3d xor $0x3d,%al
> Code; 0000000d Before first symbol
> d: 20 c1 and %al,%cl
> Code; 0000000f Before first symbol
> f: 02 00 add (%eax),%al
> Code; 00000011 Before first symbol
> 11: 00 00 add %al,(%eax)
> Code; 00000013 Before first symbol
> 13: 59 pop %ecx
>
> 00009900
> *pde = 00000000
> Oops: 0000
> CPU: 0
> EIP: 0010:[<00009900>] Not Tainted
> EFLAGS: 00010202
> eax: 00000002 ebx: c0316420 ecx: 00000099 edx: d081e000
> esi: 00000099 edi: cc94fffc ebp: cd591500 esp: c834be50
> ds: 0018 es: 0018 ss: 0018
> Process ps (pid: 1942, stackpage=c834b000)
> Stack: c11f6948 c0121a16 c0316420 00000001 bffffe62 00000000 cd591500 cc99e2a0
> c0121d5b cd591500 cc99e2a0 bffffe62 cc94fffc 00009900 00000000 c390b600
> cb4e4000 ffffffea cffbd468 cd591500 bffffe62 c0122adc cd591500 cc99e2a0
> Call Trace: [<c0121a16>] [<c0121d5b>] [<c0122adc>] [<c0120dd2>] [<c011ac0d>]
> [<c014affa>] [<c014afb0>] [<c014b30e>] [<c0130ab6>] [<c01391be>] [<c01305d7>]
> [<c0108857>]
> Code: Bad EIP value
>
>
> >>EIP; 00009900 Before first symbol <=====
>
> >>ebx; c0316420 <swap_info+0/700>
> >>edx; d081e000 <_end+104e4dfc/10528dfc>
> >>edi; cc94fffc <_end+c616df8/10528dfc>
> >>ebp; cd591500 <_end+d2582fc/10528dfc>
> >>esp; c834be50 <_end+8012c4c/10528dfc>
>
> Trace; c0121a16 <do_swap_page+86/f0>
> Trace; c0121d5b <handle_mm_fault+6b/c0>
> Trace; c0122adc <find_extend_vma+1c/b0>
> Trace; c0120dd2 <get_user_pages+82/1a0>
> Trace; c011ac0d <access_process_vm+11d/160>
> Trace; c014affa <proc_pid_cmdline+4a/e0>
> Trace; c014afb0 <proc_pid_cmdline+0/e0>
> Trace; c014b30e <proc_info_read+4e/110>
> Trace; c0130ab6 <sys_read+96/f0>
> Trace; c01391be <getname+5e/a0>
> Trace; c01305d7 <sys_open+57/80>
> Trace; c0108857 <system_call+33/38>
>
>
> On Wed, Sep 04, 2002 at 08:22:23PM +0200, Andrea Arcangeli wrote:
> > On Wed, Sep 04, 2002 at 08:11:55PM +0200, [email protected] wrote:
> > > Just in case this had someone wondering, the problem was swap
> > > corruption. I did an mkswap on the swap partition, and it doesn't
> > > OOPS anymore.
> >
> > make sense.
> >
> > The reason of the corruption could be from hardware fault to whatever
> > buggy application that played with the devices, so unless you can
> > reproduce I'd ignore this on the kernel side, at least on 2.4 (kernel
> > trusts metadata, the fs does too, kernel assumes if the data is
> > corrupted an I/O error has to be generated by the hardware, we can add
> > some check to make it more robust but it's not a 2.4 matter).
> >
> > Andrea
> > -
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
On Wed, 2002-09-11 at 18:16, [email protected] wrote:
> Just in case this might shed some more light on the problem...
> I recompiled the kernel with frame pointers about a week ago, and I
> didn't face a single oops till today morning, when I recompiled the
> kernel without frame-pointers and I've been getting the same
> oopses all day.
>
Are you using gcc 3.0.x or an early gcc 3.1.x. There are bugs in those
where they write below the stack pointer which means an IRQ will corrupt
stuff. Turning on frame pointers might well hide this
Hm, actually I am.
And from the oops traces, the offending intruction always seems to be a
pop.
I'll upgrade and try again.
Thanks,
Sapan
On Wed, Sep 11, 2002 at 06:48:16PM +0100, Alan Cox wrote:
> On Wed, 2002-09-11 at 18:16, [email protected] wrote:
> > Just in case this might shed some more light on the problem...
> > I recompiled the kernel with frame pointers about a week ago, and I
> > didn't face a single oops till today morning, when I recompiled the
> > kernel without frame-pointers and I've been getting the same
> > oopses all day.
> >
>
> Are you using gcc 3.0.x or an early gcc 3.1.x. There are bugs in those
> where they write below the stack pointer which means an IRQ will corrupt
> stuff. Turning on frame pointers might well hide this
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/