Duron kernel crash (i686 works)

Duron kernel crash (i686 works)

[Roberto Jung Drebes]

Hi,

Today I updated the BIOS of my motherboard, a ABIT KT7A (VIA Apollo KT133A
chipset). The kernel I had (2.4.9) started crashing on boot with an
invalid page fault, usually right after starting init. I tryed a i686
kernel and noticed it works OK, so I recompiled my crashy kernel only
switching the processor type and it also worked. changed it back to
Athlon/K7/Duron and it starts crashing.

Anyone else experiencing this?

TIA,

--
Roberto Jung Drebes <drebes@inf.ufrgs.br>
Porto Alegre, RS - Brasil
http://www.inf.ufrgs.br/~drebes/

Re: Duron kernel crash (i686 works)

[Roberto Jung Drebes]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1468 bytes --]

On Mon, 10 Sep 2001, Roberto Jung Drebes wrote:

> 
> Hi,
> 
> Today I updated the BIOS of my motherboard, a ABIT KT7A (VIA Apollo KT133A
> chipset). The kernel I had (2.4.9) started crashing on boot with an
> invalid page fault, usually right after starting init. I tryed a i686
> kernel and noticed it works OK, so I recompiled my crashy kernel only
> switching the processor type and it also worked. changed it back to
> Athlon/K7/Duron and it starts crashing.
> 
> Anyone else experiencing this?

I captured the log via serial console, and the problem does not always
happens at exactly the same time. The time I did the log, it happened
right after init would mount /proc. So I passes init=/bin/sh to the kernel
and initted "manually". At first things seemed to be OK. I then mounted
/proc, no probs, swapon -a, ok, then started just playing around with ls,
etc. Soon the loader would complain that there was no memory to be alloced
to run the programs. After a while, the kernel would complain about trying
to free a page that was not malloced or something like that. It seems to
be related to the VM subsys.

Anyway here is the trace done on the captured log.

Latter, I found on the archives that some people solved instability
problems on the KT133A by disabling the 3DNOW. I changed it to n in
arch/i386/config.in, but it seems to have no effect.

TIA,

--
Roberto Jung Drebes <drebes@inf.ufrgs.br>
Porto Alegre, RS - Brasil
http://www.inf.ufrgs.br/~drebes/

[-- Attachment #2: Type: TEXT/PLAIN, Size: 16651 bytes --]

ksymoops 2.3.4 on i686 2.4.9.  Options used
     -v /usr/src/linux/vmlinux (specified)
     -K (specified)
     -l /proc/modules (default)
     -o /lib/modules/2.4.9/ (specified)
     -m /usr/src/linux/System.map (specified)

No modules in ksyms, skipping objects
No ksyms, skipping lsmod
invalid operand: 0000
CPU:    0
EIP:    0010:[<c0129e5a>]
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00010286
eax: 00000020   ebx: 00000001   ecx: 00000001   edx: c0246ea8
esi: c11012dc   edi: c02481f8   ebp: 00000000   esp: c3ccfe4c
ds: 0018   es: 0018   ss: 0018
Process logger (pid: 33, stackpage=c3ccf000)
Stack: c020a34c c020a440 000000cc c02481d4 c0248360 00000000 c3c8a134 00002c83 
       00000282 c0248204 00000000 c02481d4 c0129fb3 000000d2 c116f500 c116dc40 
       c3c8a134 00000001 c024835c 000000d2 c0129f36 00000000 c01208f2 00000000 
Call Trace: [<c0129fb3>] [<c0129f36>] [<c01208f2>] [<c012098f>] [<c0120a9b>] 
   [<c0110980>] [<c0110ae3>] [<c0110980>] [<c01234c3>] [<c0123400>] [<c012f593>] 
   [<c0106f48>] 
Code: 0f 0b 83 c4 0c 90 89 f0 eb 1c 47 83 44 24 18 0c 83 ff 09 0f 

>>EIP; c0129e5a <rmqueue+23a/270>   <=====
Trace; c0129fb3 <__alloc_pages+73/280>
Trace; c0129f36 <_alloc_pages+16/20>
Trace; c01208f2 <do_anonymous_page+32/a0>
Trace; c012098f <do_no_page+2f/e0>
Trace; c0120a9b <handle_mm_fault+5b/c0>
Trace; c0110980 <do_page_fault+0/460>
Trace; c0110ae3 <do_page_fault+163/460>
Trace; c0110980 <do_page_fault+0/460>
Trace; c01234c3 <generic_file_read+63/80>
Trace; c0123400 <file_read_actor+0/60>
Trace; c012f593 <sys_read+c3/d0>
Trace; c0106f48 <error_code+34/3c>
Code;  c0129e5a <rmqueue+23a/270>
00000000 <_EIP>:
Code;  c0129e5a <rmqueue+23a/270>   <=====
   0:   0f 0b                     ud2a      <=====
Code;  c0129e5c <rmqueue+23c/270>
   2:   83 c4 0c                  add    $0xc,%esp
Code;  c0129e5f <rmqueue+23f/270>
   5:   90                        nop    
Code;  c0129e60 <rmqueue+240/270>
   6:   89 f0                     mov    %esi,%eax
Code;  c0129e62 <rmqueue+242/270>
   8:   eb 1c                     jmp    26 <_EIP+0x26> c0129e80 <rmqueue+260/270>
Code;  c0129e64 <rmqueue+244/270>
   a:   47                        inc    %edi
Code;  c0129e65 <rmqueue+245/270>
   b:   83 44 24 18 0c            addl   $0xc,0x18(%esp,1)
Code;  c0129e6a <rmqueue+24a/270>
  10:   83 ff 09                  cmp    $0x9,%edi
Code;  c0129e6d <rmqueue+24d/270>
  13:   0f 00 00                  sldt   (%eax)

invalid operand: 0000
CPU:    0
EIP:    0010:[<c0129942>]
EFLAGS: 00010286
eax: 0000001f   ebx: c11012dc   ecx: 00000001   edx: c0246ea8
esi: c11012dc   edi: 00000001   ebp: 00000000   esp: c3c77b4c
ds: 0018   es: 0018   ss: 0018
Process minilogd (pid: 31, stackpage=c3c77000)
Stack: c020a34c c020a440 00000049 c1105478 c11012dc 00000001 00000001 c11012dc 
       c01faf19 c3d7a000 c3c83000 c01239b3 c012a22a c01239c6 c0247eb0 c116dd00 
       c116f440 00000001 00000002 c3fd1ff4 c3c310e4 c3c31040 c3cbe3c0 c01209b2 
Call Trace: [<c01faf19>] [<c01239b3>] [<c012a22a>] [<c01239c6>] [<c01209b2>] 
   [<c0120a9b>] [<c0110980>] [<c0110ae3>] [<c0110980>] [<c01233f2>] [<c01218d6>] 
   [<c0106f48>] [<c0106f48>] [<c0106f48>] [<c01faace>] [<c01462ec>] [<c01472b8>] 
   [<c01469a0>] [<c0137f57>] [<c01381dc>] [<c01381f3>] [<c0105b3f>] [<c0106e57>] 
Code: 0f 0b 83 c4 0c 83 7b 08 00 74 16 6a 4b 68 40 a4 20 c0 68 4c 

>>EIP; c0129942 <__free_pages_ok+22/300>   <=====
Trace; c01faf19 <mmx_copy_page+29/30>
Trace; c01239b3 <filemap_nopage+103/3e0>
Trace; c012a22a <__free_pages+1a/20>
Trace; c01239c6 <filemap_nopage+116/3e0>
Trace; c01209b2 <do_no_page+52/e0>
Trace; c0120a9b <handle_mm_fault+5b/c0>
Trace; c0110980 <do_page_fault+0/460>
Trace; c0110ae3 <do_page_fault+163/460>
Trace; c0110980 <do_page_fault+0/460>
Trace; c01233f2 <do_generic_file_read+502/510>
Trace; c01218d6 <do_munmap+56/250>
Trace; c0106f48 <error_code+34/3c>
Trace; c0106f48 <error_code+34/3c>
Trace; c0106f48 <error_code+34/3c>
Trace; c01faace <clear_user+2e/40>
Trace; c01462ec <padzero+1c/20>
Trace; c01472b8 <load_elf_binary+918/a80>
Trace; c01469a0 <load_elf_binary+0/a80>
Trace; c0137f57 <search_binary_handler+67/170>
Trace; c01381dc <do_execve+17c/1f0>
Trace; c01381f3 <do_execve+193/1f0>
Trace; c0105b3f <sys_execve+2f/60>
Trace; c0106e57 <system_call+33/38>
Code;  c0129942 <__free_pages_ok+22/300>
00000000 <_EIP>:
Code;  c0129942 <__free_pages_ok+22/300>   <=====
   0:   0f 0b                     ud2a      <=====
Code;  c0129944 <__free_pages_ok+24/300>
   2:   83 c4 0c                  add    $0xc,%esp
Code;  c0129947 <__free_pages_ok+27/300>
   5:   83 7b 08 00               cmpl   $0x0,0x8(%ebx)
Code;  c012994b <__free_pages_ok+2b/300>
   9:   74 16                     je     21 <_EIP+0x21> c0129963 <__free_pages_ok+43/300>
Code;  c012994d <__free_pages_ok+2d/300>
   b:   6a 4b                     push   $0x4b
Code;  c012994f <__free_pages_ok+2f/300>
   d:   68 40 a4 20 c0            push   $0xc020a440
Code;  c0129954 <__free_pages_ok+34/300>
  12:   68 4c 00 00 00            push   $0x4c

invalid operand: 0000
CPU:    0
EIP:    0010:[<c0129e5a>]
EFLAGS: 00010282
eax: 00000020   ebx: 00000001   ecx: 00000001   edx: c0246ea8
esi: c11012dc   edi: c02481f8   ebp: 00000000   esp: c3ed9e74
ds: 0018   es: 0018   ss: 0018
Process rc (pid: 44, stackpage=c3ed9000)
Stack: c020a34c c020a440 000000cc c02481d4 c0248360 00000000 03e63065 00002c83 
       00000286 c0248204 00000000 c02481d4 c0129fb3 000000d2 c110925c ffffffff 
       03e63065 00000001 c024835c 000000d2 c0129f36 080c4f04 c01203b7 080c4f04 
Call Trace: [<c0129fb3>] [<c0129f36>] [<c01203b7>] [<c0120acd>] [<c0110980>] 
   [<c0110ae3>] [<c0110980>] [<c01faca3>] [<c01058a8>] [<c01132f7>] [<c0105ab4>] 
   [<c0106f48>] 
Code: 0f 0b 83 c4 0c 90 89 f0 eb 1c 47 83 44 24 18 0c 83 ff 09 0f 

>>EIP; c0129e5a <rmqueue+23a/270>   <=====
Trace; c0129fb3 <__alloc_pages+73/280>
Trace; c0129f36 <_alloc_pages+16/20>
Trace; c01203b7 <do_wp_page+157/250>
Trace; c0120acd <handle_mm_fault+8d/c0>
Trace; c0110980 <do_page_fault+0/460>
Trace; c0110ae3 <do_page_fault+163/460>
Trace; c0110980 <do_page_fault+0/460>
Trace; c01faca3 <_mmx_memcpy+53/100>
Trace; c01058a8 <copy_thread+88/a0>
Trace; c01132f7 <do_fork+5f7/6b0>
Trace; c0105ab4 <sys_fork+14/20>
Trace; c0106f48 <error_code+34/3c>
Code;  c0129e5a <rmqueue+23a/270>
00000000 <_EIP>:
Code;  c0129e5a <rmqueue+23a/270>   <=====
   0:   0f 0b                     ud2a      <=====
Code;  c0129e5c <rmqueue+23c/270>
   2:   83 c4 0c                  add    $0xc,%esp
Code;  c0129e5f <rmqueue+23f/270>
   5:   90                        nop    
Code;  c0129e60 <rmqueue+240/270>
   6:   89 f0                     mov    %esi,%eax
Code;  c0129e62 <rmqueue+242/270>
   8:   eb 1c                     jmp    26 <_EIP+0x26> c0129e80 <rmqueue+260/270>
Code;  c0129e64 <rmqueue+244/270>
   a:   47                        inc    %edi
Code;  c0129e65 <rmqueue+245/270>
   b:   83 44 24 18 0c            addl   $0xc,0x18(%esp,1)
Code;  c0129e6a <rmqueue+24a/270>
  10:   83 ff 09                  cmp    $0x9,%edi
Code;  c0129e6d <rmqueue+24d/270>
  13:   0f 00 00                  sldt   (%eax)

invalid operand: 0000
CPU:    0
EIP:    0010:[<c0129e5a>]
EFLAGS: 00010282
eax: 00000020   ebx: 00000001   ecx: 00000001   edx: c0246ea8
esi: c1101298   edi: c02481f8   ebp: 00000000   esp: c3d35e74
ds: 0018   es: 0018   ss: 0018
Process rc (pid: 45, stackpage=c3d35000)
Stack: c020a34c c020a440 000000cc c02481d4 c0248360 00000000 03f5e065 00002c82 
       00000286 c02481f8 00000000 c02481d4 c0129fb3 000000d2 c110d508 ffffffff 
       03f5e065 00000001 c024835c 000000d2 c0129f36 40016b68 c01203b7 40016b68 
Call Trace: [<c0129fb3>] [<c0129f36>] [<c01203b7>] [<c0120acd>] [<c0110980>] 
   [<c0110ae3>] [<c0110980>] [<c01391da>] [<c013a3dc>] [<c012ee3d>] [<c012ed72>] 
   [<c012f16c>] [<c012f1c3>] [<c0106f48>] 
Code: 0f 0b 83 c4 0c 90 89 f0 eb 1c 47 83 44 24 18 0c 83 ff 09 0f 

>>EIP; c0129e5a <rmqueue+23a/270>   <=====
Trace; c0129fb3 <__alloc_pages+73/280>
Trace; c0129f36 <_alloc_pages+16/20>
Trace; c01203b7 <do_wp_page+157/250>
Trace; c0120acd <handle_mm_fault+8d/c0>
Trace; c0110980 <do_page_fault+0/460>
Trace; c0110ae3 <do_page_fault+163/460>
Trace; c0110980 <do_page_fault+0/460>
Trace; c01391da <permission+2a/30>
Trace; c013a3dc <open_namei+32c/5b0>
Trace; c012ee3d <dentry_open+bd/140>
Trace; c012ed72 <filp_open+52/60>
Trace; c012f16c <filp_close+5c/70>
Trace; c012f1c3 <sys_close+43/60>
Trace; c0106f48 <error_code+34/3c>
Code;  c0129e5a <rmqueue+23a/270>
00000000 <_EIP>:
Code;  c0129e5a <rmqueue+23a/270>   <=====
   0:   0f 0b                     ud2a      <=====
Code;  c0129e5c <rmqueue+23c/270>
   2:   83 c4 0c                  add    $0xc,%esp
Code;  c0129e5f <rmqueue+23f/270>
   5:   90                        nop    
Code;  c0129e60 <rmqueue+240/270>
   6:   89 f0                     mov    %esi,%eax
Code;  c0129e62 <rmqueue+242/270>
   8:   eb 1c                     jmp    26 <_EIP+0x26> c0129e80 <rmqueue+260/270>
Code;  c0129e64 <rmqueue+244/270>
   a:   47                        inc    %edi
Code;  c0129e65 <rmqueue+245/270>
   b:   83 44 24 18 0c            addl   $0xc,0x18(%esp,1)
Code;  c0129e6a <rmqueue+24a/270>
  10:   83 ff 09                  cmp    $0x9,%edi
Code;  c0129e6d <rmqueue+24d/270>
  13:   0f 00 00                  sldt   (%eax)

invalid operand: 0000
CPU:    0
EIP:    0010:[<c0129942>]
EFLAGS: 00010286
eax: 0000001f   ebx: c1101298   ecx: 00000001   edx: c0246ea8
esi: c1101298   edi: c3d4b084   ebp: 00000000   esp: c3d35cd8
ds: 0018   es: 0018   ss: 0018
Process rc (pid: 45, stackpage=c3d35000)
Stack: c020a34c c020a440 00000049 c1101298 c1101298 c3d4b084 c3d4a16c c02a1640 
       00000000 c0299240 00000000 00000046 c012a22a c012a76a c1101298 00000069 
       c011f739 c1101298 c116ddc0 c116f140 08048000 0007c000 00448000 08448000 
Call Trace: [<c012a22a>] [<c012a76a>] [<c011f739>] [<c0121de5>] [<c0112606>] 
   [<c01162dd>] [<c01075d0>] [<c0107392>] [<c010764f>] [<c0129e5a>] [<c011ac0f>] 
   [<c011773a>] [<c0117659>] [<c011743a>] [<c01082ed>] [<c0106ee0>] [<c0106f48>] 
   [<c0129e5a>] [<c0129fb3>] [<c0129f36>] [<c01203b7>] [<c0120acd>] [<c0110980>] 
   [<c0110ae3>] [<c0110980>] [<c01391da>] [<c013a3dc>] [<c012ee3d>] [<c012ed72>] 
   [<c012f16c>] [<c012f1c3>] [<c0106f48>] 
Code: 0f 0b 83 c4 0c 83 7b 08 00 74 16 6a 4b 68 40 a4 20 c0 68 4c 

>>EIP; c0129942 <__free_pages_ok+22/300>   <=====
Trace; c012a22a <__free_pages+1a/20>
Trace; c012a76a <free_page_and_swap_cache+ba/c0>
Trace; c011f739 <zap_page_range+1b9/250>
Trace; c0121de5 <exit_mmap+b5/120>
Trace; c0112606 <mmput+26/50>
Trace; c01162dd <do_exit+9d/200>
Trace; c01075d0 <do_invalid_op+0/90>
Trace; c0107392 <die+42/50>
Trace; c010764f <do_invalid_op+7f/90>
Trace; c0129e5a <rmqueue+23a/270>
Trace; c011ac0f <do_timer+3f/70>
Trace; c011773a <bh_action+1a/50>
Trace; c0117659 <tasklet_hi_action+59/80>
Trace; c011743a <do_softirq+5a/b0>
Trace; c01082ed <do_IRQ+9d/b0>
Trace; c0106ee0 <ret_from_intr+0/7>
Trace; c0106f48 <error_code+34/3c>
Trace; c0129e5a <rmqueue+23a/270>
Trace; c0129fb3 <__alloc_pages+73/280>
Trace; c0129f36 <_alloc_pages+16/20>
Trace; c01203b7 <do_wp_page+157/250>
Trace; c0120acd <handle_mm_fault+8d/c0>
Trace; c0110980 <do_page_fault+0/460>
Trace; c0110ae3 <do_page_fault+163/460>
Trace; c0110980 <do_page_fault+0/460>
Trace; c01391da <permission+2a/30>
Trace; c013a3dc <open_namei+32c/5b0>
Trace; c012ee3d <dentry_open+bd/140>
Trace; c012ed72 <filp_open+52/60>
Trace; c012f16c <filp_close+5c/70>
Trace; c012f1c3 <sys_close+43/60>
Trace; c0106f48 <error_code+34/3c>
Code;  c0129942 <__free_pages_ok+22/300>
00000000 <_EIP>:
Code;  c0129942 <__free_pages_ok+22/300>   <=====
   0:   0f 0b                     ud2a      <=====
Code;  c0129944 <__free_pages_ok+24/300>
   2:   83 c4 0c                  add    $0xc,%esp
Code;  c0129947 <__free_pages_ok+27/300>
   5:   83 7b 08 00               cmpl   $0x0,0x8(%ebx)
Code;  c012994b <__free_pages_ok+2b/300>
   9:   74 16                     je     21 <_EIP+0x21> c0129963 <__free_pages_ok+43/300>
Code;  c012994d <__free_pages_ok+2d/300>
   b:   6a 4b                     push   $0x4b
Code;  c012994f <__free_pages_ok+2f/300>
   d:   68 40 a4 20 c0            push   $0xc020a440
Code;  c0129954 <__free_pages_ok+34/300>
  12:   68 4c 00 00 00            push   $0x4c

invalid operand: 0000
CPU:    0
EIP:    0010:[<c0129e5a>]
EFLAGS: 00010282
eax: 00000020   ebx: 00000002   ecx: 00000001   edx: c0246ea8
esi: c1104dd4   edi: c0248204   ebp: 00000001   esp: c3eeff20
ds: 0018   es: 0018   ss: 0018
Process rc (pid: 41, stackpage=c3eef000)
Stack: c020a34c c020a440 000000cc c02481d4 c0248340 00000001 c3eeffbc 00002d61 
       00000296 c0248204 00000001 c02481d4 c0129fb3 000000f0 bffff28c 00000000 
       c3eeffbc 00000000 c024833c 000000f0 c0129f36 c3eee000 c012a1ca c0112d40 
Call Trace: [<c0129fb3>] [<c0129f36>] [<c012a1ca>] [<c0112d40>] [<c0105ab4>] 
   [<c0106e57>] 
Code: 0f 0b 83 c4 0c 90 89 f0 eb 1c 47 83 44 24 18 0c 83 ff 09 0f 

>>EIP; c0129e5a <rmqueue+23a/270>   <=====
Trace; c0129fb3 <__alloc_pages+73/280>
Trace; c0129f36 <_alloc_pages+16/20>
Trace; c012a1ca <__get_free_pages+a/20>
Trace; c0112d40 <do_fork+40/6b0>
Trace; c0105ab4 <sys_fork+14/20>
Trace; c0106e57 <system_call+33/38>
Code;  c0129e5a <rmqueue+23a/270>
00000000 <_EIP>:
Code;  c0129e5a <rmqueue+23a/270>   <=====
   0:   0f 0b                     ud2a      <=====
Code;  c0129e5c <rmqueue+23c/270>
   2:   83 c4 0c                  add    $0xc,%esp
Code;  c0129e5f <rmqueue+23f/270>
   5:   90                        nop    
Code;  c0129e60 <rmqueue+240/270>
   6:   89 f0                     mov    %esi,%eax
Code;  c0129e62 <rmqueue+242/270>
   8:   eb 1c                     jmp    26 <_EIP+0x26> c0129e80 <rmqueue+260/270>
Code;  c0129e64 <rmqueue+244/270>
   a:   47                        inc    %edi
Code;  c0129e65 <rmqueue+245/270>
   b:   83 44 24 18 0c            addl   $0xc,0x18(%esp,1)
Code;  c0129e6a <rmqueue+24a/270>
  10:   83 ff 09                  cmp    $0x9,%edi
Code;  c0129e6d <rmqueue+24d/270>
  13:   0f 00 00                  sldt   (%eax)

invalid operand: 0000
CPU:    0
EIP:    0010:[<c0129e5a>]
EFLAGS: 00010282
eax: 00000020   ebx: 00000001   ecx: 00000001   edx: c0246ea8
esi: c1104e5c   edi: c02481f8   ebp: 00000000   esp: c3fc7e74
ds: 0018   es: 0018   ss: 0018
Process init (pid: 1, stackpage=c3fc7000)
Stack: c020a34c c020a440 000000cc c02481d4 c0248360 00000000 03ce6065 00002d63 
       00000286 c0248204 00000000 c02481d4 c0129fb3 000000d2 c1102d28 ffffffff 
       03ce6065 00000001 c024835c 000000d2 c0129f36 40144740 c01203b7 40144740 
Call Trace: [<c0129fb3>] [<c0129f36>] [<c01203b7>] [<c0120acd>] [<c0110980>] 
   [<c0110ae3>] [<c0110980>] [<c01391da>] [<c013a3dc>] [<c012ee3d>] [<c012ed72>] 
   [<c012f4c0>] [<c0106f48>] 
Code: 0f 0b 83 c4 0c 90 89 f0 eb 1c 47 83 44 24 18 0c 83 ff 09 0f 

>>EIP; c0129e5a <rmqueue+23a/270>   <=====
Trace; c0129fb3 <__alloc_pages+73/280>
Trace; c0129f36 <_alloc_pages+16/20>
Trace; c01203b7 <do_wp_page+157/250>
Trace; c0120acd <handle_mm_fault+8d/c0>
Trace; c0110980 <do_page_fault+0/460>
Trace; c0110ae3 <do_page_fault+163/460>
Trace; c0110980 <do_page_fault+0/460>
Trace; c01391da <permission+2a/30>
Trace; c013a3dc <open_namei+32c/5b0>
Trace; c012ee3d <dentry_open+bd/140>
Trace; c012ed72 <filp_open+52/60>
Trace; c012f4c0 <sys_llseek+c0/d0>
Trace; c0106f48 <error_code+34/3c>
Code;  c0129e5a <rmqueue+23a/270>
00000000 <_EIP>:
Code;  c0129e5a <rmqueue+23a/270>   <=====
   0:   0f 0b                     ud2a      <=====
Code;  c0129e5c <rmqueue+23c/270>
   2:   83 c4 0c                  add    $0xc,%esp
Code;  c0129e5f <rmqueue+23f/270>
   5:   90                        nop    
Code;  c0129e60 <rmqueue+240/270>
   6:   89 f0                     mov    %esi,%eax
Code;  c0129e62 <rmqueue+242/270>
   8:   eb 1c                     jmp    26 <_EIP+0x26> c0129e80 <rmqueue+260/270>
Code;  c0129e64 <rmqueue+244/270>
   a:   47                        inc    %edi
Code;  c0129e65 <rmqueue+245/270>
   b:   83 44 24 18 0c            addl   $0xc,0x18(%esp,1)
Code;  c0129e6a <rmqueue+24a/270>
  10:   83 ff 09                  cmp    $0x9,%edi
Code;  c0129e6d <rmqueue+24d/270>
  13:   0f 00 00                  sldt   (%eax)

Kernel panic: Attempted to kill init!

Re: Duron kernel crash (i686 works)

[Alan Cox]

> Today I updated the BIOS of my motherboard, a ABIT KT7A (VIA Apollo KT133A
> chipset). The kernel I had (2.4.9) started crashing on boot with an
> invalid page fault, usually right after starting init. I tryed a i686
> kernel and noticed it works OK, so I recompiled my crashy kernel only
>
> Anyone else experiencing this?

Several reports. Back down the BIOS version

Re: Duron kernel crash (i686 works)

[VDA]

>> Today I updated the BIOS of my motherboard, a ABIT KT7A (VIA Apollo KT133A
>> chipset). The kernel I had (2.4.9) started crashing on boot with an
>> invalid page fault, usually right after starting init. I tryed a i686
>> kernel and noticed it works OK, so I recompiled my crashy kernel only
>> Anyone else experiencing this?

AC> Several reports. Back down the BIOS version

Aha, we need to make kernel reprogram KT133A so that we won't be blamed
for BIOS flaws. Does anybody have a clue what's exactly changed in
chipset programming from YH to 3R BIOS? BIOSes are on
ftp://ftp.leo.org/pub/comp/general/devices/abit/bios/kt7/

>>         ...
>>         kernel_fpu_end();
>> +       from-=4096;
>> +       to-=4096;
>> +       if(memcmp(from,to,4096)!=0) {
>> +               printk("Athlon bug!"); //add printout of from,to,...?
>> +               memcpy(to,from,4096);
>> +       }
>> }

RJD> I then get 'Athlon bug!' Still oopses.

Waah! That means movntq's moved data to some other place in memory!
memcmp detected that and memcpy fixed, but that 'other place' was
corrupted and that's the cause of oops.
You may change printk to see when this happens:
    printk(KERN_ERR "Athlon bug! from=%08X to=%08X\n", from, to);
If you do, please post from/to pairs printed to lkml.

>> Comparing K7 and MMX fast_copy_page...
>> 
>> Does replacing movntq->movq makes oops go avay?

RJD> Yes, it does! Didn't tested exaustively, but it seems to go away!

This is a check to dismiss "bad PSU/memory/..." theories.
It is indeed CPU/chipset interaction bug fixable by chipset
programming.

RJD> As said earlier, this happens after upgrading from BIOS YH to 3R in the
RJD> KT7A-RAID. The processor is a Duron 800 not overclocked.
-- 
Best regards, VDA
mailto:VDA@port.imtp.ilyichevsk.odessa.ua
http://port.imtp.ilyichevsk.odessa.ua/vda/

Re: Duron kernel crash (i686 works)

[Steffen Persvold]

VDA wrote:
> 
> >>         ...
> >>         kernel_fpu_end();
> >> +       from-=4096;
> >> +       to-=4096;
> >> +       if(memcmp(from,to,4096)!=0) {
> >> +               printk("Athlon bug!"); //add printout of from,to,...?
> >> +               memcpy(to,from,4096);
> >> +       }
> >> }
> 
> RJD> I then get 'Athlon bug!' Still oopses.
> 
> Waah! That means movntq's moved data to some other place in memory!
> memcmp detected that and memcpy fixed, but that 'other place' was
> corrupted and that's the cause of oops.
Well, not necessarily. It might be that data just hasn't "arrived" yet because
of the movntq instruction.

One thing that also puzzels me is that my is the fast_copy_page() routine laid
out like this :

		"2: movq (%0), %%mm0\n"
		"   movntq %%mm0, (%1)\n"
		"   movq 8(%0), %%mm1\n"
		"   movntq %%mm1, 8(%1)\n"
		"   movq 16(%0), %%mm2\n"
		"   movntq %%mm2, 16(%1)\n"
		"   movq 24(%0), %%mm3\n"
		"   movntq %%mm3, 24(%1)\n"
		"   movq 32(%0), %%mm4\n"
		"   movntq %%mm4, 32(%1)\n"
		"   movq 40(%0), %%mm5\n"
		"   movntq %%mm5, 40(%1)\n"
		"   movq 48(%0), %%mm6\n"
		"   movntq %%mm6, 48(%1)\n"
		"   movq 56(%0), %%mm7\n"
		"   movntq %%mm7, 56(%1)\n"

When it's more intuitively more effective to fill the registers with reads first
and then write it with "movntq" like this :

		"2: movq (%0), %%mm0\n"
		"   movq 8(%0), %%mm1\n"
		"   movq 16(%0), %%mm2\n"
		"   movq 24(%0), %%mm3\n"
		"   movq 32(%0), %%mm4\n"
		"   movq 40(%0), %%mm5\n"
		"   movq 48(%0), %%mm6\n"
		"   movq 56(%0), %%mm7\n"
		"   movntq %%mm0, (%1)\n"
		"   movntq %%mm1, 8(%1)\n"
		"   movntq %%mm2, 16(%1)\n"
		"   movntq %%mm3, 24(%1)\n"
		"   movntq %%mm4, 32(%1)\n"
		"   movntq %%mm5, 40(%1)\n"
		"   movntq %%mm6, 48(%1)\n"
		"   movntq %%mm7, 56(%1)\n"

Regards,
-- 
  Steffen Persvold   |  Scali Computer AS   |   Try out the world's best   
 mailto:sp@scali.no  | http://www.scali.com | performing MPI implementation:
Tel: (+47) 2262 8950 |  Olaf Helsets vei 6  |      - ScaMPI 1.12.2 -         
Fax: (+47) 2262 8951 |  N0621 Oslo, NORWAY  | >300MBytes/s and <4uS latency

Re: Duron kernel crash (i686 works)

[VDA]

Hello Steffen,
Wednesday, September 12, 2001, 1:51:55 PM, you wrote:
>> >>         ...
>> >>         kernel_fpu_end();
>> >> +       from-=4096;
>> >> +       to-=4096;
>> >> +       if(memcmp(from,to,4096)!=0) {
>> >> +               printk("Athlon bug!"); //add printout of from,to,...?
>> >> +               memcpy(to,from,4096);
>> >> +       }
>> >> }
>> 
>> RJD> I then get 'Athlon bug!' Still oopses.
>> 
>> Waah! That means movntq's moved data to some other place in memory!
>> memcmp detected that and memcpy fixed, but that 'other place' was
>> corrupted and that's the cause of oops.

SP> Well, not necessarily. It might be that data just hasn't "arrived" yet because
SP> of the movntq instruction.

So why it is oopses then?
Also, we don't want this data to arrive late or whatever.
fast_copy_page must copy page (make it so that memcpy()==0).
If it does not, it is too much "optimized".

SP> One thing that also puzzels me is that my is the fast_copy_page() routine laid
SP> out like this :

SP>                 "2: movq (%0), %%mm0\n"
SP>                 "   movntq %%mm0, (%1)\n"
SP>                 "   movq 8(%0), %%mm1\n"
SP>                 "   movntq %%mm1, 8(%1)\n"
SP>                 "   movq 16(%0), %%mm2\n"
SP>                 "   movntq %%mm2, 16(%1)\n"
SP>                 "   movq 24(%0), %%mm3\n"
SP>                 "   movntq %%mm3, 24(%1)\n"
SP>                 "   movq 32(%0), %%mm4\n"
SP>                 "   movntq %%mm4, 32(%1)\n"
SP>                 "   movq 40(%0), %%mm5\n"
SP>                 "   movntq %%mm5, 40(%1)\n"
SP>                 "   movq 48(%0), %%mm6\n"
SP>                 "   movntq %%mm6, 48(%1)\n"
SP>                 "   movq 56(%0), %%mm7\n"
SP>                 "   movntq %%mm7, 56(%1)\n"

SP> When it's more intuitively more effective to fill the registers with reads first
SP> and then write it with "movntq" like this :

SP>                 "2: movq (%0), %%mm0\n"
SP>                 "   movq 8(%0), %%mm1\n"
SP>                 "   movq 16(%0), %%mm2\n"
SP>                 "   movq 24(%0), %%mm3\n"
SP>                 "   movq 32(%0), %%mm4\n"
SP>                 "   movq 40(%0), %%mm5\n"
SP>                 "   movq 48(%0), %%mm6\n"
SP>                 "   movq 56(%0), %%mm7\n"
SP>                 "   movntq %%mm0, (%1)\n"
SP>                 "   movntq %%mm1, 8(%1)\n"
SP>                 "   movntq %%mm2, 16(%1)\n"
SP>                 "   movntq %%mm3, 24(%1)\n"
SP>                 "   movntq %%mm4, 32(%1)\n"
SP>                 "   movntq %%mm5, 40(%1)\n"
SP>                 "   movntq %%mm6, 48(%1)\n"
SP>                 "   movntq %%mm7, 56(%1)\n"

A better way to do it is to bencmark several routines at
startup time and pick the best one. It is done now
for RAID xor'ing routine.
-- 
Best regards, VDA
mailto:VDA@port.imtp.ilyichevsk.odessa.ua
http://port.imtp.ilyichevsk.odessa.ua/vda/

Re: Duron kernel crash (i686 works)

[Arjan van de Ven]

VDA wrote:

> SP> Well, not necessarily. It might be that data just hasn't "arrived" yet because
> SP> of the movntq instruction.

this is wrong; the CPU _internal_ view of the data is always consistent,
regardless of movntq vs movq.
It's only the EXTERNAL view that is slightly different. "sfence" takes
care of syncing that.

 
> So why it is oopses then?
> Also, we don't want this data to arrive late or whatever.
> fast_copy_page must copy page (make it so that memcpy()==0).
> If it does not, it is too much "optimized".

It does; but if you read it back from memory and is corrupted, your
chipset corrupted it.
 
> SP> One thing that also puzzels me is that my is the fast_copy_page() routine laid
> SP> out like this :

[snip]

A better way to do it is to bencmark several routines at
> startup time and pick the best one. It is done now
> for RAID xor'ing routine.

I benchmarked several versions, see the testprogram at
http://www.fenrus.demon.nl/athlon.c

The interleaved one is faster on athlons because it seems to help AMD's
register aliasing logic
to operate better....

Anyway, since this code works for like 99% of the machines, and only 1%
seems to be affected, it really really really looks like a hardware bug.
This is also more or less proven by the reports that certain
biosversions "break" working setups by doing things to the via chipset
that make it break....

Greetings,
   Arjan van de Ven

Re: Duron kernel crash (i686 works)

[Alan Cox]

> So why it is oopses then?

On correct hardware it doesnt seem to oops. 

> Also, we don't want this data to arrive late or whatever.
> fast_copy_page must copy page (make it so that memcpy()==0).
> If it does not, it is too much "optimized".

See the "sfence" instruction

> A better way to do it is to bencmark several routines at
> startup time and pick the best one. It is done now
> for RAID xor'ing routine.

Not in this case. It is Athlon specific code. It was fine tuned when it
was written

Re: Duron kernel crash (i686 works)

[VDA]

Hello Alan,
Wednesday, September 12, 2001, 3:48:20 PM, you wrote:
>> So why it is oopses then?
AC> On correct hardware it doesnt seem to oops.

>> Also, we don't want this data to arrive late or whatever.
>> fast_copy_page must copy page (make it so that memcpy()==0).
>> If it does not, it is too much "optimized".
AC> See the "sfence" instruction

I meant instrumented fast_copy_page() cannot fail due to
late movntq commit to memory since memcmp() is behind sfence
and kernel_fpu_end():
>>         ...
>>         kernel_fpu_end();
>> +       /* Check for "Athlon bug" - remove when resolved */
>> +       from-=4096;
>> +       to-=4096;
>> +       if(memcmp(from,to,4096)!=0) {
>> +               printk(KERN_ERR "Athlon bug! from=%08X to=%08X\n", from, to);
>> +               memcpy(to,from,4096);
>> +       }
>> }

If we still see an oops with this instrumentation,
then fast_copy_page() must be clobbering
RAM elsewhere, right?

>> A better way to do it is to bencmark several routines at
>> startup time and pick the best one. It is done now
>> for RAID xor'ing routine.
AC> Not in this case. It is Athlon specific code. It was fine
AC> tuned when it was written

Yes, but sometimes we have routines which perform
differently on different CPUs. See inslude/asm-i386/string.h
and string-486.h: on Pentium rep movsd is faster, on 386 unrolled
loop is faster... so optimal routine can be picked only at runtime.
CPU-specific routines can compete in such runtime benchmark
too when proper processor is detected - see how KNI-specific
RAID xor routine does that.
-- 
Best regards, VDA
mailto:VDA@port.imtp.ilyichevsk.odessa.ua
http://port.imtp.ilyichevsk.odessa.ua/vda/

Re: Duron kernel crash (i686 works)

[Mike Fedyk]

On Wed, Sep 12, 2001 at 04:48:00PM +0300, VDA wrote:
> >> A better way to do it is to bencmark several routines at
> >> startup time and pick the best one. It is done now
> >> for RAID xor'ing routine.

> AC> Not in this case. It is Athlon specific code. It was fine
> AC> tuned when it was written

> Yes, but sometimes we have routines which perform
> differently on different CPUs. See inslude/asm-i386/string.h
> and string-486.h: on Pentium rep movsd is faster, on 386 unrolled
> loop is faster... so optimal routine can be picked only at runtime.
> CPU-specific routines can compete in such runtime benchmark
> too when proper processor is detected - see how KNI-specific
> RAID xor routine does that.

Hmm, just how far do you want to take that?  Compile in all of the
optimizations and test which is fastest on each processor at startup?

Hmm, that might not be a bad idea for dev kernels, as it might show
optimization problems on certain processors...

Re: Duron kernel crash (i686 works)

[Roberto Jung Drebes]

On Tue, 11 Sep 2001, VDA wrote:

> Please report to lkml as much details about your BIOSes (both older
> and newer) as you can.
> 
> You may be interesting in this msg:
> --------------------------------------------------------------
>         ...
>         kernel_fpu_end();
> +       from-=4096;
> +       to-=4096;
> +       if(memcmp(from,to,4096)!=0) {
> +               printk("Athlon bug!"); //add printout of from,to,...?
> +               memcpy(to,from,4096);
> +       }
> }

I then get 'Athlon bug!' Still oopses.

> 
> Comparing K7 and MMX fast_copy_page...
> 
> Does replacing movntq->movq fix makes oops go avay?

Yes, it does! Didn't tested exaustively, but it seems to go away!

As said earlier, this happens after upgrading from BIOS YH to 3R in the
KT7A-RAID. The processor is a Duron 800 not overclocked.

--
Roberto Jung Drebes <drebes@inf.ufrgs.br>
Porto Alegre, RS - Brasil
http://www.inf.ufrgs.br/~drebes/

Re: Duron kernel crash (i686 works)

[Liakakis Kostas]

On Tue, 11 Sep 2001, Roberto Jung Drebes wrote:

> As said earlier, this happens after upgrading from BIOS YH to 3R in the
> KT7A-RAID. The processor is a Duron 800 not overclocked.

What exactly did the new bios version change? 
Enabled STPGNT by any chance?

-K.

Re: Duron kernel crash (i686 works)

[Morten Helgesen]

The 3R BIOS includes the following changes :

1. Update BIOS code.
2. Enhance ISA PnP compatibility.
3. Enhance SCSI adapters compatibility.
4. Add 1400(133) Athlon support for KT7A/KT7A-RAID.
5. Add new option "1200 above" for high speed Athlons
   with 100FSB. KT7 / KT7-RAID / KT7A / KT7A-RAID / KT7E only support
   1.4G(100) Athlon with L1 bridges disconnected. Check L1 before
   you buy a CPU please!
6. For Creative SBLive 5.1 sound card users, you may try these
   options while experience sound quality issue.
   * PCI master read caching, default setting=Disabled
   * PCI master time-out, Default setting=1
   Setting above options to Disabled/3 will lead to the same result
   with VIA Latency patch V0.14 and may help SB Live 5.1 sound
   issue. If the system experiences low performance after these
   settings, enable the "PCI master read caching" please.
7. Enhance the high speed 133FSB Athlon stability for KT7A/KT7A-RAID.
8. HPT 370 RAID BIOS version 1.11.0402 for KT7-RAID/KT7A-RAID.
   This BIOS version is also for non RAID boards and HPT BIOS will
   be automatically disabled while RAID controller chip not detected.

I must admit that these specifications weren`t exactly the most technical I have
ever seen, but anyway ... taken from : http://fae.abit.com.tw/eng/download/bios/kt7.htm

On Wed, Sep 12, 2001 at 09:56:00AM +0300, Liakakis Kostas wrote:
> On Tue, 11 Sep 2001, Roberto Jung Drebes wrote:
> 
> > As said earlier, this happens after upgrading from BIOS YH to 3R in the
> > KT7A-RAID. The processor is a Duron 800 not overclocked.
> 
> What exactly did the new bios version change? 
> Enabled STPGNT by any chance?
> 
> -K.
> 
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/



== Morten

-- 
mvh
Morten Helgesen 
UNIX System Administrator & C Developer 
Nextframe AS
admin@nextframe.net / 93445641
http://www.nextframe.net