Date: Wed, 27 Mar 2002 18:05:52 -0800 From: "Jin Guojun[ITG]" <j_guojun@lbl.gov> To: David Bogen <db@bogen.org> Cc: hardware@FreeBSD.ORG Subject: Re: 4.5-RELEASE and AMD K6-2 not playing nice together Message-ID: <3CA27A80.BC3D136@lbl.gov> References: <3CA26C23.1040906@bogen.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Copyright (c) 1992-2002 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
The Regents of the University of California. All rights reserved.
FreeBSD 4.5-RELEASE #0: Thu Feb 7 16:33:35 PST 2002
root@spode.pacbell.net:/usr/src/sys/compile/MinMax
Timecounter "i8254" frequency 1193182 Hz
CPU: AMD-K6(tm) 3D+ Processor (420.00-MHz 586-class CPU)
Origin = "AuthenticAMD" Id = 0x591 Stepping = 1
Features=0x8021bf<FPU,VME,DE,PSE,TSC,MSR,MCE,CX8,PGE,MMX>
AMD Features=0x80000800<SYSCALL,3DNow!>
real memory = 134201344 (131056K bytes)
avail memory = 125943808 (122992K bytes)
Preloaded elf kernel "kernel" at 0xc0490000.
K6-family MTRR support enabled (2 registers)
md0: Malloc disk
I am writting this email from a AMD-K2 400 MHz box that runs 4.5 since
Feb. 7, 2002. Also, notice that this machine is overclocked to 420MHz.
I have many AMD boxes, and not one had problem with 4.5-RELEASE.
From your coredump, it seems that you had random memory page missing.
This usually means that there is memory related problem on your hardware.
Also, there was an earlier released 4.5 (three days prior to the formal
release) that contains such problem I have verified. I did diff between
that release and the formal release, and many files were different, but
I doubt you have that version.
So, make world is a possible way to verify this problem under FreeBSD.
If you can finish "make world", it normally can demostrate your system
is healthy ( not 100% guarantee, but it is a good to detect memory
problem ).
Helpfullly, this helps,
-Jin
David Bogen wrote:
>
> Until last evening, one of my home PCs had been running 4.3-STABLE.
> Before that, this PC ran nearly every RELEASE and/or STABLE from 3.4
> forward. The system was rock solid and --never-- crashed.
>
> Last night I made the mistake of "upgrading" to 4.5-RELEASE-p2. Since
> that upgrade, the system has kernel paniced no less than six times in
> eighteen hours. I can almost make the system crash at will by
> attempting to rebuild the ports index, though once the system paniced
> while rebuilding a kernel. I've rebuilt the kernel no less than 4 times
> to try eliminate any kernel compilation problems and to compile in
> debugging symbols.
>
> The system in question has an AMD K6-2 350Mgz, 64MB RAM, and 384MB swap.
>
> The crashes my AMD system is experiencing seem to be centered around the
> VM subsystem, if gdb and backtraces can be believed.
>
> My work system (1.6Mhz PIV, 256MB RAM) runs the exact same release of
> FreeBSD without a problem.
>
> Looking back in the archives of this list, it seems there was a question
> of whether or not an AMD K6-2 could reliably run 4.5-RELEASE.
>
> http://www.freebsd.org/cgi/getmsg.cgi?fetch=34976+36926+/usr/local/www/db/text/2002/freebsd-hardware/20020210.freebsd-hardware
>
> Is anyone else seeing this problem?
>
> ==========================================================================
>
> Fatal trap 12: page fault while in kernel mode
> fault virtual address = 0x13
> fault code = supervisor read, page not present
> instruction pointer = 0x8:0xc02212a8
> stack pointer = 0x10:0xc62acc38
> frame pointer = 0x10:0xc62acc40
> code segment = base 0x0, limit 0xfffff, type 0x1b
> = DPL 0, pres 1, def32 1, gran 1
> processor eflags = interrupt enabled, resume, IOPL = 0
> current process = 18919 (sh)
> interrupt mask = net bio cam
> trap number = 12
> panic: page fault
>
> syncing disks... 132 132 132 132 132 132 132 132 132 132 132 132 132 132
> 132 132 132 132 132 132
> giving up on 127 buffers
> Uptime: 13m50s
>
> dumping to dev #ad/0x20001, offset 393216
> dump ata0: resetting devices .. done
> 64 63 62 61 60 59 58 57 56 55 54 53 52 51 50 49 48 47 46 45 44 43 42 41
> 40 39 38 37 36 35 34 33 32 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17
> 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1
> ---
> #0 dumpsys () at ../../kern/kern_shutdown.c:474
> 474 if (dumping++) {
> (kgdb) bt
> #0 dumpsys () at ../../kern/kern_shutdown.c:474
> #1 0xc014a0b3 in boot (howto=256) at ../../kern/kern_shutdown.c:313
> #2 0xc014a4ad in panic (fmt=0xc029c1ec "%s") at
> ../../kern/kern_shutdown.c:582
> #3 0xc025a55b in trap_fatal (frame=0xc62acbf8, eva=19)
> at ../../i386/i386/trap.c:956
> #4 0xc025a209 in trap_pfault (frame=0xc62acbf8, usermode=0, eva=19)
> at ../../i386/i386/trap.c:849
> #5 0xc0259d83 in trap (frame={tf_fs = 16, tf_es = 16, tf_ds = 16,
> tf_edi = -968894304, tf_esi = 0, tf_ebp = -970273728,
> tf_isp = -970273756, tf_ebx = -968894304, tf_edx = -1, tf_ecx =
> 1833400,
> tf_eax = 25336, tf_trapno = 12, tf_err = 0, tf_eip = -1071508824,
> tf_cs = 8, tf_eflags = 66182, tf_esp = -1068627960, tf_ss =
> -969371904})
> at ../../i386/i386/trap.c:448
> #6 0xc02212a8 in vm_page_lookup (object=0xc63fd8a0, pindex=0)
> at ../../vm/vm_page.c:516
> #7 0xc022025e in vm_object_collapse (object=0xc63fd8a0)
> at ../../vm/vm_object.c:1137
> #8 0xc021f66c in vm_object_deallocate (object=0xc6431c60)
> at ../../vm/vm_object.c:356
> #9 0xc021cacb in vm_map_entry_delete (map=0xc623de80, entry=0xc628b180)
> at ../../vm/vm_map.c:1823
> #10 0xc021cc4d in vm_map_delete (map=0xc623de80, start=0, end=3217031168)
> at ../../vm/vm_map.c:1926
> #11 0xc021ccda in vm_map_remove (map=0xc623de80, start=0, end=3217031168)
> at ../../vm/vm_map.c:1951
> #12 0xc0141fe7 in exec_new_vmspace ()
> #13 0xc013865d in exec_elf_imgact ()
> #14 0xc0141828 in execve ()
> #15 0xc025a811 in syscall2 (frame={tf_fs = 47, tf_es = 47, tf_ds = 47,
> tf_edi = 134992304, tf_esi = 0, tf_ebp = -1077938156,
> tf_isp = -970272812, tf_ebx = 134992332, tf_edx = 134992332,
> tf_ecx = 134992431, tf_eax = 59, tf_trapno = 12, tf_err = 2,
> tf_eip = 134705924, tf_cs = 31, tf_eflags = 659, tf_esp =
> -1077938200,
> tf_ss = 47}) at ../../i386/i386/trap.c:1157
> #16 0xc024b735 in Xint0x80_syscall ()
> Cannot access memory at address 0xbfbff814.
> (kgdb)
>
> ==========================================================================
>
> Fatal trap 12: page fault while in kernel mode
> fault virtual address = 0x80b3898
> fault code = supervisor read, page not present
> instruction pointer = 0x8:0xc0257cee
> stack pointer = 0x10:0xc6438c6c
> frame pointer = 0x10:0xc6438c88
> code segment = base 0x0, limit 0xfffff, type 0x1b
> = DPL 0, pres 1, def32 1, gran 1
> processor eflags = interrupt enabled, resume, IOPL = 0
> current process = 36481 (sh)
> interrupt mask = none
> trap number = 12
> panic: page fault
>
> syncing disks... 130 130 130 129 129 129 128 126 125 123 123 123 123 123
> 122 122 122 121 121 121 120 119 119 118 118 118 116 116 114 114 113 112
> 110 109 107 107 107 107 106 103 103 102 102 101 97 97 96 95 95 94 94 91
> 91 91 90 90 90 89 88 88 88 87 87 87 85 85 85 83 83 83 82 82 82 80 80 79
> 76 76 74 74 73 73 72 72 70 70 70 69 69 69 68 66 64 64 61 61 61 60 60 59
> 58 58 58 57 57 57 56 56 56 53 53 52 51 51 50 50 49 48 46 46 46 45 45 42
> 42 40 40 40 38 37 35 35 34 34 32 31 31 29 28 28 27 27 26 24 24 24 24 23
> 23 23 22 22 22 21 20 19 19 18 18 18 17 16 16 14 13 13 12 11 11 11 8 7 5
> 5 5 4 4 3 3 3 3 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1
> giving up on 1 buffers
> Uptime: 41m49s
>
> dumping to dev #ad/0x20001, offset 393216
> dump ata0: resetting devices .. done
> 64 63 62 61 60 59 58 57 56 55 54 53 52 51 50 49 48 47 46 45 44 43 42 41
> 40 39 38 37 36 35 34 33 32 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17
> 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1
> ---
> #0 dumpsys () at ../../kern/kern_shutdown.c:474
> 474 if (dumping++) {
> (kgdb) bt
> #0 dumpsys () at ../../kern/kern_shutdown.c:474
> #1 0xc014a0b3 in boot (howto=256) at ../../kern/kern_shutdown.c:313
> #2 0xc014a4ad in panic (fmt=0xc029c1ec "%s") at
> ../../kern/kern_shutdown.c:582
> #3 0xc025a55b in trap_fatal (frame=0xc6438c2c, eva=134953112)
> at ../../i386/i386/trap.c:956
> #4 0xc025a209 in trap_pfault (frame=0xc6438c2c, usermode=0, eva=134953112)
> at ../../i386/i386/trap.c:849
> #5 0xc0259d83 in trap (frame={tf_fs = 16, tf_es = 16, tf_ds = 16,
> tf_edi = 46, tf_esi = 0, tf_ebp = -968651640, tf_isp = -968651688,
> tf_ebx = 134953088, tf_edx = -970489300, tf_ecx = 0, tf_eax = -2,
> tf_trapno = 12, tf_err = 0, tf_eip = -1071285010, tf_cs = 8,
> tf_eflags = 66050, tf_esp = -970489408, tf_ss = -970489408})
> at ../../i386/i386/trap.c:448
> #6 0xc0257cee in pmap_object_init_pt ()
> #7 0xc021b624 in vm_map_insert (map=0xc62781c0, object=0xc622bb40,
> offset=0,
> start=134512640, end=134701056, prot=5 '\005', max=7 '\a', cow=10)
> at ../../vm/vm_map.c:612
> #8 0xc01380e1 in elf_load_section ()
> #9 0xc0138709 in exec_elf_imgact ()
> #10 0xc0141828 in execve ()
> #11 0xc025a811 in syscall2 (frame={tf_fs = 47, tf_es = 47, tf_ds = 47,
> tf_edi = 135016784, tf_esi = -1, tf_ebp = -1077937856,
> tf_isp = -968650796, tf_ebx = 135016660, tf_edx = 135016800,
> tf_ecx = 135016793, tf_eax = 59, tf_trapno = 12, tf_err = 2,
> tf_eip = 134705924, tf_cs = 31, tf_eflags = 663, tf_esp =
> -1077937900,
> tf_ss = 47}) at ../../i386/i386/trap.c:1157
> #12 0xc024b735 in Xint0x80_syscall ()
> Cannot access memory at address 0xbfbff940.
>
> To Unsubscribe: send mail to majordomo@FreeBSD.org
> with "unsubscribe freebsd-hardware" in the body of the message
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hardware" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3CA27A80.BC3D136>