Date: Tue, 17 Jun 2003 01:50:11 -0700 (PDT) From: Przemyslaw Frasunek <venglin@freebsd.lublin.pl> To: freebsd-i386@FreeBSD.org Subject: Re: i386/53382: Repetable panics in ffs_vget() on Proliant ML350 with SMP/HTT enabled Message-ID: <200306170850.h5H8oBke032811@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
The following reply was made to PR i386/53382; it has been noted by GNATS.
From: Przemyslaw Frasunek <venglin@freebsd.lublin.pl>
To: freebsd-gnats-submit@freebsd.org
Cc:
Subject: Re: i386/53382: Repetable panics in ffs_vget() on Proliant ML350
with SMP/HTT enabled
Date: Tue, 17 Jun 2003 10:42:42 +0200
Ok, this looks a little bit more mysterious. I had another one panic with
SMP disabled, after about 6 hours of heavy I/O activity. Bear in mind, that
all panics I had are null pointer dereferences.
IdlePTD at phsyical address 0x00327000
initial pcb at physical address 0x0029a560
panicstr: page fault
panic messages:
---
Fatal trap 12: page fault while in kernel mode
fault virtual address = 0x18
fault code = supervisor write, page not present
instruction pointer = 0x8:0xc0210175
stack pointer = 0x10:0xff5bdc60
frame pointer = 0x10:0xff5bdc64
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 = 1092 (cp)
interrupt mask = none
trap number = 12
panic: page fault
syncing disks... 470 328 203 196 192 182 179 170 163 157 143 129 119 113
101 88 76 66 59 54 43 36 28 23 18 16 13 10 8 6 4 4
done
Uptime: 4h7m2s
xl0: reset didn't complete
xl1: reset didn't complete
dumping to dev #da/0x20001, offset 2097200
[...]
(kgdb) bt
#0 dumpsys () at ../../kern/kern_shutdown.c:487
#1 0xc0173ec7 in boot (howto=256) at ../../kern/kern_shutdown.c:316
#2 0xc01742ec in poweroff_wait (junk=0xc027036c, howto=-1071186289)
at ../../kern/kern_shutdown.c:595
#3 0xc02381ce in trap_fatal (frame=0xff5bdc20, eva=24)
at ../../i386/i386/trap.c:974
#4 0xc0237ea1 in trap_pfault (frame=0xff5bdc20, usermode=0, eva=24)
at ../../i386/i386/trap.c:867
#5 0xc0237a8b in trap (frame={tf_fs = -11468784, tf_es = -1070989296,
tf_ds = -1070989296, tf_edi = 1, tf_esi = 0, tf_ebp = -10757020,
tf_isp = -10757044, tf_ebx = 2, tf_edx = 0, tf_ecx = 1, tf_eax = 2,
tf_trapno = 12, tf_err = 2, tf_eip = -1071578763, tf_cs = 8,
tf_eflags = 66118, tf_esp = 2, tf_ss = -10756984})
at ../../i386/i386/trap.c:466
#6 0xc0210175 in _vm_object_allocate (type=2, size=1, object=0x0)
at ../../vm/vm_object.c:157
#7 0xc0210304 in vm_object_allocate (type=2, size=1)
at ../../vm/vm_object.c:240
#8 0xc0215759 in vnode_pager_alloc (handle=0xff676180, size=235, prot=0,
offset=0) at ../../vm/vnode_pager.c:145
#9 0xc019ef90 in vop_stdcreatevobject (ap=0xff5bdd74)
at ../../kern/vfs_default.c:539
#10 0xc019ec79 in vop_defaultop (ap=0xff5bdd74) at ../../kern/vfs_default.c:152
#11 0xc0206c09 in ufs_vnoperate (ap=0xff5bdd74)
at ../../ufs/ufs/ufs_vnops.c:2376
#12 0xc01a2d86 in vfs_object_create (vp=0xff676180, p=0xff51fc20,
cred=0xd9fb3180) at vnode_if.h:1383
#13 0xc019fa4a in namei (ndp=0xff5bded4) at ../../kern/vfs_lookup.c:171
#14 0xc01a830b in vn_open (ndp=0xff5bded4, fmode=1, cmode=0)
at ../../kern/vfs_vnops.c:138
#15 0xc01a4440 in open (p=0xff51fc20, uap=0xff5bdf80)
at ../../kern/vfs_syscalls.c:1028
#16 0xc02383f2 in syscall2 (frame={tf_fs = 47, tf_es = 47,
tf_ds = -1078001617, tf_edi = 134577114, tf_esi = 51,
tf_ebp = -1077937964, tf_isp = -10756140, tf_ebx = 1,
tf_edx = 134689024, tf_ecx = 2, tf_eax = 5, tf_trapno = 7, tf_err = 2,
tf_eip = 134531468, tf_cs = 31, tf_eflags = 659, tf_esp = -1077938024,
tf_ss = 47}) at ../../i386/i386/trap.c:1175
#17 0xc022c5d5 in Xint0x80_syscall ()
#18 0x8048a7d in ?? ()
#19 0x8048556 in ?? ()
#20 0x804813e in ?? ()
Then I tried to run GENERIC kernel instead of custom. It works OK (7 hours
of uptime). Even if I reenable SMP/HTT on GENERIC, it still works OK.
I've managed to prepare SMP-enabled config, that doesn't cause panics, but
I'm still not sure which particular option could introduce instability.
machine i386
cpu I686_CPU
ident KBWFW
maxusers 0
options INET
options INET6
options FFS
options FFS_ROOT
options SOFTUPDATES
options UFS_DIRHASH
options PROCFS
options COMPAT_43
options UCONSOLE
options USERCONFIG
options VISUAL_USERCONFIG
options SYSVSHM
options SYSVMSG
options SYSVSEM
options P1003_1B
options _KPOSIX_PRIORITY_SCHEDULING
options KBD_INSTALL_CDEV
options NO_F00F_HACK
options NMBCLUSTERS=32768
options IPSEC
options IPSEC_ESP
options MAXDSIZ="(1024*1024*1024)"
options MAXSSIZ="(1024*1024*1024)"
options DFLDSIZ="(1024*1024*1024)"
options IPFILTER
options IPFILTER_LOG
options IPFIREWALL
options DUMMYNET
options IPFIREWALL_DEFAULT_TO_ACCEPT
options ICMP_BANDLIM
options RANDOM_IP_ID
options SMP # Symmetric MultiProcessor Kernel
options APIC_IO # Symmetric (APIC) I/O
options HTT # HyperThreading Technology
device isa
device pci
device fdc0 at isa? port IO_FD1 irq 6 drq 2
device fd0 at fdc0 drive 0
device ata
device atadisk
device atapicd
options ATA_STATIC_ID
device ahc
device ciss
device scbus
device ch
device da
device sa
device cd
device pass
device pt
device ses
device atkbdc0 at isa? port IO_KBD
device atkbd0 at atkbdc? irq 1 flags 0x1
device vga0 at isa?
device sc0 at isa? flags 0x100
device npx0 at nexus? port IO_NPX irq 13
device miibus
device xl
device bge
pseudo-device loop
pseudo-device ether
pseudo-device pty
pseudo-device bpf
pseudo-device gif
--
* Fido: 2:480/124 ** WWW: http://www.frasunek.com/ ** NIC-HDL: PMF9-RIPE *
* Inet: przemyslaw@frasunek.com ** keyId: 2578FCAD | C0613BE3 | EC78FAB5 *
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200306170850.h5H8oBke032811>