On Mon, Aug 16, 2010 at 07:15:16PM +0400, Alexey Tarasov wrote: > Hello. > > I have a couple of Supermicro servers which got the similar kernel panic with > all FreeBSD versions I tried since 6.4. > Now I want to investigate into the problem. > The servers get into panic with similar workload: file server with a lot of > files and connections. Web server software is nginx. File system is > UFS+GJOURNAL. Outgoing traffic on each server is ~10 MB/s. > I think it is not software problem, because when I've installed Linux with > such configuration there were no kernel panics. > > Here is the short overview of the hardware: > > CPU: Intel(R) Pentium(R) 4 CPU 3.00GHz (2992.51-MHz K8-class CPU) > Origin = "GenuineIntel" Id = 0xf65 Family = f Model = 6 Stepping = 5 > > Features=0xbfebfbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE> > Features2=0xe59d<SSE3,DTES64,MON,DS_CPL,EST,TM2,CNXT-ID,CX16,xTPR,PDCM> > AMD Features=0x20100800<SYSCALL,NX,LM> > AMD Features2=0x1<LAHF> > TSC: P-state invariant > real memory = 2147483648 (2048 MB) > avail memory = 2054619136 (1959 MB) > > DMESG: http://lexasoft.ru/m/dmesg.txt > > CORE: http://lexasoft.ru/m/core.txt > > Fatal trap 1: privileged instruction fault while in kernel mode > cpuid = 1; apic id = 01 > instruction pointer = 0x20:0xffffff8040d2cc83 > stack pointer = 0x28:0xffffff8040d2ca80 > frame pointer = 0x28:0xffffff0060c0b740 > code segment = base 0x0, limit 0xfffff, type 0x1b > = DPL 0, pres 1, long 1, def32 0, gran 1 > processor eflags = interrupt enabled, resume, IOPL = 0 > current process = 9388 (nginx) > trap number = 1 > panic: privileged instruction fault > cpuid = 1 > Uptime: 17d15h48m49s > Physical memory: 2032 MB > Dumping 1485 MB: 1470 1454 1438 1422 1406 1390 1374 1358 1342 1326 1310 1294 > 1278 1262 1246 1230 1214 1198 1182 1166 1150 1134 1118 1102 1086 1070 1054 > 1038 1022 1006 990 974 958 942 926 910 894 878 862 846 830 814 798 782 766 > 750 734 718 702 686 670 654 638 622 606 590 574 558 542 526 510 494 478 462 > 446 430 414 398 382 366 350 334 318 302 286 270 254 238 222 206 190 174 158 > 142 126 110 94 78 62 46 30 14 > > > (kgdb) #0 doadump () at pcpu.h:223 > #1 0xffffffff80590c59 in boot (howto=260) > at /usr/src/sys/kern/kern_shutdown.c:416 > #2 0xffffffff8059108c in panic (fmt=0xffffffff80951fc4 "%s") > at /usr/src/sys/kern/kern_shutdown.c:579 > #3 0xffffffff80878fd8 in trap_fatal (frame=0xffffff0060c0b740, eva=Variable > "eva" is not available. > ) > at /usr/src/sys/amd64/amd64/trap.c:857 > #4 0xffffffff808799ea in trap (frame=0xffffff8040d2c9d0) > at /usr/src/sys/amd64/amd64/trap.c:644 > #5 0xffffffff8085f983 in calltrap () > at /usr/src/sys/amd64/amd64/exception.S:224 > #6 0xffffff8040d2cc83 in ?? () > #7 0xffffff8040d2cb50 in ?? () > #8 0xffffff8040d2caf0 in ?? () > #9 0xffffff8040d2cbf0 in ?? () > #10 0xffffff0060c0b740 in ?? () > #11 0xffffffff80b83c60 in sysent () > #12 0xffffff8040d2cc80 in ?? () > #13 0xffffff8040d2cae0 in ?? () > #14 0xffffffff8059c431 in bintime (bt=0xffffffff80ad3140) > at /usr/src/sys/kern/kern_tc.c:200 > Previous frame inner to this frame (corrupt stack?) > (kgdb) The backtrace make absolutely no sense. I would not trust kgdb anyway.
Compile ddb in and do backtrace in console on the panic. Also, disassemble the kernel at the fault address. I am very curious which instruction causes this. This is stock GENERIC on the bare metal booted, right ?
pgp0KYiAf9rFf.pgp
Description: PGP signature
