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 ?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
Url :
http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20100816/24e2ee71/attachment.pgp