2.4.19 OOPS [Repost]

2.4.19 OOPS [Repost]

Post by li.. » Thu, 05 Sep 2002 02:10:08



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.

Quote:>>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.

Quote:>>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.

Quote:>>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

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

2.4.19 OOPS [Repost]

Post by li.. » Fri, 06 Sep 2002 03:20:06


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)


> 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

> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

2.4.19 OOPS [Repost]

Post by Andrea Arcangel » Fri, 06 Sep 2002 03:30:08



> 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

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

2.4.19 OOPS [Repost]

Post by li.. » Sat, 07 Sep 2002 05:40:05


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

Quote:>>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>



> > 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

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/
 
 
 

2.4.19 OOPS [Repost]

Post by li.. » Fri, 13 Sep 2002 02:20:09


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


> 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>



> > > 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

> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/
 
 
 

2.4.19 OOPS [Repost]

Post by Alan Co » Fri, 13 Sep 2002 02:50:10



> 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

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

2.4.19 OOPS [Repost]

Post by li.. » Fri, 13 Sep 2002 20:50:10


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



> > 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

> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/